Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

No space left when: update-initramfs: Generating /boot/initrd.img-5.10.0-5-amd64

126 views
Skip to first unread message

Marco Ippolito

unread,
Apr 7, 2021, 8:30:05 AM4/7/21
to
Was upgrading from buster to bullseye. Space ran out, UI crashed, restarted in
recovery mode and cleaned up space. Restarted and run:

# dpkg --configure -a
Setting up initramfs-tools (0.139) ...
update-initramfs: deferring update (trigger activated)
Processing triggers for initramfs-tools (0.139) ...
update-initramfs: Generating /boot/initrd.img-5.10.0-5-amd64
cat: write error: No space left on device
update-initramfs: failed for /boot/initrd.img-5.10.0-5-amd64 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

# df -h /boot
Filesystem Size Used Avail Use% Mounted on
/dev/nvme0n1p1 236M 233M 0 100% /boot

What do you recommend I do?

Doubt: after this, by default old kernels will be cleaned up in Bullseye Vs
Buster?

Greg Wooledge

unread,
Apr 7, 2021, 8:40:04 AM4/7/21
to
On Wed, Apr 07, 2021 at 09:20:46AM -0300, Marco Ippolito wrote:
> # df -h /boot
> Filesystem Size Used Avail Use% Mounted on
> /dev/nvme0n1p1 236M 233M 0 100% /boot
>
> What do you recommend I do?

Purge one or more of your kernel images.

IL Ka

unread,
Apr 7, 2021, 8:50:04 AM4/7/21
to

# df -h /boot
Filesystem      Size  Used Avail Use% Mounted on
/dev/nvme0n1p1  236M  233M     0 100% /boot

What do you recommend I do?

1. Autoremove old automatically installed stuff

$ apt purge --autoremove

2. Check packages:

$ dpkg-query --show -f='${Installed-Size}\t${Package}\t${Status}\n' | sort -nr | head

This will give you the biggest packages (latest field should show if they are really installed).
Find the one you do not need  (old kernel probably, but be sure not to delete the current kernel: check "uname -r" !)

Then, purge them:
apt purge "package name"
 
 

Doubt: after this, by default old kernels will be cleaned up in Bullseye Vs
       Buster?


AFAIK yes, when you call "autoremove" , but one prev. kernel left untouched.

see
/etc/apt/apt.conf.d/01autoremove-kernels
or something like this





 

Stefan Monnier

unread,
Apr 7, 2021, 9:00:04 AM4/7/21
to
> What do you recommend I do?

Other than purging old kernels, I also recommend you check

/etc/initramfs-tools/initramfs.conf

where `MODULES=dep` and `COMPRESS=lzma` have made a big difference for
me (more or less shrunk the initrd images by a factor 3-4).

> Doubt: after this, by default old kernels will be cleaned up in Bullseye Vs
> Buster?

I don't think APT ever cleans up old kernels for you (at least in its
default configuration).


Stefan

Hans

unread,
Apr 7, 2021, 9:20:06 AM4/7/21
to

Am Mittwoch, 7. April 2021, 14:20:46 CEST schrieb Marco Ippolito:

Hi Marco,

just get rid of older kernels.



This is may way:



1st, check your running actual kernel:


uname -a


Then check all installed kernel versions:


ls /boot


You will see several kernels. I suppose, apt-get autoremove will not unistall them, so just use aptitude with the version you want to uninstall:


aptitude purge ~n4.9.10-amd64-*


This will uninstall all stuff with "4.9.10-amd64-" in its name, this means kernel, headers and maybe selfcompiled kernel modules like the nvidia-stuff.


Please check before saying "Y" what is going to be uninstalled.


Do this with all the kernels, except the one you are actually running.


This is working well for me, so good luck!


Best regards


Hans


--

Hans-J. Ullrich

zertifizierter Datenschutzbeauftragter

zertifizierter Datenschutzauditor

zertifizierter Penetrationtester

zertifizierter IT-Security Professionell

zertifizierter IT-Forensik Professionell

zertifizierter Network Vulnerabilty Professionell



Javier Barroso

unread,
Apr 7, 2021, 9:40:05 AM4/7/21
to


El mié., 7 abr. 2021 14:58, Stefan Monnier <mon...@iro.umontreal.ca> escribió:
> What do you recommend I do?

Other than purging old kernels, I also recommend you check

    /etc/initramfs-tools/initramfs.conf

where `MODULES=dep` and `COMPRESS=lzma` have made a big difference for
me (more or less shrunk the initrd images by a factor 3-4).

Thanks I will test!

> Doubt: after this, by default old kernels will be cleaned up in Bullseye Vs
>        Buster?

I don't think APT ever cleans up old kernels for you (at least in its
default configuration).

Recently that was fixed at unstable [1]

I found a interesting manpage for this issue [2]

Regards



        Stefan

Erwan David

unread,
Apr 7, 2021, 9:40:05 AM4/7/21
to
I also found that firmware need space, especially amd64 graphics firmware.

Marco Ippolito

unread,
Apr 7, 2021, 10:10:04 AM4/7/21
to
> Recently that was fixed at unstable [1]

I thought I had noticed a warning about this clean-up, but it does not happen
during the upgrade so I run out of space.

> I found a interesting manpage for this issue [2]

Good catch. Functionality now in apt and purge-old-kernels got deprecated.

Marco Ippolito

unread,
Apr 7, 2021, 10:10:04 AM4/7/21
to
> where `MODULES=dep` and `COMPRESS=lzma` have made a big difference for
> me (more or less shrunk the initrd images by a factor 3-4).

Thank you.

Why did you choose lzma Vs xz or zstd, by the way? Measured diff?

> > Doubt: after this, by default old kernels will be cleaned up in Bullseye Vs
> > Buster?
> I don't think APT ever cleans up old kernels for you (at least in its
> default configuration).

Read something about it during the upgrade.. was checking here.

Marco Ippolito

unread,
Apr 7, 2021, 10:20:05 AM4/7/21
to
> Hi Marco,

Hi Hans :)

> aptitude purge ~n4.9.10-amd64-*

Hadn't thought of matching a pattern, thanks.

Stefan Monnier

unread,
Apr 7, 2021, 11:40:05 AM4/7/21
to
>> where `MODULES=dep` and `COMPRESS=lzma` have made a big difference for
>> me (more or less shrunk the initrd images by a factor 3-4).
> Thank you.
> Why did you choose lzma Vs xz or zstd, by the way? Measured diff?

`lzma` and `xz` should be pretty much identical, it was a toss-up (I
have a preference for `lzip` in that space, but it's not available ;-).

`zstd` should compress significantly less (but is significantly faster
both to compress and to uncompress). I focused on disk space usage
(but I did notice that uncompression takes a non-negligible amount of
time on my old Thinkpad X30 when the initrd image is large (e.g. with
`modules=most`)).

>> > Doubt: after this, by default old kernels will be cleaned up in
>> > Bullseye Vs Buster?
>> I don't think APT ever cleans up old kernels for you (at least in its
>> default configuration).
> Read something about it during the upgrade.. was checking here.

Maybe my info is out of date then.


Stefan

Andrei POPESCU

unread,
Apr 7, 2021, 1:50:04 PM4/7/21
to
While I'm a big fan of aptitude's patterns it's also not installed by
default. For basic uses 'apt' is fine as well and supports globs:

apt list --installed linux-image-4*

apt purge linux-image-4.9.10-?-amd64


(just an example, adjust as needed)

Hope this helps,
Andrei
--
http://wiki.debian.org/FAQsFromDebianUser
signature.asc

Greg Wooledge

unread,
Apr 7, 2021, 2:10:18 PM4/7/21
to
On Wed, Apr 07, 2021 at 08:40:58PM +0300, Andrei POPESCU wrote:
> While I'm a big fan of aptitude's patterns it's also not installed by
> default. For basic uses 'apt' is fine as well and supports globs:
>
> apt list --installed linux-image-4*
>
> apt purge linux-image-4.9.10-?-amd64

Remember that you need to quote these globs (at least the special
characters in them), or else one day you *will* get a nasty surprise
when one of them matches a file in your current working directory.

Hans

unread,
Apr 7, 2021, 2:30:05 PM4/7/21
to
Am Mittwoch, 7. April 2021, 19:40:58 CEST schrieb Andrei POPESCU:
Hi Andrei,

yes, you casn do this also with using apt. However, I forgot how to do this,
it was a litttle bit more complicated.

The syntax was something like "apt-get --purge remove `somestring` " or
similar. Apt was then using regexp, and the string had to be put in backticks
or ticks whatever.

Really, maybe google is telling more. I just forgot, how to do it.

Last time I used it many years ago and my history is not that long. :-)

Best regards

Hans

David Wright

unread,
Apr 7, 2021, 2:40:05 PM4/7/21
to
And I'm a big fan of -s with commands like these, so that
you know what's going to be changed. Then recall the command
and remove the -s.

I'm also a big fan of mv -i rather than rm, for similar
reasons. Remove the files only when you're sure the system
still works without them.

Cheers,
David.

Eduard Bloch

unread,
Apr 7, 2021, 3:30:05 PM4/7/21
to
Hallo,
* Marco Ippolito [Wed, Apr 07 2021, 09:20:46AM]:

> 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
>
> # df -h /boot
> Filesystem Size Used Avail Use% Mounted on
> /dev/nvme0n1p1 236M 233M 0 100% /boot

