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.
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.
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.
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'
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.
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.
