Closed BigAl closed 3 years ago
See PR https://github.com/picodotdev/alis/pull/133 fro possible solution
The objective with this function was to allow a reinstall on same disk, when alis fails and is rexecuted (partitions can be mounted) or booting from a power off system (partitions will not be mounted).
I changed the prepare_partition function so umounts dont fail checking mounts properly with mountpoint, if this is enough for you?.
https://github.com/picodotdev/alis/commit/d40ce427c9d55747ec00c2330ba49f65d19abc13
With the PARTITION_MODE set to auto if the LVM volumes (logical, group and physical) exist should not be a problem as the disk will be wiped (but I dont know if this works completely as expected). https://github.com/picodotdev/alis/blob/ae3876df828e26e414ab1356851a2c0f8dcde59e/alis.sh#L539
So the issue with sgdisk --zap-all $DEVICE
is that because the boot kernel has already read in the VG and LV it does not accept this and you need to do a reboot to read in the new partition table in memory. Not a showstopper but I wasn't even getting this far as it would bail after failing to umount the disk that was not mounted.
Now with an understanding of the intent of the function I can see why you would not want to do what I did. My case is certainly and edge case it will only pop up when trying to reinstall over and existing working install.
I have given it a rerun with the recent update and pvcreate fails
Can't initialize physical volume "/dev/sda2" of volume group "vg" with -ff
presumable this is due to the fact the previous pv still exists. I'll need to take a look at the logs to see what I can figure out.
Looked at the LOG and yes you still need to do a lvremove
and vgremove
I'm pretty sure this is because they are still in the boot kernel memory probably.
I think adding the lvremove
and vgremovesomewhere in that block with
sgdisk --zap-all $DEVICE` will do the trick.
You were right.
I did testing using LVM on LUKS not only LVM, in the former case the behavior was different, no necessary to remove LVM volumes, with only deactivate LVM volumes and close LUKS seems was enough.
Now I hope this edge case but possible is working as expected.
I did the (lv|vg|pv)remove before creating LVM volumes, I want that data destructive operations and partitions changes to be only in partition function not also in prepare_partition.
Cool only did the LUKS setup once myself.
Did a run through now and no more issue for me now. Thanks
This is slightly tricky as I'm always ware of messing with disks. However if I do a reinstall on a previous system that already had an lvm setup the
umount
command on this line fails https://github.com/picodotdev/alis/blob/6966bb3c7052c6dd69f5fa753cdcbe2e62c9c28c/alis.sh#L349This would be expected as the filesystem should not and is not mounted. Howvever the boot kernel on the install disk has found and dejected and existing Volume Group
If think what needs/should be done here is to remove the logical volume and and remove the volume group
No need to umount the disk.