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

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

Updating kernels impossible when /boot is getting full

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

Contents

  Updating kernels impossible when /boot is getting full Ilkka Huotari <ilkkah@gmail.com> - 2021-08-01 06:40 +0200
    Re: Updating kernels impossible when /boot is getting full Paul Duncan <paul.d@soi-team.org> - 2021-08-01 12:00 +0200
    Re: Updating kernels impossible when /boot is getting full Stefan Monnier <monnier@iro.umontreal.ca> - 2021-08-01 17:40 +0200
    Re: Updating kernels impossible when /boot is getting full David Christensen <dpchrist@holgerdanske.com> - 2021-08-01 21:50 +0200
      Re: Updating kernels impossible when /boot is getting full Greg Wooledge <greg@wooledge.org> - 2021-08-01 22:10 +0200
        Re: Updating kernels impossible when /boot is getting full Hans <hans.ullrich@loop.de> - 2021-08-01 22:30 +0200
        Re: Updating kernels impossible when /boot is getting full David Christensen <dpchrist@holgerdanske.com> - 2021-08-02 00:30 +0200
          Re: Updating kernels impossible when /boot is getting full Greg Wooledge <greg@wooledge.org> - 2021-08-02 01:00 +0200
            Re: Updating kernels impossible when /boot is getting full Darac Marjal <mailinglist@darac.org.uk> - 2021-08-02 17:20 +0200
            Re: Updating kernels impossible when /boot is getting full David Christensen <dpchrist@holgerdanske.com> - 2021-08-02 20:20 +0200
              Re: Updating kernels impossible when /boot is getting full Greg Wooledge <greg@wooledge.org> - 2021-08-02 20:40 +0200
                Re: Updating kernels impossible when /boot is getting full Greg Wooledge <greg@wooledge.org> - 2021-08-02 21:50 +0200
                  Re: Updating kernels impossible when /boot is getting full David Christensen <dpchrist@holgerdanske.com> - 2021-08-02 23:30 +0200
                Re: Updating kernels impossible when /boot is getting full David Christensen <dpchrist@holgerdanske.com> - 2021-08-02 21:50 +0200
          Re: listing initrd content (was: Updating kernels impossible...) Felix Miata <mrmazda@earthlink.net> - 2021-08-02 07:30 +0200
            Re: listing initrd content (was: Updating kernels impossible...) Greg Wooledge <greg@wooledge.org> - 2021-08-02 13:30 +0200
              Re: listing initrd content The Wanderer <wanderer@fastmail.fm> - 2021-08-02 13:50 +0200
                Re: listing initrd content Greg Wooledge <greg@wooledge.org> - 2021-08-02 14:00 +0200
                  Re: listing initrd content The Wanderer <wanderer@fastmail.fm> - 2021-08-02 14:10 +0200
                  Re: listing initrd content David Wright <deblis@lionunicorn.co.uk> - 2021-08-02 17:50 +0200
                    Re: listing initrd content Greg Wooledge <greg@wooledge.org> - 2021-08-02 18:00 +0200
                    Re: listing initrd content David <bouncingcats@gmail.com> - 2021-08-02 18:10 +0200
                      Re: listing initrd content David Wright <deblis@lionunicorn.co.uk> - 2021-08-02 21:00 +0200
                      Re: listing initrd content David <bouncingcats@gmail.com> - 2021-08-03 12:00 +0200
        Re: Updating kernels impossible when /boot is getting full Teemu Likonen <tlikonen@iki.fi> - 2021-08-02 07:10 +0200
          Re: Updating kernels impossible when /boot is getting full David Wright <deblis@lionunicorn.co.uk> - 2021-08-02 18:00 +0200

Page 1 of 2  [1] 2  Next page →

#237968 — Updating kernels impossible when /boot is getting full

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

Hi,

I'm using Ubuntu 21. My /boot partition size is 500M and it's getting full:

/dev/sda1               446M  352M   61M  86% /boot

What's taking space are mainly these:

-rw-r--r--  1 root root 153M heinä  10 14:22 initrd.img-5.11.0-22-generic
-rw-r--r--  1 root root 151M heinä  23 13:13 initrd.img-5.11.0-25-generic

apt-get upgrade fails:

update-initramfs: Generating /boot/initrd.img-5.11.0-25-generic
Error 24 : Write error : cannot write compressed block
E: mkinitramfs failure cpio 141 lz4 -9 -l 24
update-initramfs: failed for /boot/initrd.img-5.11.0-25-generic with 1.
dpkg: error processing package initramfs-tools (--configure):
 installed initramfs-tools package post-installation script subprocess
returned error exit status 1
Errors were encountered while processing:
 initramfs-tools
E: Sub-process /usr/bin/dpkg returned an error code (1)

Resizing the partitions is very complicated because I'm using an encrypted
partition ( https://help.ubuntu.com/community/ResizeEncryptedPartitions ).
So that's really not an option for me.

How to fix this:

I suggest that apt-get/dpkg handles upgrading outside /boot. Two kernels
seem to fit there if the updating is done cleverly. Or if only one kernel
fits, then keep only on kernel in /boot.

Thanks,
Ilkka

[toc] | [next] | [standalone]

#237969

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

Hi Ilkka,

Try doing "apt autoremove". This should get rid of all the old, no-longer
used kernels and other software  on your system. You should then be able to
get the new stuff on :-)

Best Regards,

Paul.

