Giters

anatol / booster

Fast and secure initramfs generator

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

booster fails when loading microcode image first

basploeger opened this issue · comments

commented

I am using Void Linux and have a microcode image file next to the booster initramfs like so:

/boot/intel-ucode.img
/boot/initramfs-6.6.11_1.img

grub-mkconfig automatically picks up the microcode image and generates lines like this in /boot/grub/grub.cfg:

initrd	/intel-ucode.img /initramfs-6.6.11_1.img

This should be a supported way of early loading CPU microcode before loading the initramfs. However, booster's init fails with exit code 71 and a message to press enter to reboot.

See also here for background information.

commented

Grub+Booster certainly works on Void, e.g. see report here #29 (comment)

One way to debug your problem is to enable the booster debug logs and share it with us.

commented

I can confirm that Grub+Booster works on Void. It's the addition of the intel-ucode.img that triggers some bug in booster's init process.

I did a bunch of tests. The setup: I copied the standard Void Linux boot entry in /boot/grub/grub.cfg, then changed the initrd line to add the intel-ucode image, i.e.: initrd /intel-ucode.img /initramfs-6.6.11_1.img. Then I added various kernel command line arguments in the same entry:

  • If I add nothing, or add booster.log=debug or booster.log=error,console the error is triggered. All I can do is reboot. Sample screen output: 
     [   3.772648] booster: exit status 71:
 Press ENTER to reboot
  • If I add booster.log=debug,console or booster.log=info,console then it works. I get no error and the system boots normally.

I am not sure what this means. It seems the failure is somehow "bypassed" if (1) logging to console is enabled and (2) booster actually logs some message to the console (i.e. logs are not empty). Note that in the case of booster.log=error,console nothing gets logged (because apparently there are no errors).

How can I share the logs with you in the failure case? All I can do at that point is reboot the laptop, after which the logs are lost, right?

commented

The plot thickens.

If I disable vconsole in /etc/booster.yaml then all of the error cases above start working! So there's something fishy going on in combination with the vconsole. (And this fishiness can be avoided by logging stuff to it...).

For completeness, here are my configs:

/etc/booster.yaml

busybox: true
vconsole: false
enable_lvm: true

/etc/vconsole.conf

FONT=ter-u32n
KEYMAP=us

(Note that on Void console fonts are not configured in /etc/vconsole.conf but in /etc/rc.conf. I created /etc/vconsole.conf purely for booster.)

commented

It sounds like #234 then. See that issue, there was some debugging done there but not completely resolved yet.