Out of space on /boot

jimoe666 · January 8, 2011, 1:12am

opensuse v11.3

I started an update today. Part way through I got the message that there is not enough room on /boot to complete the kernel update. “This can’t be good,” I thought.

Indeed, there is only 6.4MB free space on /boot of 69MB; at least 9MB were expected. I do not know why the partition is so small. It is formatted ext3.

How do I go about creating a /boot partition with more space?

Here is the current disk complement:

Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/system-root
                       20G  7.0G   12G  38% /
devtmpfs              1.8G  300K  1.8G   1% /dev
tmpfs                 1.9G  584K  1.9G   1% /dev/shm
/dev/sda1              69M   59M  6.4M  91% /boot
/dev/mapper/system-home
                       25G  3.9G   20G  17% /home
/dev/sdc1             231G   12G  208G   6% /misc
/dev/sdb1             230G   19G  200G   9% /data01

ken_yap · January 8, 2011, 1:22am

You probably have some old kernels. Remove some old kernel packages. Or maybe you have both desktop and default. Remove the one you don’t use.

Incidentally these days a separate /boot partition isn’t needed, unless you have a very old machine.

jimoe666 · January 8, 2011, 1:46am

Here is a listing of /boot:

 backup_mbr
 boot -> .
 boot.readme
 config-2.6.34-12-default
 config-2.6.34-12-desktop
 grub/
 initrd -> initrd-2.6.34-12-default
 initrd-2.6.34-12-default
 initrd-2.6.34-12-desktop
 lost+found/
 message
 symsets-2.6.34.7-0.7-default.tar.gz
 symsets-2.6.34.7-0.7-desktop.tar.gz
 symtypes-2.6.34.7-0.7-default.gz
 symtypes-2.6.34.7-0.7-desktop.gz
 symvers-2.6.34-12-default.gz
 symvers-2.6.34-12-desktop.gz
 System.map-2.6.34-12-default
 System.map-2.6.34-12-desktop
 vmlinux-2.6.34-12-default.gz
 vmlinux-2.6.34.7-0.7-desktop.gz
 vmlinux-2.6.34.7-0.7-default.gz
 vmlinux-2.6.34.7-0.7-desktop.gz
 vmlinuz -> vmlinuz-2.6.34-12-default
 vmlinuz-2.6.34-12-default
 vmlinuz-2.6.34-12-desktop

I should delete the desktop files and try the update again?

Would it work to rename /boot to something else, then copy everything to a new /boot on the / partition?

ken_yap · January 8, 2011, 1:53am

Don’t delete the files directly. Uninstall the kernel-desktop package.

Moving /boot is tricky unless you know exactly what steps to do. You could make your system unbootable.

robin_listas · January 8, 2011, 2:12am

On 2011-01-08 01:36, ken yap wrote:

> Incidentally these days a separate /boot partition isn’t needed, unless
> you have a very old machine.

There are some circumstances on modern machines that require a separate /boot partition.

–
Cheers / Saludos,

Carlos E. R.
(from 11.2 x86_64 “Emerald” GM (Minas Tirith))

yasar11732 · January 8, 2011, 2:39am

I am not an expert, and I don’t know what I say exactly, but, I guess symlinking may work, perhaps?

ken_yap · January 8, 2011, 2:45am

Next time if you have need of a /boot, don’t be stingy. You probably read some old howto that said 50MB. Give it 200MB or 1GB and be done with it. That’s nothing in these days of TB drives. Unless you also have an old drive.

jimoe666 · January 8, 2011, 7:41am

Don’t delete the files directly. Uninstall the kernel-desktop package.

Okay, that worked. And the system is now up to date! Yay!

please_try_again · January 8, 2011, 10:37am

If your disk is over 2 TB and you intend to boot from this area, maybe. But when people have 3 TB hd at home (propably in a couple months) BIOS will have adapted or disappeared. For now 3 TB hard disks are sold with a separate controller.

Otherwise for most people (not speaking about LVM and RAID situations), having a separate /boot partition is not advisable, as it always ends up getting full one way or another.

hcvv · January 8, 2011, 12:05pm

You forget that /boot is not only to be accessed from a running system that knows something about symlinks, but also from GRUB during boot and GRUB knows nothing about the symlinks you made.

