1

I need to know what config and data files are pulled in to make the initrd.img-xxx when update-initramfs (mkinitramfs) is executed.

I am having a video driver problem that I have narrowed down to the generation of the initrd.img-xxx after kernel updates. I only get low-resolution single screen VESA, I should have two screen 1080p.

Debian 12 Bookworm, but it's an old install that has been upgraded from earlier versions of Debian. I still have a working fallback kernel from 2 months ago, so I set it as manually installed and held back from upgrades for now.

I created a fresh installation of Debian on a spare drive with its own EFI boot sector and grub and it has no issues. I have, as best as I can query, the same graphics drivers and firmware installed in both installs, and I purged all of them from the old install and reinstalled with apt to get fresh configs if any. I also purged and reinstalled the kernel metapackage and initram tools.

I have two identical kernel builds installed in both the old and new installs. I copied the initrd.img-123 from the new install to the old install. The old install boots correctly with correct graphics using the initrd.img-123 from the new install.

The initrd.img of the new and old install are of different file type when listed by file initrd.img-XXX and they don't unpack the same when attempting to decompress. The new is making zstd files and the old system are appearing as CPIO. (The older fallback kernel also appears to have a CPIO initrd.img but doesn't have problems.)

I have mounted both root partitions and done diff -r on /boot and /etc and cleaned up the most obvious differences with apt-get purging old packages and some manual house keeping. But there is still a lot of noise due to heirloom configurations and settings, much of which I would like to keep if this doesn't drag on too long.

Improve this question
1
  • For anyone wondering. Purging package amd64-microcode fixed the issue with the initrd file format, it was blacklisted by default anyway so I don't know what the real issue with it was.(Lots of cobwebs in a 5 year old desktop OS.) And the graphics issue was solved in /etc/modprobe.d/ somehow amdgpu had become blacklisted, commented out and it works now. Commented Dec 24, 2022 at 3:42

2 Answers 2

Reset to default
2

If you run update-initramfs with a "verbose" option, e.g. update-initramfs -u -v, it will display the name of every file it adds to the initramfs, and every hook script it executes.

Improve this answer
1
  • update-initramfs -u -v > initdumpOSa followed by sort then comm -1 -3 initdumpOSa.sorted initdumpOSb.sorted really helped me narrow down the suspects. lsinitramfs is a bit simpler but only lists included files, dumping the update-initramfs also shows hooks used in building it. Commented Dec 24, 2022 at 3:54
2

You can use lsinitramfs to list the contents of an initramfs and thus compare the working and non-working files you have.

The contents are mostly determined by /etc/initramfs-tools/initramfs.conf, in particular the MODULES value.

Improve this answer
4
  • lsinitramfs seems to be a component of dracut not Debian's initramfs-tools, and not availible as its own package. Commented Dec 22, 2022 at 20:38
  • All files under /etc/initramfs-tools/ are identical. Mysteries. Commented Dec 23, 2022 at 7:04
  • The link I gave for lsinitramfs is to the Debian manpage for the tool, so yes, it is available in Debian. It’s part of the initramfs-tools-core package and is installed in /usr/bin. Commented Dec 23, 2022 at 8:47
  • I purged and reinstalled initramfs-tools along with a bunch of other stuff and yeah lsinitramfs is in there now. Commented Dec 24, 2022 at 3:31

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.