How long should "loading ramdisk" take?

tashirosgt · #1 23rd May 2012, 04:23 PM

How long does the process "loading ramdisk" typically take on a computer with FC 16 and modern hardware?

Very early in the boot process of FC 16-64, the "loading ramdisk" messages appears. It takes 3 or 4 seconds to complete on a newly built machine with an SSD. ( All directories (including /boot) are on the SSD except for /var, /tmp and /home.) I'm curious whether people with spinning hard drives get similar times.

***Gareth Jones*** · #2 23rd May 2012, 06:03 PM

That sounds about normal. I'm not sure if it's because the boot-loader has to use BIOS routines to load the initramfs image, or whether it's decompression that takes so long.

dd_wizard · #3 23rd May 2012, 07:37 PM

I saw a post somewhere on how to boot Fedora without an intiial ramdisk, but I've never tried it. Apparently, the kernel knows how to boot an ext4 system without it.

dd_wizard

tashirosgt · #4 24th May 2012, 08:22 AM

What mystifies me is why "loading ramdisk" appears to take about 1 second or leses on a system with a Gigabyte GA-K8N ultra-sli motherboard and 2 core Athlon processor, while it takes about 5 seconds (or even longer) on a newer system with a GA-970A-UD3 and a quad core AMD Phenom processor.

Both systems have the same model Intel SSD and the same model Samsung laptop hard drive in them. Both have FC 16 with the same software and updates. The only significant difference in how the filesystems are arranged is that (by my mistake) the newer system has /boot as an ext4 filesystem and the older system has it as a ext2 filesystem.

After the "loading ramdisk" phase is over, the newer system gets through the rest of the boot process much faster than the old system.

I'm not obsessed with shaving seconds off of boot times. I just want to avoid any obvious configuration errors.

Cygn · #5 24th May 2012, 11:55 AM

Code:

$ systemd-analyze time
Startup finished in 1417ms (kernel) + 10958ms (initramfs) + 3258ms (userspace) = 15634ms

This is on a core 2 duo @3Ghz with a SSD. From what I've gathered, and compared to two older laptops both running F16, my initramfs time is at least twice longer then usual.

Quote:

Originally Posted by dd_wizard

I saw a post somewhere on how to boot Fedora without an intiial ramdisk, but I've never tried it. Apparently, the kernel knows how to boot an ext4 system without it.

dd_wizard

http://freedesktop.org/wiki/Software.../Optimizations

Code:

$ systemd-analyze time
Startup finished in 1290ms (kernel) + 5834ms (userspace) = 7125ms

***Gareth Jones*** · #6 24th May 2012, 04:36 PM

Quote:

Originally Posted by dd_wizard

I saw a post somewhere on how to boot Fedora without an intiial ramdisk, but I've never tried it. Apparently, the kernel knows how to boot an ext4 system without it.

Yes, I think you only strictly need an initramfs if your root volume is LVM/RAID/encrypted, or some other non-trivial set-up. There was a note about skipping the initramfs on the Lennart's Systemd blog recently.

---------- Post added at 04:36 PM ---------- Previous post was at 04:28 PM ----------

Quote:

Originally Posted by tashirosgt

What mystifies me is why "loading ramdisk" appears to take about 1 second or leses on a system with a Gigabyte GA-K8N ultra-sli motherboard and 2 core Athlon processor, while it takes about 5 seconds (or even longer) on a newer system with a GA-970A-UD3 and a quad core AMD Phenom processor.

Are the initramfs images in /boot about the same size?

Quote:

The only significant difference in how the filesystems are arranged is that (by my mistake) the newer system has /boot as an ext4 filesystem and the older system has it as a ext2 filesystem.

I wouldn't call that a mistake, it shouldn't make much difference. Actually, Fedora 16 onwards use the ext4 driver for ext2/3 file-systems too: http://fedoraproject.org/wiki/Featur...ForExt3AndExt2.
From /boot/config-3.3.6-3.fc16.x86_64:

Code:

# File systems
#
# CONFIG_EXT2_FS is not set
# CONFIG_EXT3_FS is not set
CONFIG_EXT4_FS=y
CONFIG_EXT4_USE_FOR_EXT23=y

tashirosgt · #7 24th May 2012, 04:40 PM

Quote:

I saw a post somewhere on how to boot Fedora without an intiial ramdisk, but I've never tried it. Apparently, the kernel knows how to boot an ext4 system without it.

dd_wizard

Quote:

Originally Posted by Cygn

http://freedesktop.org/wiki/Software.../Optimizations

Not that I'll attempt it, but is the passage about bypassing initrd the one that is relevant to skipping the ramdisk?

Quote:

Consider bypassing the initrd, if you use one. On Fedora, make sure to install the OS on a plain disk without encryption, and without LVM/RAID/... (encrypted /home is fine) when doing this. Then, simply edit grub.conf and remove the initrd from your configuration, and change the root= kernel command line parameter so that it uses kernel device names instead of UUIDs, i.e. "root=sda5" or what is appropriate for your system. Also specify the root FS type with "rootfstype=ext4" (or as appropriate). Note that using kernel devices names is not really that nice if you have multiple hard disks, but if you are doing this for a laptop (i.e. with a single hdd), this should be fine. Note that you shouldn't need to rebuild your kernel in order to bypass the initrd. Distribution kernels (at least Fedora's) work fine with and without initrd, and systemd supports both ways to be started.

Since FC 16 has grub2, according to https://help.ubuntu.com/community/Grub2 , I gather that the "proper" way to accomplish this would be to edit
/etc/default/grub and uncomment the entry:

Code:

#GRUB_DISABLE_LINUX_UUID="true"

    Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to Linux

    The search line will still use UUIDs. The linux line will use the /dev/sdXY convention when this option is enabled.

and (after other changes?) we would run

Code:

update-grub

but where do we tell grub2 the device we want? I gather the syntax we want in /boot/grub2/grub.cfg would be like:

Code:

 
linux   /vmlinuz-3.3.5-2.fc16.x86_64 root=/dev/sda1 ro rd.md=0 rd.lvm=0 rd.dm=0  KEYTABLE=us SYSFONT=latarcyrheb-sun16 rd.luks=0 LANG=en_US.UTF-8

if the /boot filesystem is on /dev/sda1.

Of course, people can directly edit /boot/grub2/grub.cfg and ignore the warnings not to do this. I'm beginning to think that on FC 16, that would be the best way since my understanding of yum updates is that they bypass update-grub and use the grubby command to modify /boot/grub2/grub.cfg.

***DBelton*** · #8 24th May 2012, 04:43 PM

Gareth is correct. Most default Fedora installs don't have to have an initramfs. Just a few special cases need it, like the OP, since he specified he has /var on a separate partition (that happens to be one of the few cases that make it necessary) Gareth mentioned a few others, as well, but I'm really not certain about the LVM. It probably does make it necessary to use a initramfs as well.

You could try to rebuild the initramfs with dracut and see if that improves things for you.

This will backup the current initramfs and create a new one for the currently running kernel:

Code:

su -

mv /boot/initramfs-$(uname -r).img /boot/initramfs-$(uname -r)-backup.img
dracut -f /boot/initramfs-$(uname -r).img $(uname -r)

Edit:

To tell it not to boot using a initrd, edit the /boot/grub2/grub.cfg and the line following the kernel line is an initrd line. That is what tells it what initramfs to load. Don't take the UUID= off of your kernel line

Edit:

Yes, you are correct. Fedora uses grubby to update your /boot/grub2/grub.cfg file when it updates the kernel, and not grub2-mkconfig.

tashirosgt · #9 25th May 2012, 09:07 AM

I switched /boot from being ext4 to being ext2 (which was an interesting exercise in Linux system administration!) and it did not shorten the "loading ramdisk" operation.

I'll try rebuilding initramfs with dracut - after I research what that does.

Update: I tried it and the time for loading the ramdisk is about the same.

#10 25th May 2012, 09:21 AM

Quote:

Originally Posted by tashirosgt

I switched /boot from being ext4 to being ext2 (which was an interesting exercise in Linux system administration!) and it did not shorten the "loading ramdisk" operation.

I'll try rebuilding initramfs with dracut - after I research what that does.

Update: I tried it and the time for loading the ramdisk is about the same.

Try

Code:

su
mv /boot/initramfs-$(uname -r).img /boot/initramfs-$(uname -r)-backup.img
dracut -f -H /boot/initramfs-$(uname -r).img $(uname -r)

tashirosgt · #11 26th May 2012, 04:05 AM

Quote:

Originally Posted by Yellowman

Try

Code:

su
mv /boot/initramfs-$(uname -r).img /boot/initramfs-$(uname -r)-backup.img
dracut -f -H /boot/initramfs-$(uname -r).img $(uname -r)

I tried that and did not notice that things went faster. However, your posta and DBelton's got me interested in dracut and, of course, all research in boot times leads to systemd-analyze blame.

The more, I learn the less I know! My impression of the time for "loading ramdisk" was based merely on the visual impression of how long it takes after that messagse appears for the text to begin scrolling on the screen. (I'm using a text boot instead of the "quiet rhgb" boot option.) I tried timing this with a clock and instead of my original impression of 3 to 4 seconds, it's more like 6 to 7 seconds.

Then I learned a better way to estimate the time by reading the "Startup finished in..." messages in /var/log/messages.

Quoting an example from http://0pointer.de/blog/projects/blame-game.html

Quote:

systemd[1]: Startup finished in 2s 65ms 924us (kernel) + 2s 828ms 195us (initrd) + 11s 900ms 471us (userspace) = 16s 794ms 590us.

And here's how you read this: 2s have been spent for kernel initialization, until the time where the initial RAM disk (initrd, i.e. dracut) was started. A bit less than 3s have then been spent in the initrd. Finally, a bit less than 12s have been spent after the actual system init daemon (systemd) has been invoked by the initrd to bring up userspace. Summing this up the time that passed since the boot loader jumped into the kernel code until systemd was finished doing everything it needed to do at boot was a bit less than 17s. This number is nice and simple to understand -- and also easy to misunderstand: it does not include the time that is spent initializing your GNOME session, as that is outside of the scope of the init system. Also, in many cases this is just where systemd finished doing everything it needed to do. Very likely some daemons are still busy doing whatever they need to do to finish startup when this time is elapsed. Hence: while the time logged here is a good indication on the general boot speed, it is not the time the user might feel the boot actually takes.

Some examples of bootup times from /var/.log/messages before I used dracut to rebuilt intitramfs:

Code:

May 20 10:06:28 comp12 systemd[1]: Startup finished in 1s 798ms 63us (kernel) + 1s 576ms 33us (initrd) + 4s 54ms 57us (userspace) = 7s 428ms 153us.

May 20 18:42:06 comp12 systemd[1]: Startup finished in 1s 788ms 343us (kernel) + 1s 650ms 634us (initrd) + 3s 835ms 140us (userspace) = 7s 274ms 117us.

May 21 07:11:13 comp12 systemd[1]: Startup finished in 1s 793ms 388us (kernel) + 1s 599ms 712us (initrd) + 3s 553ms 355us (userspace) = 6s 946ms 455us.

An example after I rebuilt initrafs

Code:

May 25 20:14:10 comp12 systemd[1]: Startup finished in 1s 554ms 616us (kernel) + 1s 545ms 425us (initrd) + 5s 213ms 56us (userspace) = 8s 313ms 97us.

As I interpret those results, either my timing based on visual appearances is way off or something is wrong with the systemd-analyze output to those logs. What exactly goes on between the time the "loading ramdisk" message appears and the text boot text begins scrolling? (On my machine, it begins printing in larger font and after about two screens, it switches to a smaller font.)