Ask Your Question
0

fedora 22 /boot insufficient disk space

asked 2015-07-10 09:01:57 -0600

this post is marked as community wiki

This post is a wiki. Anyone with karma >750 is welcome to improve it.

Hello: I recently started the upgrade process in my server, to go from Fedora 21 to 21. After updating all packages in Fedora 21, I executed fedup --network 22. All packages were downloaded, but in the end, the upgrade transaction test failed, giving this error:

Importing GPG key 0x8E1431D5:
 Userid     : "Fedora (22) <fedora@fedoraproject.org>"
 Fingerprint: c527 ea07 a934 9b58 9c35 e1bf 11ad c094 8e14 31d5
 Package    : fedora-repos-21-2.noarch (installed)
 From       : /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-22-i386
testing upgrade transaction
rpm transaction 100% [=================================================================================================]

Upgrade test failed with the following problems:
insufficient disk space:
  /boot needs 34M more free space
fedup ERROR: Upgrade test failed.

I had previously cleaned my /boot by removing old kernel packages. These are the contents of my /boot directory at the time of the upgrade:

total 138427
dr-xr-xr-x.  4 root root     3072 Jul 10 09:24 .
dr-xr-xr-x. 24 root root     4096 Jul 10 08:56 ..
-rw-r--r--   1 root root   154450 Apr 13 19:25 config-3.19.4-200.fc21.i686
-rw-r--r--   1 root root   152913 Apr 13 19:08 config-3.19.4-200.fc21.i686+PAE
-rw-r--r--   1 root root   156521 Jun 23 11:44 config-4.0.6-200.fc21.i686
-rw-r--r--   1 root root   154722 Jun 23 11:28 config-4.0.6-200.fc21.i686+PAE
drwxr-xr-x.  6 root root     1024 Jul 10 09:24 grub2
-rw-------.  1 root root 36063992 Aug 20  2014 initramfs-0-rescue-a08265a695fd4842b886e34c05485ee7.img
-rw-r--r--   1 root root 17793455 Jul  2 09:52 initramfs-4.0.6-200.fc21.i686.img
-rw-r--r--   1 root root 17810181 Jul  2 09:50 initramfs-4.0.6-200.fc21.i686+PAE.img
-rw-r--r--   1 root root 41117900 May 21 20:01 initramfs-fedup.img
-rw-r--r--.  1 root root   566934 Dec 16  2014 initrd-plymouth.img
drwx------.  2 root root    12288 Aug 20  2014 lost+found
-rw-------   1 root root  2359058 Jun 23 11:44 System.map-4.0.6-200.fc21.i686
-rw-------   1 root root  2393823 Jun 23 11:28 System.map-4.0.6-200.fc21.i686+PAE
-rwxr-xr-x.  1 root root  5115056 Aug 20  2014 vmlinuz-0-rescue-a08265a695fd4842b886e34c05485ee7
-rw-r--r--   1 root root      165 Apr 13 19:25 .vmlinuz-3.19.4-200.fc21.i686.hmac
-rw-r--r--   1 root root      169 Apr 13 19:08 .vmlinuz-3.19.4-200.fc21.i686+PAE.hmac
-rwxr-xr-x   1 root root  5735200 Jun 23 11:44 vmlinuz-4.0.6-200.fc21.i686
-rw-r--r--   1 root root      164 Jun 23 11:44 .vmlinuz-4.0.6-200.fc21.i686.hmac
-rwxr-xr-x   1 root root  5824384 Jun 23 11:28 vmlinuz-4.0.6-200.fc21.i686+PAE
-rw-r--r--   1 root root      168 Jun 23 11:28 .vmlinuz-4.0.6-200.fc21.i686+PAE.hmac
-rw-r--r--   1 root root  5744048 May 21 10:49 vmlinuz-fedup

My question is: what can I remove/delete to regain the requested 34Mbyte of space? Currently, the directory is showing 27 Mbytes of free space

edit retag flag offensive close merge delete

Comments

Also, empty your lost+found/

NuuN gravatar imageNuuN ( 2015-07-10 10:48:13 -0600 )edit

Yes! There should never be anything in there as it's just a place to store inodes that have been recovered. Also, give us the results of this command: df -h /boot because it's possible that /boot isn't big enough for what you need. Last, what are all those files with .hmac doing there except for wasting needed space?

sideburns gravatar imagesideburns ( 2015-07-10 13:29:31 -0600 )edit

Just noticing that the config for 3.19.4 kernels are still around. Delete those. Finis!

NuuN gravatar imageNuuN ( 2015-07-10 16:24:54 -0600 )edit

5 Answers

Sort by ยป oldest newest most voted
2

answered 2015-07-10 18:04:22 -0600

mclmmc gravatar image

My 2c

edit yum.conf and set the installonly_limit to 1

installonly_limit=1

try distro synchronization, or add a small package. should delete old kernel leaving only one, in addition to the current one

in any case it will be useful for the next distro upgrade.

edit flag offensive delete link more
0

answered 2015-07-10 09:25:13 -0600

cobra gravatar image

How did you remove the old kernel packages? Did you use yum or dnf to do it? Hand-deleting the kernel binaries from /boot is a bit hit and miss.

You do seem to have at least bits of two Fedora 21 kernels installed, and as long as you have one that works, you'll have a recovery mode for your system if the upgrade stutters.

Boot up using the latest F21 kernel and try removing the oldest kernel with

yum remove kernel-3.19.4-200*

then retry the upgrade

edit flag offensive delete link more
0

answered 2015-07-13 11:58:19 -0600

pcaviede gravatar image

Hi CObra I've always upgraded with yum. Don't know why those files from the 3.19.4-200 version of kernel are still there. I normally delete the old packages with the yum remove option, leaving the current one.

df -H /boot gives: Filesystem Size Used Avail Use% Mounted on /dev/sda1 195M 111M 74M 61% /boot

Looking forward to your feedback!

edit flag offensive delete link more
0

answered 2015-07-13 12:07:23 -0600

pcaviede gravatar image

HI

df -H /boot is: Filesystem Size Used Avail Use% Mounted on /dev/sda1 195M 111M 74M 60% /boot

edit flag offensive delete link more
0

answered 2015-07-13 11:44:27 -0600

pcaviede gravatar image

Hi CObra I've always upgraded with yum. Don't know why those files from the 3.19.4-200 version of kernel are still there. I normally delete the old packages with the yum remove option, leaving the current one.

df -H /boot gives: Filesystem Size Used Avail Use% Mounted on /dev/sda1 195M 111M 74M 61% /boot

Looking forward to your feedback!

edit flag offensive delete link more

Comments

One problem is that /boot is way, way too small; in fact, I'm astonished that anaconda allowed you to set it so small. it really needs to be about 500 MB at the smallest.

sideburns gravatar imagesideburns ( 2015-07-13 12:19:28 -0600 )edit

I began to realize that when it couldn't even hold two kernel packages. It was the default size of the F21 installation procedure. Way too small, indeed. Problem is: How to resize the /boot partition now? I've read about resizing with Gparted booting from a CD with the ISO image... but... what about data loss?

pcaviede gravatar imagepcaviede ( 2015-07-13 12:36:55 -0600 )edit

Before you start, of course, back up everything that's now in /boot. Gparted knows how to enlarge and shrink partitions without data loss, but there's no reason not to be careful. Depending on your partition layout, you may need to shrink whatever partition comes next, probably by cutting some off the high end, then moving what's left over to leave room. I know that it sounds scary, but it's better than a reformat and reinstall.

sideburns gravatar imagesideburns ( 2015-07-13 13:07:08 -0600 )edit

I just have two partitions. The /boot (sda1) and the rest is the LVM (sda2). Here is the fidsk readout:

Disk /dev/sda: 465.8 GiB, 500107862016 bytes, 976773168 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x000261fa

Device Boot Start End Sectors Size Id Type /dev/sda1 * 63 401624 401562 196.1M 83 Linux /dev/sda2 401625 976768064 976366440 465.6G 8e Linux LVM

Disk /dev/mapper/VolGroup00-LogVol01: 8 GiB, 8589934592 byt

pcaviede gravatar imagepcaviede ( 2015-07-13 13:17:47 -0600 )edit

I don't use LVM, so I can't advise you on how to shrink it, but I'm sure that many other people here can.

sideburns gravatar imagesideburns ( 2015-07-13 13:45:48 -0600 )edit

Question Tools

1 follower

Stats

Asked: 2015-07-10 09:01:57 -0600

Seen: 1,029 times

Last updated: Jul 10 '15