Hi,

I've just built a netboot-gtk mini.iso against unstable, including the
new kernel. A regular “almost all defaults” (except French to check
things like translations, keymap fun, etc.) install on UEFI gave an
overall successful installation according to d-i, but it doesn't boot:

Verifying shim SBAT data failed: Security Policy Violation

It's been a while since I last toyed with unstable, so I'm not sure
whether this is known already, where it's coming from, etc. Even when
built against unstable, d-i installs testing, so that shouldn't be
linked to the new Linux version running the installer, as what ends up
on disk is testing's version.

This is the exact same test setup as for (old)stable point release
preps, with qemu/bookworm running on a bookworm system.

kvm -m 1G -machine q35,smm=on -pflash /tmp/1/code.fd -pflash /tmp/1/vars.fd -hda /tmp/1/sda.img

with both pflash files initialized from those respectively:

- /usr/share/OVMF/OVMF_CODE_4M.ms.fd
- /usr/share/OVMF/OVMF_VARS_4M.ms.fd

Wild guess: Maybe ovmf would need to ship refreshed files?

Can't investigate more right now, live stream and travel are next.


Cheers,
--
Cyril Brulebois (kibi@debian.org) <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEtg6/KYRFPHDXTPR4/5FK8MKzVSAFAmZ+hzUACgkQ/5FK8MKz VSDaCRAAjc8+OuCaYbwM2yAr/zfkJiSF5AIpy6Y0j2jniNmW30rHuysErwRE0Eq+ arjGvOHI5B+rLG9OEJ+DM1U/v+2H2gZjdYJSXfvSRRURFhJCO2D8PO235wHM9YEI vWewT+/vqekyz44P+PXEKzLcvfyMjVVokXWgbxUP34GjlBsXaqO1yBPDanIbZaxh Rh2yVPmPn/8WCH1yyTPE51QLN6Cfrl+sE53ZB+u3UcF507W9Id6/AVRJcutmUrHu ZVPIpy3YXvG+huNXZf/gBaWYnMBFEGXlyJCZekfb0aLbXTLd97XG7D2NL4SndDjo ewJ2O7mUd80QB9vXPK0mXRKa8mySH7d/7knQr5GTvrM0FdsVfZTIep8crj1AixTv yeLUw5XagxekhstMTg5Wtr25stOPs+0p/nrxMAoLxBbf5g55HdjrNPsHWgbs7I6g KfpDfr44qXFrM20mN88qSdQg9Pk2IobASTrYYyJqjvFj0bQhcvmT3VyCAWYBN3au YBiYzyT8Xt9nJSm+3x53TcPqAM2zY+Q2z28uLpXkYX5gOBas748OAoWcorpgHhRZ I+1pYQnr8b199vJG+VQyQVxuCVvIgN0XC8BswZK8PIASypQij1tTAIGkOihPgx1a g5G8V5PiF+h60Mf9ukzNFCkz0qWKDMK2ERH8jzPm2QEp3Fpbvqw=
=4eaS
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
*

On Fri, Jun 28, 2024 at 11:49:44AM +0200, Cyril Brulebois wrote:

Hi,

I've just built a netboot-gtk mini.iso against unstable, including the
new kernel. A regular “almost all defaults” (except French to check >things like translations, keymap fun, etc.) install on UEFI gave an
overall successful installation according to d-i, but it doesn't boot:

Verifying shim SBAT data failed: Security Policy Violation

It's been a while since I last toyed with unstable, so I'm not sure
whether this is known already, where it's coming from, etc. Even when
built against unstable, d-i installs testing, so that shouldn't be
linked to the new Linux version running the installer, as what ends up
on disk is testing's version.

This is the exact same test setup as for (old)stable point release
preps, with qemu/bookworm running on a bookworm system.

kvm -m 1G -machine q35,smm=on -pflash /tmp/1/code.fd -pflash /tmp/1/vars.fd -hda /tmp/1/sda.img

with both pflash files initialized from those respectively:

- /usr/share/OVMF/OVMF_CODE_4M.ms.fd
- /usr/share/OVMF/OVMF_VARS_4M.ms.fd

Wild guess: Maybe ovmf would need to ship refreshed files?

Can't investigate more right now, live stream and travel are next.

Hmmm. Taking a look...

--
Steve McIntyre, Cambridge, UK. steve@einval.com The two hard things in computing:
* naming things
* cache invalidation
* off-by-one errors -- Stig Sandbeck Mathisen

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Cyril Brulebois <kibi@debian.org> (2024-06-28):

I've just built a netboot-gtk mini.iso against unstable, including the
new kernel. A regular “almost all defaults” (except French to check things like translations, keymap fun, etc.) install on UEFI gave an
overall successful installation according to d-i, but it doesn't boot:

Verifying shim SBAT data failed: Security Policy Violation

It's been a while since I last toyed with unstable, so I'm not sure
whether this is known already, where it's coming from, etc. Even when
built against unstable, d-i installs testing, so that shouldn't be
linked to the new Linux version running the installer, as what ends up
on disk is testing's version.

I tried to hack my way into reverting to the previous kernel, and
merging testing's kernel udebs into an otherwise unstable repository and pointing d-i at it (much like I'm doing for (old)stable-proposed-updates
and (old)stable for point release preps) but for some reason the mirror/udeb/http/hostname parameter pointing to it was seen on the
kernel cmdline, passed to userspace, parsed into an env var, but wasn't
used later on, leading to missing modules.

Rebuilding the installer fully against testing, I'm able to replicate
the SBAT issue.

This is the exact same test setup as for (old)stable point release
preps, with qemu/bookworm running on a bookworm system.

kvm -m 1G -machine q35,smm=on -pflash /tmp/1/code.fd -pflash /tmp/1/vars.fd -hda /tmp/1/sda.img

with both pflash files initialized from those respectively:

- /usr/share/OVMF/OVMF_CODE_4M.ms.fd
- /usr/share/OVMF/OVMF_VARS_4M.ms.fd

All that is still true.

Wild guess: Maybe ovmf would need to ship refreshed files?

I suppose this wouldn't explain everything as we're able to boot the
installer, but not the installed system…

Could this be something about version mismatches between shim in
unstable and in testing instead?

(Even wilder guesses, I'm totally off-base here.)

Can't investigate more right now, live stream and travel are next.

I really should stop here.


Cheers,
--
Cyril Brulebois (kibi@debian.org) <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEtg6/KYRFPHDXTPR4/5FK8MKzVSAFAmZ+leoACgkQ/5FK8MKz VSDF4Q//YPuIa6GdFKa4gaySty7MtgI2WJIystN3iMbypL1ySdLejCxQjAXBsnrD 7+agakOnA5a/UZoxICMNVX0Q77KvMljkJnlAoTR78IAU+HpjwbMXUvMKMI7uGrxd f/ymAgP7s7toswsEdAdNZKHACMq82PoisvhHFn43qxF58MMOLr0R9g/SI7rTTsSN N63+oFxzK0I0Vd4mWSEh8YMX+wQgZIanr+qwTNdnpv+bCUWCVOKxh8YBKuAO58dP O1mH7LqoTSdP+gATTwYY/vBluAhG4Lmk7+rL+I+46c0sgFF+n89+LQGdc8u4dJ5e WFDBSpKDr3rzoSvcwmXGoZ3Zz6RfPXgQFIov1nZPZfiIAAtL781bGwNMC4nEhSJx 4I6f5Q5eXpoJ1p3CWDIeZpyt6IFskToXhQ+gwgCzAqOsZEsIGtNKCjihPYzO47Jh Oork1Uy7MYYW0tYipcpeQRAh4SkeSKnPhCxQH4m8EMBt2cyvVzpSvLLLMAAZ0XP+ Qup//3A6U81cuywwMzvuU5EnpuDX1qyriL+fD4/q5KIgtZcRmWwSCY8uXwBccwmD 9ElEmra9wqfRf/mgcwZYomp7wQ2aEggZMUUJXaFfnQiwk8Eio7z/2pUfWyzi8LTq 1e67Gr4qGCehELgKmVddRnRaCraPmaozjUKlGt11rAuuvRoFepU=
=sjUk
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
*

On 03/07/2024 at 08:13, Roland Clobus wrote:

Who can find out which part in this file is causing the issue? Or which
tools do I need to use to debug this?

Maybe increase shim verbosity with

# mokutil --set-verbosity true

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)