Improve Update Manager's /boot space requirement calculation

[Rob Taylor]

Binary package hint: update-manager

If you have a lot of old kernel images installed (as can happen if you've done a few distro upgrades and/or followed unstable), then current gusty DistUpgradeControler calculates that you need a ridiculous amount of free space in /boot. It might be prudent to offer the option to users of removing older unused kernels if there is insufficient space in /boot.

[Rob Taylor (robtaylor)]

Ah, sorry, it appears I've already lost the log in question, ignore above attachment.

[Michael Vogt (mvo)]

Thanks for your bugreport.

The current version does remove old kernels also it tends to be rather conservative *and* it will remove them only at the end of the upgrade in the cleanup phase.

Cheers,
 Michael

[yurik81 (yurik81)]

Some newbies have troubles because by mistake using old kernels.

[Przemek K. (azrael)]

"Some newbies have troubles because by mistake using old kernels."
Yes, an example of that can be bug 442441.

[Michael Vogt (mvo)]

@Przemysław Kulczycki:
The bug your point to is different in that the problem there seems to be that the default kernel is not updated.

update-manager will always keep the current running kernel because its the only way to ensure that the system
will still be bootable after a upgrade (assuming the new kernel has a severe regressions for the hardware that
the user has).

[Sylvain Nahas (myself-sylvain-nahas)]

Hi,

I have a Dell Inspiron 6400 installed with the delivered Ubuntu CD and proposed hard-disc layout, and since then regularly updated.

During last update I have encountered the same problem described here and I really think it should be solved quit fast. For advanced users working around is easy but for "normal" users it is probably hard to overcome. And could be avoided. The tips given in the error dialog are useless. See attached screen-shot (sorry, localized in French, I can provide a translation if ever necessary).

[nutznboltz (nutznboltz-deactivatedaccount)]

Does it really make sense for update-manager (a GUI app) to clean up old kernel images instead of using computer-janitor (a CLI app with an optional computer-janitor-gtk GUI) to do the work?

[Jérôme (jerome-bouat)]

Whatever the system is, I think we have to wait about 3 months before removing an old kernel. This will allow a broken feature to be fixed in the new kernel before removing the old working kernel.

[nutznboltz (nutznboltz-deactivatedaccount)]

Do we really need more than computer-janitor? It removes kernels that are not in the apt pool.

[Lasse Kärkkäinen (tronic+mb48)]

When using a development version, the kernels accumulate very quickly. I would recommend removing anything but the latest and the currently running kernel (which obviously is working) during an update. I don't see what benefit there would be in keeping any versions other than those, as the user would still be able to install other versions manually.

[Jérôme (jerome-bouat)]

Because Ubuntu will use the latest kernel on reboot and thus it will allow to delete the previously used kernel.

In case the latest kernel has a bug which can be discovered manu weeks after its first use, the user should be able to use the latest kernel which had no bug within a few minutes.

Because the kernel is critical, the user shouldn't have to wait for a bug fix in order to use its ubuntu box (bugs can still be open for months on launchpad).

[fcolcord (fcolcord)]

I was running out of space on my 4GB boot up flash card, and reclaimed 800MB by clearing out 4 old kernels.

I figured out how to do it, but it would have been helpful if Janitor had given me the suggestion.

thanks for otherwise useful package.

[Sergey Kondakov (virtuousfox)]

after installing Ubuntu for people in dual-boot, having more then 2 select lines (latest kernel+recovery) for Ubuntu (and Windows(tm) always has only 1) really pisses them off.

while i think 2 kernels would be adequate, 4 lines really pushes it - they _never_ able to find "Windows" option among them in time at first -> having any more kernels then 2 is just evil, it traines them to always pick "familiar _one_" and never care about clust^Wpile of unknown numbers.

if you gonna target such people who do not know what "kernel" is then you have to keep boot menu as clean as possible.

[Sylvain Nahas (myself-sylvain-nahas)]

Le dimanche 21 mars 2010 à 08:59 +0000, Sergey Kondakov a écrit :
> really pisses them off.

I concur. I just have had the case with a new user who installed a
dual-boot and now complains having to scroll too much to start its other
OSes. I explained him how to remove the older kernels - that at least is
easy enough - but it is still not a very "polished" experience.

Sylvain.

[Barry Warsaw (barry)]

When Computer Janitor 2.0 lands, it will include a dbus service for finding and removing cruft. I wonder if it makes sense for Update Manager to find the cruft before it runs and ask the user to remove it? It could:

* only do this if it needs the disk space
* somehow ask the user to just clean up kernel packages, though it'll have to kind of guess this
* just provide an option to fire up the CJ gui during the upgrade process

[Sergey Kondakov (virtuousfox)]

there is no reason ever for something which being updated automatically to have multiple versions unless they can be used simultaneously. the only exception is old backup kernel in case of critical regression in the new one since kernel is core of everything, that's it.

most of people do not know what kernel is and do not want to know (hell, i can swear some even want to punch me then i trying to explain them for several minutes) and it pretty understandable (even though i strongly believe such things should be explained at schools), so _no amount of fancy GUI pop-ups will help_.

if someone wants to have some specific version of kernel when they will install it specifically. automatic updates should not bother with this but they should not clog up boot menu either and no user interaction must be required, i insist.

cleaning up something else while interacting with user when disk space is scarce is a good idea though.

[Barry Warsaw (barry)]

Well, old kernels are one of the things you can clean up, right? So update manager could say "Do you want to reclaim some disk space by removing unused software before you upgrade?" with a Details button that would provide more information for users who care.

[Sergey Kondakov (virtuousfox)]

do you read me at all ? my point that _disk space_ is NOT an ISSUE here... boot menu selection list is.

update manager should care about space only then it is scarce and if it truly "automatic updater" it should not interact with user unless it absolutely necessary for system (like it asks about updating grub config but even then i'm not sure it is really necessary since it auto generated anyway) or user has explicitly stated willingness to do stuff semi-automatically

this maybe not in the summary of this particular bug-report but in the most of its "duplicates"

[Lazy (ubuntu-bugs-oittaa)]

Upgrading from Karmic to Lucid Beta1 failed because /boot run out of space during upgrade process. See bug 542935 for attached log files.

[Barry Warsaw (barry)]

It seems like people are reporting two problems here. One is boot menu clutter after an upgrade and the other is lack of space in /boot to perform the upgrade.

As for boot menu clutter, a workaround is to remove unused kernels after an update, but I don't think this is actually a good solution. Those old kernels can often be useful when there is a regression. I can't remember how many times having the old kernel around has saved my bacon. For experienced users and those who participate in alpha testing, I think having those kernels around is very important. Those folks won't mind all the extra lines of gibberish. :)

For newbies, I agree that what they problem want is a much friendlier boot screen. About all they will care about is two options: Boot Ubuntu Linux or Boot Windows. I'm not even sure memtest is a useful option for most non-experts. The Boot Ubuntu option should simply pick the latest kernel available. I think this would improve the user experience, but it's ultimately not a bug in update manager. Wouldn't grub be the right place to improve the boot menu experience? If I were redesigning the boot menu, I'd make it all pretty and have just these options:

[X] Boot Ubuntu 10.04
[ ] Boot Windows 7
[ ] Advanced Options

The Advanced Options would lead you to today's boot menu probably. I'd also include a grub configuration option to install the old style (i.e. advanced) boot menu, which will reduce click through for advanced users.

As for running out of disk space in /boot, such that the upgrade cannot be performed, I think the right solution is to include hooks into the CJ dbus service for UM. What UM should probably do is find all the cruft on the system, analyze the package names for outdated kernels, and present some information and an option. Something like this perhaps:

You have some unused software on your system. You can reclaim the disk space now by removing this software, which could prevent update from running out of disk space. [Reclaim Disk Space Now]

That button would run computer-janitor-gtk to allow folks to remove packages before returning to complete the upgrade.

[Sylvain Nahas (myself-sylvain-nahas)]

+1

[Sergey Kondakov (virtuousfox)]

>Those old kernels can often be useful when there is a regression.

i doubt there will be much regressions in kernels of the same minor version ever.
especially ones which render kernel unbootable.

>I can't remember how many times having the old kernel around has saved my bacon.

keyword will be "old kernel" - 1 is fine, especially if it's one from which update has been made.

>For experienced users and those who participate in alpha testing,

good for testers, not users.

> I think having those kernels around is very important.

and i do not think so even for testers since they pretty much capable of reverting back after unlikely critical failure even if both "new" and "worked" kernels are broken by having 100% working version preinstalled manually or booting from live system or kernel from external device with initrd and 'root=<ubuntu root>' option

>Those folks won't mind all the extra lines of gibberish.

those folks can handle a lot of crap life can throw at them, i have no doubt about that.
but, being gentoo user myself, i do not appreciate useless stuff lying around even though i reboot my home systems no often then once per 2 weeks. and i cannot comprehend how it can be frustrating for "normal people"

new grub2 widget-like graphic menu may look fancy but probably will not include any crutches for hiding ranges of kernels with same root-option. just keep it simple, please :(

PS: "people" do not report two issues here, it just someone with too long hands is marking reports about menu and space as duplicates :\ but since those useless kernels clutter both menu and space it better to "kill two hares with a single shot"

[Barry Warsaw (barry)]

> i doubt there will be much regressions in kernels of the same minor version
> ever. especially ones which render kernel unbootable.

I've seen it happen, but very rarely during the stable maintenance period for
a release. Those tend to have very conservative kernel upgrades. Maybe once
several releases ago did I have a problem with a kernel update after final
release breaking my boot because of some weird hardware compatibility.

But let's agree that once a release is final, we probably do not need to keep
any old kernels around. Before final release, I'd want to be less aggressive
in cleaning up old kernels by default.

> keyword will be "old kernel" - 1 is fine, especially if it's one from which
> update has been made.

How would you define "old"? My definition would be "cruft as found by
computer-janitor" but for me that finds everything except the current running
kernel, so that's probably more aggressive than I'd want to be by default for
pre-releases.

>>For experienced users and those who participate in alpha testing,

> good for testers, not users.

Not even experienced users? I certainly agree that it's all gibberish to most
"normal" users.

>>I think having those kernels around is very important.

> and i do not think so even for testers since they pretty much capable of
> reverting back after unlikely critical failure even if both "new" and
> "worked" kernels are broken by having 100% working version preinstalled
> manually or booting from live system or kernel from external device with
> initrd and 'root=<ubuntu root>' option

Those are all good emergency fall back options, but they're not nearly as
convenient as just booting a different kernel line. If you're testing and get
a broken machine, I think it's better to have people up and running again as
quickly as possible. E.g. you might not have created that external device and
may not be able to once your system is broken, or maybe the dog thought your
LiveCD was a frisbee and chewed it so it wouldn't boot. :)

My point is that in general, anybody who's testing a new Ubuntu release should
be prepared for more details, less polish, etc. and extra kernel lines should
not be confusing at all. Well, unless their testing a better boot
menu. <wink>

>>Those folks won't mind all the extra lines of gibberish.

> those folks can handle a lot of crap life can throw at them, i have no doubt
> about that. but, being gentoo user myself, i do not appreciate useless stuff
> lying around even though i reboot my home systems no often then once per 2
> weeks. and i cannot comprehend how it can be frustrating for "normal people"

I'm a gentoo user too (still have one gentoo server) and I very rarely reboot
either that machine or my stable Ubuntu servers or desktops. Cleaning up
useless stuff is the job of Computer Janitor on Ubuntu so I think that's the
proper tool to use for those who want a nice tidy system.

> new grub2 widget-like graphic menu may look fancy but probably will not
> include any crutches for hiding ranges of kernels with same root-option. just
> keep it simple, please :(

I think that would be the whole point of redesigning the boot menu
experience. I'd like to get ...

[Sergey Kondakov (virtuousfox)]

and why on Earth you keep talking about testers convenience in their testing environment and pre-releases when i, and probably most people, talk about user convenience on stable, if that can be said about ubuntu, final release ? 0_o

i starting to have an impression that you suggesting that i should not try to lure away people on gnu/linux via ubuntu unless they are masochists. because i see no connection between expertise and bunch of 2.6.X.{A,B,C-Z} kernels lying around with no one explicitly "ordering" them on end-user system and no other distro i know does that.

again you probably didn't read anything i have written - this bug report is not about "just update-manager", it's about all of reports it has in "duplicates" field and you should probably read them too.
and yes, it's not a best way to get input about "boot menu" since everything alright with menu itself (you the one who stated it should be redesigned while it actually being redesigned by grub2 developers but this is off-topic), the problem is in boot list in boot menu but nor bootloader nor menu-generation code is faulty - the concept of putting bunch of useless stuff into /boot of "production-ready"\released system is faulty.

here, if anyone have trouble navigating here, bug 241368 . read the damn thing, please.
now i try to think about what's important and why would anyone mark bug 241368 as duplicate for that (probably, because both can be solved by the same thing). and no, solutions are different if you will try to work-around 2 issues which should not exist by making two crutches which should not exist - know any other OSes which been born that way and constantly nag its user with useless pop-ups ?

now you are using "they do not understand 'anything' that's why we can put anything on them unless it bothers us" argument. bad argument.

[Barry Warsaw (barry)]

I personally do not think that all the bugs marked as duplicates are actually duplicates of this bug. I do not think that boot menu clutter is the same problem as upgrades failing because /boot is full, which the OP and many of the (IMHO legitimate) duplicates are complaining about. I personally do not think it's a good idea to mark as duplicate bugs which describe different problems but which might (but only might) be fixed by the same change. I hear what you're saying and respect your opinion, but I just happen to disagree.

I'm tempted to de-dup the bugs that are about clutter and just concentrate on solving the problem of upgrades failing because /boot is full. That to me is a more serious problem, but also probably a more solvable problem. I've spoken to a few people and many of us are more conservative about removing old kernels because it's actually fairly difficult to know which should be safe to remove. The proposal to address this is https://wiki.ubuntu.com/KernelTeam/removing-old-kernels but that seems not to have gone anywhere since 2008. The problem of course is that if you get this wrong, you will break the user's system in ways that most will almost certainly be unable to fix, which seems like a bad idea <wink>.

I still think the best way to handle failing upgrades due to /boot space exhaustion is to be explicit and let the user decide to remove unused packages, including old kernels. So I still think the safest solution is to 1) make sure update-manager has a foolproof way of determining whether there is enough disk space before it proceeds; 2) providing information about "unused software" and how much space it takes up; 3) providing a button to fire off computer-janitor which will allow the user to select what they want to remove.

[Sergey Kondakov (virtuousfox)]

i totally agree with you on that way of _upgrade_ (going to another version of distribution) where interaction is expected.
usual everyday _update_ though should be unattentive as possible and this what i suggest for bug 241368.

thank you and, please, someone give some attention to 241368 too already (it was opened in 2008-06-19, dammit)

[mikasjoman (mikasjoman)]

Just curious, I might have been the guy who set this thread in the begining.

But, how does dear apple inc do it? Thats really nice and I have never heard
anyone complain. Feels like we are reinventing the wheel here, when there
seems to be a really appreciated out there.

If somebody seems to have got it right, it seems like Apple is the one right
now.

Cheers

On 24 mar 2010 12.35, "Sergey Kondakov" <email address hidden> wrote:

i totally agree with you on that way of _upgrade_ (going to another version
of distribution) where interaction is expected.
usual everyday _update_ though should be unattentive as possible and this
what i suggest for bug 241368.

thank you and, please, someone give some attention to 241368 too already
(it was opened in 2008-06-19, dammit)

--
update-manager should remove more old kernels
https://bugs.launchpad.net/bugs/132311
You receiv...

[Kevin Smith (ubuntu-qualitycode)]

As the OP of Bug 120489 I heartily agree (as I said there) that this is *NOT* a duplicate of that.

As I said over there, and as has been said here, the problem could occur even if there is absolutely nothing in /boot other than one working kernel and a minimum of other essential files.

I like what Barry said in comment #26, except that I see an even simpler possible resolution. As he says, the installer must be able to detect a lack of space. At that point, identifying cruft and/or launching a janitor would be a nice touch. I would simply settle at this point for an error saying "/boot is full. Installation is being aborted. Please retry after freeing up space on /boot". User friendly? No. Friendlier than the current behavior? Yes, by 10000%. And hopefully could be coded, tested, and distributed quickly, with minimal dependencies and minimal design discussions.

[Barry Warsaw (barry)]

@Kevin: I'm trying to see if the Computer Janitor 2.0 changes are going to make it into Lucid. If so, I think it would be pretty easy to do what I mentioned in #26. If not, your simpler approach might work. I'll look into this in more detail, and thanks for your feedback.

[Barry Warsaw (barry)]

It's too late in the Lucid cycle to implement options #2 and #3 in comment 26 for Lucid, so I've split them into bug 553561 and modified the description of this bug to address just option #1, which is still doable for Lucid.

[Barry Warsaw (barry)]

As far as correctly counting free space in /boot, I can't find too much that we can improve on in current UM, except that it seems to undercount KERNEL_INITRD_SIZE by about 260K per kernel afaict. The best I think I can do is bump that up to add an extra ~500K over what it's calculating now. That'll give it a little safety buffer for now.

[Kevin Smith (ubuntu-qualitycode)]

@Barry: To clarify, when you talk about "per kernel", you are talking about per kernel that will be installed? As opposed to per kernel already in /boot. I ask because at the time it failed for me, I may have had 10 kernels stacked up in /boot. How many kernels get installed?

Maybe you could briefly outline what that calculation is doing so the rest of us can understand it? Thanks.

[Barry Warsaw (barry)]

@Kevin: The way UM does its calculation is to count up all the kernels that are marked to-be-installed, and then simply allocates N KB per new kernel, which includes the initrd, vmlinux, etc files. Through observation I noticed that it's assigning 18*1024*1024 bytes for this, which on one of my systems is undercounting by 260KB (although on another system, it's just about right, so hmm...)