ken_yap · January 8, 2011, 12:13pm

Actually I believe the problem is not that GRUB cannot interpret symlinks (some /boot directories feature symlinks) but that the symlinks would be to a different partition in this case, not necessarily the one that was specified as the boot device to GRUB.

hcvv · January 8, 2011, 12:30pm

I was a bit short in my explanation. As soon as Grub has the correct file system it will then use it’s facilities (which it knows about), but the specifications in */boot/grub/menu.lst like (hd0,1) *will point to the wrong partition. I have no doubt that this is one of the problems you pointed to in post #4 above.

I did try not to go into details, but wanted to warn yasar11732 that his approach is a bit tricky in this case.

please_try_again · January 8, 2011, 12:44pm

You can use symlinks in Grub menu. Ubuntu/Debian traditionnaly symlink the kernel and the ram disk image. It is also a good idea while booting Ubuntu from openSUSE’s Grub, as the kernel name changes after each update while the symlinks’ name doesn’t and always refers to the latest kernel. However it won’t work if /boot is on a separate partition, as you have to specify the root device (which would be the /boot partition in this case) in the kernel line. So even if Grub would follow the symlink, it will look for it on the wrong device (I guess). One more good reason not to have a separate /boot partition.

The following two entries that boot Ubuntu’s kernel in openSUSE’s /boot/grub/menu.lst are equivalent (today):

###Don't change this comment - YaST2 identifier: Original name: Ubuntu###
title Ubuntu 10.10 (maverick) - kernel 2.6.35-24-generic
    root (hd0,5)
    kernel /boot/vmlinuz-2.6.35-24-generic root=UUID=d42b22b6-664e-494c-b3d6-08f3c03c3c08 ro vga=791
    initrd /boot/initrd.img-2.6.35-24-generic

###Don't change this comment - YaST2 identifier: Original name: Ubuntu###
title Ubuntu 10.10 (maverick) - kernel 2.6.35-24-generic
    root (hd0,5)
    kernel /vmlinuz root=UUID=d42b22b6-664e-494c-b3d6-08f3c03c3c08 ro vga=791
    initrd /initrd.img

However only the second one (using symlinks) will boot the latest kernel after an update on Ubuntu’s side. The first entry will still boot the previous kernel (which doesn’t get deinstalled by default under Ubuntu).

Bellow, the kernel and initrd.img symlinks on Ubuntu:

# ls -la /vmlinuz* /initrd*
lrwxrwxrwx 1 root root 33 Dec 20 21:53 /initrd.img -> boot/initrd.img-2.6.35-24-generic
lrwxrwxrwx 1 root root 33 Nov 30 20:20 /initrd.img.old -> boot/initrd.img-2.6.35-23-generic
lrwxrwxrwx 1 root root 30 Dec 20 21:53 /vmlinuz -> boot/vmlinuz-2.6.35-24-generic
lrwxrwxrwx 1 root root 30 Nov 30 20:20 /vmlinuz.old -> boot/vmlinuz-2.6.35-23-generic

please_try_again · January 8, 2011, 12:46pm

Yes. That’s what I was trying to explain meanwhile … but it took me longer.

robin_listas · January 8, 2011, 3:30pm

On 2011-01-08 11:06, please try again wrote:

> Otherwise for most people (not speaking about LVM and RAID situations),
> having a separate /boot partition is not advisable, as it always ends up
> getting full one way or another.

LVM and RAID is one circumstance. Having reiserfs in the root is another:
there is a bug affecting this case (with hibernation). Also, XFS had issues
with grub, although I read they were solved a year ago.

Yes, it tends to be filled. Kernels are bigger and bigger.

I remember a case posted here with a commercial SLES product (netware?)
that had a separate /boot, created by the install, not the user.

–
Cheers / Saludos,

Carlos E. R.
(from 11.2 x86_64 “Emerald” at Telcontar)

robin_listas · January 8, 2011, 3:30pm

On 2011-01-08 03:06, yasar11732 wrote:
>
> I am not an expert, and I don’t know what I say exactly, but, I guess
> symlinking may work, perhaps?

Certainly not.

If you don’t know why not, don’t try to move boot.

–
Cheers / Saludos,

Carlos E. R.
(from 11.2 x86_64 “Emerald” at Telcontar)