R32.3.1 tx2-4g should sudo update-initramfs -u work on my system

I get

sudo update-initramfs -u
[sudo] password for tbuckley:
update-initramfs: Generating /boot/initrd.img-4.9.140-tegra
Warning: couldn’t identify filesystem type for fsck hook, ignoring.
I: The initramfs will attempt to resume from /dev/zram5
I: (UUID=5ba9fe33-4207-430f-8ff4-4580572d1809)
I: Set the RESUME variable to override this.
/sbin/ldconfig.real: Warning: ignoring configuration file that cannot be opened: /etc/ld.so.conf.d/aarch64-linux-gnu_EGL.conf: No such file or directory
/sbin/ldconfig.real: Warning: ignoring configuration file that cannot be opened: /etc/ld.so.conf.d/aarch64-linux-gnu_GL.conf: No such file or directory


It is not clear what the issue you are facing. Please share steps in detail so that we can suggest next.

Please refer to this post.

I did "sudo update-initramfs -u
got Warnings.

Are the warnings OK?

is this command working correctly?

initrd and initrd.img are not changing, no clue where and how the files on my system came from.


@kayccc this thread is not being worked on either

Why are people ignoring my requests?

@linuxdev can you give any pointers to fixing this? It appears there are missing files in /etc/ld.so.conf.d dirs


I have not been using update-initramfs, so my answers are just guessing. When I do make changes to the initrd I unpack, edit, and repack. Obviously that isn’t something you’d want to do on a regular basis.

My thought is that unless the update-initramfs has knowledge of the method of booting the Jetson (which does not have any kind of standardized “BIOS” like a PC would have for providing a uniform boot interface), then it is risky to use it. One could clone first, and then try it and see, or perhaps add a second/alternate boot entry which you know works and does not use any of the default boot file names (e.g., it has “Image-backup” instead of “Image”, and similar renames for copies of any FDT entry or initrd), and boot to the backup after testing (if testing fails).

One thing to note is that (at least on the release I am looking at now on a TX2) the file “/etc/ld.so.conf.d/aarch64-linux-gnu_EGL.conf” is a symbolic link pointing at another file in “/etc/alternatives”, and this in turn points to the real file here (you’d want to check where each symbolic link points in order to find the real file since it might vary between releases or Jetson models):

The file above simply adds “/usr/lib/aarch64-linux-gnu/tegra-egl” to the linker list. The actual files used for the NVIDIA driver with EGL are there. If the linker path includes that location, then files should be found. Similar for the GL version of the file.

What I don’t know is if update-initramfs is able to deal with those locations. There could be some simple issue going on such as the method the update-initramfs uses working only with some “standard” path, while the Jetson is more custom…don’t know.

If you follow the symbolic links, are the hard link files eventually found?

@linuxdev I messed up the first time I looked at it and thought the files were missing.

After your post I went back and looked again. Then I copied the linked file into the actual file and update-initramfs -u now works, looks like the tool did not like the symbolic links

@kayccc consider making this the solution, nvidia links upset the update-initramfs, remove links and put the actual text into the file.


We will check if the issue is present in latest version and investigate further. Thanks for the suggestion.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.