[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: initrd sizes mushroomed several months ago



On Fri 03 Feb 2023 at 07:49:39 (-0500), Greg Wooledge wrote:
> On Fri, Feb 03, 2023 at 01:45:33AM -0500, Felix Miata wrote:
> > David Wright composed on 2023-02-01 22:39 (UTC-0600):
> > >   $ cpio -t < /boot/initrd.img-6.0.0-6-amd64
> > 
> > Is that a typo? I copied & pasted that and the screen loaded binary gibberish.
> 
> GNU cpio(1) says that -t implies -i, so it should work on Debian.
> 
> unicorn:~$ cpio -t < /boot/initrd.img-5.10.0-21-amd64 
> kernel
> kernel/x86
> kernel/x86/microcode
> kernel/x86/microcode/.enuineIntel.align.0123456789abc
> kernel/x86/microcode/GenuineIntel.bin
> 9794 blocks
> 
> Not sure how *useful* it is, since it only lists the TOC from the first
> cpio archive in the initrd image, and there may be multiple.  But it
> should give a human-readable table of contents.  If it doesn't, then
> either you're not using GNU cpio (try cpio -it for portability), or
> your archive may be corrupt.

It's useful, as seen in my post, to skip past the early archive in
order to see how the main archive has been compressed.

I would assume that Felix's initrd lacks any early archive, and my
command has run up against the compressed main archive itself.

unmkinitramfs, of course, takes account of all this, but tells you
nothing about how the contents on the initrd are arranged. I've read
that binwalk can do this, but installing that is a 43 package waste
for me (with Recommends).

So I was posting a widely used method of hand-dismantling the initrd,
which naturally relies on interactively responding to what's observed.

Cheers,
David.


Reply to: