On Wednesday 23 December 2015 12:39:18 Anders Andersson wrote: > On Wed, Dec 23, 2015 at 9:52 AM, David Baron <d_ba...@012.net.il> wrote: > > On reboot (to old system or otherwise), the UUID of the target partition > > was CHANGED! > > Unlikely, how do you know? What would change them during a reboot?
When I resized the target partition, /dev/disk/by-uuid showed what I afterwards placed in fstab and lilo.conf. Today, a desperate try, placed the new fstab on the old root and rebooted. Root could not be mounted and the original mounted read-only (correct behavior in this case). I, of course, could not fix it this way. When I tried to remount it or mount the new root over it, got error that the uuid could not be found. listing the /dev/disk/by-uuid now showed a new uuid for the target partition. Mounted the new partition by /dev/sd..., placed the correct(ed) uuid in fstab and lilo.conf, went through the recommended procedure and voile. > > > If the problem was not hidden behind a screenfull of lvm errors, I > > would/should have seen that right away, huh? > > To my knowledge, lvm does not care about UUIDs. What were these errors? The lvm error on a functional boot up is once and spurious. This is a bug somewhere in the initramfs, I suppose. The repeated lvm error meant it could not find incorrectly uuid'd partition. I repeat, I am using no logical volumes. I did not notice the errant uuid as cited in the error messages. Might have indeed been but it did not catch my eye at the times.
