| View previous topic :: View next topic |
| Author |
Message |
alecStewart1
Apprentice
Joined: 03 Jul 2022
Posts: 156
|
 Posted: Mon Nov 25, 2024 3:59 pm Post subject: If dracut doesn't create bootable initramfs, will UKI work? |
 |
|
Hello friends,
So I've in a way been "stuck" on kernel version 6.6.53 of the gentoo-sources for some time now. Dracut, after the updates to the profiles 17 - 23 (I'm on default/linux/amd64/23.0/split-usr/hardened), has never been able to create a bootable initramfs for me regardless version of dracut. I switched to genkernel from using the dist-kernel, as that was the only thing has ever worked for me. However having now switched to a bootstrapped LLVM/Clang genkernel seems to now be throwing a fit. I get some error some libtool about relinking a file from util-linux:
| Code: |
libtool: install: error: relink `libmount.la' with the above command before installing it
|
The error (which I can't access at the moment), also mentions a different version of util-linux (the current is 24 something I believe, and the mentioned is 23 something) than what I have installed, so I re-emerged util-linux and that still didn't fix the issue.
That's a separate issue that I'll post about later with logs and such when I'm back at home, but part of me thinks it's something with cross-compilation, and makes me wonder if I should which to the no-multilib equivalent of the profile I currently use to see if there's something funky with compiling 32-bit specific code. I don't really use anything that's specifically needs 32-bit versions of libraries/objects/binaries/etc., unless if playing games with Steam or through Lutris specifically needs it (though I have feeling they don't).
Since I seemingly can't use genkernel at the moment, I thought I could try the dist-kernel again, as that made my life a lot simpler before I had to move to genkernel. Well, dracut still doesn't create a bootable initramfs, with the error when I boot mentioning it doesn't know where the device root=really-long-uuid is.
This is not me using UKI, though, and having a separate initramfs file that I reference in the initrd in the kernel commandline with efibootmgr. My question is, would using UKI produce any different results? Or would it still be the same, dracut not being able to produce a valid initramfs?
Again, I'll post about the genkernel issue in another thread when I can post all of the necessary information, I'm just curious if it's even useful to switch to UKI instead of having a separate initramfs if dracut can't even make a valid initramfs. I guess my last resort would be to build the initramfs myself or try UGRD even though I don't use LUKS or LVM. |
|
| Back to top |
|
 |
pingtoo
Veteran
Joined: 10 Sep 2021
Posts: 1272
Location: Richmond Hill, Canada
|
| Posted: Mon Nov 25, 2024 4:14 pm Post subject: |
|
|
UKI just have embedded initramfs into the result binary. It is not about eliminate initramfs.
So if you have setup require use of initramfs (i.e. encrypted rootfs) than UKI will not help. |
|
| Back to top |
|
|
zen_desu
n00b
Joined: 25 Oct 2024
Posts: 28
|
| Posted: Mon Nov 25, 2024 4:16 pm Post subject: |
|
|
If the initramfs alone does not function, baking it into a UKI likely won't help it work. The main reason I could see a UKI helping is if the root= cmdline option was incorrect outside the UKI but set correctly within it.
ugrd was mostly made to make it easier to boot LUKS setups, just because it detects config for you and attempts to validate it. It works fine for simpler setups. One notable thing about it is that it builds in root info from the host, so a "root=" option is not required, but attempted if passed.
Do you really need an initramfs? If you have a custom kernel you could probably just build in everything which is required to boot, modules can be loaded after the rootfs is mounted. In some cases an initramfs just adds parts which can break.
_________________
µgRD dev
Wiki writer |
|
| Back to top |
|
|
alecStewart1
Apprentice
Joined: 03 Jul 2022
Posts: 156
|
| Posted: Mon Nov 25, 2024 4:49 pm Post subject: |
|
|
| zen_desu wrote: | | Do you really need an initramfs? If you have a custom kernel you could probably just build in everything which is required to boot, modules can be loaded after the rootfs is mounted. In some cases an initramfs just adds parts which can break. |
That's a great question, actually. I initially just went with the dist-kernel and initramfs because it seemed like the simplest path at the time. Although, if I understand correctly, if one is using the split-usr profiles (/usr is being separate) then you need to use initframfs? I could likely have that wrong.
If it's not much effort to move away from default/linux/amd64/split-usr/hardened to /default/linux/amd64/no-multilib/hardended then I'm definitely all for it.
So if I could go without initramfs and shove everything in the kernel, erm, someone might need to point me to a guide. I recall there being one somewhere on the wiki, I just don't remember what the page was called. |
|
| Back to top |
|
|
alecStewart1
Apprentice
Joined: 03 Jul 2022
Posts: 156
|
| Posted: Mon Nov 25, 2024 4:52 pm Post subject: |
|
|
| Oh well there is this which isn't gentoo specific, but it's certainly a helpful starting place. |
|
| Back to top |
|
|
zen_desu
n00b
Joined: 25 Oct 2024
Posts: 28
|
| Posted: Mon Nov 25, 2024 4:57 pm Post subject: |
|
|
| alecStewart1 wrote: | | zen_desu wrote: | | Do you really need an initramfs? If you have a custom kernel you could probably just build in everything which is required to boot, modules can be loaded after the rootfs is mounted. In some cases an initramfs just adds parts which can break. |
That's a great question, actually. I initially just went with the dist-kernel and initramfs because it seemed like the simplest path at the time. Although, if I understand correctly, if one is using the split-usr profiles (/usr is being separate) then you need to use initframfs? I could likely have that wrong.
If it's not much effort to move away from default/linux/amd64/split-usr/hardened to /default/linux/amd64/no-multilib/hardended then I'm definitely all for it.
So if I could go without initramfs and shove everything in the kernel, erm, someone might need to point me to a guide. I recall there being one somewhere on the wiki, I just don't remember what the page was called. |
If you have a separate /usr partition, you may need an initramfs to boot because the system may need stuff from /usr to start the init. Essentially, the initramfs is just there to kickstart the boot process, it gets the root mounted and starts the "real" init system, which often handles things such as additional mounts. If there is no initramfs, the kernel may be able to directly mount the root filesystem, which could be enough for the init to start and do its thing. If not, then that is where the initramfs helps to get things ready.
In the case of LUKS, it decrypts the filesystem, then mounts it. In the case of a separate /usr partition, it mounts that so /usr/bin, etc. is available for the init system.
Depending on how you boot, an initramfs may not be required with dist-kernel. If you're sure you don't need one you can set "USE=-initramfs" for dist-kernel. One notable component which may be missing is the nvme module (important if you boot from a nvme). If you run ugrd, you should see it list some "init kernel modules" which should give you a good idea of what you need to build in if you want to avoid using an initramfs.
I would avoid building _everything_ into the kernel, and would start by simply adding portions which are required specifically to boot. This is also a somewhat advanced method and it's worth noting that using an initramfs here is generally simpler/easier to maintain, but there isn't technically anything wrong about this method.
_________________
µgRD dev
Wiki writer |
|
| Back to top |
|
|
grknight
Retired Dev
Joined: 20 Feb 2015
Posts: 1931
|
| Posted: Mon Nov 25, 2024 5:11 pm Post subject: |
|
|
| alecStewart1 wrote: | | Although, if I understand correctly, if one is using the split-usr profiles (/usr is being separate) then you need to use initframfs? |
Please don't confuse split-usr/merged-usr with having a separate /usr volume.
The former is a layout where /{,s}bin and /lib{,64} are moved under /usr.
The latter is often broken and not recommended in modern times because of complexity. An initramfs that is aware of separate /usr is required or things will not work.
The simplest solution is to move the separate /usr back to the rootfs if space allows. This can be done easily via a bind mount and rsync. |
|
| Back to top |
|
|
alecStewart1
Apprentice
Joined: 03 Jul 2022
Posts: 156
|
| Posted: Mon Nov 25, 2024 5:30 pm Post subject: |
|
|
| grknight wrote: | | alecStewart1 wrote: | | Although, if I understand correctly, if one is using the split-usr profiles (/usr is being separate) then you need to use initframfs? |
Please don't confuse split-usr/merged-usr with having a separate /usr volume.
The former is a layout where /{,s}bin and /lib{,64} are moved under /usr.
The latter is often broken and not recommended in modern times because of complexity. An initramfs that is aware of separate /usr is required or things will not work.
The simplest solution is to move the separate /usr back to the rootfs if space allows. This can be done easily via a bind mount and rsync. |
Ah apologies. I don't actually have a separate /usr volume. Just ye 'ol simple boot (efi), swap and root. So I could go without an initramfs. |
|
| Back to top |
|
|
alecStewart1
Apprentice
Joined: 03 Jul 2022
Posts: 156
|
| Posted: Mon Nov 25, 2024 5:32 pm Post subject: |
|
|
| zen_desu wrote: |
If you have a separate /usr partition, you may need an initramfs to boot because the system may need stuff from /usr to start the init. Essentially, the initramfs is just there to kickstart the boot process, it gets the root mounted and starts the "real" init system, which often handles things such as additional mounts. If there is no initramfs, the kernel may be able to directly mount the root filesystem, which could be enough for the init to start and do its thing. If not, then that is where the initramfs helps to get things ready.
In the case of LUKS, it decrypts the filesystem, then mounts it. In the case of a separate /usr partition, it mounts that so /usr/bin, etc. is available for the init system.
Depending on how you boot, an initramfs may not be required with dist-kernel. If you're sure you don't need one you can set "USE=-initramfs" for dist-kernel. One notable component which may be missing is the nvme module (important if you boot from a nvme). If you run ugrd, you should see it list some "init kernel modules" which should give you a good idea of what you need to build in if you want to avoid using an initramfs.
I would avoid building _everything_ into the kernel, and would start by simply adding portions which are required specifically to boot. This is also a somewhat advanced method and it's worth noting that using an initramfs here is generally simpler/easier to maintain, but there isn't technically anything wrong about this method. |
I actually don't have a separate /usr partition and I just boot with an EFI stub. So I can give it a go. |
|
| Back to top |
|
|
zen_desu
n00b
Joined: 25 Oct 2024
Posts: 28
|
| Posted: Mon Nov 25, 2024 5:36 pm Post subject: |
|
|
| alecStewart1 wrote: | | grknight wrote: | | alecStewart1 wrote: | | Although, if I understand correctly, if one is using the split-usr profiles (/usr is being separate) then you need to use initframfs? |
Please don't confuse split-usr/merged-usr with having a separate /usr volume.
The former is a layout where /{,s}bin and /lib{,64} are moved under /usr.
The latter is often broken and not recommended in modern times because of complexity. An initramfs that is aware of separate /usr is required or things will not work.
The simplest solution is to move the separate /usr back to the rootfs if space allows. This can be done easily via a bind mount and rsync. |
Ah apologies. I don't actually have a separate /usr volume. Just ye 'ol simple boot (efi), swap and root. So I could go without an initramfs. |
You can if you're careful that required modules are built into the kernel. If you only need to add a few, this can be done simply with "gentoo-kernel":
https://wiki.gentoo.org/wiki/Project:Distribution_Kernel#Using_.2Fetc.2Fkernel.2Fconfig.d
Essentially, if you need nvme modules, you can add something like:
to /etc/kernel/config.d/my_patches.config
You may need more modules than that, that's just an example.
You should see these config changes being logged when emerging the kernel, and can double check the resulting kernel .config to be sure required modules were included before rebooting.
_________________
µgRD dev
Wiki writer |
|
| Back to top |
|
|
alecStewart1
Apprentice
Joined: 03 Jul 2022
Posts: 156
|
| Posted: Mon Nov 25, 2024 5:45 pm Post subject: |
|
|
| zen_desu wrote: |
You can if you're careful that required modules are built into the kernel. If you only need to add a few, this can be done simply with "gentoo-kernel":
https://wiki.gentoo.org/wiki/Project:Distribution_Kernel#Using_.2Fetc.2Fkernel.2Fconfig.d
Essentially, if you need nvme modules, you can add something like:
to /etc/kernel/config.d/my_patches.config
You may need more modules than that, that's just an example.
You should see these config changes being logged when emerging the kernel, and can double check the resulting kernel .config to be sure required modules were included before rebooting. |
I've used savedconfig with the dist-kernel, so I have a kernel .config for 6.6.62 that I can update. If I understand correctly, doing -initramfs on gentoo-kernel, intel-microcode and linux-firmware and then going through the kernel .config and changing CONFIG_SOME_MODULE=m to CONFIG_SOME_MODULE=y.
What would the "best" or "easiest" way to figure out what modules are needed for creating a monolithic kernel (I just remembered the term)/kernel without initramfs? |
|
| Back to top |
|
|
zen_desu
n00b
Joined: 25 Oct 2024
Posts: 28
|
| Posted: Mon Nov 25, 2024 6:27 pm Post subject: |
|
|
I think monolithic would mean a kernel with NO modules. Here, it would probably be most reasonable to make it so kmods aren't required to boot, but can be used later.
Once you build _everything_ into the kernel, you may run into issues, such as firmware loading problems. Some components expect to be modules, especially so firmware can be loaded later. Firmware must be loaded when the kmod is initialized in most cases. If you have a true monolothic kernel this means all required firmware must be builtin to function. This is generally complex and means you can no longer unload/reload modules.
You should still be able to use a microcode initramfs, even with a fully monolothic kernel. This initramfs just contains microcode which is loaded very early in the boot process. The alternative is to build the ucode into the kernel but that is extra work, and having a separate ucode image means you can update microcode without updating your kernel.
I think using ugrd may be a reasonable way to see which kmods are required to boot. It should find them (through various mechanisms) and it will clearly list what it pulls. You can test this it and then use that info to figure out what needs to be built in once you confirm it does what is needed.
_________________
µgRD dev
Wiki writer |
|
| Back to top |
|
|
pietinger
Moderator
Joined: 17 Oct 2006
Posts: 5149
Location: Bavaria
|
| Posted: Mon Nov 25, 2024 6:43 pm Post subject: |
|
|
| alecStewart1 wrote: | [...] I've used savedconfig with the dist-kernel, so I have a kernel .config for 6.6.62 that I can update. If I understand correctly, doing -initramfs on gentoo-kernel, intel-microcode and linux-firmware and then going through the kernel .config and changing CONFIG_SOME_MODULE=m to CONFIG_SOME_MODULE=y.
What would the "best" or "easiest" way to figure out what modules are needed for creating a monolithic kernel (I just remembered the term)/kernel without initramfs? |
I dont recommend to edit the .config (even if your think it is possible) ... but sometimes a module loaded as <M>odule has OTHER dependencies than a module loaded statically <*>
I have a manually configured, signed, monolithic and hardened (with KSPP) kernel (booted by UEFI directly) and I suggest to start here:
https://wiki.gentoo.org/wiki/User:Pietinger/Tutorials/Manual_kernel_configuration (please follow all the links)
You can select whatever you want - maybe you want emerge the newest gentoo-cources (6.12.1 at the moment) and play a little bit with the configuration ... 
In this article you will find also this chapter:
https://wiki.gentoo.org/wiki/User:Pietinger/Tutorials/Manual_kernel_configuration#Before_you_start
_________________
https://wiki.gentoo.org/wiki/User:Pietinger |
|
| Back to top |
|
|
alecStewart1
Apprentice
Joined: 03 Jul 2022
Posts: 156
|
| Posted: Mon Nov 25, 2024 8:48 pm Post subject: |
|
|
| zen_desu wrote: | I think monolithic would mean a kernel with NO modules. Here, it would probably be most reasonable to make it so kmods aren't required to boot, but can be used later.
Once you build _everything_ into the kernel, you may run into issues, such as firmware loading problems. Some components expect to be modules, especially so firmware can be loaded later. Firmware must be loaded when the kmod is initialized in most cases. If you have a true monolothic kernel this means all required firmware must be builtin to function. This is generally complex and means you can no longer unload/reload modules.
You should still be able to use a microcode initramfs, even with a fully monolothic kernel. This initramfs just contains microcode which is loaded very early in the boot process. The alternative is to build the ucode into the kernel but that is extra work, and having a separate ucode image means you can update microcode without updating your kernel.
I think using ugrd may be a reasonable way to see which kmods are required to boot. It should find them (through various mechanisms) and it will clearly list what it pulls. You can test this it and then use that info to figure out what needs to be built in once you confirm it does what is needed. |
Okay, so, I'm getting a bit lost in the weeds here, but let me see if I understand here with presenting what I think it actionable.
Change the USE flags I have for sys-kernel/installkernel to be
| Code: |
ugrd uki efistub -dracut -systemd -systemd-boot -refind -grub
|
Change sys-kernel/gentoo-kernel to have the following USE flags (hardened is implied on my profile)
| Code: |
experimental savedconfig modules-compress modules-sign -initramfs
|
Make sure sys-kernel/linux-firmware is installed with the following USE flags
| Code: |
compress-zstd deduplicate savedconfig dist-kernel redistributable -initramfs
|
Make sure sys-firmware/intel-microcode is installed with the following USE flags
| Code: |
hostonly initramfs dist-kernel
|
Reinstall the above packages, see what firmware and kmods ugrd reports.
Then...?
Or, for sys-firmware/intel-microcode I need to have sys-kernel/gentoo-kernel have +initramfs, or do I need to turn off initramfs for sys-firmware microcode? |
|
| Back to top |
|
|
zen_desu
n00b
Joined: 25 Oct 2024
Posts: 28
|
| Posted: Mon Nov 25, 2024 8:54 pm Post subject: |
|
|
the linux-firmware initramfs USE flag essentially makes amd microcode, while the initramfs USE flag for the intel package makes intel microcode. You only really need initramfs set on whichever matches your processor.
If you set "-initramfs" on the kernel packages, it won't require installkernel has an initrd generator (ugrd or dracut) set. If you first emerge installkernel with ugrd support, then you can run it and check which kmods it tries to pull and use those as a base for what you will build into your kernel. It's worth making sure it actually boots at least once to be reasonably sure the kmods listed are what you need.
Once you have an idea of which kmods you need, you can simply enable them in your kernel config with Y instead of M then rebuild the kernel. This resulting kernel should not need an initramfs.
_________________
µgRD dev
Wiki writer |
|
| 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
|
|
Kernel & Hardware
