The Dracut Initramfs Generator Is Slow - Could Be Much Faster As Shown By Distri's Minitrd

[anarki2]

Those 'few seconds' add up when installing a new kernel that, for example, has several dkms modules, etc. In my case, I have 5 different dkms modules that are installed with every kernel update. Considering the kernel updates several times a month, it can take quite a while to wait for everything to be regenerated. Every second counts.

Speeding up dracut won't speed up the module build. Mellanox modules take like minutes to build. DKMS is a horrible design as a whole, you rebuild when your module changes, you rebuild when your kernel changes. Yet you're worried about the few seconds the initramfs update takes.

But why does every second count to begin with? Are you blocked from doing other things while your initramfs is being built? I don't get it. I'm not even doing manual upgrades, apt and yum does that for me, every day, automatically, in the background. I'm not even noticing anything.

[BwackNinja]

No, you don't need udev for that:

http://man7.org/linux/man-pages/man8/findfs.8.html

This is also not about systemd, but copying everything into the initramfs, which shares little to no services with the final system.
And Dracut is a bunch of maintained scripts (does some funny things like polling devices since systemd is not used for that), not really possible to separate the root and initramfs (means a broken systemd will kill the initramfs aswell), and a pain to setup if you want to use it somewhere else than the running system.

Unless you have some complicated setup, with needing udev to load multiple layers of drivers, I don't see the big appeal.

The appeal is much simpler than that. An initramfs is a small Linux system whose purpose is (usually) to find and load a bigger Linux system. While there are leaner alternatives available for various functions it performs, using the same components in the initramfs that are used on a regular system means a reduced maintenance burden and an greater expectation of consistency in behavior between the initramfs and the full system.

[discordian]

The appeal is much simpler than that. An initramfs is a small Linux system whose purpose is (usually) to find and load a bigger Linux system. While there are leaner alternatives available for various functions it performs, using the same components in the initramfs that are used on a regular system means a reduced maintenance burden and an greater expectation of consistency in behavior between the initramfs and the full system.

There is no inconsistency, unless you want to do things the full system is doing. There is little overlap in functionality and the less you do in the initramfs the less issues you can expect.
The problem with dracut is that its a dead-end, you cant scale down (in case you just need a local mount), you cant scale up to have one initramfs for multiple OS (you can run into the inconsistencies there as you copy over userspace tools from *one* of these OSes).
Its alot easier to add (e)udev to initramfs-tools than rip something out from dracut, means you can start from a simple local boot and build one that mounts USB Devices, renames network interfaces by simply adding to it. A single initramfs for multiple OSes is possible aswell.

[pal666]

hey, but at least dracut is bunch of shell scripts unix way

[BwackNinja]

There is no inconsistency, unless you want to do things the full system is doing. There is little overlap in functionality and the less you do in the initramfs the less issues you can expect.
The problem with dracut is that its a dead-end, you cant scale down (in case you just need a local mount), you cant scale up to have one initramfs for multiple OS (you can run into the inconsistencies there as you copy over userspace tools from *one* of these OSes).
Its alot easier to add (e)udev to initramfs-tools than rip something out from dracut, means you can start from a simple local boot and build one that mounts USB Devices, renames network interfaces by simply adding to it. A single initramfs for multiple OSes is possible aswell.

I agree with you, because I prefer a more minimal system myself. I did run without an initramfs at all for several years, but the key words you said are "unless you want to do things the full system is doing"...

If the bootloader isn't doing everything itself to give you an accessible root device (which itself means duplicated functionality that needs to be maintained separately), for example when you're running systemd-boot on a UEFI system rather than GRUB2, you'll still have several tools to run that are the same as (or perform the same functions as) tools on the full system. You load a variable set of modules (because your hardware can change, or you're booting this on a completely different machine) and wait for devices to appear -- your hard drive controller and drives themselves -- and udev fits that bill. You might need to assemble your software RAID for your root filesystem, invoking mdadm because you're not using the old metadata format that the Linux kernel can handle itself. You might be running things on an LVM, thus invoking another daemon. Or encrypted, yet another, and maybe plymouth for a place to type your password, even if you're not using its splash screen functionality. And then you're running a number of services, potentially with dependencies on each other, so you toss in a service manager rather than working to get your scripts just right. And now you have everything but the kitchen sink.

Again, I agree with you that it can be done more minimally and dracut's initramfs is bigger than it needs to be -- especially for the simplest (and probably most common) use-case. Unfortunately for anyone with those sentiments, its goals as well the goals of the distributions that use it are to be comprehensive and reliable. Efficiency, whether measured by speed or size, is secondary.

[discordian]

I agree with you, because I prefer a more minimal system myself. I did run without an initramfs at all for several years, but the key words you said are "unless you want to do things the full system is doing"...

Ok then, I guess I am a bit sour because I fell for dracut's advertised advantages only to realise that this is quite the opposite of what I expected.

If the bootloader isn't doing everything itself to give you an accessible root device (which itself means duplicated functionality that needs to be maintained separately), for example when you're running systemd-boot on a UEFI system rather than GRUB2, you'll still have several tools to run that are the same as (or perform the same functions as) tools on the full system. You load a variable set of modules (because your hardware can change, or you're booting this on a completely different machine) and wait for devices to appear -- your hard drive controller and drives themselves -- and udev fits that bill. You might need to assemble your software RAID for your root filesystem, invoking mdadm because you're not using the old metadata format that the Linux kernel can handle itself. You might be running things on an LVM, thus invoking another daemon. Or encrypted, yet another, and maybe plymouth for a place to type your password, even if you're not using its splash screen functionality. And then you're running a number of services, potentially with dependencies on each other, so you toss in a service manager rather than working to get your scripts just right. And now you have everything but the kitchen sink..

The point is that the added functionality from dracut is rather small, compared to busybox + a few shell scripts. all of the above is working with debian' mkinitramfs. And that's not requiring to copy copy over alot of software and its depended libraries. I tried reducing the dependencies by using buildroot (its an supported option) which just broke everything.
If I ever find the time, ill try adopting alpines solution for debian, this tool does practically the same as udev: https://github.com/alpinelinux/mkini...lplug-findfs.c

Again, I agree with you that it can be done more minimally and dracut's initramfs is bigger than it needs to be -- especially for the simplest (and probably most common) use-case. Unfortunately for anyone with those sentiments, its goals as well the goals of the distributions that use it are to be comprehensive and reliable. Efficiency, whether measured by speed or size, is secondary.

• I run debian "testing", where updates might break your systems once in a couple years. I dont really see the upside in potentially messing up the initramfs at the same time (ie. I would like to use completely separate tools)
• you cant really DL dracut and setup a different system, you need to install it and it will always inquire your running system
• it has a ton of dependencies of tools, and often a specific, rather new version of them
• it builds the initramfs from whats needed for the boot, but that's pretty much everything by default. making the build complex and not flexible
• it does not seem to be tested much outside of fedora.
• if you try to extend it, you will find its a rather complicated bunch of scripts, even for the simple stuff. Rather hard to inspect, especially if you are trying to extend it.

That's not going into speed or size, its juts very little gain for maximum pain.

[Etherman]

This initramfs stupidity needs to go away.
Things were a lot better when we booted straight to root fs.

Turns out the only thing missing from my system was pressing "y" on ahci sata driver in kernel config and adding root=/dev/sda1 to command line. (current xanmod from AUR)
Now it boots up superfast without initrd.

BTW does the kernel support a more robust root= parameter than root=/dev/sd* ? Because root=UUID=********* does not work.

[skeevy420]

Turns out the only thing missing from my system was pressing "y" on ahci sata driver in kernel config and adding root=/dev/sda1 to command line. (current xanmod from AUR)
Now it boots up superfast without initrd.

BTW does the kernel support a more robust root= parameter than root=/dev/sd* ? Because root=UUID=********* does not work.

/*
 *    Convert a name into device number.  We accept the following variants:
 *
 *    1) <hex_major><hex_minor> device number in hexadecimal represents itself
 *         no leading 0x, for example b302.
 *    2) /dev/nfs represents Root_NFS (0xff)
 *    3) /dev/<disk_name> represents the device number of disk
 *    4) /dev/<disk_name><decimal> represents the device number
 *         of partition - device number of disk plus the partition number
 *    5) /dev/<disk_name>p<decimal> - same as the above, that form is
 *       used when disk name of partitioned disk ends on a digit.
 *    6) PARTUUID=00112233-4455-6677-8899-AABBCCDDEEFF representing the
 *       unique id of a partition if the partition table provides it.
 *       The UUID may be either an EFI/GPT UUID, or refer to an MSDOS
 *       partition using the format SSSSSSSS-PP, where SSSSSSSS is a zero-
 *       filled hex representation of the 32-bit "NT disk signature", and PP
 *       is a zero-filled hex representation of the 1-based partition number.
 *    7) PARTUUID=<UUID>/PARTNROFF=<int> to select a partition in relation to
 *       a partition with a known unique id.
 *    8) <major>:<minor> major and minor number of the device separated by
 *       a colon.
 *    9) PARTLABEL=<name> with name being the GPT partition label.
 *       MSDOS partitions do not support labels!
 *    10) /dev/cifs represents Root_CIFS (0xfe)
 *
 *    If name doesn't have fall into the categories above, we return (0,0).
 *    block_class is used to check if something is a disk name. If the disk
 *    name contains slashes, the device name has them replaced with
 *    bangs.
 */