[MASTER] /boot free space check message misleading and space requirement too big

[K9JM]

While attempting to upgrade to Fawn, I got an error saying that I needed at least 12megs on my /boot partition. Both df and gparted report that I have 16 megs free. The installation terminated okay...

[Michael Vogt (mvo)]

Thanks for your bugreport.

It seems like the dialog text is misleading. It means that an additional 12Mb are required.

Cheers,
 Michael

[K9JM (k9jmlinux)]

On Tue, 2007-04-10 at 08:57 +0000, Michael Vogt wrote:
> Thanks for your bugreport.
>
> It seems like the dialog text is misleading. It means that an
> additional
> 12Mb are required.
>
> Cheers,
> Michael
>

Dang... I moved my entire /boot partition to another drive and tried
the up grade and it reported I needed 3600k more space. Once Fawn is
released with the amount of boot space required go down?? To upgrade
kernels it only takes less than 20megs, not 45megs.

Cheers
Jim

[Michael Vogt (mvo)]

Thanks for your bugreport and sorry for your trouble upgrading.

The current savety buffer is 40MB. Each kernel requires ~10MB (kernel+initrd).

Currently the code does not take the amount of kernels into account that actually gets installed. This should be fixed early in feisty+1, but its too late for feisty. The reason for 40 is that one can have easily multiple kernels installed (-lowlatency, -server, -generic).

I hope the upgrade went ok otherwise?

Cheers,
 Michael

[K9JM (k9jmlinux)]

My oldest machine is the one with the problem... reason is that it has a
BIOS that requires a boot within N sectors, and it requires a /boot
partition. It has been through several upgrades in the past. The /boot
partition is 47 megs. As I said, I cleaned out the /boot partition and
then tried the upgrade and found that I needed another 3megs more. So
I think the magic number is more like 50 megs. That machine was a
"production" machine but is now serves as a canary.

Thanks!
Jim

On Wed, 2007-04-11 at 08:44 +0000, Michael Vogt wrote:
> Thanks for your bugreport and sorry for your trouble upgrading.
>
> The current savety buffer is 40MB. Each kernel requires ~10MB
> (kernel+initrd).
>
> Currently the code does not take the amount of kernels into account that
> actually gets installed. This should be fixed early in feisty+1, but its
> too late for feisty. The reason for 40 is that one can have easily
> multiple kernels installed (-lowlatency, -server, -generic).
>
> I hope the upgrade went ok otherwise?
>
> Cheers,
> Michael
>
> ** Changed in: update-manager (Ubuntu)
> Importance: Undecided => Low
> Status: Needs Info => Confirmed
> Target: None => later
>

[Arthur (moz-liebesgedichte)]

I have 33162 KB of free space in /boot and the update-manager complains about needing at least something about 7 MB. That's why I've tried remounting and moving bits and bytes over and over again. A fix to the message would be a godsend.

[Arthur (moz-liebesgedichte)]

Ah, OK, the dialog is about how much _additional_ free space is missing. The German translation certainly doesn't sound like that. It sounds as if it's talking about the total amount of needed free space.

[K9JM (k9jmlinux)]

On Fri, 2007-04-20 at 09:45 +0000, Michael Vogt wrote:
> ** Summary changed:
>
> - Failure to upgrade to Fawn
> + [MASTER] Failure to upgrade to Fawn
>
> ** Summary changed:
>
> - [MASTER] Failure to upgrade to Fawn
> + [MASTER] /boot free space check message misleading and space requirement too big
>

My problem is that the boot partition is too small... even if I wipe it
clean ;-<

Jim

[K9JM (k9jmlinux)]

On Thu, 2007-04-19 at 19:33 +0000, Arthur wrote:
> Ah, OK, the dialog is about how much _additional_ free space is
> missing.
> The German translation certainly doesn't sound like that. It sounds as
> if it's talking about the total amount of needed free space.
>
>
Neither does it in English. My problem is that my /boot partition isn't
large enough... it is only 48 megs and you need 50 some meg. There is
no reason they need that much space unless you have many versions of the
kernel at the same time... I don't get it. It is planned to be fixed
at Feisty + 1.

