-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Updating Debian package does not remove /boot/initrd.img #3
Comments
Can you post the entries in the boot directory (i.e. run |
I already deleted the files by hand to save some space in the
I can get a new list after the next round of surface kernel updates. |
I cannot reproduce this in a LXC container running Ubuntu 19.10. The Which distribution are you running, specifically? |
|
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
|
This seems to be a problem with the if [ -z "$1" ] || [ "$1" != "remove" ]; then
exit 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 |
Would it be possible to remove the stale |
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 |
Here is my output, where I didn't delete any files:
|
Over the course of the past few months, the problem has grown to affect me more seriously. I now have 11 of them in
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. |
I'll try to have a go at it this weekend. |
@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 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 |
@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. |
@qzed, thanks for looking into this and making meta-packages! Today I wanted to install the newly available packages, but I get the following errors. I don't know if this is because of this metapackage thing...
I have both the |
Yeah, that's caused by the change, thanks for the feedback! This means that to upgrade the packages, you'll have to manually uninstall linux-surface and linux-surace-lts and then re-install them. Basically, what happens is (as far as I can see it): The |
I managed to recover from this error with:
|
In Ubuntu, running autoremove or purging is not necessary as of the last four or more months. When the software updater window appears it prompts to remove old kernels. I haven't had to run either of those commands, for the purpose of removing old Ubuntu kernels, for months. Going forward, does this mean you have to uninstall the current linux-surface kernel before you can install the latest version or it'll error? Or it's a one-off as a result of the changes listed in #96? Am I pointing out something relevant here or am I pointing out the obvious! Do say! |
Intersting, thanks for sharing! Do you have any idea how the kernel packages are identified and marked for removal? Can you have an eye on this over the next couple of linux-surface kernel releases to check if that's working correctly/how that behaves?
This should be a one-off for this upgrade only, although I haven't been able to test that, so would be neat to have some feedback on that over the next couple of releases. I've also updated the announcement to make this a bit clearer. |
The update went well
Boots fine. I also encountered the thing with:
I don't use the GUI :)
This could be avoided even for the first time with a |
I'm not sure how I would find that out, I spent some time googling related terms but couldn't find anything useful. Here is the [1]dpkg log when the kernels were being removed, here is the journalctl [2]log when the preceding update was in progress, installing new kernels via the Software Updater and here is a [3]log of the Software Updater removing kernels. If you see any other files mentioned in these links, you think might help tell me and I'll have a look at posting. [1]https://github.com/condemnedmeat/dot/blob/master/dpkg.txt |
Or perhaps the answer is somewhere here... /etc/kernel/postinst.d: /etc/kernel/postrm.d: |
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 |
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. |
The solution may be to I'm not sure if you only need to remove those files or if you must remove the files in the boot partition too. The source of my information was: |
No depmod issues and the previous kernel is automatically removed during the update so all works on 18.04 & 20.04. |
Neat! Closing this as it seems to be resolved. Feel free to comment/re-open if there are still issues remaining. |
It worked today and automatically removed the third last kernel. It also magically preserved the second last kernel. |
Currently the old kernels are not being removed at the time the new kernel is being installed when using Software Updater. It is listed to be removed next time the Updater is used. Perhaps I reported it as working incorrectly in July, or this is intended behaviour. This has been the case since debian_lts-4.19.134 or so. |
I guess as long as |
I should think that works as it is meant to. |
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?
The text was updated successfully, but these errors were encountered: