You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Updating Debian package does not remove /boot/initrd.img #3
When updating the Debian package (both 4.19-lts and 5.6), the file initrd.img-xxx from the old package stays behind. I just found 5 of those outdated files.
Is there a chance to include the removal in the Debian packages?
I cannot reproduce this in a LXC container running Ubuntu 19.10. The postrm script of the package calls the hooks in /etc/kernel/postrm.d with, as far as I can tell, the correct version, which should then take care of updating/removing the initrd, at least on Ubuntu and Debian.
The "problem" was, that after an kernel update from - let's say 5.6.14 to 5.6.15 - there were these files in /boot (I hope I reconstructed it correctly):
This seems to be a problem with the /etc/kernel/postrm.d/initramfs-tools script, updating the initramfs after package removal/upgrade. This contains
if [ -z"$1" ] || [ "$1"!="remove" ];thenexit 0
fi
which returns if the package is not removed, e.g. is upgraded. it seems that Debian/Ubuntu expect all kernel packages to be specifically named with their version in the name. That way the package does not really get upgraded, but removed and a completely new package (with different name) gets installed.
There's nothing we can do to change the /etc/kernel/postrm.d/initramfs-tools script, since that's not part of the kernel package. To replicate the behavior of original Debian/Ubuntu packages, we'd have to switch to meta-packages (#2).
Would it be possible to remove the stale initrd.img-xxx file with the help of package maintainer scripts? A lot of time has passed since I was responsible for a Debian package, that I can't remember all the details...
Possible yes, although that would bypass the initrd tools and I'm not sure if that is a good idea. I think that a better quick-fix would probably be modifying https://github.com/torvalds/linux/blob/b3a9e3b9622ae10064826dccb4f7a52bd88c7407/scripts/package/builddeb#L193 for postrm by replacing upgrade with remove (first parameter to the script). The best solution would be to switch to meta-packages, but doing that will cost more time.
Over the course of the past few months, the problem has grown to affect me more seriously. I now have 11 of them in /boot and there is not a single byte of disk space left. This caused APT to fail with the following error today:
Processing triggers for initramfs-tools (0.136ubuntu6.2) ...
update-initramfs: Generating /boot/initrd.img-5.7.6-surface
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.7.6-surface with 1.
dpkg: error processing package initramfs-tools (--configure):
installed initramfs-tools package post-installation script subprocess returned error exit status 1
Processing triggers for libc-bin (2.31-0ubuntu9) ...
Errors were encountered while processing:
linux-firmware
initramfs-tools
E: Sub-process /usr/bin/dpkg returned an error code (1)
While I am aware of this bug and that I need to apply the workaround of deleting those files, others might not be. They might be confused and wonder why initramfs-tools suddenly started failing.
@danielzgtg Okay, so I'm trying to figure out how Debian/Ubuntu implement the kernel metapackages. Specifically how they remove old kernels (they do that, right?). If they do that, any idea how?
Old kernels are removed by being "no longer required." They are removed with apt autoremove. That forms part of the apt update && apt upgrade && apt dist-upgrade && apt autoremove --purge I do.
The latest kernel is always depended upon by the metapackage. The second latest kernel is not depended on, but somehow isn't marked "no longer required." Earlier kernels are always marked as "no longer required." The command that updates the metapackage does not remove the old kernel; that is done manually in a separate command.
Thanks! That does clear things up for me. I just wanted to be certain that there isn't any "magic" behavior just for kernel packages that removes old ones on apt upgrade automatically. So it should be enough to just specify a dependency.
@danielzgtg Can you test if upgrading to the latest version works without any problems?
Edit: Just noticed I screwed up the LTS release. Can you try updating the non-LTS release? That should work.
Edit 2: The LTS release should now also work.
Can you test if upgrading to the latest version works without any problems?
The update went well
root@daniel-tablet1:~# apt upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
The following NEW packages will be installed:
linux-headers-5.7.7-surface linux-image-5.7.7-surface
The following packages will be upgraded:
linux-headers-surface linux-image-surface surface-control
3 upgraded, 2 newly installed, 0 to remove and 0 not upgraded.
Need to get 70.7 MB of archives.
After this operation, 28.8 MB disk space will be freed.
Do you want to continue? [Y/n] y
Get:1 https://pkg.surfacelinux.com/debian release/main amd64 linux-headers-5.7.7-surface amd64 5.7.7-surface-2 [7,788 kB]
Get:2 https://pkg.surfacelinux.com/debian release/main amd64 linux-headers-surface amd64 5.7.7-surface-2 [2,458 B]
Get:3 https://pkg.surfacelinux.com/debian release/main amd64 linux-image-5.7.7-surface amd64 5.7.7-surface-2 [62.6 MB]
Get:4 https://pkg.surfacelinux.com/debian release/main amd64 linux-image-surface amd64 5.7.7-surface-2 [2,454 B]
Get:5 https://pkg.surfacelinux.com/debian release/main amd64 surface-control amd64 0.2.6-1 [259 kB]
Fetched 70.7 MB in 13s (5,266 kB/s)
Selecting previously unselected package linux-headers-5.7.7-surface.
(Reading database ... 313679 files and directories currently installed.)
Preparing to unpack .../linux-headers-5.7.7-surface_5.7.7-surface-2_amd64.deb ...
Unpacking linux-headers-5.7.7-surface (5.7.7-surface-2) ...
dpkg: error processing archive /var/cache/apt/archives/linux-headers-5.7.7-surface_5.7.7-surface-2_amd64.deb (--unpack):
trying to overwrite '/lib/modules/5.7.7-surface/build', which is also in package linux-headers-surface 5.7.7-1
Preparing to unpack .../linux-headers-surface_5.7.7-surface-2_amd64.deb ...
Unpacking linux-headers-surface (5.7.7-surface-2) over (5.7.7-1) ...
Selecting previously unselected package linux-image-5.7.7-surface.
Preparing to unpack .../linux-image-5.7.7-surface_5.7.7-surface-2_amd64.deb ...
Unpacking linux-image-5.7.7-surface (5.7.7-surface-2) ...
dpkg: error processing archive /var/cache/apt/archives/linux-image-5.7.7-surface_5.7.7-surface-2_amd64.deb (--unpack):
trying to overwrite '/boot/System.map-5.7.7-surface', which is also in package linux-image-surface 5.7.7-1
dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
Preparing to unpack .../linux-image-surface_5.7.7-surface-2_amd64.deb ...
Unpacking linux-image-surface (5.7.7-surface-2) over (5.7.7-1) ...
Preparing to unpack .../surface-control_0.2.6-1_amd64.deb ...
Unpacking surface-control (0.2.6-1) over (0.2.5-3) ...
Errors were encountered while processing:
/var/cache/apt/archives/linux-headers-5.7.7-surface_5.7.7-surface-2_amd64.deb
/var/cache/apt/archives/linux-image-5.7.7-surface_5.7.7-surface-2_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)
root@daniel-tablet1:~# apt install -f
Reading package lists... Done
Building dependency tree
Reading state information... Done
Correcting dependencies... Done
The following additional packages will be installed:
linux-headers-5.7.7-surface linux-image-5.7.7-surface
The following NEW packages will be installed:
linux-headers-5.7.7-surface linux-image-5.7.7-surface
0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded.
3 not fully installed or removed.
Need to get 70.4 MB of archives.
After this operation, 330 MB of additional disk space will be used.
Do you want to continue? [Y/n] y
Get:1 https://pkg.surfacelinux.com/debian release/main amd64 linux-headers-5.7.7-surface amd64 5.7.7-surface-2 [7,788 kB]
Get:2 https://pkg.surfacelinux.com/debian release/main amd64 linux-image-5.7.7-surface amd64 5.7.7-surface-2 [62.6 MB]
Fetched 70.4 MB in 20s (3,526 kB/s)
(Reading database ... 277865 files and directories currently installed.)
Preparing to unpack .../linux-headers-5.7.7-surface_5.7.7-surface-2_amd64.deb ...
Unpacking linux-headers-5.7.7-surface (5.7.7-surface-2) ...
Preparing to unpack .../linux-image-5.7.7-surface_5.7.7-surface-2_amd64.deb ...
Unpacking linux-image-5.7.7-surface (5.7.7-surface-2) ...
Setting up surface-control (0.2.6-1) ...
Setting up linux-headers-5.7.7-surface (5.7.7-surface-2) ...
Setting up linux-image-5.7.7-surface (5.7.7-surface-2) ...
* dkms: running auto installation service for kernel 5.7.7-surface [ OK ]
update-initramfs: Generating /boot/initrd.img-5.7.7-surface
Sourcing file `/etc/default/grub'
Sourcing file `/etc/default/grub.d/init-select.cfg'
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-5.7.7-surface
Found initrd image: /boot/initrd.img-5.7.7-surface
Found Windows Boot Manager on /dev/nvme0n1p1@/EFI/Microsoft/Boot/bootmgfw.efi
Adding boot menu entry for UEFI Firmware Settings
done
Setting up linux-headers-surface (5.7.7-surface-2) ...
Setting up linux-image-surface (5.7.7-surface-2) ...
root@daniel-tablet1:~#
Boots fine. initrd.img-5.7.6-surface is still left in /boot/, but it should be the last one that needs to be removed manually. Once 5.7.8/5.8 comes out, the removal of initrd.img-5.7.7-surface can be tested.
I also encountered the thing with:
I managed to recover from this error with [...]
When the software updater window appears it prompts to remove old kernels
I don't use the GUI :)
one-off for this upgrade only
This could be avoided even for the first time with a Conflicts line.
This could be avoided even for the first time with a Conflicts line.
Ah thanks! I'll keep that in mind for the next time. On the other hand, the failure gets users to (hopefully) look at the announcements and makes them aware of the outdated initrd files, so I think it might not be that bad of a thing.
I also encountered the thing with:
I managed to recover from this error with [...]
Thanks! I've updated the announcement and added the apt-get --fix-broken install command.
I think that could be it. In that case it should already work (since the initramfs-tools stuff works). Guess the only way to know for sure is to check the behavior over the next couple of releases.
It somewhat looks like there are still remnants of old kernels around. As I don't use Ubuntu, I have no clue where, or what would cause the initrds to be rebuilt.
I guess as long as apt autoremove removes them (except for maybe the latest N versions), it works as intended. Let me know if apt autoremove doesn't work.
Activity
qzed commentedon Jun 14, 2020
Can you post the entries in the boot directory (i.e. run
ls -al /boot)?sphh commentedon Jun 14, 2020
I already deleted the files by hand to save some space in the
/bootpartition, but here it is anyway:I can get a new list after the next round of surface kernel updates.
qzed commentedon Jun 14, 2020
I cannot reproduce this in a LXC container running Ubuntu 19.10. The
postrmscript of the package calls the hooks in/etc/kernel/postrm.dwith, as far as I can tell, the correct version, which should then take care of updating/removing the initrd, at least on Ubuntu and Debian.Which distribution are you running, specifically?
qzed commentedon Jun 14, 2020
initrd.img-5.6.15-surfaceis exactly the same name I see in my container so it doesn't seem to be any difference there.sphh commentedon Jun 14, 2020
I run Linux Mint 19.3 Cinnamon.
The "problem" was, that after an kernel update from - let's say 5.6.14 to 5.6.15 - there were these files in
/boot(I hope I reconstructed it correctly):qzed commentedon Jun 14, 2020
This seems to be a problem with the
/etc/kernel/postrm.d/initramfs-toolsscript, updating the initramfs after package removal/upgrade. This containswhich returns if the package is not removed, e.g. is upgraded. it seems that Debian/Ubuntu expect all kernel packages to be specifically named with their version in the name. That way the package does not really get upgraded, but removed and a completely new package (with different name) gets installed.
There's nothing we can do to change the
/etc/kernel/postrm.d/initramfs-toolsscript, since that's not part of the kernel package. To replicate the behavior of original Debian/Ubuntu packages, we'd have to switch to meta-packages (#2).sphh commentedon Jun 14, 2020
Would it be possible to remove the stale
initrd.img-xxxfile with the help of package maintainer scripts? A lot of time has passed since I was responsible for a Debian package, that I can't remember all the details...qzed commentedon Jun 14, 2020
Possible yes, although that would bypass the initrd tools and I'm not sure if that is a good idea. I think that a better quick-fix would probably be modifying https://github.com/torvalds/linux/blob/b3a9e3b9622ae10064826dccb4f7a52bd88c7407/scripts/package/builddeb#L193 for postrm by replacing
upgradewithremove(first parameter to the script). The best solution would be to switch to meta-packages, but doing that will cost more time.danielzgtg commentedon Jun 15, 2020
Here is my output, where I didn't delete any files:
danielzgtg commentedon Jul 2, 2020
Over the course of the past few months, the problem has grown to affect me more seriously. I now have 11 of them in
/bootand there is not a single byte of disk space left. This caused APT to fail with the following error today:While I am aware of this bug and that I need to apply the workaround of deleting those files, others might not be. They might be confused and wonder why initramfs-tools suddenly started failing.
qzed commentedon Jul 2, 2020
I'll try to have a go at it this weekend.
qzed commentedon Jul 3, 2020
@danielzgtg Okay, so I'm trying to figure out how Debian/Ubuntu implement the kernel metapackages. Specifically how they remove old kernels (they do that, right?). If they do that, any idea how?
danielzgtg commentedon Jul 4, 2020
Old kernels are removed by being "no longer required." They are removed with
apt autoremove. That forms part of theapt update && apt upgrade && apt dist-upgrade && apt autoremove --purgeI do.The latest kernel is always depended upon by the metapackage. The second latest kernel is not depended on, but somehow isn't marked "no longer required." Earlier kernels are always marked as "no longer required." The command that updates the metapackage does not remove the old kernel; that is done manually in a separate command.
qzed commentedon Jul 4, 2020
Thanks! That does clear things up for me. I just wanted to be certain that there isn't any "magic" behavior just for kernel packages that removes old ones on
apt upgradeautomatically. So it should be enough to just specify a dependency.qzed commentedon Jul 5, 2020
@danielzgtg Can you test if upgrading to the latest version works without any problems?
Edit: Just noticed I screwed up the LTS release. Can you try updating the non-LTS release? That should work.
Edit 2: The LTS release should now also work.
5 remaining items
danielzgtg commentedon Jul 6, 2020
The update went well
Boots fine.
initrd.img-5.7.6-surfaceis still left in/boot/, but it should be the last one that needs to be removed manually. Once 5.7.8/5.8 comes out, the removal ofinitrd.img-5.7.7-surfacecan be tested.I also encountered the thing with:
I don't use the GUI :)
This could be avoided even for the first time with a
Conflictsline.qzed commentedon Jul 6, 2020
Neat!
Ah thanks! I'll keep that in mind for the next time. On the other hand, the failure gets users to (hopefully) look at the announcements and makes them aware of the outdated initrd files, so I think it might not be that bad of a thing.
Thanks! I've updated the announcement and added the
apt-get --fix-broken installcommand.qzed commentedon Jul 6, 2020
I think that could be it. In that case it should already work (since the initramfs-tools stuff works). Guess the only way to know for sure is to check the behavior over the next couple of releases.
qzed commentedon Jul 10, 2020
It somewhat looks like there are still remnants of old kernels around. As I don't use Ubuntu, I have no clue where, or what would cause the initrds to be rebuilt.
qzed commentedon Jul 16, 2020
Neat! Closing this as it seems to be resolved. Feel free to comment/re-open if there are still issues remaining.
danielzgtg commentedon Jul 22, 2020
It worked today and automatically removed the third last kernel. It also magically preserved the second last kernel.
qzed commentedon Aug 18, 2020
I guess as long as
apt autoremoveremoves them (except for maybe the latest N versions), it works as intended. Let me know ifapt autoremovedoesn't work.