Updating kernels impossible when /boot is getting full

Ilkka Huotari

unread,

Aug 1, 2021, 12:40:05 AM8/1/21

to

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

unread,

Aug 1, 2021, 6:00:04 AM8/1/21

to

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.

--

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.

Ilkka Huotari

unread,

Aug 1, 2021, 6:40:06 AM8/1/21

to

Hi Paul,

Thanks. I should have said, that also apt-get autoremove fails:

$ sudo apt-get autoremove
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
1 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Setting up initramfs-tools (0.139ubuntu3) ...
update-initramfs: deferring update (trigger activated)
Processing triggers for initramfs-tools (0.139ubuntu3) ...

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)

Maybe this is a bug in the dpkg?

This sounds like some disk (it's a few years old SSD) error, but I don't know:

"Error 24 : Write error : cannot write compressed block"

Contents of the /boot:

total 343M
-rw-r--r-- 1 root root 248K kesä 17 01:38 config-5.11.0-22-generic
-rw-r--r-- 1 root root 248K heinä 9 20:42 config-5.11.0-25-generic
drwx------ 6 root root 4,0K tammi 1 1970 efi
drwxr-xr-x 4 root root 4,0K heinä 23 13:13 grub

-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

lrwxrwxrwx 1 root root 28 heinä 23 06:04 initrd.img.old -> initrd.img-5.11.0-22-generic
drwx------ 2 root root 16K heinä 6 08:52 lost+found
-rw-r--r-- 1 root root 179K elo 18 2020 memtest86+.bin
-rw-r--r-- 1 root root 181K elo 18 2020 memtest86+.elf
-rw-r--r-- 1 root root 181K elo 18 2020 memtest86+_multiboot.bin
-rw------- 1 root root 5,7M kesä 17 01:38 System.map-5.11.0-22-generic
-rw------- 1 root root 5,7M heinä 9 20:42 System.map-5.11.0-25-generic
lrwxrwxrwx 1 root root 25 heinä 23 06:04 vmlinuz -> vmlinuz-5.11.0-25-generic
-rw------- 1 root root 15M kesä 17 01:55 vmlinuz-5.11.0-22-generic
-rw------- 1 root root 15M heinä 9 21:04 vmlinuz-5.11.0-25-generic
lrwxrwxrwx 1 root root 25 heinä 23 06:04 vmlinuz.old -> vmlinuz-5.11.0-22-generic

Ilkka

The Wanderer

unread,

Aug 1, 2021, 7:00:05 AM8/1/21

to

On 2021-08-01 at 06:21, Ilkka Huotari wrote:

> Hi Paul,
>
> Thanks. I should have said, that also apt-get autoremove fails:
>
> $ sudo apt-get autoremove
> Reading package lists... Done
> Building dependency tree... Done
> Reading state information... Done
> 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
> 1 not fully installed or removed.
> After this operation, 0 B of additional disk space will be used.
> Setting up initramfs-tools (0.139ubuntu3) ...
> update-initramfs: deferring update (trigger activated)
> Processing triggers for initramfs-tools (0.139ubuntu3) ...
> 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)
>
> Maybe this is a bug in the dpkg?

It could be argued, but I'm not sure what dpkg could plausibly do about
it, so I'm not convinced just up-front.

> This sounds like some disk (it's a few years old SSD) error, but I don't
> know:
> "Error 24 : Write error : cannot write compressed block"

That could (I don't know, myself) just be the way cpio reports failing
to write in the case when the disk would have been full, after which the
automatic system cleans up the incomplete file it was creating, so the
disk is no longer full.

> Contents of the /boot:
>
> total 343M
> -rw-r--r-- 1 root root 248K kesä 17 01:38 config-5.11.0-22-generic
> -rw-r--r-- 1 root root 248K heinä 9 20:42 config-5.11.0-25-generic
> drwx------ 6 root root 4,0K tammi 1 1970 efi
> drwxr-xr-x 4 root root 4,0K heinä 23 13:13 grub
> -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
> lrwxrwxrwx 1 root root 28 heinä 23 06:04 initrd.img.old ->
> initrd.img-5.11.0-22-generic
> drwx------ 2 root root 16K heinä 6 08:52 lost+found
> -rw-r--r-- 1 root root 179K elo 18 2020 memtest86+.bin
> -rw-r--r-- 1 root root 181K elo 18 2020 memtest86+.elf
> -rw-r--r-- 1 root root 181K elo 18 2020 memtest86+_multiboot.bin
> -rw------- 1 root root 5,7M kesä 17 01:38 System.map-5.11.0-22-generic
> -rw------- 1 root root 5,7M heinä 9 20:42 System.map-5.11.0-25-generic
> lrwxrwxrwx 1 root root 25 heinä 23 06:04 vmlinuz ->
> vmlinuz-5.11.0-25-generic
> -rw------- 1 root root 15M kesä 17 01:55 vmlinuz-5.11.0-22-generic
> -rw------- 1 root root 15M heinä 9 21:04 vmlinuz-5.11.0-25-generic
> lrwxrwxrwx 1 root root 25 heinä 23 06:04 vmlinuz.old ->
> vmlinuz-5.11.0-22-generic

Which kernel are you currently running?

If you're running 5.11.0-22-generic, then things are trickier. I don't
have any immediate suggestions for that circumstance.

If you're running 5.11.0-25-generic, then I think I see a possible way
out of this for a one-off instance, although it involves doing some
things by hand.

At that point, it should be safe to remove the -22-generic kernel, it's
just that the automatic tools for doing so want to do something else
first which is failing.

What I might try doing in that circumstance is to identify the largest
file in that directory which would be removed as part of the removal of
the -22-generic kernel (in this case, initrd.img-5.11.0-22-generic),
move it to another filesystem, create a symlink to it from its original
location, try the removal again, and - assuming it succeeds -
(eventually) delete the moved file from its new location.

Of course, depending on exactly how much checking of what the files it's
processing at removal time dpkg actually does, that might just make the
removal fail another way. In which case things would have to get
trickier again.

And do note that I am *not* certain that this would actually work
correctly, and there's a minor chance that it could break things. Please
don't proceed on anything involving manually manipulating the contents
of /boot without having a recovery-boot medium (e.g., live-boot USB
drive) available as a fallback!

(None of this resolves the underlying problem: the filesystem in
question is too small for today's boot-configuration requirements. Given
the constraint on enlarging it which you noted in your original inquiry,
however, I don't have any suggestions at all on that front.)

--
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

signature.asc

Paul Duncan

unread,

Aug 1, 2021, 7:00:05 AM8/1/21

to

Hmmm... Thats a little annoying.

Maybe try removing the -22 image manually, like this:

apt-get remove linux-image-5.11.0-22

See if that works. If it doesn't, I'm not sure what else to try - other than a re-install - at which I would make /boot a little bigger :-)

I'm sure others more knowledgeable than me will chime in with ideas too.

Best Regards,

Paul.

didier gaumet

unread,

Aug 1, 2021, 9:00:05 AM8/1/21

to

Hello,

Disclaimer: I have never tested what is following.

Perhaps another way of keeping two kernels without increasing the size oft the /boot partition would be to decrease the size of the initrd files: by default they are built with allmost all possible modules, but they can be built with only the modules that are needed (for the hardware which is automatically detected). That is, if Ubuntu acts as Debian in this regard (Debian here)

As root or via sudo:
1) edit the /etc/initramfs-tools/initramfs.conf file to replace the MODULES=most line by a MODULES=dep one
2) to make room in /boot for the following step, delete the big initrd images:
# rm /boot/initrd*
3) generate smaller initrd images
# update-initramfs -c -k all

Next time there is a kernel update, the initrd will automatically be generated with a smaller size (but you will perhaps have to make room for it if you have not enough space for three kernels)

songbird

unread,

Aug 1, 2021, 9:40:05 AM8/1/21

to

Paul Duncan wrote:
...

> Hmmm... Thats a little annoying.
>
> Maybe try removing the -22 image manually, like this:
>
> apt-get remove linux-image-5.11.0-22

if that is the kernel that is being run then you risk
putting your system into a completely unbootable state (if
the upgrade failed that means the new kernel is not yet
installed).

> See if that works. If it doesn't, I'm not sure what else to try - other
> than a re-install - at which I would make /boot a little bigger :-)
>
> I'm sure others more knowledgeable than me will chime in with ideas too.

...

as it is an Ubuntu system i don't have any certain ideas
adding the complexity of it being encrypted makes it worse
as i don't have any experience with those either.

if you continue with what i've written below you are in
what i considered uncharted territory. use at your own
risk. with backups and recovery plan that is known to
work.

i know what i would do on my system:

1. make sure i have a backup of /boot and /
2. make sure i have a working boot medium with the tools i
would need to fix things if /boot or / are broken
3. make sure i'm running the previous kernel (uname -a )
4. remove the attempted broken upgrade from /boot
5. pin the kernel version at the one that is completely installed
6. reboot to make sure that all worked and i have a bootable
system and am running the right kernel version
7. merge /boot and / keeping only /boot/efi on it's own partition
- set up a temp dir on /
- copy /boot/* to it
- remove efi from that and make sure it is still on /boot/efi
- change /etc/fstab to reflect these changes
- unmount /boot and then rename the temp dir on / as /boot
- reboot to make sure i've not broken something

8. if that comes up then you should have a way forward by
unpinning kernel and attempting upgrade again

songbird

Darac Marjal

unread,

Aug 1, 2021, 10:40:04 AM8/1/21

to

Another avenue to try is changing the compression used. I see the OP
uses lz4 compression, XZ and Zstd compression often give better results
but this is definitely a "Your Mileage May Vary" situation. As with the
"MODULES" option above, you can configure the compression with the
"COMPRESS" option.

>

OpenPGP_signature

Gene Heskett

unread,

Aug 1, 2021, 11:00:04 AM8/1/21

to

I can offer some long term experience, applicable in this case only if
you can re-install.

1. SSD's and u-sd's have, generally speaking, more aggressive
housekeeping than spinning rust.

2. If they have room to work, they can be far more dependable than
spinning rust, but that is a BIG IF.

3. I rum a farm here with each machine running a CNC machine, a milling
machine or lathe for carving metal. And I've been doing it since K6-II
days for cpu's.

4. Because the kernels need to be special built for real time response
while moving multi-horsepower, potentially dangerous machines, they may
be built in-house or supplied by the LinuxCNC folks, in any event they
are generally pinned such that the package manager doesn't just upgrade
them unless it has a darned good reason.

5. example, a raspberry pi 4 with 2gigs of ram, I use a 64GB u-sd to boot
from. One of my wintel boxes also has a 64GB SSD as its only storage. In
the wintel case, it can boot from an ext4 drive, and the whole system is
about 7GB, and it has 28GB to play in. Only 2 partitions as I always
make a separate /home, so / and /home are it. But its a 4G of dram, so
it has a 4G swap, that's on the 64G SSD. And its been running that way
since a 64G SSD was the biggest thing available.

The pi is built different and can boot only from a vfat file system, so
its /boot is a partition of 256 megabytes on a 64G u-sd. But dpkg
doesn't have a way to make an installable kernel deb. So I made a
tarball out of what it needed, that can be unpacked to the u-sd, mounted
as vfat in another wintel machine, that simply overwrites whatever is
there or creates it new, and the uncompressed tarball is only 30 megs.
Nothing new has been written to that partition of that u-sd in about 5
years. The remaining space, about 61Gigs, is the rest of the linux
install, currently 25% occupied. Swap has been moved to a 120G SSD, and
a backup of /boot is also on that SSD, plugged into a usb3 adapter.

And a 2nd SSD, 256G is on the other usb3 port. Why? because I am running
a buildbot to build LinuxCNC deb packages everytime there is a commit to
github, master branch, playing the canary in a coal mine for LinuxCNC on
the armhf platform. Almost grotesque, a 2 oz pi running a 1500 lb lathe.
The only write traffic to the u-sd is the output of those deb's.

So If you wind up reinstalling, make /boot a minimum of 2G so you do not
hit this situation in the lifetime of the hardware ever again, make 2x
you memory as swap, and split the rest into / and /home. It just works
for me, your storage will have room to keep itself clean and functional.
But YMMV. :) The lesson here is that the cost is coming ever down,
scrimping on storage isn't the best use of ones available sheckels.

Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>

Stefan Monnier

unread,

Aug 1, 2021, 11:40:05 AM8/1/21

to

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

David Christensen

unread,

Aug 1, 2021, 3:50:04 PM8/1/21

to

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

Hans

unread,

Aug 1, 2021, 4:30:05 PM8/1/21

to

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.

signature.asc

Andy Smith

unread,

Aug 1, 2021, 6:40:04 PM8/1/21

to

Hello,

OP: You are pretty safe deleting (rm) vmlinuz* and initrd* things
from /boot that are related to any kernels you aren't actually
booted into at the time. That can give you back enough space to let
apt finish what it wants to do. Just remember to do:

# update-initramfs -u -k all

afterwards to regenerate the initrd for any installed kernel that
you do want to boot into next time.

I would suggest not deleting the initrd* for the current kernel
because if you find yourself unable to regenerate it for any reason
then you have a system that can't be rebooted. If you leave the
current kernel's files alone then at least you know you have a
known-good setup.

On Sun, Aug 01, 2021 at 10:51:59AM -0400, Gene Heskett wrote:
> So If you wind up reinstalling, make /boot a minimum of 2G so you do not
> hit this situation in the lifetime of the hardware ever again, make 2x
> you memory as swap, and split the rest into / and /home. It just works
> for me, your storage will have room to keep itself clean and functional.
> But YMMV. :)

There is very little advantage these days to separating out /boot
and /home etc on such devices. You are far better off just putting
it all in / and making sure you have backups a quick way to re-image
the thing.

If you absolutely must do it, I advise making a fairly small / (5G
or so counts as small these days) that has /boot in it (not separate
fs) and then do your other splits with a volume manager like LVM,
btrfs or ZFS.

Splitting things into multiple filesystems fundamentally invites
problems such as the one encountered in this thread - you guess
wrong and make something too small. Nobody is perfect or omniscient
so this happens quite often. Meanwhile a lot of the reasons for
splitting things up have been obsoleted back in the mists of time.
Just strongly consider not doing it any more and see if your life
improves.

At this point there will probably be some people who consider
themselves veterans saying that one must absolutely split things off
because of various reasons like differing mount options being
desirable, ability to re-use contents of /home after reinstall,
having multiple devices and wanting to suit filesystem contents to
drive characteristics, … or whatever. Most of that will not apply to
any given person, and if it does then I believe it's better done
with volume management.

So really think hard before splitting off a filesystem outside of
volume management. I believe it is more likely to cause problems
than it is to avoid problems.

I think I've heard all the arguments for doing it and I also agree
with some of them in some situations - but since the '90s we've had
volume management to help with this. If someone has come up with
some obscure reason why they must split their storage into multiple
mount points with no volume management then I don't need to hear
about it - I'm happy to believe them that it may be necessary for
their specific circumstances while also not agreeing that it's a
good idea in the general case!

Gene's recommendation is to not spare the drive capacity and be
generous, but then Gene recommends doing something that severely
restricts drive capacity: making hard-to-change decisions about
carving it up. I agree with Gene's suggestion to be generous with
capacity, and I suggest that is achieved by just giving it all to /
unless you have very very good reason not to (and then use volume
management if you must).

Cheers,
Andy

David

unread,

Aug 1, 2021, 7:00:05 PM8/1/21

to

On Mon, 2 Aug 2021 at 08:33, Andy Smith <an...@strugglers.net> wrote:

> At this point there will probably be some people who consider
> themselves veterans saying that one must absolutely split things off
> because of various reasons like differing mount options being
> desirable, ability to re-use contents of /home after reinstall,
> having multiple devices and wanting to suit filesystem contents to
> drive characteristics, … or whatever. Most of that will not apply to
> any given person, and if it does then I believe it's better done
> with volume management.

In addition to the good advice given, one use case not mentioned is
that Debian installer for current stable creates a separate unencrypted
/boot partition if the rest of the disk is encrypted.

My understanding is that this is due to Grub2 not supporting LUKS2,
which is the Debian default, even though it seems that Grub2 can
support LUKS1.

I haven't been following if that will change for the upcoming Bullseye
release, but if not then I expect separate /boot will be around for some time.
And people really should consider disk encryption, especially their
portable devices.

Greg Wooledge

unread,

Aug 1, 2021, 7:00:05 PM8/1/21

to

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.

Stefan Monnier

unread,

Aug 2, 2021, 12:40:05 AM8/2/21

to

> So really think hard before splitting off a filesystem outside of
> volume management. I believe it is more likely to cause problems
> than it is to avoid problems.

All my machines have a separate /boot partition (and everything
else in LVM). These are all "historical accidents", because at the time
I set them up, the respective boot loader (LILO, Grub, U-Boot) didn't
know how to read LVM volumes, and I just never bothered to change.

But I fully agree with you: if your bootloader can read from LVM
(as is the case with Grub2), then you're better off without a separate
/boot partition.

Stefan "not sure if U-Boot can read from LVM yet"

Teemu Likonen

unread,

Aug 2, 2021, 1:10:05 AM8/2/21

to

* 2021-08-01 16:00:24-0400, Greg Wooledge wrote:

> 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*.

Initrd image is large when the pairing kernel is compiled with debugging
symbols. I can't tell if this is the case with the original poster.

Large unneeded files can be deleted with "rm". It's rough but pretty
much the only option if the package manager can't work anymore on a full
partition. I would use "rm" to delete the oldest not running kernel and
initrd file and update the kernel with package manager. Then I would
delete the old kernel and related packages with the package manager.

--
/// Teemu Likonen - .-.. https://www.iki.fi/tlikonen/
// OpenPGP: 4E1055DC84E9DFF613D78557719D69D324539450

signature.asc

Felix Miata

unread,

Aug 2, 2021, 1:30:05 AM8/2/21

to

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

Greg Wooledge

unread,

Aug 2, 2021, 7:30:05 AM8/2/21

to

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.