/boot/initrd vs. /boot/initrd.img

Robotics & Edge Computing Jetson & Embedded Systems Jetson Xavier NX
1

Dear Experts,

In /boot I have files called both “initrd” and “initrd.img”. Only “initrd” is present on the original SD card image. I think that initrd.img must have been created by something like update-initramfs during the first Ubuntu startup, or something.

extlinux.conf only refers to “initrd”, so “initrd.img” is not used unless I change extlinux.conf. If I do change to initrd.img the board still boots.

Some differences that I have noticed include:

  • initrd doesn’t understand root=UUID=xxxxxx; it only understands root=PARTUUID=xxxxx.

  • initrd.img lacks the xusb firmware.

  • initrd doesn’t seem to “rootwait”, i.e. it doesn’t wait for a root device that takes a while to appear, and that includes NVMe SSDs.

initrd is much smaller than initrd.img. My guess is that initrd is Nvidia’s custom version and initrd.img is the Ubuntu version. So, does the Nvidia version have any “magic” in it that I don’t get if I use the Ubuntu version?

initramfs-tools have lots of customisation hooks; it would be great if L4T used those to adapt the regular Ubuntu/Debian initrd, rather than creating its own.

The situation seems to be the same on both the Nano and the Xavier NX.

Thanks for any insight!
Phil.

4

Typically “/boot/initrd” (at least on a Jetson) is just a symbolic link to the real file. For example, in this “ls -l /boot/initrd*”, the “initrd.img” is not a real file:

/boot# ls -l initrd*
-rw-r--r-- 1 root root  5488163 Jul  1 03:52 initrd
lrwxrwxrwx 1 root root       24 Jan 28  2018 initrd.img -> initrd.img-4.9.140-tegra
-rw-r--r-- 1 root root 15225477 Jul 27 12:42 initrd.img-4.9.140-tegra

Depending on the boot software, it wouldn’t be unusual that the one being used is from the “INITRD” key/value pair of “/boot/extlinux/extlinux.conf”, e.g.:

LABEL primary
...
      INITRD /boot/initrd
...

Quite often Linux (or any *NIX) will have several versions of files available. Perhaps a library, perhaps an initrd…it doesn’t really matter. In case an application looks for only the most generic file name, then typically this will be a symbolic link pointing to the real file which has a specific release verison in its name. Then, if the more specific version is updated, then the symbolic link can point at the new version without the end application needing to make any such distinction.

Not all of the Jetsons use extlinux.conf in the same way. Earlier releases used this all the time since U-Boot was always used. There is an earlier boot stage though, CBoot, and in Xavier (and I think NX) U-Boot is not used. For a while L4T releases on those platforms no longer used extlinux.conf, but U-Boot functionality has been slowly added back in via CBoot (U-Boot is still not used for these, but the behavior now mimics U-Boot for the extlinux.conf file), and so more recent L4T releases on these relevant platforms use extlinux.conf (and thus the INITRD key/value pair) to determine which initrd image to use.

In the end, if the initrd comes from “/boot”, the actual file is just a tar and cpio archive. This is rather simple and has a tree of files, but there is no traditional filesystem, and thus no need for special drivers. The initrd itself is not custom, but the process of finding and using the initrd might be different on a Jetson. More than one initrd can be used if you create extra boot entries in extlinux.conf, and then use serial console to pick the entry at boot.

Although the initrd is itself 100% generic in its mechanism, and not different from that of a desktop PC, the boot environment and architecture is different, and there would be some reflection of this in the initrd content. A PC has a CMOS BIOS/UEFI, and a Jetson does not…most of those other non-rootfs partitions of a Jetson are the equivalent of the CMOS setting things up for the bootloader. Once those services load the Linux kernel and initrd (if used), then the content of the initrd supports arm64, and any custom “BIOS” style functions do not exist. The mechanism of the initrd itself is entirely stock, the content surrounding initrd are mandated by the boot environment.

1 Like
5

But it’s not, as your ls shows:

Yes initrd.img is a link to initrd.img-4.9.140-tegra, but initrd (with no extension) is a different file.

Regards, Phil.

6

Only the file on your system matters, mine was just to illustrate.

What does your “/boot/extlinux/extlinux.conf” show? To complicate this question, depending on how you flashed, this might be the extlinux.conf on the eMMC, or the one on any alternate rootfs media. Is your module eMMC or microSD?

Note that when you flash that parameters will essentially set up the NX to search for the extlinux.conf within local “/boot/extlinux” content, or on remote “/boot/extlinux” content: There are two possible versions of the same file, and the one actually used may not be the one you expect.

I have not used an external SSD for this, so I have no way of testing, but flash instructions to external media tends to be specific for both the L4T release and Jetson model. If you are looking at the correct extlinux.conf, then I would expect the UUID to work. Incidentally, you can mount on a host PC by UUID as well; this would be a good test of whether the mount by that UUID is valid.

If you really want to know what is in a particular initrd, then this is just a cpio tar archive you can unpack. An example, if you copy your initrd to an empty temporary directory as name “initrd”, would be:

# Do this in a clean temp directory:
gunzip < initrd > initrd.cpio
# This unpacks in the current directory:
sudo cpio -vid < initrd.cpio

…and you will then be able to explore the created subdirectory, which should include some minimal init system. Once in that subdirectory, what do you see from:
ls -ld $(find . -print)

7

Yes, I know how to unpack an initrd etc. etc. I’m not new to this stuff and thanks for your long posts but with respect I don’t need a tutorial

Does anyone have any insight into my original question - is there any rationale for the presence of the confusingly-similar-named initrd and initrd.img files, and does initrd have any “magic” in it that the Ubuntu-generated initrd.img lacks?

Thanks, Phil.

8

may I know what is the purpose of the investigation?
is there any particular concern or purpose?

9

My concern is that initrd might contain some custom Nvidia initialisation that I’m missing by using initrd.img.

I also have a suspicion that the existence of the two files is unintentional, and I wanted to bring this to the attention of whoever is responsible.

1 Like
10

the initrd present in sd card is nvidia created. This is only 5MB Image.
What ubuntu is created is not having the customization nvidia has done.