How to relocate LVM pv to make room for grub install
Upgrading a workstation from Jessie to Stretch I found that the original
disk partitioning left insufficient space for grub (re)install. The
system has two identical ~233 GiB disks, sda and sdb, partitioned
identically:
Disk /dev/sda: 232.9 GiB, 250059350016 bytes, 488397168 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: 0x00015e37
Device Boot Start End Sectors Size Id Type
/dev/sda1 * 63 122077934 122077872 58.2G 8e Linux LVM
/dev/sda2 122077935 244155869 122077935 58.2G 8e Linux LVM
/dev/sda3 244155870 366233804 122077935 58.2G 8e Linux LVM
/dev/sda4 366233805 488392064 122158260 58.3G 8e Linux LVM
sda1 and sdb2 form a volume group with active LVs containing OS and
data; sdb1 underpins a vg containing additional data. The other
partitions, sda2-sda4 and sdb3-sdb4, are not used at present, but are
configured as lvm physical volumes. Gparted is installed and I used it
to move these partitions toward the end of the disks, so that the maps
now are:
Device Boot Start End Sectors Size Id Type
/dev/sdb1 63 122077934 122077872 58.2G 8e Linux LVM
/dev/sdb2 122077935 244155869 122077935 58.2G 8e Linux LVM
*gap 244155870 244162559 6690 3.2M
/dev/sdb3 244162560 366239743 122077184 58.2G 8e Linux LVM
/dev/sdb4 366239744 488397167 122157424 58.3G 8e Linux LVM
and
Device Boot Start End Sectors Size Id Type
/dev/sda1 * 63 122077934 122077872 58.2G 8e Linux LVM
*gap 122077935 122085375 7441 3.6M
/dev/sda2 122085376 244162559 122077184 58.2G 8e Linux LVM
/dev/sda3 244162560 366239743 122077184 58.2G 8e Linux LVM
/dev/sda4 366239744 488397167 122157424 58.3G 8e Linux LVM
If I understand correctly, I should now be able to boot with a rescue
disk or USB key that has lvm, and move sdb2, sdb1, and sda1 similarly,
leaving several megabytes free at the beginning of each disk.
I haven't needed to do anything like this for quite a while and would be
grateful for corrections and suggestions to reduce risk, false starts,
and rework.
Specific questions addressed to anyone who knows:
1. the core.img file is 31952 bytes, apparently 208 bytes too long. Is
there a way to shorten it by that much without sacrificing the
capability to boot from an lvm logical volume and jfs file systems?
2. The grub install failed. The current modified grub.cfg was not
changed materially and references most objects by uuid. If I shut down
and move the necessary partitions, is the system likely to boot
successfully using the (hopefully unchanged) original grub installation,
so that I could simply move the pv partitions, reboot normally, run
grub-install, and then continue upgrading?
3. The problem occurred at the end of "apt upgrade." The necessary grub
commands appear to be in the current (although updated) grub.cfg.
Failing a successful normal boot, is it likely that I can boot the
system from a grub rescue device once the partitions are moved and
simply continue the upgrade from that point?
4. Any other suggestions thought useful are welcome.
I have file system backups from before the interrupted update and,
before I can see any possible responses, also will have a backup of the
current state of all file systems. The system appears to be running
normally and I do not plan to shut it down before finalizing a recovery
plan.
Thanks in advance,
Tom Dial
Reply to: