Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #228867 > unrolled thread

Size of initrd

Back to article view | Back to linux.debian.user

Contents

  Size of initrd Stefan Monnier <monnier@iro.umontreal.ca> - 2020-11-21 21:00 +0100
    Re: Size of initrd <tomas@tuxteam.de> - 2020-11-21 22:10 +0100
      Re: Size of initrd Stefan Monnier <monnier@iro.umontreal.ca> - 2020-11-23 05:50 +0100
        Re: Size of initrd David Wright <deblis@lionunicorn.co.uk> - 2020-11-23 06:20 +0100
          Re: Size of initrd Stefan Monnier <monnier@iro.umontreal.ca> - 2020-11-24 00:40 +0100
            Re: Size of initrd <tomas@tuxteam.de> - 2020-11-24 10:20 +0100
              Re: Size of initrd Greg Wooledge <wooledg@eeg.ccf.org> - 2020-11-24 14:00 +0100
                Re: Size of initrd Curt <curty@free.fr> - 2020-11-24 15:40 +0100
              Re: Size of initrd Stefan Monnier <monnier@iro.umontreal.ca> - 2020-11-24 16:00 +0100
        Re: initrd inspection (was: Size of initrd) Felix Miata <mrmazda@earthlink.net> - 2020-11-23 07:40 +0100
          Re: initrd inspection (was: Size of initrd) <tomas@tuxteam.de> - 2020-11-23 09:50 +0100
            Re: initrd inspection Sven Hartge <sven@svenhartge.de> - 2020-11-23 12:30 +0100
              Re: initrd inspection <tomas@tuxteam.de> - 2020-11-23 13:00 +0100
                Re: initrd inspection Stefan Monnier <monnier@iro.umontreal.ca> - 2020-11-24 00:40 +0100
      Re: Size of initrd Curt <curty@free.fr> - 2020-11-23 14:00 +0100
        Re: Size of initrd Curt <curty@free.fr> - 2020-11-23 14:30 +0100
        Re: initrd inspection (was: Size of initrd) Felix Miata <mrmazda@earthlink.net> - 2020-11-23 18:30 +0100
      Re: Size of initrd Greg Wooledge <wooledg@eeg.ccf.org> - 2020-11-23 14:20 +0100
        Re: Size of initrd <tomas@tuxteam.de> - 2020-11-23 16:20 +0100
    Re: Size of initrd David Wright <deblis@lionunicorn.co.uk> - 2020-11-21 22:40 +0100
    Re: Size of initrd Andy Smith <andy@strugglers.net> - 2020-11-21 22:50 +0100
      Re: Size of initrd David Wright <deblis@lionunicorn.co.uk> - 2020-11-22 00:10 +0100

Page 1 of 2  [1] 2  Next page →

#228867 — Size of initrd

I have two machines with very similar setups: both running Debian i386
testing, they actually come from the same install done years ago
and were cloned at some point in time.

One of the has /boot/initrd.img files that take about 15MB while the
other has /boot/initrd.img files that take about 30MB (in both cases,
they are compressed with `lzma`).

Any idea what this difference could come from (or how I could try and
track it down) and how I could fix the size to be more like 15MB?


        Stefan

[toc] | [next] | [standalone]

#228869

[Multipart message — attachments visible in raw view] — view raw

On Sat, Nov 21, 2020 at 02:52:49PM -0500, Stefan Monnier wrote:
> I have two machines with very similar setups: both running Debian i386
> testing, they actually come from the same install done years ago
> and were cloned at some point in time.
> 
> One of the has /boot/initrd.img files that take about 15MB while the
> other has /boot/initrd.img files that take about 30MB (in both cases,
> they are compressed with `lzma`).
> 
> Any idea what this difference could come from (or how I could try and
> track it down) and how I could fix the size to be more like 15MB?

The initramfs is a compressed cpio archive (of the initial file
system at boot time). You can inspect it like so:

  gunzip < /boot/initrd.img-4.19.0-10-amd64 | cpio -it | less

(substitute your real initramfs file name, of course).

Its manufacturing depends on several files (see the FILES section
of your `mkinitramfs' man page.

Perhaps the one image has more kernel modules because your system
thinks it needs them for the hardware?

Cheers
 - t

[toc] | [prev] | [next] | [standalone]

#228934

>> I have two machines with very similar setups: both running Debian i386
>> testing, they actually come from the same install done years ago
>> and were cloned at some point in time.
>> 
>> One of the has /boot/initrd.img files that take about 15MB while the
>> other has /boot/initrd.img files that take about 30MB (in both cases,
>> they are compressed with `lzma`).
>> 
>> Any idea what this difference could come from (or how I could try and
>> track it down) and how I could fix the size to be more like 15MB?
>
> The initramfs is a compressed cpio archive (of the initial file
> system at boot time).

Duh!  Indeed, even `file` tells me that.
It turns out that the bigger one says it's an "ASCII cpio archive",
whereas the smaller one says it's an LZMA compressed file.

So apparently the issue is that while I configured "lzma" on both
machines in /etc/initramfs, one of the two machines maybe doesn't have
`lzma` installed?

> You can inspect it like so:
>
>   gunzip < /boot/initrd.img-4.19.0-10-amd64 | cpio -it | less

The "smaller" archive (the one that got compressed) gives me the kind of
listing I expected (except I see a lot of X11-related crap in there, it
looks like some kind of "boot splash screen" code got in there even
I thought I had all that disabled),
but oddly the "bigger" archive gives me a much smaller list:

    % cpio -vt < yuca-initrd.img-5.9.0-2-686-pae  
    drwxr-xr-x   2 root     root            0 Aug 20 08:00 kernel
    drwxr-xr-x   2 root     root            0 Aug 20 08:00 kernel/x86
    drwxr-xr-x   2 root     root            0 Aug 20 08:00 kernel/x86/microcode
    drwxr-xr-x   2 root     root            0 Aug 20 08:00 kernel/x86/microcode/.enuineIntel.align.0123456789abc
    -rw-r--r--   1 root     root      3692544 Aug 20 08:00 kernel/x86/microcode/GenuineIntel.bin
    7214 blocs
    % l yuca-initrd.img-5.9.0-2-686-pae
    -rw-r--r-- 1 monnier users 24421797 nov 21 14:51 yuca-initrd.img-5.9.0-2-686-pae
    %

How come the archive weighs in at 24MB when it doesn't even contain 4MB
of data?


        Stefan

[toc] | [prev] | [next] | [standalone]

#228935

On Sun 22 Nov 2020 at 23:46:54 (-0500), Stefan Monnier wrote:
> >> I have two machines with very similar setups: both running Debian i386
> >> testing, they actually come from the same install done years ago
> >> and were cloned at some point in time.
> >> 
> >> One of the has /boot/initrd.img files that take about 15MB while the
> >> other has /boot/initrd.img files that take about 30MB (in both cases,
> >> they are compressed with `lzma`).
> >> 
> >> Any idea what this difference could come from (or how I could try and
> >> track it down) and how I could fix the size to be more like 15MB?
> >
> > The initramfs is a compressed cpio archive (of the initial file
> > system at boot time).
> 
> Duh!  Indeed, even `file` tells me that.
> It turns out that the bigger one says it's an "ASCII cpio archive",
> whereas the smaller one says it's an LZMA compressed file.
> 
> So apparently the issue is that while I configured "lzma" on both
> machines in /etc/initramfs, one of the two machines maybe doesn't have
> `lzma` installed?
> 
> > You can inspect it like so:
> >
> >   gunzip < /boot/initrd.img-4.19.0-10-amd64 | cpio -it | less
> 
> The "smaller" archive (the one that got compressed) gives me the kind of
> listing I expected (except I see a lot of X11-related crap in there, it
> looks like some kind of "boot splash screen" code got in there even
> I thought I had all that disabled),
> but oddly the "bigger" archive gives me a much smaller list:
> 
>     % cpio -vt < yuca-initrd.img-5.9.0-2-686-pae  
>     drwxr-xr-x   2 root     root            0 Aug 20 08:00 kernel
>     drwxr-xr-x   2 root     root            0 Aug 20 08:00 kernel/x86
>     drwxr-xr-x   2 root     root            0 Aug 20 08:00 kernel/x86/microcode
>     drwxr-xr-x   2 root     root            0 Aug 20 08:00 kernel/x86/microcode/.enuineIntel.align.0123456789abc
>     -rw-r--r--   1 root     root      3692544 Aug 20 08:00 kernel/x86/microcode/GenuineIntel.bin
>     7214 blocs
>     % l yuca-initrd.img-5.9.0-2-686-pae
>     -rw-r--r-- 1 monnier users 24421797 nov 21 14:51 yuca-initrd.img-5.9.0-2-686-pae
>     %
> 
> How come the archive weighs in at 24MB when it doesn't even contain 4MB
> of data?

Use unmkinitramfs. It appears you've only looked at the first archive,
the early one, which gets the kernel into shape. The second, main one
is the big one.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#228979

> Use unmkinitramfs. It appears you've only looked at the first archive,
> the early one, which gets the kernel into shape. The second, main one
> is the big one.

OK, for those interested I tracked it down: indeed the machine with the
larger initrd had MODULES=most instead of MODULES=dep.

It took me some effort to figure out that it was actually
LZMA-compressed as I had specified (the first CPIO archive, containing
the intel microcode blob isn't, but the second is): `unmkinitramfs`
splits the initrd into separate CPIO archives but doesn't let you see
them, so I could easily see the content of the archives but they were
silently decompressed so you can't immediately see what compression (if
any) is used.  I had to tweak the code to preserve the intermediate temp
files in order to get to the bottom of it.

In any case, thanks all for the help,


        Stefan

[toc] | [prev] | [next] | [standalone]

#228994

[Multipart message — attachments visible in raw view] — view raw

On Mon, Nov 23, 2020 at 06:30:46PM -0500, Stefan Monnier wrote:
> > Use unmkinitramfs. It appears you've only looked at the first archive,
> > the early one, which gets the kernel into shape. The second, main one
> > is the big one.
> 
> OK, for those interested I tracked it down: indeed the machine with the
> larger initrd had MODULES=most instead of MODULES=dep.

My unqualified guess was modules, since that's the really fat part
of that cake.

> It took me some effort to figure out that it was actually
> LZMA-compressed as I had specified (the first CPIO archive, containing
> the intel microcode blob isn't, but the second is) [...]

I feel somewhat guilty, because my "solution" implied (as I thought at
the time) that initramfs is /just/ one cpio archive. I've been corrected
in the meantime.

Sorry for that. I know it's a sleazy way of learning -- spewing out some
nonsense, being corrected and caching that for the next time.

Your extra time was the collateral damage. I owe you a beer -- post-Covid.

Cheers
 - t

[toc] | [prev] | [next] | [standalone]

#229001

On Tue, Nov 24, 2020 at 10:09:51AM +0100, tomas@tuxteam.de wrote:
> Sorry for that. I know it's a sleazy way of learning -- spewing out some
> nonsense, being corrected and caching that for the next time.

It's only sleazy if you do it on purpose.

[toc] | [prev] | [next] | [standalone]

#229005

On 2020-11-24, Greg Wooledge <wooledg@eeg.ccf.org> wrote:
> On Tue, Nov 24, 2020 at 10:09:51AM +0100, tomas@tuxteam.de wrote:
>> Sorry for that. I know it's a sleazy way of learning -- spewing out some
>> nonsense, being corrected and caching that for the next time.
>
> It's only sleazy if you do it on purpose.

If that were the extent of my moral degradation I wouldn't worry about
it too much.

[toc] | [prev] | [next] | [standalone]

#229007

> Sorry for that. I know it's a sleazy way of learning -- spewing out some
> nonsense, being corrected and caching that for the next time.

You're describing the scientific method,


        Stefan

[toc] | [prev] | [next] | [standalone]

#228940 — Re: initrd inspection (was: Size of initrd)

Tomas composed on 2020-11-21 22:46 (UTC+0100):

> You can inspect it like so:

>   gunzip < /boot/initrd.img-4.19.0-10-amd64 | cpio -it | less

That was shortened to 'lsinitrd <initrdfile> | less' in 2008 in openSUSE[1], which
Mandriva already had, eventually upstream'd to dracut, I'm guessing well over 5
years ago, since I can't figure out how to find dracut's changelog. I wonder why
Debian's dracut doesn't have it?

https://github.com/dracutdevs/dracut/blob/master/lsinitrd.sh

[1] https://bugzilla.opensuse.org/show_bug.cgi?id=439103#c7
-- 
Evolution as taught in public schools, like religion,
	is based on faith, not on science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

[toc] | [prev] | [next] | [standalone]

#228942 — Re: initrd inspection (was: Size of initrd)

[Multipart message — attachments visible in raw view] — view raw

On Mon, Nov 23, 2020 at 01:36:05AM -0500, Felix Miata wrote:
> Tomas composed on 2020-11-21 22:46 (UTC+0100):
> 
> > You can inspect it like so:
> 
> >   gunzip < /boot/initrd.img-4.19.0-10-amd64 | cpio -it | less
> 
> That was shortened to 'lsinitrd <initrdfile> | less' in 2008 in openSUSE[1], which
> Mandriva already had, eventually upstream'd to dracut, I'm guessing well over 5
> years ago, since I can't figure out how to find dracut's changelog. I wonder why
> Debian's dracut doesn't have it?

Hm. Apt-file search says (Buster) that /usr/bin/lsinitrd is in package
dracut-core (not installed in my box, so I can't double check now).

Cheers
 - t

[toc] | [prev] | [next] | [standalone]

#228948 — Re: initrd inspection

tomas@tuxteam.de wrote:
> On Mon, Nov 23, 2020 at 01:36:05AM -0500, Felix Miata wrote:
>> Tomas composed on 2020-11-21 22:46 (UTC+0100):
 
>>> You can inspect it like so:
>> 
>>>   gunzip < /boot/initrd.img-4.19.0-10-amd64 | cpio -it | less
 
>> That was shortened to 'lsinitrd <initrdfile> | less' in 2008 in openSUSE[1], which
>> Mandriva already had, eventually upstream'd to dracut, I'm guessing well over 5
>> years ago, since I can't figure out how to find dracut's changelog. I wonder why
>> Debian's dracut doesn't have it?

> Hm. Apt-file search says (Buster) that /usr/bin/lsinitrd is in package
> dracut-core (not installed in my box, so I can't double check now).

Try

initramfs-tools-core: /usr/bin/lsinitramfs

Grüße,
Sven.

-- 
Sigmentation fault. Core dumped.

[toc] | [prev] | [next] | [standalone]

#228949 — Re: initrd inspection

[Multipart message — attachments visible in raw view] — view raw

On Mon, Nov 23, 2020 at 12:19:02PM +0100, Sven Hartge wrote:
> tomas@tuxteam.de wrote:
> > On Mon, Nov 23, 2020 at 01:36:05AM -0500, Felix Miata wrote:
> >> Tomas composed on 2020-11-21 22:46 (UTC+0100):
>  
> >>> You can inspect it like so:
> >> 
> >>>   gunzip < /boot/initrd.img-4.19.0-10-amd64 | cpio -it | less

[...]

> > Hm. Apt-file search says (Buster) that /usr/bin/lsinitrd is in package
> > dracut-core (not installed in my box, so I can't double check now).
> 
> Try
> 
> initramfs-tools-core: /usr/bin/lsinitramfs

Thanks :-)

Cheers
 - t

[toc] | [prev] | [next] | [standalone]

#228980 — Re: initrd inspection

>> > Hm. Apt-file search says (Buster) that /usr/bin/lsinitrd is in package
>> > dracut-core (not installed in my box, so I can't double check now).
>> initramfs-tools-core: /usr/bin/lsinitramfs

Apparently `lsinitrd` only lists the contents of the first archive,
whereas `lsinitramfs` lists the content of all the concatenated archives
(under the assumption that all but the last one are not compressed).

I assume this is because dracut doesn't generate such
concatenation-of-archives for its initrds.


        Stefan

[toc] | [prev] | [next] | [standalone]

#228952

On 2020-11-21, <tomas@tuxteam.de> <tomas@tuxteam.de> wrote:
>
> The initramfs is a compressed cpio archive (of the initial file
> system at boot time). You can inspect it like so:
>
>   gunzip < /boot/initrd.img-4.19.0-10-amd64 | cpio -it | less

    lsinitramfs /boot/initrd.img-4.19.0-10-amd64

[toc] | [prev] | [next] | [standalone]

#228955

On 2020-11-23, Curt <curty@free.fr> wrote:
> On 2020-11-21, <tomas@tuxteam.de> <tomas@tuxteam.de> wrote:
>>
>> The initramfs is a compressed cpio archive (of the initial file
>> system at boot time). You can inspect it like so:
>>
>>   gunzip < /boot/initrd.img-4.19.0-10-amd64 | cpio -it | less
>
>     lsinitramfs /boot/initrd.img-4.19.0-10-amd64


I see this has already been mentioned as a shorter alternative.

[toc] | [prev] | [next] | [standalone]

#228970 — Re: initrd inspection (was: Size of initrd)

Curt composed on 2020-11-23 12:39 (UTC):

> tomas wrote:

>> The initramfs is a compressed cpio archive (of the initial file
>> system at boot time). You can inspect it like so:

>>   gunzip < /boot/initrd.img-4.19.0-10-amd64 | cpio -it | less

>     lsinitramfs /boot/initrd.img-4.19.0-10-amd64

If /boot/initrd.img-4.19.0-10-amd64 is the current kernel, then:

	lsinitramfs /initrd.img

should be identical. ;-)
-- 
Evolution as taught in public schools, like religion,
	is based on faith, not on science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

[toc] | [prev] | [next] | [standalone]

#228954

On Sat, Nov 21, 2020 at 10:03:06PM +0100, tomas@tuxteam.de wrote:
> The initramfs is a compressed cpio archive (of the initial file
> system at boot time). You can inspect it like so:
> 
>   gunzip < /boot/initrd.img-4.19.0-10-amd64 | cpio -it | less

Debian's initrd images are actually multiple cpio archives concatenated
together.  The command you used here only views the first archive.

Use lsinitramfs instead.  It will open all of the archives inside the
image.

[toc] | [prev] | [next] | [standalone]

#228960

[Multipart message — attachments visible in raw view] — view raw

On Mon, Nov 23, 2020 at 08:15:47AM -0500, Greg Wooledge wrote:
> On Sat, Nov 21, 2020 at 10:03:06PM +0100, tomas@tuxteam.de wrote:
> > The initramfs is a compressed cpio archive (of the initial file
> > system at boot time). You can inspect it like so:
> > 
> >   gunzip < /boot/initrd.img-4.19.0-10-amd64 | cpio -it | less
> 
> Debian's initrd images are actually multiple cpio archives concatenated
> together [...]

I see, thanks

Cheers
 - t

[toc] | [prev] | [next] | [standalone]

#228871

On Sat 21 Nov 2020 at 14:52:49 (-0500), Stefan Monnier wrote:
> I have two machines with very similar setups: both running Debian i386
> testing, they actually come from the same install done years ago
> and were cloned at some point in time.
> 
> One of the has /boot/initrd.img files that take about 15MB while the
> other has /boot/initrd.img files that take about 30MB (in both cases,
> they are compressed with `lzma`).
> 
> Any idea what this difference could come from (or how I could try and
> track it down) and how I could fix the size to be more like 15MB?

Perhaps check out /etc/initramfs/initramfs.conf and the contents
of /etc/initramfs/conf.d/ for the value assigned to MODULES.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.user

csiph-web