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