That's not much if you have more than a few kernels installed. They are
simply too fat nowadays, too many drivers included. And with the "most"
strategy (which you normally want to have a bootable system), they are
just too fat nowadays. I decided to let MY initramfs images go on diet
and added a little script which removes a few drivers that I certainly
don't need (checked with lsmod) and which contained lots of firmwares
and similar stuff.

So, one _might_ try that but only on your own risk, it could render your
system unbootable. I selected those three because they contributed most
to the overall usage (unpacked initramfs image with unmkinitramfs and
checking with "du|sort -n").

$ cat /etc/initramfs-tools/hooks/zz_drop_stuff
#!/bin/sh

if ! test "$DESTDIR"; then
. /usr/share/initramfs-tools/hook-functions
fi

set -x

#experiments: radeon infiniband lpfc qla2xxx qla4xxx cxgb4 drbd nfs bfa f2fs xfs btrfs aic7xxx gma500

for nam in i915 amdgpu ethernet
do
find ${DESTDIR} -name $nam | xargs --no-run-if-empty rm -rv
done

#USEDMODPAT=$(lsmod | grep -v " 0 " | sed -e "s, .*,,;s,_,.,g;s,$,.ko,")
#for pat in $USEDMODPAT
#do
# find ${DESTDIR} | grep "/${pat}$" || echo "WARNING: $pat not found, essential module missing!"

That script probably should be set executable.

Best regards,
Eduard.

Marco Ippolito

unread,
Apr 7, 2021, 5:00:05 PM4/7/21
to
> I decided to let MY initramfs images go on diet
> and added a little script which removes a few drivers that I certainly
> don't need (checked with lsmod) and which contained lots of firmwares
> and similar stuff.

Creative. I liked it. Indeed the ``most'' strategy produces large files.

Marco Ippolito

unread,
Apr 8, 2021, 8:30:05 AM4/8/21
to
> And I'm a big fan of -s with commands like these, so that
> you know what's going to be changed. Then recall the command
> and remove the -s.

Where would I put the -s please?

David

unread,
Apr 8, 2021, 9:20:05 AM4/8/21
to
Explanation of how to find the answer:
He was talking about 'apt' commands.
If you read 'man apt' it hints that it is a front-end to
various 'apt-*' commands like 'apt-get'.
The hints look like "apt-get(8)" which is a reference
to the 'apt-get' man page in Section 8, which can
be read using the command:
man 8 apt-get
And if you read that man page, you can find an
explanation of the -s option when used with a
'apt-get' command.

Marco Ippolito

unread,
Apr 8, 2021, 9:40:05 AM4/8/21
to
> > Where would I put the -s please?
>
> Explanation of how to find the answer:
> He was talking about 'apt' commands.
> If you read 'man apt' it hints that it is a front-end to
> various 'apt-*' commands like 'apt-get'.
> The hints look like "apt-get(8)" which is a reference
> to the 'apt-get' man page in Section 8, which can
> be read using the command:
> man 8 apt-get
> And if you read that man page, you can find an
> explanation of the -s option when used with a
> 'apt-get' command.

Gotcha. I like the long option names there, almost all of which are immediately
suggestive of what the change of behaviour might be:

--simulate, --just-print, --dry-run, --recon, --no-act

Especially: --simulate and --dry-run (for users of rsync and other commands
that use the same long option name)

David

unread,
Apr 9, 2021, 7:00:05 AM4/9/21
to
On Thu, 8 Apr 2021 at 23:33, Marco Ippolito <marol...@gmail.com> wrote:

> Gotcha. I like the long option names there, almost all of which are immediately
> suggestive of what the change of behaviour might be:
>
> --simulate, --just-print, --dry-run, --recon, --no-act

Yes, and my impression/guess is that because 'apt' docs describe it
as being basically a front end with more convenient defaults for
interactive use, what happens when 'apt' is given these (or other
similar) options that it does not recognise as its own as documented
in the 'apt' man page, it behaves the same as if it handed these
options off to whatever command it runs as its back-end.
So 'apt -s install ...' behaves like 'apt-get -s install ...'.
I don't know if that's literally how it is implemented, but it's
the general behaviour that I would expect. 'apt' is still under
development so the details of it's behaviour might change
between releases.

Marco Ippolito

unread,
Apr 9, 2021, 9:20:04 PM4/9/21
to
> Yes, and my impression/guess is that because 'apt' docs describe it
> as being basically a front end with more convenient defaults for
> interactive use, what happens when 'apt' is given these (or other
> similar) options that it does not recognise as its own as documented
> in the 'apt' man page, it behaves the same as if it handed these
> options off to whatever command it runs as its back-end.

I wonder if documentation for options like -s belongs only in apt-get, both in
apt-get and apt or something else. Currenly, the option is accepted by apt but
not documented in the man page I have on my system for apt.
0 new messages