12

I have seen the answers to the general question regarding resizing the boot partition. In my case, I have installed Ubuntu 12.04 Alternate with full disk encryption. Since the drive can not be mounted during the resize operation, won't this corrupt the main partition?

I have everything backed up so I could potentially do a re-install, but I do not know how to specify the boot partition size prior to encryption.

3

I know this question is old, but comes up when searching for the small boot partition problem and using disk encryption.

Ubuntu installer ubiquity uses partman for partitioning. When "Use the entire disk" option is selected, the partition configurations come from partman recipe files in /lib/partman/recipes-[arch]/* and /lib/partman/recipes/* on the live CD. Find the recipe used by the installer, and modify the maximum size for /boot partition. On my system, the default recipe used is /lib/partman/recipes/30atomic. Open the Terminal:

ubuntu@ubuntu:~$ sudo nano /lib/partman/recipes/30atomic

Go to the section for the boot partition and change the third number (256 below) to the size you want (I'd recommend at least 512):

128 512 256 ext2
    $defaultignore{ }
    method{ format }
    format{ }
    use_filesystem{ }
    filesystem{ ext2 }
    mountpoint{ /boot }

This section says size is going to be between 128M and 256M with a priority of 512, which determines how important the size of this partition with respect to others.

Save it with Ctrl+O, Enter. Then start the installer, install as usual.

2

I assume by full disk encryption, you mean having a small unencrypted boot partition and another partition which is a physical volume for encryption (dm-crypt). If there isn't any space in between them, you won't be able to non-destructively resize the encrypted partition to create more space for /boot.

Take a look at my answer here - this might help.

0

Yes, resizing boot is possible but it is very complicated. I would only attempt this after backing up ALL your data. If you make a mistake the potential for data loss is quite high. You will want to have some bootable Ubuntu live USB/CD ready as you should be performing these operations after booting to a live USB/CD.

I found out the hard way a while back when the linux community change the requirements regarding the required size of the boot partition. Previously, 100-200 MB was sufficient for boot but then the community doubled its size requirements. This impacted users who were following the previous guidelines.

https://serverfault.com/questions/334663/what-is-the-recommended-size-for-a-linux-boot-partition

For current requirements for /boot I would refer you to the official guidelines.

https://help.ubuntu.com/community/DiskSpace

At the time of this writing the guidelines recommend /boot from 250MB to 1GB of space. I would recommend a separate boot partition with the largest required space. The boot partition needs to be unencrypted during the boot process. The boot process will be mounting different encrypted partitions along the way for example LUKS encrypted disks or encrypted HOME directories and there are difference between these approaches. In my experience, using the various Ubuntu hard disk encryption options tends to result in problems when upgrading Ubuntu later on requiring manual intervention.

For a general overview, I will referred you to this article I consider well written.

'LUKS encrypting multiple partitions on Debian/Ubuntu with a single passphrase'

https://www.martineve.com/2012/11/02/luks-encrypting-multiple-partitions-on-debianubuntu-with-a-single-passphrase/

When you find the need to change your partitions, I found this post very helpful.

'How to Resize a LUKS Encrypted File System'

https://ubuntuforums.org/showthread.php?t=726724

Now because gparted does not support moving encrypted LUKS partitions this can not be done using gparted commands from the command line nor the GUI. I have found that you can use gparted to create partitions and then use dd to move your encrypted partitions around using sector by sector copies. This does involve being able to compute partion sizes in terms of sectors. Making a mistake means data loss and a re-install.

In my case, I need to increase the size of my boot partion from 537MB to 1GB. I need this as part of my upgrade from Ubuntu 12.04 to 14.04 so that the Ubuntu upgrade could find enough space on /boot. Yes, you can remove autoremove to free up space in /boot but the general requirements had changed so I was enlarging boot to adjust to those guidelines as well. Here was my partition layout.

Partition Table: gpt

Number  Start   End    Size   File system  Name  Flags
 1      1049kB  538MB  537MB  fat32              boot
 2      538MB   794MB  256MB  ext2
 3      794MB   240GB  239GB

I have the LUKS encrypted disk in partion #3 and my boot in partition #1 so there was not enough space to extend /boot. Note Gparted cannot move partition #3 as it is an encrypted partition. To fix this I created a fourth partion at the end of my disk of the same size in sectors and used dd to copy the contents of partition #3 to partition #4. I found it useful to resize my root to the minimum size necessary. Thus, I performed the following operations to address the size of my /boot.

  1. Shrunk the root filesystem in #3 partition
  2. Resized the #3 partition (to be smaller)
  3. Created a #4 partition of the same size (at the end of the disk)
  4. Used DD to copy the sectors of the #3 partition to the #4 partition
  5. Deleted the #3 partition to free up space on the disk
  6. Used Gparted to resize and move the #1 and #2 partitions
  7. Created a new #3 partion of the same size as the shrunk #3 (or #4 partition)
  8. Used DD to copy the sectors of the #4 partition to the #3 partition
  9. Delete the #4 partition
  10. Expand the size of the #3 partion to the original #3 size
  11. Updated the filesystem contained in the #3 encrypted partition to remaining space

This way I could delete partition #3 and use gparted to move and enlarge partitions #1 and #2. Reading through the guides above should provide enough insight to navigate your way forward. It is not shown here but in shrinking my root partition, I deleted a swap volume group on the same partition and recreated it at the end. All of this is being done while booted to a Linux Live USB flash drive. The following are a few of my notes that were not readily available in the guides above.

I found blockdev useful in displaying the size of partitions in sectors. This help me as I was calculating sector sizes.

sudo blockdev --getsize /dev/mapper/isw_dcgdihhid_SSD_CRUCIAL_M500p2
499712

The Gparted command 'unit s' will display your partition table in sectors. All of the partition sizing, deletion, and creation is done using Gparted. This way you can just do all of the math in sectors. The 'unit compact' will switch back to MB/GB format, if you want see what the sector math looks like.

(parted) unit s
(parted) p                                                                
Model: Linux device-mapper (mirror) (dm)
Disk /dev/mapper/isw_dcgdihhid_SSD_CRUCIAL_M500: 468857096s
Sector size (logical/physical): 512B/4096B
Partition Table: gpt

Number  Start     End         Size        File system  Name  Flags
 1      2048s     1050623s    1048576s    fat32              boot
 2      1050624s  1550335s    499712s     ext2
 3      1550336s  456656896s  455106561s

The resize2fs command has a nifty option to resize to the Minimum. Also, I deleted my swap volume group during this part.

ubuntu@ubuntu:~$ sudo resize2fs -M -p /dev/ubuntu-vg/root
resize2fs 1.42.9 (4-Feb-2014)
Resizing the filesystem on /dev/ubuntu-vg/root to 2261211 (4k) blocks.
Begin pass 3 (max = 1600)
Scanning inode table          XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
The filesystem on /dev/ubuntu-vg/root is now 2260992 blocks long.

When you resize partition tables go back and update gparted. Used 4096 * 2260992 and then blockdev to check the math here. Here is the gparted command.

(parted) resizepart 3
End?  [224419843s]? 225970179s 
Warning: Shrinking a partition can cause data loss, are you sure you want to continue?
Yes/No? yes                                                               
Device /dev/mapper/isw_dcgdihhid_SSD_CRUCIAL_M500p3 not found
device-mapper: table ioctl on  failed: No such device or address
(parted) p                                                                
Model: Linux device-mapper (mirror) (dm)
Disk /dev/mapper/isw_dcgdihhid_SSD_CRUCIAL_M500: 468857096s
Sector size (logical/physical): 512B/4096B
Partition Table: gpt

Number  Start     End         Size        File system  Name  Flags
 1      2048s     1050623s    1048576s    fat32              boot
 2      1050624s  1550335s    499712s     ext2
 3      1550336s  225970179s  224419844s

Note the sector count size of partition #3 is smaller than my original listing i.e. This way you can use gparted to create the #4 partition in advance of the DD copy. The shrinking frees up more disk space for that copy.

ubuntu@ubuntu:~$ sudo dd if=/dev/mapper/isw_dcgdihhid_SSD_CRUCIAL_M500 of=/dev/mapper/isw_dcgdihhid_SSD_CRUCIAL_M500 bs=512 skip=1550336 count=224419844 seek=244437218
224419844+0 records in
224419844+0 records out
114902960128 bytes (115 GB) copied, 2146.1 s, 53.5 MB/s

After the DD copy, go ahead and enlarge the size of your /boot partition. You will delete the original #3 partion and then re-created partition #3 at a new sector location after the enlarged #1 and #2 partitions. Again blockdev was used to measure sector sizes. I created this #3 partition as the same size as #4 partition which is smaller than #3 was originally. Use DD to copy the #4 sectors to #3 partition.

ubuntu@ubuntu:~$ sudo dd if=/dev/mapper/isw_dcgdihhid_SSD_CRUCIAL_M500 of=/dev/mapper/isw_dcgdihhid_SSD_CRUCIAL_M500 bs=512 skip=244437218 count=224419844 seek=9242624

After copying, delete the #4 partition and expand the size of the #3 partition. In my case, I just restored to the #3 partion to size it was when I started. I had enough space to do this.

(parted) resizepart 3                                                     
End?  [464349185s]? 464349184s                                           
Warning: Shrinking a partition can cause data loss, are you sure you want to continue?
Yes/No? y                                                                 
Device /dev/mapper/isw_dcgdihhid_SSD_CRUCIAL_M500p3 not found
device-mapper: table ioctl on  failed: No such device or address
(parted) p                                                                
Model: Linux device-mapper (mirror) (dm)
Disk /dev/mapper/isw_dcgdihhid_SSD_CRUCIAL_M500: 468857096s
Sector size (logical/physical): 512B/4096B
Partition Table: gpt

Number  Start     End         Size        File system  Name  Flags
 1      2048s     4192255s    4190208s    fat32              boot
 2      5146624s  9242623s    4096000s    ext2
 3      9242624s  464349184s  455106561s

When gparted increased the partition size it does not update the filesystem. Note the filesystem is contained inside the encrypted partition so it has to be opened and mounted to make this change. Use the following command to fix this. This can be done on the live system if necessary.

user@zagyg:/$ sudo resize2fs /dev/ubuntu-vg/root
resize2fs 1.42.9 (4-Feb-2014)
Filesystem at /dev/ubuntu-vg/root is mounted on /; on-line resizing required
old_desc_blocks = 1, new_desc_blocks = 13
The filesystem on /dev/ubuntu-vg/root is now 54266880 blocks long.

In conclusion, while Gparted does not support his operation natively but it is an incredible useful tool for managing partitions. In my opinion is a little more useful than fdisk. Between Gparted and DD I was able to manage my partitions and then just use the Ubuntu tools to upgrade from 12.04 LTS to 14.04 LTS.

  • Boot partition does not have to be unencrypted. I do not have a separate /boot partition, it is just part of my main encrypted rootfs. Grub can boot in such configuration just fine. II boot from my 1 MiB EFI partition. And while resizing /boot takes roughly these steps, there is no need to do them manually. You can just use KDE Partition Manager 3.0 to perform all these steps. E.g. I perform some operations here on my encrypted rootfs from inside the system without even using live cd youtube.com/watch?v=FKCQ7pJN1vY Although live cd is necessary to move luks partition. – Andrius Štikonas Jan 6 '17 at 16:33

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.