On Sun, 1 Aug 2021 at 04:36, Ilkka Huotari <ilkkah@gmail.com> wrote:

> Hi,
>
> I'm using Ubuntu 21. My /boot partition size is 500M and it's getting full:
>
> /dev/sda1               446M  352M   61M  86% /boot
>
> What's taking space are mainly these:
>
> -rw-r--r--  1 root root 153M heinä  10 14:22 initrd.img-5.11.0-22-generic
> -rw-r--r--  1 root root 151M heinä  23 13:13 initrd.img-5.11.0-25-generic
>
> apt-get upgrade fails:
>
> update-initramfs: Generating /boot/initrd.img-5.11.0-25-generic
> Error 24 : Write error : cannot write compressed block
> E: mkinitramfs failure cpio 141 lz4 -9 -l 24
> update-initramfs: failed for /boot/initrd.img-5.11.0-25-generic with 1.
> dpkg: error processing package initramfs-tools (--configure):
>  installed initramfs-tools package post-installation script subprocess
> returned error exit status 1
> Errors were encountered while processing:
>  initramfs-tools
> E: Sub-process /usr/bin/dpkg returned an error code (1)
>
> Resizing the partitions is very complicated because I'm using an encrypted
> partition ( https://help.ubuntu.com/community/ResizeEncryptedPartitions
> ). So that's really not an option for me.
>
> How to fix this:
>
> I suggest that apt-get/dpkg handles upgrading outside /boot. Two kernels
> seem to fit there if the updating is done cleverly. Or if only one kernel
> fits, then keep only on kernel in /boot.
>
> Thanks,
> Ilkka
>


-- 


*Paul Duncan*

Lead Marine Technician, RV Falkor

SCHMIDT OCEAN INSTITUTE

mobile +1 650 387 4151

VOIP +1 954 672 4943

www.schmidtocean.org

Follow us on Twitter, Facebook and Google+

*This email message is for the sole use of the intended recipient(s) and
may contain confidential and privileged*

*information. Any unauthorized review, use, disclosure or distribution is
prohibited. If you have received it in*

*error, please advise the sender by reply email and delete the message and
any attachments. Thank you.*

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

#237984

Ilkka Huotari [2021-08-01 07:20:20] wrote:
> I'm using Ubuntu 21. My /boot partition size is 500M and it's getting full:

Notice that this is a Debian mailing-list, so questions about Ubuntu are
not really "on topic".

AFAIK Ubuntu handles the initrd files and kernels slightly differently
from what Debian does, so you'll probably be better served asking this
on an Ubuntu mailing-list or forum, otherwise you risk getting
confusing advice.


        Stefan

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

#237992

