| View previous topic :: View next topic |
| Author |
Message |
drumgod
n00b
Joined: 12 Dec 2003
Posts: 61
|
 Posted: Wed Oct 18, 2023 7:35 pm Post subject: [now un-solved] UEFI+UKI/initrd+LVM-raid1+systemd = confused |
 |
|
Per the current handbook, /efi = /dev/sda1 vfat. The root partition is LVM raid1... so I need an initrd.
I've been reading through the various wiki articles about all of the involved components but nothing seems to really cover this too well. Or perhaps I just don't understand it? In the past I've booted similar bios systems with grub and a kernel built with a (genkernel made) initrd specified in the kernel config. That results in a kernel installed in /boot, found with grub-mkconfig.
It seems I should be able to use UEFI to boot a uki image (without grub or systemd-boot), either with a separate or compiled in initrd, and added to efi with efibootmgr. From my reading it looks like dracut is the "best" way to generate/manage the uki/initrd.
Right now I have my kernel configured with a "Built-in kernel command line" (root=UUID=UUID-OF-LVM-RAID1) and inird support enabled but no source defined. With dracut installed I was expecting "make && make modules_install && make install" to build a kernel then call dracut which would build a uki/ramdisk and drop it in the correct place in /efi. Make install just wants, as usual, to drop a kernel in /boot. Running "dracut --host-only --kver 6.5.7" results in an initrd file at /efi/Default/6.5.7/initrd
What am I missing?
Can I make a kernel bzimage and drop it into the same directory as the initrd then combine/add it with a manual call to efibootmgr?
If not, how do I generate and install the kernel itself?
Is there a correct/better way to do this?
Thanks guys.
Last edited by drumgod on Thu Feb 01, 2024 5:01 pm; edited 2 times in total |
|
| Back to top |
|
 |
GDH-gentoo
Veteran
Joined: 20 Jul 2019
Posts: 1730
Location: South America
|
| Posted: Wed Oct 18, 2023 8:15 pm Post subject: |
|
|
Does this help?
_________________
| NeddySeagoon wrote: | I'm not a witch, I'm a retired electronics engineer  |
| Ionen wrote: | | As a packager I just don't want things to get messier with weird build systems and multiple toolchains requirements though |
|
|
| Back to top |
|
|
drumgod
n00b
Joined: 12 Dec 2003
Posts: 61
|
| Posted: Thu Oct 19, 2023 11:29 am Post subject: |
|
|
Thanks GDH. I did see that thread and bookmarked an earlier post for if I want to try using systemd-boot. Unfortunately, after running dracut, there is no "/usr/src/linux/arch/x86/boot/uki.efi" or any other files with the .efi extension in the kernel tree, just the previously mentioned initrd dracut placed in "/efi/Default/6.5.7/". |
|
| Back to top |
|
|
drumgod
n00b
Joined: 12 Dec 2003
Posts: 61
|
| Posted: Thu Oct 19, 2023 11:46 am Post subject: |
|
|
Maybe I need to change something in the dracut config files? They are currently untouched.
Current EFI settings in the kernel .config:
| Code: | CONFIG_EFI=y
CONFIG_EFI_STUB=y
CONFIG_EFI_HANDOVER_PROTOCOL=y
CONFIG_EFI_MIXED=y
# CONFIG_EFI_FAKE_MEMMAP is not set
CONFIG_EFI_RUNTIME_MAP=y
CONFIG_EFI_PARTITION=y
CONFIG_DMI_SCAN_MACHINE_NON_EFI_FALLBACK=y
# EFI (Extensible Firmware Interface) Support
CONFIG_EFI_ESRT=y
CONFIG_EFI_DXE_MEM_ATTRIBUTES=y
CONFIG_EFI_RUNTIME_WRAPPERS=y
# CONFIG_EFI_BOOTLOADER_CONTROL is not set
# CONFIG_EFI_CAPSULE_LOADER is not set
# CONFIG_EFI_TEST is not set
# CONFIG_EFI_RCI2_TABLE is not set
# CONFIG_EFI_DISABLE_PCI_DMA is not set
CONFIG_EFI_EARLYCON=y
CONFIG_EFI_CUSTOM_SSDT_OVERLAYS=y
# CONFIG_EFI_DISABLE_RUNTIME is not set
# CONFIG_EFI_COCO_SECRET is not set
# end of EFI (Extensible Firmware Interface) Support
CONFIG_FB_EFI=y
CONFIG_EFIVAR_FS=y
# CONFIG_EFI_PGT_DUMP is not set |
[Moderator edit: added [code] tags to preserve output layout. -Hu] |
|
| Back to top |
|
|
drumgod
n00b
Joined: 12 Dec 2003
Posts: 61
|
| Posted: Thu Oct 19, 2023 1:36 pm Post subject: |
|
|
Progress?
"dracut --uefi --kernel-source /usr/src/linux/arch/x86/boot/compressed/vmlinux --host-only --kver 6.5.7" produces "/efi/EFI/Linux/linux-6.5.7-Default.efi"
That looks more promising... No initrd is produced though. Is it built into the .efi image? |
|
| Back to top |
|
|
drumgod
n00b
Joined: 12 Dec 2003
Posts: 61
|
| Posted: Tue Oct 24, 2023 5:27 pm Post subject: |
|
|
Well, I suppose I should mark this "solved" but this seems to be a tmtowtdi thing... This is what I ended up doing:
Build the kernel and install in the default location /boot:
| Code: | | make && make modules_install && make install |
Use dracut to make the efi kernel (with seemingly integrated initrd) and place it in /efi/EFI/Linux/linux-<kver>-<machine id>.efi:
| Code: | | dracut --uefi --host-only --kver <kver> |
Use efibootmgr to add the new boot entry:
| Code: | | efibootmgr -c -d /dev/sda -p 1 -L "Linux <kver>" -l "\EFI\Linux\linux-<kver>-<machine id>.efi" |
Truthfully, I can't say if this is the "correct" way to do things. It does however work. I decided to keep the default /boot directory installation step to keep track of kernels and configs and because it's the default location for dracut to look. At some point I may look into systemd-boot as it looks like this would make kernel maintenance easier and more automated...
Thanks guys. |
|
| Back to top |
|
|
drumgod
n00b
Joined: 12 Dec 2003
Posts: 61
|
| Posted: Thu Feb 01, 2024 4:59 pm Post subject: Un-solved... |
|
|
Well, this no longer works. After an "emerge -1uDNvp world" behavior has changed significantly...
Systemd has the useflags "gnuefi boot". I'm not using systemd-boot but the "boot" flag seems to be needed to get the stub that dracut needs to create UKIs.
The last news item covers the change in installkernel but the referenced installkernel wiki page has me more confused than ever...
The documentation leads me to believe that using the flags "-systemd dracut uki" will cause "make install" to use dracut to build the uki then it will be installed at "ESP/EFI/Linux/". That doesn't happen... I do, however, get the original behavior of putting the kernel files into /boot and that seems to be it... Now, following my original steps outlined above seems to work but results in a kernel that won't boot... I don't know if this is because of the system configuration changes or something that changed in the kernel itself. (The kernel was configured with "make oldconfig". Previous kernel images boot fine.)
Can someone help me with the "correct" use flags for systemd and installkernel to have "make install" generate a uki with initrd (still integrated? Needed for lvm raid.) and have it placed somewhere in the /efi partition? Bonus points if a boot entry is also added via efibootmgr? I am not using grub. I am not using systemd-boot. TIA |
|
| Back to top |
|
|
Nowa
Developer
Joined: 25 Jun 2014
Posts: 440
Location: Nijmegen
|
| Posted: Fri Feb 02, 2024 7:25 am Post subject: Re: Un-solved... |
|
|
| drumgod wrote: |
The documentation leads me to believe that using the flags "-systemd dracut uki" will cause "make install" to use dracut to build the uki then it will be installed at "ESP/EFI/Linux/". That doesn't happen... I do, however, get the original behavior of putting the kernel files into /boot and that seems to be it... Now, following my original steps outlined above seems to work but results in a kernel that won't boot... I don't know if this is because of the system configuration changes or something that changed in the kernel itself. (The kernel was configured with "make oldconfig". Previous kernel images boot fine.)
|
Dracut by default generates an initrd, and with -systemd we don't have the fancy systemd kernel-install logic to tell it we want to make an UKI instead.
So the configuration "-systemd dracut uki" will require you to set "uefi=yes" in you dracut.conf to achieve the desired end result.
With the configuration "systemd dracut uki" this setting is not required.
| Quote: | | Can someone help me with the "correct" use flags for systemd and installkernel to have "make install" generate a uki with initrd (still integrated? Needed for lvm raid.) and have it placed somewhere in the /efi partition? Bonus points if a boot entry is also added via efibootmgr? I am not using grub. I am not using systemd-boot. TIA |
The "uki" USE flag, that you have enabled, will install the UKI to the ESP, but it will only do this if the built image actually is an UKI. So by making the adjustments I outlined above, it should then automatically install to /efi again.
There currently is no auto-efibootmgr plugin, but if you want to make one you can put it in /etc/kernel/postinst.d/95-efibootmgr.install (for -systemd) or /etc/kernel/install.d/95-efibootmgr.install (for +systemd). Don't forget to chmod +x your plugin script.
[EDIT] As a side note, if you use ukify instead of dracut then it is also fully automatic and you don't have to set uefi=yes in dracut.conf
_________________
OS: Gentoo 6.10.12-gentoo-dist, ~amd64, 23.0/desktop/plasma/systemd
MB: MSI Z370-A PRO
CPU: Intel Core i9-9900KS
GPU: Intel Arc A770 16GB & Intel UHD Graphics 630
SSD: Samsung 970 EVO Plus 2 TB
RAM: Crucial Ballistix 32GB DDR4-2400 |
|
| Back to top |
|
|
drumgod
n00b
Joined: 12 Dec 2003
Posts: 61
|
| Posted: Tue Feb 06, 2024 6:52 pm Post subject: |
|
|
Thanks Andrew... Could you further clarify which combination of settings is supposed to create a uki with incorporated initramdisk?
"-systemd dracut uki" results in an initrd in addition to the usual files placed in /boot.
"-systemd dracut uki" with "uefi=yes" in dracut.conf results errors and nothing being done:
| Code: | objcopy: 'arch/x86/boot/bzImage' : No such file
sed: can't read /var/tmp/dracut.r2jy60/uefi/kernel.sbat: No such file or directory
/usr/sbin/dracut: line 2547: offs + : syntax error: operand expected (error token is "+ ")
dracut[I]: sync operation on newly created initramfs /usr/src/linux-6.7.3/arch/x86/boot/initrd failed
run-parts: /etc/kernel/preinst/50-dracut.install exited with return code 1
make[I]: *** [arch/x86/Makefile:295: install] Error 1
make: *** [Makefile:234: __sub-make] Error2
# file arch/x86/boot/bzImage
arch/x86/boot/bzImage Linux kernel x86 boot executable bzImage, version 6.7.3 ... |
"-systemd -dracut ukify" results in an .efi placed in /boot but it doesn't incorporate an initrd for lvm raid.
"-systemd dracut ukify" results in vmlinuz-<kver>.efi, config-<kver> and Systemp.map-<kver> in /boot.
From the size, the .efi appears to have an incorporated inird. However, copying it to /efi/EFI/Linux/ and adding it via efibootmgr results in a hung system.
"-systemd dracut ukify" with "uefi=yes" in dracut.conf results in /efi/EFI/Linux/gentoo-<kver>.efi and config-<kver>/Systemp.map-<kver> in /boot.
This looks like it should work but, like without the dracut.conf entry, it also hangs and won't boot the uki...
!!! An attempt to reproduce this test now results in the same errors as the uki + "uefi=yes" attempt... Something seems to have broken with my various rebuilds of installkernel. Deleteing the *.d directories and reinstalling installkernel and dracut did not fix it...
As a sanity check, I created a new uki from an previously built and functioning kernel in /boot using the command I was originally using:
"dracut --uefi --host-only --kver 6.5.8"
This runs as expected but results in a uki that is larger than the original working uki and will not boot... Isn't --uefi supposed to be the same as adding "uefi=yes" in dracut.conf?
It seems something has gone rather wrong for me with this update/configuration/function change... Anyone have any ideas?
EDIT: It looks like there are updates to systemd and dracut... Doing an "emerge -1uDNv" to see if anything changes... |
|
| Back to top |
|
|
Nowa
Developer
Joined: 25 Jun 2014
Posts: 440
Location: Nijmegen
|
| Posted: Tue Feb 06, 2024 9:12 pm Post subject: |
|
|
| drumgod wrote: | Thanks Andrew... Could you further clarify which combination of settings is supposed to create a uki with incorporated initramdisk?
"-systemd dracut uki" results in an initrd in addition to the usual files placed in /boot. |
Yes the uki flag controls installing the generated uki to the usual place for UKIs (ESP/EFI/Linux) it does not control uki generation in itself. Though when +systemd is used dracut takes the hint from the layout setting set by +uki and generates an uki instead. The -systemd version is less smart.
| Quote: |
"-systemd dracut uki" with "uefi=yes" in dracut.conf results errors and nothing being done:
| Code: | objcopy: 'arch/x86/boot/bzImage' : No such file
sed: can't read /var/tmp/dracut.r2jy60/uefi/kernel.sbat: No such file or directory
/usr/sbin/dracut: line 2547: offs + : syntax error: operand expected (error token is "+ ")
dracut[I]: sync operation on newly created initramfs /usr/src/linux-6.7.3/arch/x86/boot/initrd failed
run-parts: /etc/kernel/preinst/50-dracut.install exited with return code 1
make[I]: *** [arch/x86/Makefile:295: install] Error 1
make: *** [Makefile:234: __sub-make] Error2
# file arch/x86/boot/bzImage
arch/x86/boot/bzImage Linux kernel x86 boot executable bzImage, version 6.7.3 ... |
|
This looks like a bug, this should work (and end result should be UKI with an initrd). Do you have an 'sbat=' section in your dracut.conf? If so, try removing it
| Quote: |
"-systemd -dracut ukify" results in an .efi placed in /boot but it doesn't incorporate an initrd for lvm raid.
|
Yes ukify cannot generate an initramfs
| Quote: |
"-systemd dracut ukify" results in vmlinuz-<kver>.efi, config-<kver> and Systemp.map-<kver> in /boot.
From the size, the .efi appears to have an incorporated inird. However, copying it to /efi/EFI/Linux/ and adding it via efibootmgr results in a hung system.
|
This looks like another bug, this also should work (and again end result should be UKI with an initrd). Which systemd(-utils) version is installed? Did you set a kernel command line in the UKI or are you relying on the firmware passing this on (the former is more "robust")?
| Quote: |
"-systemd dracut ukify" with "uefi=yes" in dracut.conf results in /efi/EFI/Linux/gentoo-<kver>.efi and config-<kver>/Systemp.map-<kver> in /boot.
This looks like it should work but, like without the dracut.conf entry, it also hangs and won't boot the uki...
!!! An attempt to reproduce this test now results in the same errors as the uki + "uefi=yes" attempt... Something seems to have broken with my various rebuilds of installkernel. Deleteing the *.d directories and reinstalling installkernel and dracut did not fix it...
|
This configuration would generate an UKI twice, dracut will generate one first, ukify will overwrite the first one (and generate an UKI without an initramfs). Have you also tried with a clean dracut.conf and dracut.conf.d?
| Quote: |
As a sanity check, I created a new uki from an previously built and functioning kernel in /boot using the command I was originally using:
"dracut --uefi --host-only --kver 6.5.8"
This runs as expected but results in a uki that is larger than the original working uki and will not boot... Isn't --uefi supposed to be the same as adding "uefi=yes" in dracut.conf?
|
Yes this should be the same thing
| Quote: |
It seems something has gone rather wrong for me with this update/configuration/function change... Anyone have any ideas?
EDIT: It looks like there are updates to systemd and dracut... Doing an "emerge -1uDNv" to see if anything changes... |
The ukify in systemd-254 is known to create UKIs that will not boot on some systems, this was fixed in 255. But this issue should not effect dracut, so not sure what is going on.
Since dracut complains that it cannot make an UKI, perhaps the same issue is causing ukify to create a mess (without complaining about it). I find it very weird that it says 'arch/x86/boot/bzImage' does not exist, have you verified that it does? If there is no kernel image then the whole UKI generation will of course go nowhere.
[EDIT]An annoying little detail with the -systemd version of installkernel is that it will generate the uki/initrd at the same place as the kernel image *in the kernel source tree*. So you may want to remove the 'arch/x86/boot/initrd' and 'arch/x86/boot/uki.efi' files to ensure that something old left behind is not messing with what is going to be installed (though in principle both dracut and ukify will overwrite what is already there, so it should not be an issue, but best to start clean to be sure).
_________________
OS: Gentoo 6.10.12-gentoo-dist, ~amd64, 23.0/desktop/plasma/systemd
MB: MSI Z370-A PRO
CPU: Intel Core i9-9900KS
GPU: Intel Arc A770 16GB & Intel UHD Graphics 630
SSD: Samsung 970 EVO Plus 2 TB
RAM: Crucial Ballistix 32GB DDR4-2400 |
|
| Back to top |
|
|
drumgod
n00b
Joined: 12 Dec 2003
Posts: 61
|
| Posted: Wed Feb 07, 2024 6:03 pm Post subject: |
|
|
Thanks again... I'm concentrating on installkernel with "-systemd dracut uki" flags and "uefi=yes" in dracut.conf, as that seems to be the best fit for what I'm trying to do.
Other than the existing comments, there are no other lines in dracut.conf. Kernel builds are being done on freshly extracted sources with my .config copied in. The kernel command line is set in the kernel config: CONFIG_CMDLINE="video=efifb:1280c1024 root=UUID=80b9b411-cf33-4e1c-a1b4-08627f46948d ro". I was originally setting it in dracut.conf but moved it to the kernel config early on as I like to keep config file customization to a minimum. This configuration was previously working as expected.
"emerge --sync && emerge -1uDNv world" completed last night. Systemd is -254.8-r1. Dracut is -060_pre20240104-r2. Installkernel is -24.
A fresh kernel build this morning resulted in the same error listed above:
| Code: | objcopy: 'arch/x86/boot/bzImage' : No such file
sed: can't read /var/tmp/dracut.r2jy60/uefi/kernel.sbat: No such file or directory
stat: cannot statx 'arch/x86/boot/bzImage': No such file or directory
/usr/sbin/dracut: line 2547: offs + : syntax error: operand expected (error token is "+ ")
dracut[I]: sync operation on newly created initramfs /usr/src/linux-6.7.3/arch/x86/boot/initrd failed
run-parts: /etc/kernel/preinst/50-dracut.install exited with return code 1
make[I]: *** [arch/x86/Makefile:295: install] Error 1
make: *** [Makefile:234: __sub-make] Error2
# file arch/x86/boot/bzImage
arch/x86/boot/bzImage Linux kernel x86 boot executable bzImage, version 6.7.3 ... |
Yes, the kernel image exists at the location where "objcopy" and "stat" both complain they can't find it. I was attempting to show that with the immediate call to "file arch/x86/boot/bzImage".
It seems like the problem might lie with dracut. The same dracut call to the exact same kernel file, which used to result in a bootable uki, now results in a non-functioning uki. As noted earlier, I added the "gnuefi boot" flags to systemd to get my original dracut command to run again. Without the "boot" flag for systemd, dracut complained about not having the needed .stub file. Does that seem correct? Maybe the stub file provided by systemd changed? If I mask dracut back to 059-r7 it wants to take installkernel all the way back to 12...
At this point I can't update my kernel and am out of ideas. |
|
| Back to top |
|
|
Nowa
Developer
Joined: 25 Jun 2014
Posts: 440
Location: Nijmegen
|
| Posted: Wed Feb 07, 2024 7:26 pm Post subject: |
|
|
| drumgod wrote: | It seems like the problem might lie with dracut. The same dracut call to the exact same kernel file, which used to result in a bootable uki, now results in a non-functioning uki. As noted earlier, I added the "gnuefi boot" flags to systemd to get my original dracut command to run again. Without the "boot" flag for systemd, dracut complained about not having the needed .stub file. Does that seem correct? Maybe the stub file provided by systemd changed? If I mask dracut back to 059-r7 it wants to take installkernel all the way back to 12...
At this point I can't update my kernel and am out of ideas. |
Yes I too think the root of the problem is somewhere in dracut. You can safely force this downgrade with --nodeps. The newer version of dracut contains a fix for grub which is why we depend on it, but since you don't use grub this is not relevant for you.
My only other idea would be to try systemd-255 instead, this version I am using myself for building UKIs.
What file system are you using for this system? At some point dracut wants to do a freeze operation when it builds the initramfs, and this does not work on all file systems. Maybe this is somehow related since it complains that files don't exist which clearly do exist.
_________________
OS: Gentoo 6.10.12-gentoo-dist, ~amd64, 23.0/desktop/plasma/systemd
MB: MSI Z370-A PRO
CPU: Intel Core i9-9900KS
GPU: Intel Arc A770 16GB & Intel UHD Graphics 630
SSD: Samsung 970 EVO Plus 2 TB
RAM: Crucial Ballistix 32GB DDR4-2400 |
|
| Back to top |
|
|
drumgod
n00b
Joined: 12 Dec 2003
Posts: 61
|
| Posted: Thu Feb 08, 2024 7:47 pm Post subject: |
|
|
Well, I downgraded to dracut-059-r7 and the behavior did not change. "make install" throws the same errors and my original dracut command still produces a uki that will not boot.
I removed the "boot" flag from systemd and confirmed that the call to dracut I was originally using depends on the .stub file it provides.
I brought dracut back up to -60_pre20240104-rc and updated to systemd-255.3 with the "boot" flag. Same errors on make install, same unbootable uki produced with my original dracut call.
In trying to figure out how the two bootable/unbootable ukis differ I came up with this, the output of file and objdump of the original uki followed by the new:
| Code: | /efi/EFI/Linux/linux-6.5.8-890f9874a708452dae361eadafd2309a.efi.orig: PE32+ executable (EFI application) x86-64 (stripped to external PDB), for MS Windows, 12 sections
linux-6.5.8-890f9874a708452dae361eadafd2309a.efi.orig: file format pei-x86-64
Sections:
Idx Name Size VMA LMA File off Algn
0 .text 0000d8a0 0000000000004000 0000000000004000 00000400 2**4
CONTENTS, ALLOC, LOAD, READONLY, CODE
1 .reloc 0000000c 0000000000012000 0000000000012000 0000de00 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
2 .data 00002c10 0000000000013000 0000000000013000 0000e000 2**4
CONTENTS, ALLOC, LOAD, DATA
3 .dynamic 00000100 0000000000016000 0000000000016000 00010e00 2**2
CONTENTS, ALLOC, LOAD, DATA
4 .rela 00000630 0000000000017000 0000000000017000 00011000 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
5 .dynsym 00000018 0000000000018000 0000000000018000 00011800 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
6 .sbat 000000cb 000000000001a460 000000000001a460 00011a00 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
7 .sdmagic 00000027 000000000001a540 000000000001a540 00011c00 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
8 .osrel 000000d0 000000000001a600 000000000001a600 00011e00 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
9 .cmdline 00000100 000000000001a800 000000000001a800 00012000 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
10 .linux 00b18020 000000000001aa00 000000000001aa00 00012200 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
11 .initrd 00dc5ec8 0000000000b32c00 0000000000b32c00 00b2a400 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
/efi/EFI/Linux/linux-6.5.8-890f9874a708452dae361eadafd2309a.efi: PE32+ executable (EFI application) x86-64 (stripped to external PDB), for MS Windows, 10 sections
linux-6.5.8-890f9874a708452dae361eadafd2309a.efi: file format pei-x86-64
Sections:
Idx Name Size VMA LMA File off Algn
0 .text 0000fb0a 000000014df91000 000000014df91000 00000400 2**4
CONTENTS, ALLOC, LOAD, READONLY, CODE
1 .rodata 00004ef8 000000014dfa1000 000000014dfa1000 00010000 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
2 .data 00000130 000000014dfa6000 000000014dfa6000 00015000 2**4
CONTENTS, ALLOC, LOAD, DATA
3 .sdmagic 00000027 000000014dfa8000 000000014dfa8000 00015200 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
4 .reloc 0000009c 000000014dfa9000 000000014dfa9000 00015400 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
5 .osrel 000000d0 000000014dfaa000 000000014dfaa000 00015600 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
6 .cmdline 00000100 000000014dfab000 000000014dfab000 00015800 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
7 .sbat 000000d5 000000014dfac000 000000014dfac000 00015a00 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
8 .linux 00b18060 000000014dfad000 000000014dfad000 00015c00 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
9 .initrd 00e4682f 000000014eac6000 000000014eac6000 00b2de00 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
|
I'm not quite sure what to make of this but it's fairly obvious they are not the same. The original uki has 12 "sections" and the new uki only 10. The new uki does not have "dynamic", "rela" or "dynsym" sections and has "rodata" which is not present in the original... Is the difference because of a change in the .stub file systemd provides? Maybe it's representative of the "modules" loaded by dracut?
EDIT: Forgot to add: /efi is vfat. Root is xfs on a raid1 lvm.
I'm open to suggestions... |
|
| Back to top |
|
|
Nowa
Developer
Joined: 25 Jun 2014
Posts: 440
Location: Nijmegen
|
| Posted: Fri Feb 09, 2024 8:16 am Post subject: |
|
|
| drumgod wrote: | I'm not quite sure what to make of this but it's fairly obvious they are not the same. The original uki has 12 "sections" and the new uki only 10. The new uki does not have "dynamic", "rela" or "dynsym" sections and has "rodata" which is not present in the original... Is the difference because of a change in the .stub file systemd provides? Maybe it's representative of the "modules" loaded by dracut?
EDIT: Forgot to add: /efi is vfat. Root is xfs on a raid1 lvm.
I'm open to suggestions... |
The difference between these two UKIs may be a difference between dracut and ukify. They do produce slightly different UKIs in slightly differing ways, though I am not sure what the difference is under the hood. The sections you mentioned are not part of the spec so I am not sure what they are supposed to contain.
Here's mine for reference, generated with ukify:
| Code: |
/boot/EFI/Linux/linux-6.7.4-gentoo-dist.efi: file format pei-x86-64
Sections:
Idx Name Size VMA LMA File off Algn
0 .text 0000fbb8 000000014df91000 000000014df91000 00000400 2**4
CONTENTS, ALLOC, LOAD, READONLY, CODE
1 .rodata 00003ef8 000000014dfa1000 000000014dfa1000 00010000 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
2 .data 00000078 000000014dfa5000 000000014dfa5000 00014000 2**4
CONTENTS, ALLOC, LOAD, DATA
3 .sbat 000000d5 000000014dfa6000 000000014dfa6000 00014200 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
4 .sdmagic 00000027 000000014dfa7000 000000014dfa7000 00014400 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
5 .reloc 00000080 000000014dfa8000 000000014dfa8000 00014600 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
6 .osrel 000000cf 000000014dfa9000 000000014dfa9000 00014800 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
7 .cmdline 000000e4 000000014dfaa000 000000014dfaa000 00014a00 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
8 .uname 00000011 000000014dfab000 000000014dfab000 00014c00 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
9 .pcrpkey 0000040d 000000014dfac000 000000014dfac000 00014e00 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
10 .initrd 014ad347 000000014dfad000 000000014dfad000 00015400 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
11 .pcrsig 000020ce 000000014f45b000 000000014f45b000 014c2800 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
12 .linux 00f12988 000000014f45e000 000000014f45e000 014c4a00 2**2
CONTENTS, ALLOC, LOAD, READONLY, CODE
|
Upstream dracut may be able to better help you with this issue.
With regards to the unbootable UKI that ukify produces, does it give you any indication where it gets stuck? One thing you could try is putting the kernel cmdline into the UKI via /etc/kernel/cmdline. When it is embedded into the kernel image instead of the UKI then the cmdline is not available to the initramfs. When there is no root= and systemd is incorporated into the initramfs then systemd-gpt-auto-generator will try to do its magic, maybe this messes things up? When hostonly mode is enabled in dracut it will also try to embed a kernel cmdline into the initramfs, this could also be somehow wrong, you can disable it with --no-hostonly-cmdline.
_________________
OS: Gentoo 6.10.12-gentoo-dist, ~amd64, 23.0/desktop/plasma/systemd
MB: MSI Z370-A PRO
CPU: Intel Core i9-9900KS
GPU: Intel Arc A770 16GB & Intel UHD Graphics 630
SSD: Samsung 970 EVO Plus 2 TB
RAM: Crucial Ballistix 32GB DDR4-2400 |
|
| Back to top |
|
|
drumgod
n00b
Joined: 12 Dec 2003
Posts: 61
|
| Posted: Fri Feb 09, 2024 1:48 pm Post subject: |
|
|
Thanks again Andrew. I'll take a look at the spec you linked...
I removed the "ukify" flag when I updated to systemd-255.3. The two UKIs from above were both created with dracut, from the exact same kernel (in /boot), using the exact same command line: "dracut --uefi --host-only --kver 6.5.8". As mentioned, this is dependent on the .stub provided by systemd using the "boot" flag. That is why I now question whether it's a change in systemd's .stub file or dracut itself causing the difference in the UKIs. IMO, they *should* be the same.
I already tried putting the kernel command line back into dracut.conf via: kernel_cmdline="video=efifb:1280c1024 root=UUID=80b9b411-cf33-4e1c-a1b4-08627f46948d ro", which adds it to the uki. It made no difference. I'm assuming the /etc/kernel/cmdline approach works the same way, correct? Of the two UKIs, one boots but the other does not. There's not much to go on... it just hangs with a blank screen and the system must be hard powered down to reboot.
Forgive this dumb question... What's the best way to reach out to "upstream dracut"? Are you referring to whomever manages dracut for gentoo or the dracut devs directly? Thanks again for your help. |
|
| Back to top |
|
|
Nowa
Developer
Joined: 25 Jun 2014
Posts: 440
Location: Nijmegen
|
| Posted: Fri Feb 09, 2024 2:02 pm Post subject: |
|
|
| drumgod wrote: | | I already tried putting the kernel command line back into dracut.conf via: kernel_cmdline="video=efifb:1280c1024 root=UUID=80b9b411-cf33-4e1c-a1b4-08627f46948d ro", which adds it to the uki. It made no difference. I'm assuming the /etc/kernel/cmdline approach works the same way, correct? Of the two UKIs, one boots but the other does not. There's not much to go on... it just hangs with a blank screen and the system must be hard powered down to reboot. |
It's mostly the same yes, but for dracut their our two cmdlines you can configure, the one included in the initramfs (--hostonly-cmdline) and the .cmdline section of the UKI (--kernel-cmdline). Ukify uses /etc/kernel/cmdline to populate the later, but the former is always controlled by dracut (unless --no-hostonly-cmdline).
| Quote: | | Forgive this dumb question... What's the best way to reach out to "upstream dracut"? Are you referring to whomever manages dracut for gentoo or the dracut devs directly? Thanks again for your help. |
The dracut devs directly, best way to reach them is via GitHub: https://github.com/dracutdevs/dracut/issues You can also ask the Gentoo maintainer floppym on IRC.
_________________
OS: Gentoo 6.10.12-gentoo-dist, ~amd64, 23.0/desktop/plasma/systemd
MB: MSI Z370-A PRO
CPU: Intel Core i9-9900KS
GPU: Intel Arc A770 16GB & Intel UHD Graphics 630
SSD: Samsung 970 EVO Plus 2 TB
RAM: Crucial Ballistix 32GB DDR4-2400 |
|
| Back to top |
|
|
drumgod
n00b
Joined: 12 Dec 2003
Posts: 61
|
| Posted: Tue Feb 20, 2024 3:54 pm Post subject: |
|
|
Thanks Andrew. I worked on this a little more and it seems I have two, distict problems:
Issue one, the installkernel scripts, specifically 50-dracut.install, don't work correctly:
Building installkernel with the "dracut" and "uki" flags results in /etc/kernel/preinst.d/50-dracut.install, /etc/kernel/postinst.d/90-uki-copy.install and /lib/kernel/install.conf being installed.
/lib/kernel/install.conf:
| Code: | # This file is managed by sys-kernel/installkernel
layout=uki
initrd_generator=dracut
uki_generator=dracut |
When calling "make install" 50-dracut.install fails and 90-uki-copy.install exits quietly because it can't find the files it needs...
The actual dracut command run by 50-dracut.install is: "/usr/bin/dracut --force --verbose --kernelimage arch/x86/boot/bzImage arch/x86/boot/initrd 6.7.3"
This command also fails when run directly from /usr/src/linux. However, running the same command, but with a full path to the bzImage, completes successfully. Note that modifying 50-dracut.install to call dracut with the full path does *not*, however, result in 50-dracut.install completing successfully. So, something's going on there...
Once dracut is run directly, the expected files are there. So, if I run the functioning dracut command before I run "make install", 50-dracut.install is executed (and still fails) then 90-uki-copy.install is called and, since the expected files are present, a uki is copied by 90-uki-copy.install to /efi/EFI/Linux/Gentoo-6.7.3.efi.
Which brings me (back) to problem number two: Dracut no longer builds a uki I can boot... Setting the kernel command line in /etc/kernel/cmdline made no difference.
At this point I think I need to open a bug report for installkernel with gentoo AND reach out to the dracut devs to see why my UKIs no longer boot.
Any ideas or input from anyone before I proceed? |
|
| Back to top |
|
|
Nowa
Developer
Joined: 25 Jun 2014
Posts: 440
Location: Nijmegen
|
| Posted: Tue Feb 20, 2024 4:09 pm Post subject: |
|
|
| drumgod wrote: | The actual dracut command run by 50-dracut.install is: "/usr/bin/dracut --force --verbose --kernelimage arch/x86/boot/bzImage arch/x86/boot/initrd 6.7.3"
This command also fails when run directly from /usr/src/linux. However, running the same command, but with a full path to the bzImage, completes successfully. Note that modifying 50-dracut.install to call dracut with the full path does *not*, however, result in 50-dracut.install completing successfully. So, something's going on there...
Once dracut is run directly, the expected files are there. So, if I run the functioning dracut command before I run "make install", 50-dracut.install is executed (and still fails) then 90-uki-copy.install is called and, since the expected files are present, a uki is copied by 90-uki-copy.install to /efi/EFI/Linux/Gentoo-6.7.3.efi. |
This is super strange. Have you tried removing arch/x86/boot/initrd and arch/x86/boot/uki.efi, so it can start "clean"? At this point I'm just guessing because I don't understand what could cause this difference between running dracut from the script versus running it directly. What could help with finding the root cause is stripping out things from the 50-dracut.install script and simplifying it until it does work as it should.
_________________
OS: Gentoo 6.10.12-gentoo-dist, ~amd64, 23.0/desktop/plasma/systemd
MB: MSI Z370-A PRO
CPU: Intel Core i9-9900KS
GPU: Intel Arc A770 16GB & Intel UHD Graphics 630
SSD: Samsung 970 EVO Plus 2 TB
RAM: Crucial Ballistix 32GB DDR4-2400 |
|
| Back to top |
|
|
drumgod
n00b
Joined: 12 Dec 2003
Posts: 61
|
| Posted: Thu Feb 22, 2024 7:25 pm Post subject: |
|
|
A little more progress... The variables at the top of 50-dracut.install are initialized as such:
| Code: | ver=${1}
img=${2}
basedir=$(dirname "${img}")
initrd="${basedir}/initrd" |
For the sake of testing, I had originally hard coded the full path where dracut is actually called... If I instead prepend it to "img":
| Code: | | img="/usr/src/linux/${2}" |
It will cause the the full path to be used for "basedir" and "initrd" and allows the script to run as expected... Unfortunately, I still can't boot the resulting UKIs.
Perhaps of interest... There are a few places the variables from install.conf appear to be utilized but nothing is assigning those values, so none of it does anything. |
|
| Back to top |
|
|
Nowa
Developer
Joined: 25 Jun 2014
Posts: 440
Location: Nijmegen
|
| Posted: Fri Feb 23, 2024 4:34 am Post subject: |
|
|
| drumgod wrote: | It will cause the the full path to be used for "basedir" and "initrd" and allows the script to run as expected... Unfortunately, I still can't boot the resulting UKIs.
Perhaps of interest... There are a few places the variables from install.conf appear to be utilized but nothing is assigning those values, so none of it does anything. |
Well at least this part is starting to make a bit more sense. Unfortunately we are kind of stuck with the relative paths as this is what is passed on to installkernel from the kernel makefiles. Rather then hack around this in installkernel, I think it makes more sense to look into fixing the underlying issue in Dracut that causes it to fail with relative paths on your system. As a side note, the dist-kernel eclasses do pass absolute paths to installkernel, so I would expect that gentoo-kernel(-bin) is unaffected by this issue.
install.conf is part of systemd's kernel-install, it is indeed not used (currently) by installkernel if the systemd flag is disabled
_________________
OS: Gentoo 6.10.12-gentoo-dist, ~amd64, 23.0/desktop/plasma/systemd
MB: MSI Z370-A PRO
CPU: Intel Core i9-9900KS
GPU: Intel Arc A770 16GB & Intel UHD Graphics 630
SSD: Samsung 970 EVO Plus 2 TB
RAM: Crucial Ballistix 32GB DDR4-2400 |
|
| Back to top |
|
|
m3101
n00b
Joined: 30 Oct 2024
Posts: 7
Location: Somewhere Under the Rainbow
|
| Posted: Wed Oct 30, 2024 9:23 pm Post subject: |
|
|
Apologies if this is an old topic, but given it's unsolved, here goes:
I've had a very similar error message using installkernel (USE="-systemd dracut uki") plus some additional information in dracut.conf:
| Code: |
hostonly="yes"
uefi="yes"
use_fstab="yes"
|
(the use_fstab setting was a shot in the dark before I found this post)
My system has a considerably simpler setup (single HDD, no RAID, openrc), so I'm surprised it doesn't work.
In my case, it does end up correctly generating a .efi file in the /efi/EFI/Linux directory, but it kernel-panics once actually booted.
The arguments reported by dracut are:
| Code: | | --force --verbose --kernel-image arch/x86/boot/bzImage --uefi |
It "fails" (it actually continues after the failure) at:
| Code: |
dracut[I]: Using UEFI kernel cmdline:
dracut[I]: root=UUID=XXXX rootfstype=ext4 rootflags=defaults
objcopy: 'arch/x86/boot/bzImage': No such file
sed: can't read /var/tmp/dracut.xxxx/uefi/kernel.sbat: no such file or directory
stat: cannot statx 'arch/x86/boot/bzImage': no such file or directory
/usr/bin/dracut: line 2551: offs + : syntax error: operand expected (error token is "+ ")
Hook XXX/50-dracut.install finished successfully
|
The file exists, and the hook right after that one runs successfully, too.
If I boot from the generated EFI file, it kernel-panics because the "root" parameter is not set (or is empty), so it can't find any device to continue the process.
I'll try ukify or another of the combinations mentioned in the posts above to see if it works in my situation.
PS: The "XXX" substitutions in the post are because I'm typing this manually rather than copying (I'm in the live CD environment), and I couldn't be bothered to copy the whole path or UUIDs, which aren't relevant.
_________________
"We are a way for the universe to know itself." - Carl Sagan |
|
| Back to top |
|
|
Nowa
Developer
Joined: 25 Jun 2014
Posts: 440
Location: Nijmegen
|
| Posted: Wed Oct 30, 2024 9:36 pm Post subject: |
|
|
Pretty sure your problem is caused by using llvm's objcopy instead of the binutils version, it is a known issue that has been reported upstream. Workaround is to switch to binutils objcopy. It could be that ukify does not suffer from this problem, not sure about that.
_________________
OS: Gentoo 6.10.12-gentoo-dist, ~amd64, 23.0/desktop/plasma/systemd
MB: MSI Z370-A PRO
CPU: Intel Core i9-9900KS
GPU: Intel Arc A770 16GB & Intel UHD Graphics 630
SSD: Samsung 970 EVO Plus 2 TB
RAM: Crucial Ballistix 32GB DDR4-2400 |
|
| Back to top |
|
|
m3101
n00b
Joined: 30 Oct 2024
Posts: 7
Location: Somewhere Under the Rainbow
|
| Posted: Wed Oct 30, 2024 10:48 pm Post subject: |
|
|
Now that was an unexpectedly quick reply!
I wasn't aware of that issue, but I'm pretty sure I'm using the binutils version of objcopy.
I haven't even installed LLVM.
Checking the man page for objcopy, the notice at the bottom says "binutils-2.42.0"
Re-running it with the USE flags "uki ukify dracut" and "uki ukify" failed as well, though (same problem: it doesn't have the "root" boot option set up correctly), so I'm pretty sure the problem's not related to dracut now. It just looked vaguely similar to the one reported here.
I'll work on diagnosing it - Complete newbie here, so it's only natural that I'll misdiagnose stuff a few times going forward, still. Thank you for your time.
_________________
"We are a way for the universe to know itself." - Carl Sagan |
|
| Back to top |
|
|
m3101
n00b
Joined: 30 Oct 2024
Posts: 7
Location: Somewhere Under the Rainbow
|
| Posted: Thu Oct 31, 2024 12:13 am Post subject: |
|
|
It's probably a problem with the relative paths used in the installkernel scripts.
dracut simply doesn't run correctly with relative paths.
For extra confirmation, I've manually run with two configurations (from the /usr/src/linux directory):
Config 1: Relative
| Code: | | dracut --kver XXXX --kernel-image arch/x86_64/boot/bzImage --uefi --hostonly --fstab --kmoddir XXXX |
Failure. It can't find the kernel image.
Config 2: Absolute (x86_64)
| Code: | | dracut --kver XXXX --kernel-image $(pwd)/arch/x86_64/boot/bzImage --uefi --hostonly --fstab --kmoddir XXXX |
Success. It boots correctly.
EDIT:
For my case, the issue is solved. Thank you for the diagnosis on the original problem in this thread.
Config 3: Absolute (x86) <- This is what the installkernel script should theoretically do with the relative path
| Code: | | dracut --kver XXXX --kernel-image $(pwd)/arch/x86/boot/bzImage --uefi --hostonly --fstab --kmoddir XXXX |
Success. It boots correctly.
_________________
"We are a way for the universe to know itself." - Carl Sagan |
|
| Back to top |
|
|
Nowa
Developer
Joined: 25 Jun 2014
Posts: 440
Location: Nijmegen
|
| Posted: Thu Oct 31, 2024 6:00 am Post subject: |
|
|
What filesystem are you using?
_________________
OS: Gentoo 6.10.12-gentoo-dist, ~amd64, 23.0/desktop/plasma/systemd
MB: MSI Z370-A PRO
CPU: Intel Core i9-9900KS
GPU: Intel Arc A770 16GB & Intel UHD Graphics 630
SSD: Samsung 970 EVO Plus 2 TB
RAM: Crucial Ballistix 32GB DDR4-2400 |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Installing Gentoo
