I am attempting to increase the partition size of '/boot' (recent update put strain on the current ~250 MB partition) but running into problems as GParted (when run from a LiveCD) will not recognize my HDD.

This is odd considering that 'fdisk -l' does. I have tried unmounting and remounting the HDD, to no avail. Also, I have played around with the SATA setup in boot options (RAID and AHCI), but this does not appear to help either (AHCI is my default setting for SATA).

I am not sure if the fact that if the file system of this drive (ext3/ext4) is part of the problem or what, but any help would be appreciated.

  • Have you tried the drop-down menu on the right side of the toolbar which lets you choose your device? – spacelander Jan 21 '16 at 12:48
  • 250MB should however be more than sufficient for /boot? how did you manage to fill it? – spacelander Jan 21 '16 at 12:50
  • @spacelander, yeah I tried this, and I can see other devices such as another USB when I plug it in. I have found that 300MB-500MB is now being considered the recommended /boot partition size for future versions of linux. I made sure to remove all previous linux-images as well before going through this hassle and will try and strip it down even further, but instead of dealing with this problem later I wanted to try and solve it now. – puzzleHead Jan 21 '16 at 13:30
  • Does fdisk or gdisk complain about corrupted partition table? – spacelander Jan 21 '16 at 13:40
  • fdisk output is: (textuploader.com/5zfri) and gdisk output is: (textuploader.com/5zfrw). Both of which seem sensible, though I am admittedly not that familiar with output int terms of gdisk to say that, it may be the source of the problem. – puzzleHead Jan 21 '16 at 14:11

This problem started with the need to increase my /boot partition to make way for a rather large Ubuntu security update (4.2.0-25, meant to address the key ring exploit) which called for 183 MB free space.

This was inordinately large, as far as software updates go, especially for users that have /boot separately partitioned (where 250 MB is historically regarded as more than enough space). Beyond removing old kernel images (as is the first step when it comes to cleaning /boot out) I had to also remove a .old-dkms-backup file (which a first made sure to backup), which thankfully freed up enough space. However, the fact that these newer kernel images (for 4.2. at least) are nearly twice the size (35 MB compared to 20 MB) of their 3.13 counterparts means that for those installing newer Linux kernels (4.2 and onward) may want to set aside ~ 500 MB for their /boot partitions to avoid this problem.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.