Re: Re: Updating kernels impossible when /boot is getting full
> Large unneeded files can be deleted with "rm". This is what I ended up doing. The version 25 was in currently use and I rm'ed all the old version files. That worked, but I needed to do the same when version 31 appeared. Fortunately the new version will get into use so rm will work. Maybe apt-get upgrade could use some magic to get around the space limitation issue. Or maybe something else could be done. At install time it would be good to suggest some good size for the boot partition. I did search a bit but ended up creating a too small partition, maybe the info was too old. Thanks all! Ilkka
Re: Updating kernels impossible when /boot is getting full
On Sun 01 Aug 2021 at 21:55:15 (+0200), Kamil Jońca wrote: > David Christensen writes: > > [...] > > > > A 500 GB boot partition would be enough for several kernels, etc., on > > Debian 10 amd64. > > OP wrote about 500 _M_ bytes (0.5G), and I can confirm, this is rather > little, when trying updating kernels. Ah, good—you're a regular here, and more likely to respond. Some of us are perplexed as to why 500MB is rather little, or IOW, why are some initrd.img files so huge. The OP's are bigger than 150MB, and their lsinitramfs listing could make interesting here, but seems unlikely to be posted. Could you elaborate on your experience? Cheers, David.
Re: Updating kernels impossible when /boot is getting full
On 8/1/21 12:55 PM, Kamil Jońca wrote: David Christensen writes: [...] A 500 GB boot partition would be enough for several kernels, etc., on Debian 10 amd64. OP wrote about 500 _M_ bytes (0.5G), Please see: > On 8/1/21 3:29 PM, David Christensen wrote: >> I see a typo in my post -- that should be 500 MB. and I can confirm, this is rather little, when trying updating kernels. We need the OP to run lsinitrd.sh and/or lsinitramfs on their computer and post the (compressed) output to see why the initrd.img files are ~150 MB on their (Ubuntu) computer. David
Re: Updating kernels impossible when /boot is getting full
David Christensen writes: [...] > > A 500 GB boot partition would be enough for several kernels, etc., on > Debian 10 amd64. OP wrote about 500 _M_ bytes (0.5G), and I can confirm, this is rather little, when trying updating kernels. KJ -- http://stopstopnop.pl/stop_stopnop.pl_o_nas.html
Re: Updating kernels impossible when /boot is getting full
Sorry, Stefan. This was supposed to go to the list. On 8/2/21 11:02 PM, Marc Shapiro wrote: On 8/1/21 9:33 PM, Stefan Monnier wrote: 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" I am primarily running Devuan, these days, but I also still have root/boot partitions (boot is not separate from root) for Stretch and Buster. My /boot directory contains 4 kernels and their associated files and the whole lot only takes up about 140MB. Since I use Lilo as my boot loader (and it can read LVM), and I don't use encryption, I can put everything (including root/boot) into a single LVM physical volume. No hassles if I need to resize any partition, since they are all logical volumes in a single volume group on a single physical volume. If I ever need more total space, which I find unlikely, I can add additional disks to the PV and then add space to any LVs as needed. Marc
Re: Updating kernels impossible when /boot is getting full
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 root0 Apr 25 08:00 kernel drwxr-xr-x 2 root root0 Apr 25 08:00 kernel/x86 drwxr-xr-x 2 root root0 Apr 25 08:00 kernel/x86/microcode drwxr-xr-x 2 root root0 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 root0 Aug 2 14:37 . lrwxrwxrwx 1 root root7 Aug 2 14:37 bin -> usr/bin drwxr-xr-x 3 root root0 Aug 2 14:37 conf -rw-r--r-- 1 root root 16 Aug 2 14:37 conf/arch.conf drwxr-xr-x 2 root root0 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
Re: Updating kernels impossible when /boot is getting full
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 root0 Apr 25 08:00 kernel drwxr-xr-x 2 root root0 Apr 25 08:00 kernel/x86 drwxr-xr-x 2 root root0 Apr 25 08:00 kernel/x86/microcode drwxr-xr-x 2 root root0 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 root0 Aug 2 14:37 . lrwxrwxrwx 1 root root7 Aug 2 14:37 bin -> usr/bin drwxr-xr-x 3 root root0 Aug 2 14:37 conf -rw-r--r-- 1 root root 16 Aug 2 14:37 conf/arch.conf drwxr-xr-x 2 root root0 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.
Re: Updating kernels impossible when /boot is getting full
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 initrd.img-4.19.0-17-amd64.txt.gz Description: application/gzip
Re: Updating kernels impossible when /boot is getting full
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.
Re: Updating kernels impossible when /boot is getting full
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
Re: Updating kernels impossible when /boot is getting full
On Mon 02 Aug 2021 at 08:04:25 (+0300), Teemu Likonen wrote: > * 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. I always thought they were in the System.map file, which is sizeable but not excessive as far as 500MB is concerned. > 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. That seems like a dangerous strategy here. We've had two upgrades of the kernel recently where the version number hasn't changed. So you'd be overwriting your sole kernel with the upgrade, and totally reliant on that process working perfectly. Cheers, David.
Re: Updating kernels impossible when /boot is getting full
On Sun 01 Aug 2021 at 13:21:11 (+0300), Ilkka Huotari wrote: > 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" If Ubuntu is parallelling Debian, I'd be very wary. Would it be true to say that: . You've got two kernels installed, 22 and 25, and 25 is running. . You're trying to upgrade to a new version of 25, so the new version is overwriting the old one. This is exactly why you need 22 as a backup, in case the new version of 25 doesn't work, for whatever reason. So I would not remove it unless you take action to be able to boot up with it from another location. Whatever you do now involves risk, so it's just a matter of choosing the risk you can most easily cope with. BTW, and AIUI, apt/dpkg doesn't like installing/removing packages when the system is "broken", so it will try to finish configuring that failed one first. This may explain your "bug". I have no idea whether any of these alternatives would work: . Copy initrd.img-5.11.0-25-generic somewhere safe and external, then delete it. Now reinstall 25, and the system should have room to rebuild the initrd.img. If it¹ doesn't work, restore the copy, and you've lost nothing. . Reboot the system with 22. Now you can be more brutal with removing 25's files in /boot, in order to either reinstall it, or remove and then install it. . Copy the four *-5.11.0-22-generic files somewhere safe and external, then delete them. Now reinstall 25, and the system should have room to rebuild the initrd.img. If it¹ doesn't work, restore the copies, and you've lost nothing. In addition to any of these, I would consider copying all the four files for each installed kernel onto a safe, external device, and adding a custom entry to /boot/grub/grub.cfg by means of /etc/grub.d/40_custom, copying the first menuentry, but mangling it so that it can find the external device, and load the kernel-… and initrd.img-… from there. (NB I've no idea how ubuntu differs from debian.) ¹ "it" means the process just described. I don't mean "reboot the system and see if it works". Check everything is correctly back in place before rebooting. Cheers, David.
Re: Updating kernels impossible when /boot is getting full
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. OpenPGP_signature Description: OpenPGP digital signature
Re: Updating kernels impossible when /boot is getting full
> 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"
Re: Updating kernels impossible when /boot is getting full
* 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 Description: PGP signature
Re: Updating kernels impossible when /boot is getting full
On Mon, 2 Aug 2021 at 08:33, Andy Smith 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.
Re: Updating kernels impossible when /boot is getting full
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.
Re: Updating kernels impossible when /boot is getting full
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
Re: Updating kernels impossible when /boot is getting full
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 root7 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 root7 Aug 1 14:12 lib -> usr/lib
lrwxrwxrwx 1 root root9 Aug 1 14:12 lib32 -> usr/lib32
lrwxrwxrwx 1 root root9 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 root8 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 >
Re: Updating kernels impossible when /boot is getting full
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 Description: This is a digitally signed message part.
Re: Updating kernels impossible when /boot is getting full
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. initrd.img-5.10.0-8-amd64.txt.gz Description: application/gzip
Re: Updating kernels impossible when /boot is getting full
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
Re: Updating kernels impossible when /boot is getting full
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
Re: Updating kernels impossible when /boot is getting full
On Sunday 01 August 2021 06:57:54 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 > > 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. > > On Sun, 1 Aug 2021 at 10:39, 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? > > > > 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 elo18 2020 memtest86+.bin > > -rw-r--r-- 1 root root 181K elo18 2020 memtest86+.elf > > -rw-r--r-- 1 root root 181K elo18 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 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
Re: Updating kernels impossible when /boot is getting full
On 01/08/2021 13:34, didier gaumet wrote: > 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) 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 Description: OpenPGP digital signature
Re: Updating kernels impossible when /boot is getting full
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
Re: Re: Updating kernels impossible when /boot is getting full
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)
Re: Re: Updating kernels impossible when /boot is getting full
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. On Sun, 1 Aug 2021 at 10:39, 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? > > 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 elo18 2020 memtest86+.bin > -rw-r--r-- 1 root root 181K elo18 2020 memtest86+.elf > -rw-r--r-- 1 root root 181K elo18 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 > -- *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.*
Re: Updating kernels impossible when /boot is getting full
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 elo18 2020 memtest86+.bin > -rw-r--r-- 1 root root 181K elo18 2020 memtest86+.elf > -rw-r--r-- 1 root root 181K elo18 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 Description: OpenPGP digital signature
Re: Re: Updating kernels impossible when /boot is getting full
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 elo18 2020 memtest86+.bin -rw-r--r-- 1 root root 181K elo18 2020 memtest86+.elf -rw-r--r-- 1 root root 181K elo18 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
Re: Updating kernels impossible when /boot is getting full
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 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.*
Updating kernels impossible when /boot is getting full
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
