Re: How to relocate LVM pv to make room for grub install
On 01/01/2018 02:46 AM, Pascal Hambourg wrote:
> Le 01/01/2018 à 06:51, Tom Dial a écrit :
>> 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
>
> This partition table must have been created a long time ago. At the time
> of Jessie, current partitioning tools would have aligned partitions on
> 1-MiB boundaries instead of cylinder boundaries, leaving plenty of room
> for GRUB's core image.
Yes: March, 2008; Etch installed then, later upgraded successively to
Lenny, Squeeze, Wheezy, and Jessie without major difficulty.
>
>> 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.
>
> Do you mean that they are not part of any volume group ?
Correct.
>
>> 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
>
> Which is the boot disk ?
/dev/sda
>
>> 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.>
> LVM tools cannot move partitions. pvmove does not move PV, it just moves
> LV data between PVs. You need Gparted to move partitions (and their
> contents). Of course you need to run Gparted from a system which does
> not use the partitions to be moved.
Thanks for the correction. I might have caught the error, or might not.
>
>> 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?
>
> Hardly. The core image must include necessary modules to read
> /boot/grub, including the partition table, lvm and the filesystem. You
> could move /boot/grub to a new LV with another filesystem type requiring
> less space in the core image. Checking the modules sizes, jfs.mod is
> slightly bigger than ext2.mod (by 156 bytes so I'm afraid it would not
> be enough). Smaller modules are fat.ko and minix*.ko. I have never used
> Minix filesystem, but I know GRUB can be installed on FAT, even though
> it does nogt sound very satifactory.
>
> Other options :
>
> - Move /boot/grub to a non-LVM partition. But I am not sure that the
> free 3.6 MiB on your disks will be enough even with a light filesystem.
>
> - Install GRUB boot and core images in a btrfs non-LVM partition, which
> supports GRUB embedding, instead of in the MBR. However IME the minimum
> partition size for btrfs is at least 5 MiB (or 16 MiB, depending on
> btrfs tools version).
>
> - Convert the partition table to GPT with gdisk and create a "BIOS boot"
> partition which GRUB can use to write the core image. However since you
> moved partitions to the very end of the disk there is no room any more
> to write the backup GPT partition table.
>
>> 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?
>
> The current state is :
> - GRUB boot image and core image from Jessie in the MBR and gap
> - GRUB modules from Stretch in /boot/grub
>
> So I am afraid that the core image and modules won't match and GRUB may
> not boot properly, ending up in the rescue prompt. However it may work
> if the versions are close enough. GRUB versions in jessie and stretch
> are much closer than those in wheezy and jessie.
>
>> 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?
>
> Yes.
>
>>
>> 4. Any other suggestions thought useful are welcome.
>
> You can delete an unused PV, this will leave plenty of free disk space
> to set up any of the above options.
>
>> 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.
>
> You can restore Jessie's /boot/grub/ contents in order to boot without
> GRUB rescue.
So maybe the right plan is
0. make a grub-rescue CD just in case of need
1. restore the old (jessie) /boot/grub/*
2. shut down, move the remaining partitions with gparted
3. reboot using the old grub, kernel, initrd, etc.
4. restore the new (stretch) /boot/grub/*
5. run grub-install to install the new grub
6. reboot and finish the stretch upgrade.
Thank you very much for the quick, concise, and detailed answers.
Tom Dial
Reply to: