© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
1b1ed1a
(Get the code!)
I experienced the same problem on a System running 15.04. I know that's EOL, but just for reference this is how I ended up in this situation:
My system is a server (Supermicro SYS-6028R-WTRT, latest firmware) with a 4TB RAID1 for the OS, and another RAID volume for data. The system supports legacy and UEFI boot, but due to the disk size involved I disabled legacy or "dual mode" booting and forced the system to UEFI only so that the installer would dtrt on an EFI system.
I used MAAS to install it. MAAS (or, the preseeds that ship with it) created a 4TB root fs (cloudimg-rootfs) and an EFI partition.
That is the fundamental issue here: grub cannot deal with files outside the 2TB limit it seems. I tried to manually load the initrd, and got a similar error message.
So I started using the rescue boot provided by the Ubuntu Server install ISO to repartition.
In the end, I created separate LVM logical volumes on the second RAID, moved /usr /var /home to separate filesystems in LVM, and eventually reduced the space consumed by the rootfs to a manageable size.
I created another LV for the root filesystem and one for swap (the MAAS install used /swap.img on the root fs...)
Then I copied all the directories from the root partition (/bin, /sbin, /lib etc) to that new filesystem.
After editing fstab in the new root, and rebooting with the rescue image using the new LV as root FS, I was able to delete my /dev/sda1, recreate it with ~1.5TB of space, and moved everything that was in /boot on the root filesystem over there.
Summary: I made sure that grub, kernel etc live in an area of the disk that grub can access.
After repartitioning, I did update-grub, reinstalled the kernel just to be sure, and rebooted - the system now boots fine again.
My suggestion is to still create a ~1GB /boot partition even on EFI systems. And in case the installer still defaults to ~256M in case of legacy systems, that should get fixed as well if the disk is large enough - autoremoving old kernels was only fixed recently :)