IIUC, the code uses statvfs on the underlying /boot file system to determine how much space is already consumed, so it doesn't have to count kernels that are already installed specifically.

Do you know how much space you had available in the /boot filesystem when it failed?

You generally only need one active kernel at a time. You can probably use Computer Janitor to clean up those old kernels and free up /boot space. Some people feel it's good to keep at least one old (i.e. not active) known-good kernel around just in case you find a problem with the one that is active, i.e. the last installed.

[Kevin Smith (ubuntu-qualitycode)]

@Barry: Thanks for the details.

The bug bit me back in 2007 (upgrading to 7.04), so obviously the details are pretty hazy by now. I mentioned in my bug report that I had 5 kernels in /boot at the time of failure. I just booted up that old system, and df reports a size of 101086 total 1K blocks. Sorry I can't give you more details about the state of things back then.

[Barry Warsaw (barry)]

@Kevin: cool. Do youmean that /boot had about 101MB of free space left? That should definitely have been enough to install a new kernel. Oh well, 7.04 was a long time ago :)

Is anybody still seeing this bug on Karmic or Lucid?

[Kevin Smith (ubuntu-qualitycode)]

@Barry: No, that was total size, not free space. Subtract out however much space five 6.10-era kernels would have consumed, along with whatever other typical /boot files might take up.

[highjack (magge)]

Hi,

This is to inform you that $14,520.70 has been deposited into your bank account this morning.

If you are interested in our offer, please Watch this for a quick tutorial on how you can claim your funds.

Your balance can be withdrawn any time and without delay.

If you are interested in our offer, please See How Here