udev is mandatory for initramfs since genkernel 4.1.0. But in practice it is not convenient for many users: 1. Many Gentoo users configured their kernels to have all modules required for boot without need of external helper. 2. Host system's eudev/systemd can be fine tuned with hand crafted configuration, while user have no control on eudev embedded into initramfs. 3. If user don't have any software RAID, crypto FS or any other fancy FS (like >97% users), eudev in initramfs doesn't really improve anything. 4. initramfs becomes several times larger with eudev, which could be important for embedded systems. 5. boot process is slower, see https://bugs.gentoo.org/738378 6. Double initialisation of hardware could be potentially problematic. A typical situation could be: Gentoo on single SATA (or NVME) SSD, ext4 FS. The only function of initramfs is to find correct partition by UUID and mount it. Busybox alone could do it just fine, no need for blkid, eudev etc. While it's nice to have a universal initramfs, which allow booting on any machine, but Gentoo users typically limit everything to their specific hardware. A huge advantage of Gentoo is ability to exclude bloated software and leave things really needed for user's specific objectives and user's hardware. I really appreciate the hard work on porting eudev to initramfs and I'm sure that it's valuable for many problematic situations where mdev generate problems, but making eudev optional will give users more flexibility. I'd like to remind you the general concept of genkernel: ============================================================= Genkernel's primary job is to bring up only the basic stuff needed to mount your (block) device containing the root filesystem so that we can hand off control to real system as soon as possible. It's _not_ genkernel's goal to load all available modules, to start all available devices, to unlock additional volumes, to start network or do other fancy stuff. ============================================================= I fully agree that devices SHOULD NOT be started by initramfs if they are not required to mount root FS.
(In reply to Karlson2k from comment #0) > udev is mandatory for initramfs since genkernel 4.1.0. And this will *not* change. We switched back(!) to UDEV because this is required mainly for systemd users where it is required that when a device was created, that some metadata were attached to it or systemd-udevd won't be able to use the already existing device afterwards. See bug 706434. However, switching to UDEV has also some benefits for non-systemd users: Relying on events (udev settle) will prevent race-conditions like seen in bug 717774. Also, before genkernel-4.1.1, genkernel tried to load every module listed in modules_load file (genkernel-4 tried to implement smart loading, i.e. stop loading modules once root device became available, but this wouldn't work for when using LVM or LUKS for example). So if you were using a generic kernel configuration (because you booted Gentoo's admin CD to install your system and created your first kernel based on current running kernel like recommended in handbook or you are using genkernel's generic config) you spent some time to load unnecessary modules which are even affecting kernel's memory usage. Since genkernel-4.1.1 and thanks to the switch to udev, we no longer need to process modules_load file blindly all the time. Instead we can rely on udev to load all required drivers. Because by default we only add modules to initramfs listed on modules_load file, there is also no/limited chance to load/start unnecessary modules/devices at all. Keep in mind: genkernel is a large piece of software allowing dozen of different configurations. If we would add support for different device managers we would at least double runtime testing requirement (but it would even affect compilation like we would need to test if X is still building without udev and would even need conditional patching). Even if we would ignore all the mentioned benefits, this is something that we simply cannot do due to limited manpower. So yes, you are right: There are multiple use cases when you don't need what genkernel is providing you. Keep in mind that some setups don't even need an initramfs at all. But in these cases, genkernel is just not the tool designed for you. Stop using genkernel in this case and do everything manually or find a tool which is just doing what you really need the way you want it.
I'm NOT asking to remove UDEV. Not at all! I'm asking to make it OPTIONAL. It could be included by default so novice users will not have any problems (however novice users usually don't have RAID or other fancy FS). But if user know what he/she is doing, option to remove UDEV could be useful to fit specific needs. With limited manpower (resources are always limited, right?), I could prepare a shallow patch which will do the job. We could limit conditions when it's possible to skip udev, like no modules at all in initramfs, no raids etc and explicitly set configuration variable. Does it make sense?
I told that udev can save CPU time, RAM and kernel resources. If we care about all those things, let user ability to choose configuration without udev, so user will be able so save even more resources and time. As a simple example: monolithic kernel without raids.
(In reply to Karlson2k from comment #3) > I told that udev can save CPU time, RAM and kernel resources. Sorry, you told it. :)
> If we would add support for different device > managers we would at least double runtime testing requirement. There are many situations where device manager in initramfs in not needed at all. I'm not talking about alternative device manager, like mdev. I'm not talking about reverting to blind module loading. I'm talking about giving users *ability* to use initramfs without device manager if and only if they configured it and configuration is suitable: no modules, no raids etc. The minimal initramfs should include busybox and, probably, bklid. BTW busybox is still optional, which doesn't make sense with non-optional eudev and other staff.
Sorry, something like that isn't really worth it: From the moment you don't have root on just /dev/sdaX, i.e. using DM (LVM), LUKS, MDRAID, BTRFS, DMRAID, iSCSI or whatever, you will need the other stuff. Now in case you want to support LVM but still want to avoid UDEV, you would have to use a different gkbuild for LVM (no, genkernel's gkbuilds don't support USE flags and implementing something like that would be overkill). But that's not enough: Because we removed all the dead code which called LVM manually, you will now have to provide your own linuxrc script to do that again. And don't forget about the patches we are applying to build stuff statically which isn't always supported by upstream -- you would need to patch conditionally, once for people using udev and once for people avoiding udev. Who is going to maintain all of this? Who is going to test all of this? I can assure you, I won't be that guy, sorry. > Busybox alone could do it just fine, no need for blkid, eudev etc. We recently switch from switch_root implementation provided by busybox to switch_root implementation provided by util-linux because there is a window for a small race-condition because when using switch_root from busybox we have to manually move /dev, /proc, /sys before actually calling switch_root but during that time we are still using these filesystems which can cause troubles. Now that we are building util-linux we are also adding blkid all the time because it's part of util-linux and doesn't really affect build time. What you can do today: Replace everything you don't like using --initramfs-overlay. Or maybe just replace genkernel's linuxrc with your own using --linuxrc parameter doing only what you like. It sounds like genkernel is not the right tool for your need. I wouldn't be surprised if you are also unhappy that using "genkernel --luks all" will enable ciphers you don't use or that "genkernel --mdadm all" will enable every available RAID mode although you only care about RAID1. But that's because genkernel is targeting users getting started with Gentoo. They probably haven't built a kernel before but if they would have to learn what's required to boot their system before getting into Gentoo at all they would be probably lost. > BTW busybox is still optional, which doesn't make sense with non-optional eudev and other staff. Have you actually tried what happens when you try to build kernel/initramfs with --no-busybox? You end up with an initramfs containing basically just /lib/modules -- nothing else. If that is what you are looking for, genkernel is really not your tool.