Jim

[Stephan (stephan-h)]

If this is the Master thread regarding "space requirement too big"
could you please raise the importance?

Reason: this problem may absolutely prohibit the upgrade to feisty.
In some scenarios resizing partitions may be a (risky)
workaround to satisfy the overly conservative space requirement,
but if "/" holds a filesystem for which shrinking is not supported
by gparted (like xfs, reiser4) it may not be possible to grow "/boot".

If a quick fix is not likely, is there a workaround without repartitioning?

[Péter Károly Juhász (stone-midway)]

I used https://help.ubuntu.com/community/FeistyUpgradesManual to upgrade, everything was OK.

[JamesRichardson (james-time4tea)]

Please raise importance of this bug, totally unable to upgrade without repartitioning, as used ext2 & raw partition for /boot. maybe this was wrong, but there it is just now...

root@myth:/boot/grub# df -h .
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 37M 9.4M 26M 28% /boot

root@myth:/boot/grub# mount -t ext2
/dev/sda1 on /boot type ext2 (rw)

thx.

[Simon Ruggier (simon80)]

JamesRichardson: is there something preventing you from using the FeistyUpgradesManual page to upgrade your system?

If so, you might also try setting up your system to use your root partition to store /boot in. This involves running:

# cp -a /boot /tmp/boot.backup
# umount /boot
# cp -a /tmp/boot.backup/* /boot

and then:
-commenting the line that mounts /boot out of your fstab
-editing your /boot/grub/menu.lst to point to your root partition instead of the /boot one
-reinstalling grub to the hard drive you boot from with something like:

# grub
grub> root (hdx,y)
grub> setup (hdx)

[K9JM (k9jmlinux)]

On Mon, 2007-05-07 at 23:50 +0000, Simon Ruggier wrote:
> JamesRichardson: is there something preventing you from using the
> FeistyUpgradesManual page to upgrade your system?
>
> If so, you might also try setting up your system to use your root
> partition to store /boot in. This involves running:
>
> # cp -a /boot /tmp/boot.backup
> # umount /boot
> # cp -a /tmp/boot.backup/* /boot
>
> and then:
> -commenting the line that mounts /boot out of your fstab
> -editing your /boot/grub/menu.lst to point to your root partition instead of the /boot one
> -reinstalling grub to the hard drive you boot from with something like:
>
> # grub
> grub> root (hdx,y)
> grub> setup (hdx)
>

Most people (self included) who actually make a boot partition did so
because the BIOS is old and places restrictions on how many sectors in
it can boot from... so you can't have /boot in with on the main
partition.

When it complains about not enough space in /boot and that it needs X
bytes more... it lies. So this adds to the confusion.

James Michener

[Arthur (moz-liebesgedichte)]

> When it complains about not enough space in /boot and that it needs X
> bytes more... it lies. So this adds to the confusion.
I'm not so sure about this anymore. During the upgrade Ubuntu creates new initrd images for every installed kernel including backups and temporarily uses (at least on my system) as much space as advertised. The hole process should probably be streamlined and people should be made aware that not only space for a new kernel is needed but also for a lot of old cruft that gets rebuilt.

[Simon Ruggier (simon80)]

The installer could use /tmp for the extra stuff, or anywhere else,
since it's running with root privileges.

[geraldf (gcforum)]

Importance is NOT low, because
- it makes upgrading impossible for many users,
- it wastes a lot of valuable work time.

Best regards
Gerald

[Sebastian Heinlein (glatzor)]

The bug is known and worked on. So please do not try to raise its awarness by adding comments.

Cheers,

Sebastian

[ryanmbruce (ryanmbruce)]

Just figured I'd add in my own experience with this bug on an upgrade to Gutsy Tribe3, as I haven't seen anyone with quite as hefty of a space requirement as what update-manager is asking of me. 315MB in addition to the 228 that is on there adds up to a rather large boot partition.

I have two questions:

1) What portion of the current upgrade process is taking up this space

2) Can we look at streamlining it so that less space is used, or at least the space requirement stays constant? No standard user should have to face repartitioning/resizing during an upgrade.

---------
bobo@Sixteen:~$ update-manager -d
...
[DIALOG BOX]
Not enough free disk space

The upgrade aborts now. The upgrade needs a total of 325058560 free space on disk /boot. Please free at least an additional 313M of disk space on /boot. Empty your trash and remove temporary packages of former installations using 'sudo apt-get clean'.
[/DIALOG BOX]

-------------

bobo@Sixteen:~$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/Ubuntu-root
                       75G 53G 23G 71% /
varrun 253M 84K 252M 1% /var/run
varlock 253M 4.0K 253M 1% /var/lock
procbususb 253M 112K 252M 1% /proc/bus/usb
udev 253M 112K 252M 1% /dev
devshm 253M 0 253M 0% /dev/shm
lrm 253M 34M 219M 14% /lib/modules/2.6.20-16-386/volatile
/dev/mapper/hda5 228M 205M 12M 95% /boot
--------------

Cheers,
-Ryan

[ryanmbruce (ryanmbruce)]

I would also suggest that we create a different bug for the required repartition/large space requirement that is separate from the misleading text(which has been fixed).

Cheers,
-Ryan

[Arthur (moz-liebesgedichte)]

>315MB in addition to the 228 that is on there adds up to a rather large boot partition.

I think what's using up so much space is that it rebuilds all initrd.imgs it can find and backups the old ones and then adds additional entries to your boot menu. I haven't looked at the code, it's just what I've surmised. When you delete some of the old kernel cruft (including the grub-entries) the additional space requirements should come down as well.

So one of the questions that remain is: Should there be an automatic clean up of old kernels? People would loose the possibility to go back to old ones but wouldn't run into that many problems with full boot partitions.

[ryanmbruce (ryanmbruce)]

I always just assumed there was an old kernel clean-up because I set
the grub menu to only display 2 or 4 I didn't realize it kept ALL of
them until I cleaned out all but the last four. To me, it seems like
not cleaning those up is somewhat of a waste (both in processing power
when rebuilding, and in memory) not to mention a ticking time bomb
that will eventually force everyone to resize their boot
partitions(somewhat dangerous/impossible for some).

-Ryan

On 8/23/07, Arthur <email address hidden> wrote:
> >315MB in addition to the 228 that is on there adds up to a rather large
> boot partition.
>
> I think what's using up so much space is that it rebuilds all
> initrd.imgs it can find and backups the old ones and then adds
> additional entries to your boot menu. I haven't looked at the code, it's
> just what I've surmised. When you delete some of the old kernel cruft
> (including the grub-entries) the additional space requirements should
> come down as well.
>
> So one of the questions that remain is: Should there be an automatic
> clean up of old kernels? People would loose the possibility to go back
> to old ones but wouldn't run into that many problems with full boot
> partitions.
>
> --
> [MASTER] /boot free space check message misleading and space requirement too big
> https://bugs.launchpad.net/bugs/104337
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[ryanmbruce (ryanmbruce)]

"I think what's using up so much space is that it rebuilds all
initrd.imgs it can find and backups the old ones and then adds
additional entries to your boot menu."

I think it may be doing more than this because I have cleaned out every single image with the exception of the four I absolutely need, and those are only 6-7M each. Even if it makes a backup and a new image, I can't see it using up all of the space. My newest usage stats are below.

I'm really stuck right now because I can't resize my boot partition, and I can't clean any more out of it. I absolutely cannot upgrade to Gutsy unless a workaround is found, or the space requirement is lowered. Any help would be appreciated.

Cheers,
-Ryan

-----
bobo@Sixteen:~$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/Ubuntu-root
                       75G 21G 54G 28% /
varrun 253M 88K 252M 1% /var/run
varlock 253M 4.0K 253M 1% /var/lock
procbususb 253M 124K 252M 1% /proc/bus/usb
udev 253M 124K 252M 1% /dev
devshm 253M 0 253M 0% /dev/shm
lrm 253M 34M 219M 14% /lib/modules/2.6.20-16-386/volatile
/dev/mapper/hda5 228M 47M 170M 22% /boot

-----
bobo@Sixteen:/boot$ ls -lah
total 43M
drwxr-xr-x 4 root root 3.0K 2007-08-26 18:21 .
drwxr-xr-x 22 root root 656 2007-08-06 11:42 ..
-rw-r--r-- 1 root root 280K 2006-12-05 16:42 abi-2.6.17-10-386
-rw-r--r-- 1 root root 280K 2007-03-13 18:46 abi-2.6.17-11-386
-rw-r--r-- 1 root root 402K 2007-04-15 03:01 abi-2.6.20-15-386
-rw-r--r-- 1 root root 402K 2007-06-07 15:51 abi-2.6.20-16-386
-rw-r--r-- 1 root root 74K 2006-12-05 14:38 config-2.6.17-10-386
-rw-r--r-- 1 root root 74K 2007-03-13 16:42 config-2.6.17-11-386
-rw-r--r-- 1 root root 82K 2007-04-15 00:04 config-2.6.20-15-386
-rw-r--r-- 1 root root 82K 2007-06-07 12:48 config-2.6.20-16-386
drwxr-xr-x 2 root root 1.0K 2007-08-22 21:35 grub
-rw-r--r-- 1 root root 7.9M 2007-05-01 01:58 initrd.img-2.6.17-10-386
-rw-r--r-- 1 root root 7.9M 2007-05-01 01:57 initrd.img-2.6.17-11-386
-rw-r--r-- 1 root root 7.9M 2007-05-01 01:57 initrd.img-2.6.20-15-386
-rw-r--r-- 1 root root 7.9M 2007-08-06 11:42 initrd.img-2.6.20-16-386
drwxr-xr-x 2 root root 12K 2002-04-19 19:59 lost+found
-rw-r--r-- 1 root root 93K 2006-10-20 06:44 memtest86+.bin
-rw-r--r-- 1 root root 697K 2006-12-05 16:42 System.map-2.6.17-10-386
-rw-r--r-- 1 root root 699K 2007-03-13 18:46 System.map-2.6.17-11-386
-rw-r--r-- 1 root root 771K 2007-04-15 03:03 System.map-2.6.20-15-386
-rw-r--r-- 1 root root 771K 2007-06-07 15:52 System.map-2.6.20-16-386
-rw-r--r-- 1 root root 1.6M 2006-12-05 16:42 vmlinuz-2.6.17-10-386
-rw-r--r-- 1 root root 1.6M 2007-03-13 18:46 vmlinuz-2.6.17-11-386
-rw-r--r-- 1 root root 1.6M 2007-04-15 03:01 vmlinuz-2.6.20-15-386
-rw-r--r-- 1 root root 1.7M 2007-06-07 15:51 vmlinuz-2.6.20-16-386

-----
bobo@Sixteen:/boot$ du -h
12K ./lost+found
169K ./grub
43M .

-----
[DIALOG BOX]
Not enough free disk space

The upgrade aborts now. The upgrade needs a total of 325058560 free space on disk /boot. Please free at least an additional 148M of disk...

[Michael Vogt (mvo)]

Thanks for your bugreport.

This looks like a bug in the parition detection code. Could you please attach the file /var/log/dist-upgrade/main.log to this report? And also the content of /proc/mounts?

Thanks,
 Michael

[Michael Vogt (mvo)]

@ryanmbruce: please not that this looks like a seperate bug from the original reported one, but I need the requested files to verify this.

[Simon Ruggier (simon80)]

On 8/26/07, ryanmbruce <email address hidden> wrote:
> I'm really stuck right now because I can't resize my boot partition, and
> I can't clean any more out of it. I absolutely cannot upgrade to Gutsy
> unless a workaround is found, or the space requirement is lowered. Any
> help would be appreciated.

According to one of the previous comments in the bug, there is a
workaround - you can manually change your sources to gutsy and do a
dist-upgrade.

see https://help.ubuntu.com/community/FeistyUpgradesManual

Also, I don't think I had more than 2 Linux images in my 50MB /boot
partition when I did my upgrade, and I still ran into this bug.

[ryanmbruce (ryanmbruce)]

bobo@Sixteen:~$ cat /proc/mounts
rootfs / rootfs rw 0 0
none /sys sysfs rw,nosuid,nodev,noexec 0 0
none /proc proc rw,nosuid,nodev,noexec 0 0
udev /dev tmpfs rw 0 0
/dev/mapper/Ubuntu-root / reiserfs rw,noatime 0 0
/dev/mapper/Ubuntu-root /dev/.static/dev reiserfs rw 0 0
tmpfs /var/run tmpfs rw,nosuid,nodev,noexec 0 0
tmpfs /var/lock tmpfs rw,nosuid,nodev,noexec 0 0
tmpfs /lib/modules/2.6.20-16-386/volatile tmpfs rw 0 0
tmpfs /dev/shm tmpfs rw 0 0
devpts /dev/pts devpts rw 0 0
usbfs /dev/bus/usb/.usbfs usbfs rw 0 0
udev /proc/bus/usb tmpfs rw 0 0
usbfs /proc/bus/usb/.usbfs usbfs rw 0 0
tmpfs /var/run tmpfs rw,nosuid,nodev,noexec 0 0
tmpfs /var/lock tmpfs rw,nosuid,nodev,noexec 0 0
/dev/disk/by-uuid/69b5eadb-b284-425d-93b9-cb01fbc48ce1 /boot ext3 rw,data=ordered 0 0
binfmt_misc /proc/sys/fs/binfmt_misc binfmt_misc rw 0 0

-------------

@Michael - Maybe a bug with lvm uuids?

Cheers,
-Ryan

[Michael Vogt (mvo)]

@ryanmbruce: Thanks for the logs! It looks like you removed the images from the filesystem, but not the kernel packages. Please use synaptic to remove the no longer used kernels (make sure to keep the one you are currently using :)

2007-08-26 22:56:14,237 DEBUG linux-image-2.6.17-10-386 (upgrade|installed) added with 20971520 to boot space
2007-08-26 22:56:14,259 DEBUG linux-image-2.6.15-22-386 (upgrade|installed) added with 20971520 to boot space
2007-08-26 22:56:14,272 DEBUG linux-image-2.6.17-7-386 (upgrade|installed) added with 20971520 to boot space
2007-08-26 22:56:14,292 DEBUG linux-image-2.6.15-17-386 (upgrade|installed) added with 20971520 to boot space
2007-08-26 22:56:14,317 DEBUG linux-image-2.6.17-8-386 (upgrade|installed) added with 20971520 to boot space
2007-08-26 22:56:14,324 DEBUG linux-image-2.6.15-21-386 (upgrade|installed) added with 20971520 to boot space
2007-08-26 22:56:14,363 DEBUG linux-image-2.6.22-10-386 (new-install) added with 10485760 to boot space
2007-08-26 22:56:14,371 DEBUG linux-image-2.6.17-6-386 (upgrade|installed) added with 20971520 to boot space
2007-08-26 22:56:14,382 DEBUG linux-image-2.6.17-9-386 (upgrade|installed) added with 20971520 to boot space
2007-08-26 22:56:14,411 DEBUG linux-image-2.6.17-11-386 (upgrade|installed) added with 20971520 to boot space
2007-08-26 22:56:14,437 DEBUG linux-image-2.6.17-5-386 (upgrade|installed) added with 20971520 to boot space
2007-08-26 22:56:14,454 DEBUG linux-image-2.6.20-15-386 (upgrade|installed) added with 20971520 to boot space
2007-08-26 22:56:14,531 DEBUG linux-image-2.6.20-16-386 (upgrade|installed) added with 20971520 to boot space
2007-08-26 22:56:14,561 DEBUG linux-image-2.6.15-20-386 (upgrade|installed) added with 20971520 to boot space
2007-08-26 22:56:14,572 DEBUG linux-image-2.6.15-23-386 (upgrade|installed) added with 20971520 to boot space
2007-08-26 22:56:14,605 DEBUG linux-image-2.6.17-4-386 (upgrade|installed) added with 20971520 to boot space

The space calculation is correct.

[ryanmbruce (ryanmbruce)]

ahhh....duh. I incorrectly assumed it was calculating the space by
looking at the images on disk. Boy do I feel dumb now. Thanks for
the help!

Cheers,
-Ryan

On 8/28/07, Michael Vogt <email address hidden> wrote:
> @ryanmbruce: Thanks for the logs! It looks like you removed the images
> from the filesystem, but not the kernel packages. Please use synaptic to
> remove the no longer used kernels (make sure to keep the one you are
> currently using :)
>
> 2007-08-26 22:56:14,237 DEBUG linux-image-2.6.17-10-386 (upgrade|installed) added with 20971520 to boot space
> 2007-08-26 22:56:14,259 DEBUG linux-image-2.6.15-22-386 (upgrade|installed) added with 20971520 to boot space
> 2007-08-26 22:56:14,272 DEBUG linux-image-2.6.17-7-386 (upgrade|installed) added with 20971520 to boot space
> 2007-08-26 22:56:14,292 DEBUG linux-image-2.6.15-17-386 (upgrade|installed) added with 20971520 to boot space
> 2007-08-26 22:56:14,317 DEBUG linux-image-2.6.17-8-386 (upgrade|installed) added with 20971520 to boot space
> 2007-08-26 22:56:14,324 DEBUG linux-image-2.6.15-21-386 (upgrade|installed) added with 20971520 to boot space
> 2007-08-26 22:56:14,363 DEBUG linux-image-2.6.22-10-386 (new-install) added with 10485760 to boot space
> 2007-08-26 22:56:14,371 DEBUG linux-image-2.6.17-6-386 (upgrade|installed) added with 20971520 to boot space
> 2007-08-26 22:56:14,382 DEBUG linux-image-2.6.17-9-386 (upgrade|installed) added with 20971520 to boot space
> 2007-08-26 22:56:14,411 DEBUG linux-image-2.6.17-11-386 (upgrade|installed) added with 20971520 to boot space
> 2007-08-26 22:56:14,437 DEBUG linux-image-2.6.17-5-386 (upgrade|installed) added with 20971520 to boot space
> 2007-08-26 22:56:14,454 DEBUG linux-image-2.6.20-15-386 (upgrade|installed) added with 20971520 to boot space
> 2007-08-26 22:56:14,531 DEBUG linux-image-2.6.20-16-386 (upgrade|installed) added with 20971520 to boot space
> 2007-08-26 22:56:14,561 DEBUG linux-image-2.6.15-20-386 (upgrade|installed) added with 20971520 to boot space
> 2007-08-26 22:56:14,572 DEBUG linux-image-2.6.15-23-386 (upgrade|installed) added with 20971520 to boot space
> 2007-08-26 22:56:14,605 DEBUG linux-image-2.6.17-4-386 (upgrade|installed) added with 20971520 to boot space
>
> The space calculation is correct.
>
> --
> [MASTER] /boot free space check message misleading and space requirement too big
> https://bugs.launchpad.net/bugs/104337
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[ryanmbruce (ryanmbruce)]

Just to update everyone, deleting the kernel packages using apt-get
allowed the update manager to run with no hitches.

I have a few ideas/suggestions to help avoid more bug reports on this
in the future:

1) The text in the 'not enough free space' dialog box could be amended
to include a note about removing old kernels using apt-get, synaptic,
etc.

2) Change the process which consumes the space in the first place.
Try to squeeze out any unnecessary/overkill space requirements. [I'm
obviously not familiar with what's all is happening in these steps,
but I'm sure you know if this can be done or not.]

3) Increase the default size of the boot partition during a server
install. [The installation on this system is somewhat fuzzy to me now,
but I'm pretty sure I used the sizes suggested when using LVM]

4) If the update manager finds that there is not enough free space on
the drive, it could allow the user to select which kernels to keep, or
which ones/how many to keep. Then it would proceed to remove them
automatically, making sure to keep the ones the user wants.

5) Failing both of the former options, the update manager could guide
the user through a partition resizing application. This is a bit
scary for the user to do on their own, so help from above might ease
the situation. I wouldn't (at least for the foreseeable future) want
to see this become a standard part of an upgrade due to
risk/instability.

These are just some ideas I pulled off the top of my head, so I make
no claim that they're fully baked. I would like to hear input if you
have any.

Cheers,
-Ryan

On 8/28/07, Ryan Bruce <email address hidden> wrote:
> ahhh....duh. I incorrectly assumed it was calculating the space by
> looking at the images on disk. Boy do I feel dumb now. Thanks for
> the help!
>
> Cheers,
> -Ryan
>
> On 8/28/07, Michael Vogt <email address hidden> wrote:
> > @ryanmbruce: Thanks for the logs! It looks like you removed the images
> > from the filesystem, but not the kernel packages. Please use synaptic to
> > remove the no longer used kernels (make sure to keep the one you are
> > currently using :)
> >
> > 2007-08-26 22:56:14,237 DEBUG linux-image-2.6.17-10-386 (upgrade|installed) added with 20971520 to boot space
> > 2007-08-26 22:56:14,259 DEBUG linux-image-2.6.15-22-386 (upgrade|installed) added with 20971520 to boot space
> > 2007-08-26 22:56:14,272 DEBUG linux-image-2.6.17-7-386 (upgrade|installed) added with 20971520 to boot space
> > 2007-08-26 22:56:14,292 DEBUG linux-image-2.6.15-17-386 (upgrade|installed) added with 20971520 to boot space
> > 2007-08-26 22:56:14,317 DEBUG linux-image-2.6.17-8-386 (upgrade|installed) added with 20971520 to boot space
> > 2007-08-26 22:56:14,324 DEBUG linux-image-2.6.15-21-386 (upgrade|installed) added with 20971520 to boot space
> > 2007-08-26 22:56:14,363 DEBUG linux-image-2.6.22-10-386 (new-install) added with 10485760 to boot space
> > 2007-08-26 22:56:14,371 DEBUG linux-image-2.6.17-6-386 (upgrade|installed) added with 20971520 to boot space
> > 2007-08-26 22:56:14,382 DEBUG linux-image-2.6.17-9-386 (upgrade|installed) added with 20971520 to boot space
> > 2007-08-26 22:56:14,411 DEBUG linux-image-2.6...

[Mikhail (mikhail.kalkov)]

-----Begin Error message-------
Not enough free disk space

The upgrade aborts now. The upgrade needs a total of 41.9M free space on disk '/boot'. Please free at least an additional 18.8M of disk space on '/boot'. Empty your trash and remove temporary packages of former installations using 'sudo apt-get clean'.
-----End of Error message-----

I was about to file a bug, but will request for a feature now. Wouldn't it be nice
1). to have a warning during the initial installation of Ubuntu, that suggests one to choose the size of the partition for /boot (if it is separate) to be not less then **M;
2). to suggest one to delete old kernel packages using a _package_manager_?

I've lost more then an hour on this issue...

[ryanmbruce (ryanmbruce)]

Groover,

I definitely agree. Will you please link us to the feature request that you file?

Thanks,
-Ryan

[Mikhail (mikhail.kalkov)]

Ok, here is the link to the first feature suggested: https://blueprints.launchpad.net/ubuntu/+spec/ubuntu-installer

I haven't found where to request for the second one. However, since, as I assume, people responsible for update-manager are subscribed to this bug, they were already notified of it. Anyway, I would like to hear their response in this thread.

ryanmbruce, I have already subscribed you to the blueprint. And thanks for your support!

[Pierre (pierre-php)]

I'm not sure to follow the discussion currently but there is clearly and obviously a bug. The error should be correct and let the user knows what actually happen. The worst case I had was a message asking me to free 115MB. After having removed two old kernels, the error was finally gone.

That being said, Ryan is right, the update manager may suggest a list of kernel to remove while upgrading :)

Thanks for your great work anyway, the update is yet done and everything seems to work like a charm!

[XXXXXXX (yddraiggoch)]

Fixed in update manager 1:0.63. Marking as fix released.