On 7/31/21 9:20 PM, Ilkka Huotari wrote:
> Hi,
> 
> I'm using Ubuntu 21. My /boot partition size is 500M and it's getting full:
> 
> /dev/sda1               446M  352M   61M  86% /boot
> 
> What's taking space are mainly these:
> 
> -rw-r--r--  1 root root 153M heinä  10 14:22 initrd.img-5.11.0-22-generic
> -rw-r--r--  1 root root 151M heinä  23 13:13 initrd.img-5.11.0-25-generic
> 
> apt-get upgrade fails:
> 
> update-initramfs: Generating /boot/initrd.img-5.11.0-25-generic
> Error 24 : Write error : cannot write compressed block
> E: mkinitramfs failure cpio 141 lz4 -9 -l 24
> update-initramfs: failed for /boot/initrd.img-5.11.0-25-generic with 1.
> dpkg: error processing package initramfs-tools (--configure):
>   installed initramfs-tools package post-installation script subprocess
> returned error exit status 1
> Errors were encountered while processing:
>   initramfs-tools
> E: Sub-process /usr/bin/dpkg returned an error code (1)
> 
> Resizing the partitions is very complicated because I'm using an encrypted
> partition ( https://help.ubuntu.com/community/ResizeEncryptedPartitions ).
> So that's really not an option for me.
> 
> How to fix this:
> 
> I suggest that apt-get/dpkg handles upgrading outside /boot. Two kernels
> seem to fit there if the updating is done cleverly. Or if only one kernel
> fits, then keep only on kernel in /boot.
> 
> Thanks,
> Ilkka


A 500 GB boot partition would be enough for several kernels, etc., on 
Debian 10 amd64.


Please post (where /dev/sdX is your system device):

     # fdisk -l /dev/sdX

     # du -msx /boot /

     # ls -l /boot


David

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

#237993

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

On Sun, Aug 01, 2021 at 12:45:27PM -0700, David Christensen wrote:
> On 7/31/21 9:20 PM, Ilkka Huotari wrote:
> > -rw-r--r--  1 root root 153M heinä  10 14:22 initrd.img-5.11.0-22-generic
> > -rw-r--r--  1 root root 151M heinä  23 13:13 initrd.img-5.11.0-25-generic

> A 500 GB boot partition would be enough for several kernels, etc., on Debian
> 10 amd64.

(which they're not running)

> Please post (where /dev/sdX is your system device):
> 
>     # fdisk -l /dev/sdX
> 
>     # du -msx /boot /
> 
>     # ls -l /boot

What's the point?  We know the issue is they've got two or more
gigantic initrd files.  The question is why their initrd files are 5 times
as big as normal.

unicorn:~$ ls -l /boot/initrd.img-*
-rw-r--r-- 1 root root 30924690 Jan 29  2021 /boot/initrd.img-4.19.0-13-amd64
-rw-r--r-- 1 root root 34310935 Jul 21 07:30 /boot/initrd.img-5.10.0-7-amd64
-rw-r--r-- 1 root root 34313404 Jul 31 09:05 /boot/initrd.img-5.10.0-8-amd64

We get these threads too damned often.  Someone who knows what makes
initrd images swell up, please step in and advise.  And no, it's not
"try using a different compression algorithm".  It's something in the
*content*.

The only advice I can give is "open them up and see what's inside them,
and compare that to what you see in a regular Debian stable initrd file".
But that's a lot of work, and I can't imagine an Ubuntu user actually
doing that.[1]

Unfortunately, it may turn out that what makes them 5 times as big is
something unique to Ubuntu.  Perhaps they ship a hundred megabytes of
extra non-free firmware.  Who the hell knows?  Not a Debian list, that's
for sure.

[1] But just in case I'm dead wrong, here's the contents of mine, to
compare against.  Attached, compressed.  It's a large text file, but
it compresses pretty well.  Maybe the list software won't strip it.

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

#237994

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

Am Sonntag, 1. August 2021, 22:00:24 CEST schrieb Greg Wooledge:
Try to uninstall old kernels with

aptitude purge ~n5.10.0-7-* 

for uninstalling all related packages with "5.10.0-7-" in its name. Do it with 
all unneeded kernels.

It will also uninstall headers and modules for that kernel-version.

Hope this helps.

Best regards

Hans

> On Sun, Aug 01, 2021 at 12:45:27PM -0700, David Christensen wrote:
> > On 7/31/21 9:20 PM, Ilkka Huotari wrote:
> > > -rw-r--r--  1 root root 153M heinä  10 14:22
> > > initrd.img-5.11.0-22-generic
> > > -rw-r--r--  1 root root 151M heinä  23 13:13
> > > initrd.img-5.11.0-25-generic
> > 
> > A 500 GB boot partition would be enough for several kernels, etc., on
> > Debian 10 amd64.
> 
> (which they're not running)
> 
> > Please post (where /dev/sdX is your system device):
> >     # fdisk -l /dev/sdX
> >     
> >     # du -msx /boot /
> >     
> >     # ls -l /boot
> 
> What's the point?  We know the issue is they've got two or more
> gigantic initrd files.  The question is why their initrd files are 5 times
> as big as normal.
> 
> unicorn:~$ ls -l /boot/initrd.img-*
> -rw-r--r-- 1 root root 30924690 Jan 29  2021
> /boot/initrd.img-4.19.0-13-amd64 -rw-r--r-- 1 root root 34310935 Jul 21
> 07:30 /boot/initrd.img-5.10.0-7-amd64 -rw-r--r-- 1 root root 34313404 Jul
> 31 09:05 /boot/initrd.img-5.10.0-8-amd64
> 
> We get these threads too damned often.  Someone who knows what makes
> initrd images swell up, please step in and advise.  And no, it's not
> "try using a different compression algorithm".  It's something in the
> *content*.
> 
> The only advice I can give is "open them up and see what's inside them,
> and compare that to what you see in a regular Debian stable initrd file".
> But that's a lot of work, and I can't imagine an Ubuntu user actually
> doing that.[1]
> 
> Unfortunately, it may turn out that what makes them 5 times as big is
> something unique to Ubuntu.  Perhaps they ship a hundred megabytes of
> extra non-free firmware.  Who the hell knows?  Not a Debian list, that's
> for sure.
> 
> [1] But just in case I'm dead wrong, here's the contents of mine, to
> compare against.  Attached, compressed.  It's a large text file, but
> it compresses pretty well.  Maybe the list software won't strip it.

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

#237999

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

On 8/1/21 1:00 PM, Greg Wooledge wrote:
> On Sun, Aug 01, 2021 at 12:45:27PM -0700, David Christensen wrote:
>> On 7/31/21 9:20 PM, Ilkka Huotari wrote:
>>> -rw-r--r--  1 root root 153M heinä  10 14:22 initrd.img-5.11.0-22-generic
>>> -rw-r--r--  1 root root 151M heinä  23 13:13 initrd.img-5.11.0-25-generic
> 
>> A 500 GB boot partition would be enough for several kernels, etc., on Debian
>> 10 amd64.
> 
> (which they're not running)


True.  And, I see a typo in my post -- that should be 500 MB.


> The question is why their initrd files are 5 times as big as normal.
> 
> unicorn:~$ ls -l /boot/initrd.img-*
> -rw-r--r-- 1 root root 30924690 Jan 29  2021 /boot/initrd.img-4.19.0-13-amd64
> -rw-r--r-- 1 root root 34310935 Jul 21 07:30 /boot/initrd.img-5.10.0-7-amd64
> -rw-r--r-- 1 root root 34313404 Jul 31 09:05 /boot/initrd.img-5.10.0-8-amd64


Agreed.  "153M" and "151M" are considerably larger than expected:

2021-08-01 13:45:08 dpchrist@dipsy ~
$ cat /etc/debian_version ; uname -a
10.10
Linux dipsy 4.19.0-17-amd64 #1 SMP Debian 4.19.194-3 (2021-07-18) x86_64 
GNU/Linux

2021-08-01 13:46:33 dpchrist@dipsy ~
$ ls -l /boot/initrd.img-4.19.0-1*
-rw-r--r-- 1 root root 37293255 Mar 29 16:45 
/boot/initrd.img-4.19.0-14-amd64
-rw-r--r-- 1 root root 37310536 Mar 29 16:56 
/boot/initrd.img-4.19.0-16-amd64
-rw-r--r-- 1 root root 37316775 Jul 25 12:43 
/boot/initrd.img-4.19.0-17-amd64


> We get these threads too damned often.  Someone who knows what makes
> initrd images swell up, please step in and advise.  And no, it's not
> "try using a different compression algorithm".  It's something in the
> *content*.
> 
> The only advice I can give is "open them up and see what's inside them,
> and compare that to what you see in a regular Debian stable initrd file".
> But that's a lot of work, and I can't imagine an Ubuntu user actually
> doing that.[1]
> 
> Unfortunately, it may turn out that what makes them 5 times as big is
> something unique to Ubuntu.  Perhaps they ship a hundred megabytes of
> extra non-free firmware.  Who the hell knows?  Not a Debian list, that's
> for sure.
> 
> [1] But just in case I'm dead wrong, here's the contents of mine, to
> compare against.  Attached, compressed.  It's a large text file, but
> it compresses pretty well.  Maybe the list software won't strip it.


I don't know why the OP's initrd files are large.


STFW here is information on initrd.img files:

https://www.kernel.org/doc/html/latest/filesystems/ramfs-rootfs-initramfs.html


Get the listing for my initrd.img file:

2021-08-01 13:52:37 root@dipsy ~
# file /boot/initrd.img-4.19.0-17-amd64
/boot/initrd.img-4.19.0-17-amd64: gzip compressed data, last modified: 
Sun Jul 25 19:43:38 2021, from Unix, original size 126331392

2021-08-01 14:10:00 root@dipsy ~
# mkdir /tmp/initrd.img-4.19.0-17-amd64

2021-08-01 14:10:19 root@dipsy ~
# cd /tmp/initrd.img-4.19.0-17-amd64/

2021-08-01 14:10:24 root@dipsy /tmp/initrd.img-4.19.0-17-amd64
# gunzip -c /boot/initrd.img-4.19.0-17-amd64 | cpio -i -d -H newc 
--no-absolute-filenames
246741 blocks

2021-08-01 14:12:36 root@dipsy /tmp/initrd.img-4.19.0-17-amd64
# ls -l
total 36
lrwxrwxrwx  1 root root    7 Aug  1 14:12 bin -> usr/bin
drwxr-xr-x  3 root root 4096 Aug  1 14:12 conf
drwxr-xr-x  2 root root 4096 Aug  1 14:12 cryptroot
drwxr-xr-x  8 root root 4096 Aug  1 14:12 etc
-rwxr-xr-x  1 root root 6338 Aug  1 14:12 init
lrwxrwxrwx  1 root root    7 Aug  1 14:12 lib -> usr/lib
lrwxrwxrwx  1 root root    9 Aug  1 14:12 lib32 -> usr/lib32
lrwxrwxrwx  1 root root    9 Aug  1 14:12 lib64 -> usr/lib64
lrwxrwxrwx  1 root root   10 Aug  1 14:12 libx32 -> usr/libx32
drwxr-xr-x  2 root root 4096 Aug  1 14:12 run
lrwxrwxrwx  1 root root    8 Aug  1 14:12 sbin -> usr/sbin
drwxr-xr-x 10 root root 4096 Aug  1 14:12 scripts
drwxr-xr-x 10 root root 4096 Aug  1 14:12 usr
drwxr-xr-x  3 root root 4096 Aug  1 14:12 var

2021-08-01 14:55:47 root@dipsy ~
# OUT=/home/dpchrist/initrd.img-4.19.0-16-amd64.txt.gz && find * | xargs 
ls -ld | gzip -9 > $OUT && chown dpchrist:dpchrist $OUT


Please see initrd.img-4.19.0-16-amd64.txt.gz, attached.


If the OP would care to run the above commands and post his initrd.img 
file, we could examine it.


Munge your listing file and my listing file to remove number of links, 
size, month, day, and time fields, and sort:

2021-08-01 14:35:17 dpchrist@dipsy ~
$ gunzip initrd.img-5.10.0-8-amd64.txt.gz

2021-08-01 14:59:00 dpchrist@dipsy ~
$ gunzip initrd.img-4.19.0-16-amd64.txt.gz

2021-08-01 15:10:56 dpchrist@dipsy ~
$ IN=initrd.img-5.10.0-8-amd64.txt && perl -ane 
'@F[1,4,5,6,7]=("","","","",""); $F[8]=~s/\d\.\d+\.\d-\d+/V.V.V-V/; 
print "@F\n"' $IN | sort > $IN.2

2021-08-01 15:13:37 dpchrist@dipsy ~
$ IN=initrd.img-4.19.0-16-amd64.txt && perl -ane 
'@F[1,4,5,6,7]=("","","","",""); $F[8]=~s/\d\.\d+\.\d-\d+/V.V.V-V/; 
print "@F\n"' $IN | sort > $IN.2


Compare the munged files:

2021-08-01 15:15:10 dpchrist@dipsy ~
$ diff -d initrd.img-4.19.0-16-amd64.txt.2 
initrd.img-5.10.0-8-amd64.txt.2 | gzip -9 > 
initrd.img-4.19.0-16-amd64.diff.initrd.img-5.10.0-8-amd64.gz

Please see initrd.img-4.19.0-16-amd64.diff.initrd.img-5.10.0-8-amd64.gz, 
attached.


David

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

#238004

On Sun, Aug 01, 2021 at 03:29:07PM -0700, David Christensen wrote:
> 2021-08-01 13:52:37 root@dipsy ~
> # file /boot/initrd.img-4.19.0-17-amd64
> /boot/initrd.img-4.19.0-17-amd64: gzip compressed data, last modified: Sun
> Jul 25 19:43:38 2021, from Unix, original size 126331392

Your initrd image, *uncompressed*, is smaller than the OP's compressed
images.  That should put to bed any more silly comments about "try
switching from gzip to bzip2 or xz" that we always get whenever someone
makes one of these threads.

(Or... at least, the first CPIO archive in your initrd image is that size.
And maybe you've only got one.  You appear not to have any microcode
in yours.  But other people will generally not have just one.)

> # gunzip -c /boot/initrd.img-4.19.0-17-amd64 | cpio -i -d -H newc
> --no-absolute-filenames
> 246741 blocks

That may not extract the full content of the initrd.  It only reads
one of the concatenated CPIO archives.  Also, the first archive may not
be gzipped.  Also also, hard-coding the input archive format is weird;
I'd prefer to let cpio auto-detect it.

To get a full listing, either use "lsinitramfs -l", or write a command
that reads *all* of the CPIO archives, not just the first one.  I'd
advise using lsinitramfs -l, because it'll be a lot easier.

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

#238037

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

On 01/08/2021 23:51, Greg Wooledge wrote:
> On Sun, Aug 01, 2021 at 03:29:07PM -0700, David Christensen wrote:
>> 2021-08-01 13:52:37 root@dipsy ~
>> # file /boot/initrd.img-4.19.0-17-amd64
>> /boot/initrd.img-4.19.0-17-amd64: gzip compressed data, last modified: Sun
>> Jul 25 19:43:38 2021, from Unix, original size 126331392
> Your initrd image, *uncompressed*, is smaller than the OP's compressed
> images.  That should put to bed any more silly comments about "try
> switching from gzip to bzip2 or xz" that we always get whenever someone
> makes one of these threads.

I object slightly to the comments being "silly", but you are right
that,  although changing the compression will save some space, thinning
out the contents of the initrd is going to have a much bigger effect. I
stand corrected.

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

#238049

On 8/1/21 3:51 PM, Greg Wooledge wrote:
> On Sun, Aug 01, 2021 at 03:29:07PM -0700, David Christensen wrote:
>> 2021-08-01 13:52:37 root@dipsy ~

>> # gunzip -c /boot/initrd.img-4.19.0-17-amd64 | cpio -i -d -H newc
>> --no-absolute-filenames
>> 246741 blocks
> 
> That may not extract the full content of the initrd.  It only reads
> one of the concatenated CPIO archives.  Also, the first archive may not
> be gzipped.  Also also, hard-coding the input archive format is weird;
> I'd prefer to let cpio auto-detect it.
> 
> To get a full listing, either use "lsinitramfs -l", or write a command
> that reads *all* of the CPIO archives, not just the first one.  I'd
> advise using lsinitramfs -l, because it'll be a lot easier.


Please post your console session showing how you created 
initrd.img-5.10.0-8-amd64.txt.gz.


David

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

#238050

On Mon, Aug 02, 2021 at 11:11:11AM -0700, David Christensen wrote:
> On 8/1/21 3:51 PM, Greg Wooledge wrote:
> > On Sun, Aug 01, 2021 at 03:29:07PM -0700, David Christensen wrote:
> > > 2021-08-01 13:52:37 root@dipsy ~
> 
> > > # gunzip -c /boot/initrd.img-4.19.0-17-amd64 | cpio -i -d -H newc
> > > --no-absolute-filenames
> > > 246741 blocks
> > 
> > That may not extract the full content of the initrd.  It only reads
> > one of the concatenated CPIO archives.  Also, the first archive may not
> > be gzipped.  Also also, hard-coding the input archive format is weird;
> > I'd prefer to let cpio auto-detect it.
> > 
> > To get a full listing, either use "lsinitramfs -l", or write a command
> > that reads *all* of the CPIO archives, not just the first one.  I'd
> > advise using lsinitramfs -l, because it'll be a lot easier.
> 
> 
> Please post your console session showing how you created
> initrd.img-5.10.0-8-amd64.txt.gz.

I didn't.  It was created automatically when I installed dracut-core.

Prior to that, it was created automatically every time I did anything
with apt-get which touched the "low level stuff" (kernel, firmware,
microcode, busybox, other tools that live in the initrd, and so on).

Here's an example:

unicorn:~$ sudo apt-get purge dracut-core cryptsetup
[sudo] password for greg: 
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following packages will be REMOVED:
  cryptsetup* cryptsetup-initramfs* cryptsetup-run* dracut-core*
0 upgraded, 0 newly installed, 4 to remove and 0 not upgraded.
After this operation, 1,847 kB disk space will be freed.
Do you want to continue? [Y/n] 
(Reading database ... 157820 files and directories currently installed.)
Removing cryptsetup-run (2:2.3.5-1) ...
Removing cryptsetup-initramfs (2:2.3.5-1) ...
update-initramfs: deferring update (trigger activated)
Removing cryptsetup (2:2.3.5-1) ...
Removing dracut-core (051-1) ...
Processing triggers for man-db (2.9.4-2) ...
Processing triggers for initramfs-tools (0.140) ...
update-initramfs: Generating /boot/initrd.img-5.10.0-8-amd64
(Reading database ... 157360 files and directories currently installed.)
Purging configuration files for cryptsetup (2:2.3.5-1) ...
Purging configuration files for dracut-core (051-1) ...
Purging configuration files for cryptsetup-initramfs (2:2.3.5-1) ...
unicorn:~$ ls -l /boot/initrd*
-rw-r--r-- 1 root root 30924690 Jan 29  2021 /boot/initrd.img-4.19.0-13-amd64
-rw-r--r-- 1 root root 34310935 Jul 21 07:30 /boot/initrd.img-5.10.0-7-amd64
-rw-r--r-- 1 root root 39491974 Aug  2 14:26 /boot/initrd.img-5.10.0-8-amd64

Gah.  It's still inflated.

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

#238057

On Mon, Aug 02, 2021 at 12:43:27PM -0700, David Christensen wrote:
> I'd rather not install dracut.

Me too.  So why not use lsinitramfs -l ?  Why keep reinventing the wheel?

unicorn:~$ lsinitramfs -l /boot/initrd.img-5.10.0-8-amd64 | head -12
drwxr-xr-x   2 root     root            0 Apr 25 08:00 kernel
drwxr-xr-x   2 root     root            0 Apr 25 08:00 kernel/x86
drwxr-xr-x   2 root     root            0 Apr 25 08:00 kernel/x86/microcode
drwxr-xr-x   2 root     root            0 Apr 25 08:00 kernel/x86/microcode/.enuineIntel.align.0123456789abc
-rw-r--r--   1 root     root      4609024 Apr 25 08:00 kernel/x86/microcode/GenuineIntel.bin
drwxr-xr-x   7 root     root            0 Aug  2 14:37 .
lrwxrwxrwx   1 root     root            7 Aug  2 14:37 bin -> usr/bin
drwxr-xr-x   3 root     root            0 Aug  2 14:37 conf
-rw-r--r--   1 root     root           16 Aug  2 14:37 conf/arch.conf
drwxr-xr-x   2 root     root            0 Aug  2 14:37 conf/conf.d
-rw-r--r--   1 root     root           49 Jan 11  2018 conf/conf.d/resume
-rw-r--r--   1 root     root         1365 Sep 13  2020 conf/initramfs.conf

No dracut needed.

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

#238063

On 8/2/21 12:47 PM, Greg Wooledge wrote:
> On Mon, Aug 02, 2021 at 12:43:27PM -0700, David Christensen wrote:
>> I'd rather not install dracut.
> 
> Me too.  So why not use lsinitramfs -l ?  Why keep reinventing the wheel?
> 
> unicorn:~$ lsinitramfs -l /boot/initrd.img-5.10.0-8-amd64 | head -12
> drwxr-xr-x   2 root     root            0 Apr 25 08:00 kernel
> drwxr-xr-x   2 root     root            0 Apr 25 08:00 kernel/x86
> drwxr-xr-x   2 root     root            0 Apr 25 08:00 kernel/x86/microcode
> drwxr-xr-x   2 root     root            0 Apr 25 08:00 kernel/x86/microcode/.enuineIntel.align.0123456789abc
> -rw-r--r--   1 root     root      4609024 Apr 25 08:00 kernel/x86/microcode/GenuineIntel.bin
> drwxr-xr-x   7 root     root            0 Aug  2 14:37 .
> lrwxrwxrwx   1 root     root            7 Aug  2 14:37 bin -> usr/bin
> drwxr-xr-x   3 root     root            0 Aug  2 14:37 conf
> -rw-r--r--   1 root     root           16 Aug  2 14:37 conf/arch.conf
> drwxr-xr-x   2 root     root            0 Aug  2 14:37 conf/conf.d
> -rw-r--r--   1 root     root           49 Jan 11  2018 conf/conf.d/resume
> -rw-r--r--   1 root     root         1365 Sep 13  2020 conf/initramfs.conf
> 
> No dracut needed.


Did you not make a post that lsinitrd.sh and lsinitramfs produced 
different output?

https://lists.debian.org/debian-user/2021/08/msg00057.html


They seem to produce the same output on my machine.  So, yes, 
lsinitramfs(8) is preferable:

$ lsinitramfs -l /boot/initrd.img-4.19.0-17-amd64 | sort -k 9 > 
initrd.img-4.19.0-17-amd64.lsinitramfs

$ diff -s initrd.img-4.19.0-17-amd64.txt 
initrd.img-4.19.0-17-amd64.lsinitramfs
Files initrd.img-4.19.0-17-amd64.txt and 
initrd.img-4.19.0-17-amd64.lsinitramfs are identical


David

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

#238059

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

On 8/2/21 11:29 AM, Greg Wooledge wrote:
> On Mon, Aug 02, 2021 at 11:11:11AM -0700, David Christensen wrote:

>> Please post your console session showing how you created
>> initrd.img-5.10.0-8-amd64.txt.gz.
> 
> I didn't.  It was created automatically when I installed dracut-core.
> 
> Prior to that, it was created automatically every time I did anything
> with apt-get which touched the "low level stuff" (kernel, firmware,
> microcode, busybox, other tools that live in the initrd, and so on).


I'd rather not install dracut.


The source for lsinitrd.sh is available on github:

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


The cpio(1) listing incantation appears on line 177.  Reworking my 
previous command:

$ gunzip -c /boot/initrd.img-4.19.0-17-amd64 | cpio --extract --verbose 
--list | sort -k9 | gzip -9 > initrd.img-4.19.0-17-amd64.txt.gz
246741 blocks


Please see initrd.img-4.19.0-17-amd64.txt.gz, attached.


If the OP would care to run the above command and post the result, 
perhaps we can see what is bloating their initrd.img.


David

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

#238009 — Re: listing initrd content (was: Updating kernels impossible...)

David Christensen composed on 2021-08-01 15:29 (UTC-0700):

> 2021-08-01 14:10:24 root@dipsy /tmp/initrd.img-4.19.0-17-amd64
> # gunzip -c /boot/initrd.img-4.19.0-17-amd64 | cpio -i -d -H newc 
> --no-absolute-filenames
> 246741 blocks
											
If only searching whether a string is contained therein, or wanting a list,
it can be simpler:

# uname -v
#1 SMP Debian 5.10.46-3 (2021-07-28)
# which lsinitrd
/usr/bin/lsinitrd
# apt-file search /usr/bin/lsinitrd
dracut-core: /usr/bin/lsinitrd
# lsinitrd /initrd.img | wc -l
455
-- 
Evolution as taught in public schools is, like religion,
	based on faith, not based on science.

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

Felix Miata

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

#238017 — Re: listing initrd content (was: Updating kernels impossible...)

On Mon, Aug 02, 2021 at 01:20:13AM -0400, Felix Miata wrote:
> David Christensen composed on 2021-08-01 15:29 (UTC-0700):
> 
> > 2021-08-01 14:10:24 root@dipsy /tmp/initrd.img-4.19.0-17-amd64
> > # gunzip -c /boot/initrd.img-4.19.0-17-amd64 | cpio -i -d -H newc 
> > --no-absolute-filenames
> > 246741 blocks
> 											
> If only searching whether a string is contained therein, or wanting a list,
> it can be simpler:
> 
> # uname -v
> #1 SMP Debian 5.10.46-3 (2021-07-28)
> # which lsinitrd
> /usr/bin/lsinitrd
> # apt-file search /usr/bin/lsinitrd
> dracut-core: /usr/bin/lsinitrd
> # lsinitrd /initrd.img | wc -l
> 455

unicorn:~$ lsinitrd /boot/initrd.img-5.10.0-8-amd64 | wc -l
1646
unicorn:~$ lsinitramfs /boot/initrd.img-5.10.0-8-amd64 | wc -l
1635

Curious.

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

#238019 — Re: listing initrd content

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

On 2021-08-02 at 07:25, Greg Wooledge wrote:

> unicorn:~$ lsinitrd /boot/initrd.img-5.10.0-8-amd64 | wc -l
> 1646
> unicorn:~$ lsinitramfs /boot/initrd.img-5.10.0-8-amd64 | wc -l
> 1635
> 
> Curious.

Try a diff between the lsinit* outputs? I don't have dracut-core
installed, or I'd run the test myself just out of curiosity.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw

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

#238020 — Re: listing initrd content

On Mon, Aug 02, 2021 at 07:41:03AM -0400, The Wanderer wrote:
> On 2021-08-02 at 07:25, Greg Wooledge wrote:
> 
> > unicorn:~$ lsinitrd /boot/initrd.img-5.10.0-8-amd64 | wc -l
> > 1646
> > unicorn:~$ lsinitramfs /boot/initrd.img-5.10.0-8-amd64 | wc -l
> > 1635
> > 
> > Curious.
> 
> Try a diff between the lsinit* outputs? I don't have dracut-core
> installed, or I'd run the test myself just out of curiosity.

I didn't have it either; I installed it specifically to test this thing.
Unfortunately, installing it also brought in "cryptsetup" and related
packages, which modified the initrd images.  Because of that, I don't
recommend this test for anyone else.

unicorn:~$ lsinitramfs -l /boot/initrd.img-5.10.0-8-amd64 | head
drwxr-xr-x   2 root     root            0 Apr 25 08:00 kernel
drwxr-xr-x   2 root     root            0 Apr 25 08:00 kernel/x86
drwxr-xr-x   2 root     root            0 Apr 25 08:00 kernel/x86/microcode
drwxr-xr-x   2 root     root            0 Apr 25 08:00 kernel/x86/microcode/.enuineIntel.align.0123456789abc
-rw-r--r--   1 root     root      4609024 Apr 25 08:00 kernel/x86/microcode/GenuineIntel.bin
drwxr-xr-x   8 root     root            0 Aug  2 07:24 .
lrwxrwxrwx   1 root     root            7 Aug  2 07:24 bin -> usr/bin
drwxr-xr-x   3 root     root            0 Aug  2 07:24 conf
-rw-r--r--   1 root     root           16 Aug  2 07:24 conf/arch.conf
drwxr-xr-x   2 root     root            0 Aug  2 07:24 conf/conf.d

unicorn:~$ lsinitrd /boot/initrd.img-5.10.0-8-amd64 | head
Image: /boot/initrd.img-5.10.0-8-amd64: 39M
========================================================================
Early CPIO image
========================================================================
drwxr-xr-x   2 root     root            0 Apr 25 08:00 kernel
drwxr-xr-x   2 root     root            0 Apr 25 08:00 kernel/x86
drwxr-xr-x   2 root     root            0 Apr 25 08:00 kernel/x86/microcode
drwxr-xr-x   2 root     root            0 Apr 25 08:00 kernel/x86/microcode/.enuineIntel.align.0123456789abc
-rw-r--r--   1 root     root      4609024 Apr 25 08:00 kernel/x86/microcode/GenuineIntel.bin
========================================================================

At first glance, it looks like the difference in line count might be
due to these headers and footers around each archive.

But if I actually do

diff -u <(lsinitramfs -l /boot/initrd.img-5.10.0-8-amd64) <(lsinitrd /boot/initrd.img-5.10.0-8-amd64) | less

there are a whole bunch of other differences.  Some archive member files
are moved around, which I cannot understand (the biggest offenders are
the 0-length hard link indicators such as usr/bin/umount).  I'm not sure
if those are the *only* differences, because there's so much noise due
to that.

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

#238022 — Re: listing initrd content

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

On 2021-08-02 at 07:51, Greg Wooledge wrote:

> On Mon, Aug 02, 2021 at 07:41:03AM -0400, The Wanderer wrote:
>
>> On 2021-08-02 at 07:25, Greg Wooledge wrote:
>> 
>> > unicorn:~$ lsinitrd /boot/initrd.img-5.10.0-8-amd64 | wc -l
>> > 1646
>> > unicorn:~$ lsinitramfs /boot/initrd.img-5.10.0-8-amd64 | wc -l
>> > 1635
>> > 
>> > Curious.
>> 
>> Try a diff between the lsinit* outputs? I don't have dracut-core
>> installed, or I'd run the test myself just out of curiosity.
> 
> I didn't have it either; I installed it specifically to test this thing.
> Unfortunately, installing it also brought in "cryptsetup" and related
> packages, which modified the initrd images.  Because of that, I don't
> recommend this test for anyone else.

dracut-core has cryptsetup in Recommends:, so that could be avoided with
--no-install-recommends. Maybe try removing dracut-core, 'apt-get
autoremove' / 'apt-get remove $(deborphan)' etc. till nothing new is
removed, then install dracut-core again without Recommends and see if
that improves things any?

That's a bigger and more drastic operation than it sounded like when I
started writing out the steps, though, so maybe not worth bothering with.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw

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

#238041 — Re: listing initrd content

On Mon 02 Aug 2021 at 07:51:55 (-0400), Greg Wooledge wrote:
> On Mon, Aug 02, 2021 at 07:41:03AM -0400, The Wanderer wrote:
> > On 2021-08-02 at 07:25, Greg Wooledge wrote:
> > 
> > > unicorn:~$ lsinitrd /boot/initrd.img-5.10.0-8-amd64 | wc -l
> > > 1646
> > > unicorn:~$ lsinitramfs /boot/initrd.img-5.10.0-8-amd64 | wc -l
> > > 1635
> > > 
> > > Curious.
> > 
> > Try a diff between the lsinit* outputs? I don't have dracut-core
> > installed, or I'd run the test myself just out of curiosity.
> 
> I didn't have it either; I installed it specifically to test this thing.
> Unfortunately, installing it also brought in "cryptsetup" and related
> packages, which modified the initrd images.  Because of that, I don't
> recommend this test for anyone else.
> 
> unicorn:~$ lsinitramfs -l /boot/initrd.img-5.10.0-8-amd64 | head
> [ … ]
> unicorn:~$ lsinitrd /boot/initrd.img-5.10.0-8-amd64 | head
> [ … ]
> 
> At first glance, it looks like the difference in line count might be
> due to these headers and footers around each archive.
> 
> But if I actually do
> 
> diff -u <(lsinitramfs -l /boot/initrd.img-5.10.0-8-amd64) <(lsinitrd /boot/initrd.img-5.10.0-8-amd64) | less
> 
> there are a whole bunch of other differences.  Some archive member files
> are moved around, which I cannot understand (the biggest offenders are
> the 0-length hard link indicators such as usr/bin/umount).  I'm not sure
> if those are the *only* differences, because there's so much noise due
> to that.

You posted here their precise sizes before you installed dracut.
What's the size of your new initrd.img—has dracut done its job?

  Package: dracut-core
  Description-md5: 5df7edfd996e6db7e65cd0435ed243c3
  Description-en: dracut is an event driven initramfs infrastructure (core tools)
   Unlike existing initramfs's, this is an attempt at having as little as
   possible hard-coded into the initramfs as possible.  The initramfs has
   (basically) one purpose in life -- getting the rootfs mounted so that
   we can transition to the real rootfs.  This is all driven off of
   device availability.  Therefore, instead of scripts hard-coded to do
   various things, we depend on udev to create device nodes for us and
   then when we have the rootfs's device node, we mount and carry on.
   Having the root on MD, LVM2, LUKS is supported as well as NFS, iSCSI,
   NBD and FCOE with dracut-network.

BTW I encrypt only /home and swap, and AFAICT my initrd.img doesn't
contain crypt stuff except for /usr/bin/cryptroot-unlock (5686B).
So I ignore a polite warning at every rebuild:

  update-initramfs: Generating /boot/initrd.img-4.19.0-17-amd64
  cryptsetup: WARNING: The initramfs image may not contain cryptsetup binaries 
      nor crypto modules. If that's on purpose, you may want to uninstall the 
      'cryptsetup-initramfs' package in order to disable the cryptsetup initramfs 
      integration and avoid this warning.
  Log ended: 2021-07-20  10:07:25

Cheers,
David.

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web