Le 03/01/2018 à 09:10, Tom Dial a écrit :
On 01/02/2018 11:14 AM, Pascal Hambourg wrote: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.
IMO, moving partitions is complicated, tedious, and dangerous. I avoid doing it as much as possible. Complicated because it requires running Gparted, in a graphic environment, without the partition being in use. Tedious because it requires moving (=reading and writing) each data block around, which can take a long time with big partitions. Dangerous because if anything interrupts the process before completion (system crash, power loss, or maybe even read/write error), the partition and its contents is lost.
This is why I suggested alternatives.
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.
This is not good. The partition should not have been reduced. If it had happened to a plain ext4 partition without reducing the filesystem first, the kernel would refust to mount it. You can try to resize the PV with pvresize, in hope that the missing extents were not allocated to any LV.
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.
If the PV was fully allocated, then I'm afraid you experience trouble sooner or later. You can check with pvdisplay.