EFI Stub

[julie-de-ville]

Hello,

I am on my second build, and this time I am using ugrd with an EFI stub instead of grub, and a distribution kernel to speed things up. After installing the kernel, I manually ran ugrd, but it looks like it had problems loading the btrfs module, as I got this error

Auto-enabling module: btrfs
INFO     | Processing module: ugrd.fs.btrfs
WARNING  | Ignored kernel modules: dm_mod, btrfs
WARNING  | 'cryptsetup_prompt' is disabled, if the 'quiet' kernel parameter is not set, the prompt may be hidden under log me
ssages at runtime.

So when I boot, it loads the efi executable and the kernel, but it does not prompt for decryption, and instead gives these messages:

EFI stub: WARNING: Failed to measure data for event 1: 0x80000000000000b
EFI stub: WARNING: Command line is too long: truncated to 2043 bytes
EFI stub: WARNING: Loaded initrd from command line option

Given the earlier error, I tried typing my passphrase anyway, but nothing happens. I am using the default uefi-mkconfig config file.

[desultory]

EFI stub: WARNING: Command line is too long: truncated to 2043 bytes

What is your command line? you should be able to see it if you use a livecd and efibootmgr -u, I think it's an issue with your efi cmdline. All you need is initrd=your-microcode-image initrd=initramfs-your-kernel-version when using ugrd.

[julie-de-ville]

Figured that might be the issue, I'll try that. Thanks!

[julie-de-ville]

I added the cmdline, and it loads the initramfs and prompts for decryption now, but after entering my passphrase, it hangs indefinitely.

[desultory]

I added the cmdline, and it loads the initramfs and prompts for decryption now, but after entering my passphrase, it hangs indefinitely.

Are you using the latest stable version (1.22.0)?

Auto-enabling module: btrfs
INFO     | Processing module: ugrd.fs.btrfs
WARNING  | Ignored kernel modules: dm_mod, btrfs
WARNING  | 'cryptsetup_prompt' is disabled, if the 'quiet' kernel parameter is not set, the prompt may be hidden under log me
ssages at runtime.

This output makes me think you're on a later version, which should still work, but it "ignores" btrfs because it detects it as builtin, the result of that is that it doesn't needlessly modprobe it, but it should be fine.

If you add debug to the kernel command line it should say more, and the recovery arg should give you a shell if it fails. There shouldn't be any portions of ugrd which should hang. It should print either a success/fail message, then print the output of btrfs device scan after it successfully opens a device.

[julie-de-ville]

Thanks. It is still hanging, but I enabled "quiet" this time to see whether the cursor moves upon pressing "enter," and it does not. I think it might be an input problem, but I can't figure out why, because my keyboard works for bios and on grub on the bootable drive I am using. When I did not have 'quiet' enabled, it showed the keyboard as being detected and identified.

Note, the installation is not fully completed, I am at the end of the Kernel Configuration section of the Gentoo handbook, and I have had trouble booting in the past so I decided to test it out before proceeding.

[desultory]

Thanks. It is still hanging, but I enabled "quiet" this time to see whether the cursor moves upon pressing "enter," and it does not. I think it might be an input problem, but I can't figure out why, because my keyboard works for bios and on grub on the bootable drive I am using. When I did not have 'quiet' enabled, it showed the keyboard as being detected and identified.

Note, the installation is not fully completed, I am at the end of the Kernel Configuration section of the Gentoo handbook, and I have had trouble booting in the past so I decided to test it out before proceeding.

You shouldn't really need to install that much for it to at least boot through the initramfs. ugrd will raise exceptions if you're missing stuff like cryptsetup and btrfs binaries. You should also see it move the cursor when you press enter. Did you let installkernel generate the initramfs for you? Have you tried using the latest stable version? You seem to be on a testing version. If you want to try a testing version, you can try the latest dev branch, there may be bugs in 1.25.0

Other than ensuring you're using a stable release, it may be worth trying to press control d, control c, or enter an empty password. If cryptsetup can't open the device you should see some warning messages.

[julie-de-ville]

I did the first time, but working through the past few errors, I have just been generating using the 'ugrd' command, and if needed, uefi-mkconfig. I will try with the latest stable, and installkernel.

[desultory]

An easy way to re-run installkernel is to run emerge --config gentoo-kernel-bin or whichever kernel package you're using.

If you're running it manually, are you passing any args in addition to --kver?

[julie-de-ville]

Nope, just kver

[desultory]

another option would be to use -m ugrd.base.debug to include the debug module, which should give you a shell near the start of it running. You can use that to confirm input works and do stuff like try cryptsetup manually.

[julie-de-ville]

I'll try that as well. I just ran emerge --config, and same issue, but forgot to downgrade to the stable ugrd version.

[desultory]

were you able to test with the debug module or a downgraded version? The debug module can help in any case just to confirm input works and to get more verbose output from things.

[julie-de-ville]

I upgraded from 1.20 to 1.22, and with the debug module, input does not work, but I get these errors

bash : cannot set terminal process group (-1): Inappropriate ioctl for device
bash: no job control in this shell

[desultory]

I upgraded from 1.20 to 1.22, and with the debug module, input does not work, but I get these errors

bash : cannot set terminal process group (-1): Inappropriate ioctl for device
bash: no job control in this shell

That error should be fine, that is just what happens when you run bash directly as the init. Can you try reattaching the keyboard or attaching a different one? It should show kernel messages if it's recognized over USB. I think on dist-kernel, all required drivers for a keyboard should be builtin. Do you have strange hardware?

[julie-de-ville]

It's an old apple usb keyboard; I tried reattaching, and it shows the messages with no errors. I was wondering about compatibility though; it works with my bios, and with the live USB I am using for the install. Unfortunately, I don't have an alternative keyboard that I can use at the moment.

[desultory]

Do you have kmod_autodetect_lspci enabled? If so, you can try kmod_autodetect_lsmod but that will pull most kmods which are currently loaded. It could be some missing kmod.

[julie-de-ville]

Yeah, I tried both. Also tried rebuilding linux-firmware, and the kernel, but no luck. I think I am going to pick up a new keyboard to test, because at this point it seems like it could be that.

[desultory]

if the keyboard works in the livecd, it should work with dist-kernel. Can you share your lsmod output in the livecd?

[julie-de-ville]

I picked up a new keyboard and it works now. Thank you for your help!

[desultory]

I picked up a new keyboard and it works now. Thank you for your help!

Thanks for testing and confirming this, once booted does the older keyboard work? It would be nice if you could help identify what is required to use that, it may be something simple. It could be as simple as a missing kmod, but I'm still confused why it would how up in the kernel log but then not work.