Univention Bugzilla – Bug 48154
Automatic partitioning in debian installer not possible if LVM already exists
Last modified: 2021-05-14 16:37:59 CEST
A customer reported, that the guided partitioning could not be completed during system setup. He received the following message: "Vermutlich ist die ausgewählte Festplatte oder der ausgewählte freie Speicher nicht groß genug, um automatisch partitioniert zu werden" ------------------------------------------------------------------------------- "Probably the selected hard disk or free space is not large enough to be automatically partitioned." However, he was able to partition the hard disk manually. A workaround is to completely repartition the disk, including a new partition layout. In addition; there was definitely an old LVM on the hard disk before, but the customer deleted and recreated it during the installation process.
This happend multiple times now and I once tried to analyze it on the customer site. It looks like some previous LVM setup is found and activated BEFORE the partitioning starts. Then the D-I parman modules re-partition the disk and setups the new LVM, which fails as the previous LVM was not deactivated properly. The referenced ticket shows a VG named "root", while the UCS installer uses "vg_ucs" by default. So far I was not able to reproduce this bug by installing UCS on a pre-partitioned disk.
(In reply to Philipp Hahn from comment #1) > So far I was not able to reproduce this bug by installing UCS on a > pre-partitioned disk. Clarification: I was not able to find the *triggering* LVM condition, that is I do not know what is required to make partman fail: - If I try it with a VM, were UCS was previously installed, installing UCS again works. - I also tried it with a different VG name. The fix / work-around is to wipe any PVs and partitions by hand once and then to re-run D-I partman.
(In reply to Philipp Hahn from comment #2) > (In reply to Philipp Hahn from comment #1) > > So far I was not able to reproduce this bug by installing UCS on a > > pre-partitioned disk. > > Clarification: I was not able to find the *triggering* LVM condition, that > is I do not know what is required to make partman fail: > - If I try it with a VM, were UCS was previously installed, installing UCS > again works. > - I also tried it with a different VG name. > > The fix / work-around is to wipe any PVs and partitions by hand once and > then to re-run D-I partman. Can "d-i partman/early_command string" be used to wipe any PVs and partitions?
Philipp, if I remember correctly, you've further analyzed that on the customer systems, right?
(In reply to Stefan Gohmann from comment #4) > Philipp, if I remember correctly, you've further analyzed that on the > customer systems, right? Yes, I tried to reproduce it, but never succeeded - only seen so far at customer 00026, at least two times. (In reply to Stefan Gohmann from comment #3) > Can "d-i partman/early_command string" be used to wipe any PVs and > partitions? This is Debian Bug #740271: <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=740271#40>, which is what the customer uses as a work-around: > d-i partman/early_command string for lv in $(lvdisplay | grep "LV Name" | cut -d" " -f 20); do lvremove -f $lv;done; for vg in $(vgdisplay | grep "VG Name" | cut -d" " -f 19); do vgremove -f $vg;done; for pv in $(pvdisplay | grep "PV Name" | cut -d" " -f 19); do pvremove -y -ff $pv;done It can be simplified to > partman/early_command string swapoff -a;for pv in $(pvs --noheadings -o pv_name);do pvremove -y -ff "$pv";done
This issue has been filed against UCS 4.3. UCS 4.3 is out of maintenance and many UCS components have changed in later releases. Thus, this issue is now being closed. If this issue still occurs in newer UCS versions, please use "Clone this bug" or reopen it and update the UCS version. In this case please provide detailed information on how this issue is affecting you.