Re: How to relocate LVM pv to make room for grub install
On 01/02/2018 11:14 AM, Pascal Hambourg wrote:
> Le 02/01/2018 à 00:56, Tom Dial a écrit :
>>
>>> Which is the boot disk ?
>>
>> /dev/sda
>
> Then you didn't need to make room for GRUB on /dev/sdb.
>
>> So maybe the right plan is
>
> This is one of the many possible plans.
But it is uncomplicated and simple to execute using available or easily
obtained tools. The total outage time was around 2 hours and, as pointed
out below, could have been much less if I had moved only the partitions
on the current boot disk.
>
>> 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
>
> Actually only /dev/sda1, which must not be in used, i.e. no LV having
> extents in it must be active.
I realized that part way through, but pushed on for consistency, and
with a half-formed and unresearched notion of installing grub on the
second disk as well.
What I did not know until finishing is that gparted would, without being
told, leave the first 2048 blocks vacant. So I told it explicitly to
leave 1M empty at the beginning, so the first partitions now actually
begin at block 4096.
>
>> 3. reboot using the old grub, kernel, initrd, etc.
>> 4. restore the new (stretch) /boot/grub/*
>
> No need to restore the new /boot/grub/*, grub-install will recreate it.
Another thing I did not know, then.
>
>> 5. run grub-install to install the new grub
>> 6. reboot and finish the stretch upgrade.
Overall, it went fairly well, and in particular, there were no boot
issues or data corruption. The only issue is that the first partition on
the boot drive was resized, but the PV it contains apparently was not,
so now is larger than the partition. I suspect this happened because the
PV was fully allocated to LVs. It has not caused any apparent problems,
probably because the file systems on the LVs are not very full. I will
need to fix it, though.
Thanks again.
Tom Dial
Reply to: