Why initrd?

Post Reply
campbell
Posts: 380
Joined: Thu Sep 03, 2015 1:13 pm
languages_spoken: english
ODROIDs: N2, C2, C1+, XU4, XU3, Cloudshell, Smart Power
Contact:

Why initrd?

Unread post by campbell » Fri Mar 01, 2019 10:37 am

What does the initrd accomplish on these boards? Why not boot directly into the root filesystem?

User avatar
rooted
Posts: 6435
Joined: Fri Dec 19, 2014 9:12 am
languages_spoken: english
Location: Gulf of Mexico, US
Contact:

Re: Why initrd?

Unread post by rooted » Fri Mar 01, 2019 10:43 am

Initrd contains modules which aren't built in which can be loaded before root.

Example, say ext4 is a module instead of built in and / is on an ext4 partition. You couldn't load / because the module is on /.

campbell
Posts: 380
Joined: Thu Sep 03, 2015 1:13 pm
languages_spoken: english
ODROIDs: N2, C2, C1+, XU4, XU3, Cloudshell, Smart Power
Contact:

Re: Why initrd?

Unread post by campbell » Fri Mar 01, 2019 10:50 am

rooted wrote:
Fri Mar 01, 2019 10:43 am
Initrd contains modules which aren't built in which can be loaded before root.

Example, say ext4 is a module instead of built in and / is on an ext4 partition. You couldn't load / because the module is on /.
I know what they are for in general on x86 systems, my question was specifically about these boards. ext4 support IS built into the kernel. On Arch Linux ARM /boot/ isn't even a separate partition, it's just a directory on the same ext4 partition as rootfs, which means the Hardkernel uboot is perfectly capable of having /boot/ be ext4. So why even load a uInitrd if the ext4 partition is already being read?

User avatar
rooted
Posts: 6435
Joined: Fri Dec 19, 2014 9:12 am
languages_spoken: english
Location: Gulf of Mexico, US
Contact:

Re: Why initrd?

Unread post by rooted » Fri Mar 01, 2019 11:01 am

I don't think it's necessary and I had no way of knowing you understood what it was for.

What is your concern?

campbell
Posts: 380
Joined: Thu Sep 03, 2015 1:13 pm
languages_spoken: english
ODROIDs: N2, C2, C1+, XU4, XU3, Cloudshell, Smart Power
Contact:

Re: Why initrd?

Unread post by campbell » Fri Mar 01, 2019 11:06 am

rooted wrote:
Fri Mar 01, 2019 11:01 am
I don't think it's necessary and I had no way of knowing you understood what it was for.

What is your concern?
It seems like an unnecessary complication. Building the kernel and dtb and modules is easy, supplying a rootfs from your distribution of choice is easy, but the guidance for building an initrd seems to be "find an existing initrd and modify according to your needs".

Also, I really don't understand how it works on the Odroid N2 Ubuntu image. The actual boot partition is mounted at /media/boot, but there is also a /boot/, which is not an exact copy of it. When you do apt-get upgrade, files in both places get touched, but it's hard to tell what's actually happening. I don't remember the C2 being this complicated.

User avatar
rooted
Posts: 6435
Joined: Fri Dec 19, 2014 9:12 am
languages_spoken: english
Location: Gulf of Mexico, US
Contact:

Re: Why initrd?

Unread post by rooted » Fri Mar 01, 2019 11:22 am

I agree about /boot > /media/boot being strange, I don't understand it.

I even wish /boot wasn't a separate partition but I understand the need for it to be.

I don't know why we use initrd either, likely there is a reason and someone will enlighten us.

mlinuxguy
Posts: 840
Joined: Thu Feb 28, 2013 10:28 am
languages_spoken: english
ODROIDs: X, X2, XU, XU3, XU4, C1, C1+, C2, N1, USB-IO
Contact:

Re: Why initrd?

Unread post by mlinuxguy » Fri Mar 01, 2019 12:15 pm

The initrd image as you said holds information that allows the system to boot up.
For example if I load a SAN device driver onto my system (say a RHEL OS), I would need to run dracut afterwards
to read any new kernel modules in and load them into the initrd image. If I fail to do that step it could be that
I won't boot (or not recognize the new devices at boot).

The initrd image is loaded by the kernel prior to when the real root filesystem becomes available. If you compile
the needed kernel modules to boot into the kernel then you do not need this image, as in the case of the N2.
However, linux in general doesn't know this and always recreates the initrd image (or initramfs image) after certain updates.
As far as I know we don't use it to boot. If you check /media/boot it has no initrd image, our kernel comes from the Image.gz file.

An interesting test would be to do something custom in a script in initrd and see if it ever gets executed... I suspect not.
For grins I extracted the N2's initrd image to /tmp

Code: Select all

root@odroidn2-1:/tmp/hold# ls
bin  conf  etc  init  lib  run  sbin  scripts  usr  var
You can see where you could put a custom script here:

Code: Select all

root@odroidn2-1:/tmp/hold# ls scripts/
functions  init-bottom  init-premount  init-top  local  local-block  local-bottom  local-premount  local-top  nfs  panic
And here you can see that initrd is a copy of our N2's /etc/modprobe.d/ subdir (as would be expected since recreated if modules change)

Code: Select all

root@odroidn2-1:/tmp/hold# ls etc
console-setup  dhcp   ld.so.cache  ld.so.conf.d  motd  nsswitch.conf  passwd    udev
default        fstab  ld.so.conf   modprobe.d    mtab  os-release     plymouth
root@odroidn2-1:/tmp/hold# ls etc/modprobe.d/
blacklist-ath_pci.conf   blacklist-framebuffer.conf   blacklist.conf  rtl_sdr.conf
blacklist-firewire.conf  blacklist-rare-network.conf  iwlwifi.conf
root@odroidn2-1:/tmp/hold# ls /etc/modprobe.d/
blacklist-ath_pci.conf   blacklist-framebuffer.conf   blacklist.conf  rtl_sdr.conf
blacklist-firewire.conf  blacklist-rare-network.conf  iwlwifi.conf
Note: you can do some fancy things by having enough /bin executables to somewhat debug a non-booting system loaded into initrd.
Last edited by mlinuxguy on Fri Mar 01, 2019 12:21 pm, edited 1 time in total.

campbell
Posts: 380
Joined: Thu Sep 03, 2015 1:13 pm
languages_spoken: english
ODROIDs: N2, C2, C1+, XU4, XU3, Cloudshell, Smart Power
Contact:

Re: Why initrd?

Unread post by campbell » Fri Mar 01, 2019 12:19 pm

mlinuxguy wrote:
Fri Mar 01, 2019 12:15 pm
The initrd image as you said holds information that allows the system to boot up.
For example if I load a SAN device driver onto my system (say a RHEL OS), I would need to run dracut afterwards
to read any new kernel modules in and load them into the initrd image. If I fail to do that step it could be that
I won't boot (or not recognize the new devices at boot).

The initrd image is loaded by the kernel prior to when the real root filesystem becomes available. If you compile
the needed kernel modules to boot into the kernel then you do not need this image, as in the case of the N2.
However, linux in general doesn't know this and always recreates the initrd image (or initramfs image) after certain updates.
As far as I know we don't use it to boot. If you check /media/boot it has no initrd image, our kernel comes from the Image.gz file.

An interesting test would be to do something custom in a script in initrd and see if it ever gets executed... I suspect not.
But there IS a uInitrd in /media/boot/, and the booti command in boot.ini DOES tell uboot to use it. The documentation for booti suggests that you can substitute "-" for that argument instead of an actual initrd, but if we do that, does uboot know how to find the root filesystem? (Not how to mount it - we know uboot and the kernel already have ext4 builtin and not as a module).

mlinuxguy
Posts: 840
Joined: Thu Feb 28, 2013 10:28 am
languages_spoken: english
ODROIDs: X, X2, XU, XU3, XU4, C1, C1+, C2, N1, USB-IO
Contact:

Re: Why initrd?

Unread post by mlinuxguy » Fri Mar 01, 2019 12:31 pm

You are correct, its been too long since I messed with those files.
We do need to have a uInitrd image, I recall now having to recreate that when it was deleted.
and I think we had to update it when we tried for booting off either the network or a USB disk (don't recall which).

User avatar
memeka
Posts: 4230
Joined: Mon May 20, 2013 10:22 am
languages_spoken: english
ODROIDs: XU rev2 + eMMC + UART
U3 + eMMC + IO Shield + UART
Contact:

Re: Why initrd?

Unread post by memeka » Fri Mar 01, 2019 1:15 pm

re: /boot and /media/boot
this is specific to Ubuntu - it is not a HK thing, they merely follow the "Ubuntu way" :)
/media/boot is the actually partition, which contains initrd, kernel, and boot.ini. Usually they are not versioned (e.g. you have uInitrd).
/boot is part of rootfs, and contains versioned config, initrd etc. (e.g. uIinitrd-4.14.100, uInitrd-4.14.101).
I think the rationale is /boot should be on rootfs because rootfs is bigger than the boot partition - /media/boot space is limited and contains only current kernel.

User avatar
tobetter
Posts: 2807
Joined: Mon Feb 25, 2013 10:55 am
languages_spoken: Korean, English
ODROIDs: X, X2, U2, U3, XU3, C1
Location: Paju, South Korea
Contact:

Re: Why initrd?

Unread post by tobetter » Fri Mar 01, 2019 1:27 pm

We can omit the second parameter which is for initrd with boot* command then Linux kernel will directly look up the root file system given by the command line like root=/dev/mmclbk0p1 or root=UUID=..... The advantage of using initrd is that when Linux kernel fails to boot because it is not able to find out the root file system or init is not exist, we can have a shell from initrd at least. Such that we can recover or find out the problem. Otherwise, the Linux kernel will keep rebooting.

Personally, I don't like to mount the boot partition to /media/boot, not /boot, on HK's Ubuntu release. That's one reason why I prefer my Debian installation. :)

And one reason why the boot partition is not ext2/3/4 is because of boot.ini. There are still many people does use Windows which does not access such a file system directly and this makes people modify the boot.ini.

campbell
Posts: 380
Joined: Thu Sep 03, 2015 1:13 pm
languages_spoken: english
ODROIDs: N2, C2, C1+, XU4, XU3, Cloudshell, Smart Power
Contact:

Re: Why initrd?

Unread post by campbell » Fri Mar 01, 2019 2:00 pm

tobetter wrote:
Fri Mar 01, 2019 1:27 pm
We can omit the second parameter which is for initrd with boot* command then Linux kernel will directly look up the root file system given by the command line like root=/dev/mmclbk0p1 or root=UUID=..... The advantage of using initrd is that when Linux kernel fails to boot because it is not able to find out the root file system or init is not exist, we can have a shell from initrd at least. Such that we can recover or find out the problem. Otherwise, the Linux kernel will keep rebooting.
Thanks for the tip. I just tried this and I can confirm that with root=/dev/mmcblk0p2 in the kernel args, and the stuff about uInitrd omitted from booti, the Ubuntu image boots just fine without initrd.

(Interestingly, the root=UUID=e139ce78-9841-40fe-8823-96a304a09859 was ALREADY in the kernel args, and that is indeed the UUID of /dev/mmcblk0p2, but for some reason that doesn't work. It only works when I change it to root=/dev/mmcblk0p2)

User avatar
OverSun
Posts: 1432
Joined: Mon Apr 29, 2013 5:12 pm
languages_spoken: english
Contact:

Re: Why initrd?

Unread post by OverSun » Fri Mar 01, 2019 2:17 pm

campbell wrote:
Fri Mar 01, 2019 2:00 pm
(Interestingly, the root=UUID=e139ce78-9841-40fe-8823-96a304a09859 was ALREADY in the kernel args, and that is indeed the UUID of /dev/mmcblk0p2, but for some reason that doesn't work. It only works when I change it to root=/dev/mmcblk0p2)
I was going to write it, but you answered it yourself.
Initrd is not really required, you can boot without it. Initrd is required for root=UUID= parameter, it's not kernel specific, this UUID= part work only with initrd. In this particular case this is very useful because people are going to flash image to eMMC or SD, and they are different /dev/mmcblk(0/1). Image composed that way is universal, without it, it would be SD/eMMC specific.

User avatar
tobetter
Posts: 2807
Joined: Mon Feb 25, 2013 10:55 am
languages_spoken: Korean, English
ODROIDs: X, X2, U2, U3, XU3, C1
Location: Paju, South Korea
Contact:

Re: Why initrd?

Unread post by tobetter » Fri Mar 01, 2019 2:30 pm

One comment on top of @OverSun's comment, you can use PARTUUID=... instead of UUID=..., which is the partition ID while UUID is the file system ID. Practically, one of script in initrd converts UUID=... to PARTUUID=... before chroot. One difficulty of using /dev/mmcblk* for ODROID device was that the /dev/mmcblk0 was always the boot device eMMC or SD card in prevideo ODROID SBCs, but for ODROID-N2, /dev/mmcblk0 is eMMC and /dev/mmcbk1 is SD card.

User avatar
mad_ady
Posts: 5398
Joined: Wed Jul 15, 2015 5:00 pm
languages_spoken: english
ODROIDs: XU4, C1+, C2, N1, H2, N2
Location: Bucharest, Romania
Contact:

Re: Why initrd?

Unread post by mad_ady » Fri Mar 01, 2019 2:38 pm

One important thing that initrd does is that it can fsck the rootfs before switching to it

umiddelb
Posts: 450
Joined: Thu Jan 29, 2015 6:42 am
languages_spoken: English, German
ODROIDs: ODROID-C1, ODROID-XU4, ODROID-C2
Contact:

Re: Why initrd?

Unread post by umiddelb » Fri Mar 01, 2019 3:59 pm

tobetter wrote:
Fri Mar 01, 2019 1:27 pm
...
And one reason why the boot partition is not ext2/3/4 is because of boot.ini. There are still many people does use Windows which does not access such a file system directly and this makes people modify the boot.ini.
Older u-boot versions have difficulties to read from ext2/ext4 filesystems and even today you need to omit some features during file system creation. For the C2 the ext4 filesystem needs to be created without journaling and 64bit support (-O ^has_journal -O ^64bit), otherwise u-boot is unable to access the kernel image, etc.

IHMO systemd requires/supposes that you boot your Linux system via initrd. It is not that complicated to create or maintain a initrd, the only thing you need is the current kernel configuration:

Code: Select all

kver=`make kernelrelease`
arch="arm64"
sudo update-initramfs -c -k ${kver}
sudo mkimage -A ${arch} -O linux -T ramdisk -a 0x0 -e 0x0 -n initrd-${kver}.img -d initrd.img-${kver} uInitrd-${kver}

campbell
Posts: 380
Joined: Thu Sep 03, 2015 1:13 pm
languages_spoken: english
ODROIDs: N2, C2, C1+, XU4, XU3, Cloudshell, Smart Power
Contact:

Re: Why initrd?

Unread post by campbell » Fri Mar 01, 2019 5:26 pm

umiddelb wrote:
Fri Mar 01, 2019 3:59 pm
IHMO systemd requires/supposes that you boot your Linux system via initrd.
Can you explain? What specific functionality is missing from systemd if you do not boot via initrd? The documentation at https://www.freedesktop.org/wiki/Softwa ... Interface/ says that "systemd supports initrd and initrd-less boots".

back2future
Posts: 197
Joined: Sun Jul 23, 2017 3:19 pm
languages_spoken: english
Contact:

Re: Why initrd?

Unread post by back2future » Fri Mar 01, 2019 7:05 pm

If one wants or needs a backup rootfs or boots without using storage access for rootfs an initrd (initial ram disk) is one possibility, besides extended kernels, that include .dtb and rootfs itself.
Kernel/initrd/device tree is naming for boot 'image' parts and entry points within. (Some for x86/x64 are widely fixed entry points, because platform does not differ (that much) for different vendors, while embedded devices emphasize this because of hardware needs. Grub for x86/x64 provides some feedback on loading initrd images, that helps understanding this boot process, while 'goto' initrd_load().). Without a bootloader (on EFI that's possibly a kernel: CONFIG_EFI_STUB) loading initrd (for a kernel) ramdisk files are not available from ram for an os.rootfs. Never heard about loading initrd (to where?) for a running os after booting has finished and systemd maintains processes. Further having an initrd (within an extended/more capable boot process: seconds or ms?) can slim the kernel because of less built-in modules.
That's one reason
depends on os and purpose
[What os' keep initrd persistently at ram?]
Last edited by back2future on Fri Mar 01, 2019 8:16 pm, edited 2 times in total.

User avatar
OverSun
Posts: 1432
Joined: Mon Apr 29, 2013 5:12 pm
languages_spoken: english
Contact:

Re: Why initrd?

Unread post by OverSun » Fri Mar 01, 2019 7:45 pm

Let me summarize that.
1) initrd is not a requirement. if you know how to deal with your Linux and you don't want initrd - noone forces you to.
2) prebuilt odroid images utilizes initrd because of convenience that brings to booting the system
Dixi.

crashoverride
Posts: 4314
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1
Contact:

Re: Why initrd?

Unread post by crashoverride » Fri Mar 01, 2019 8:19 pm

Since nobody has yet mentioned it, I will add that what is need to is to get rid of the uInitrd the same as we got rid of the uImage. Wrapping initrd with a uboot specific header does not provide any additional function or features. It only makes the build process non-standard by requiring the 'mkimage' command. We should be using the product of 'update-initramfs' directly without any further processing.

umiddelb
Posts: 450
Joined: Thu Jan 29, 2015 6:42 am
languages_spoken: English, German
ODROIDs: ODROID-C1, ODROID-XU4, ODROID-C2
Contact:

Re: Why initrd?

Unread post by umiddelb » Mon Mar 04, 2019 5:19 am

campbell wrote:
Fri Mar 01, 2019 5:26 pm
umiddelb wrote:
Fri Mar 01, 2019 3:59 pm
IHMO systemd requires/supposes that you boot your Linux system via initrd.
Can you explain? What specific functionality is missing from systemd if you do not boot via initrd? The documentation at https://www.freedesktop.org/wiki/Softwa ... Interface/ says that "systemd supports initrd and initrd-less boots".
Lennart Poettering mentioned this during his interview with Tim Pritlove. Unfortunately the whole interview is in German and things might have been changed in the meantime ...

campbell
Posts: 380
Joined: Thu Sep 03, 2015 1:13 pm
languages_spoken: english
ODROIDs: N2, C2, C1+, XU4, XU3, Cloudshell, Smart Power
Contact:

Re: Why initrd?

Unread post by campbell » Mon Mar 04, 2019 10:58 am

Having the filesystem that contains the kernel and boot.ini and the dtb be fat32 is not without disadvantages. I'm currently reflashing my emmc because that filesystem got corrupted during a bad unmount. It would be really great if the OS image would come with the tools to fsck the type of filesystem containing the kernel...

campbell
Posts: 380
Joined: Thu Sep 03, 2015 1:13 pm
languages_spoken: english
ODROIDs: N2, C2, C1+, XU4, XU3, Cloudshell, Smart Power
Contact:

Re: Why initrd?

Unread post by campbell » Mon Mar 04, 2019 11:00 am

umiddelb wrote:
Fri Mar 01, 2019 3:59 pm
IHMO systemd requires/supposes that you boot your Linux system via initrd.
Ironically, having an initrd makes NOT using systemd a bit easier. Without initrd, and without a proper init, you have to mount /sys/ and /proc/ by hand after booting into init=/bin/bash, whereas, with an initrd, those things are done for you.

Post Reply

Return to “Ubuntu”

Who is online

Users browsing this forum: No registered users and 1 guest