picodotdev / alis

Arch Linux Install Script (or alis, also known as the Arch Linux executable installation guide and wiki) installs an unattended, automated and customized Arch Linux system.
https://picodotdev.github.io/alis/
GNU General Public License v3.0
823 stars 319 forks source link

Failure if an existing lvm is found #132

Closed BigAl closed 3 years ago

BigAl commented 3 years ago

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#L349

This 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

        lvremove "/dev/$LVM_VOLUME_GROUP/$LVM_VOLUME_LOGICAL"
        vgremove "/dev/$LVM_VOLUME_GROUP"

No need to umount the disk.

BigAl commented 3 years ago

See PR https://github.com/picodotdev/alis/pull/133 fro possible solution

picodotdev commented 3 years ago

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

BigAl commented 3 years ago

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.

BigAl commented 3 years ago

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 withsgdisk --zap-all $DEVICE` will do the trick.

picodotdev commented 3 years ago

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.

BigAl commented 3 years ago

Cool only did the LUKS setup once myself.

Did a run through now and no more issue for me now. Thanks