Bug 33494 - pvcreate fails, PV signature not removed with create_partitiontable - PXE profile based installation
pvcreate fails, PV signature not removed with create_partitiontable - PXE pro...
Status: RESOLVED WONTFIX
Product: UCS
Classification: Unclassified
Component: UCS Installer
UCS 3.2
amd64 Linux
: P5 normal (vote)
: UCS 3.x
Assigned To: Installer maintainers
:
Depends on: 18771 31925
Blocks:
  Show dependency treegraph
 
Reported: 2013-11-20 17:21 CET by Philipp Hahn
Modified: 2017-08-08 07:11 CEST (History)
4 users (show)

See Also:
What kind of report is it?: ---
What type of bug is this?: ---
Who will be affected by this bug?: ---
How will those affected feel about the bug?: ---
User Pain:
Enterprise Customer affected?: Yes
School Customer affected?:
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number:
Bug group (optional):
Max CVSS v3 score:


Attachments
installer.log (47.86 KB, text/x-log)
2013-11-20 17:21 CET, Philipp Hahn
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Philipp Hahn univentionstaff 2013-11-20 17:21:19 CET
Created attachment 5665 [details]
installer.log

+++ This bug was initially created as a clone of Bug #31925 +++
My UCS-3.2 PXE installation on the PCs of our Schulungsraum suddenly started failing with the strange error message, that
  "mkdir /etc/ldap/slapd.conf"
failed, because the *file* already exists.

That is from /var/lib/dpkg/info/slapd.postinst:493
>        echo -n "  Creating initial configuration... " >&2
>
>        # Create the slapd.d directory.
>        rm -rf ${SLAPD_CONF}/cn=config ${SLAPD_CONF}/cn=config.ldif
>        mkdir -p ${SLAPD_CONF}
(IMHO an "mkdir" after the "rm" looks very strange)

The real cause for this is that the PCs were installed multiple times: 1st with MBR, which was then changed to GPT. On 3rd try the above mentioned error occurred.

Digging in installer.log shows that on all subsequent installs, where the HD still contains a valid GPT installation, the previous installation is not removed and a new installation if placed on the still existing file system still containing the previous installation.

$ grep ^'PARTITION-GPT:.*run_cmd' /tmp/installer.log
...
> PARTITION-GPT:1460: run_cmd(['/sbin/pvdisplay', '-c'])
> PARTITION-GPT:1460: run_cmd(['/sbin/vgdisplay'])
> PARTITION-GPT:1460: run_cmd(['/sbin/vgdisplay', '-c'])
> PARTITION-GPT:1460: run_cmd(['/sbin/lvdisplay', '-c'])
> PARTITION-GPT:1460: run_cmd(['/sbin/vgchange', '-ay'])

Here the old VG is visible

> PARTITION-GPT:1460: run_cmd(['/sbin/vgchange', '-an'])

and now no longer

> PARTITION-GPT:1460: run_cmd(['/sbin/parted', '-s', '/dev/sda', 'mklabel', 'gpt'])

so here an empty GPT is created

> PARTITION-GPT:1460: run_cmd(['/sbin/vgchange', '-ay'])

so here no VG can be found any longer

> PARTITION-GPT:1301: (profile) run_cmd(['/sbin/lvremove', '-f', 'vg_ucs'])
> PARTITION-GPT:1301: (profile) run_cmd(['/sbin/vgreduce', '-a', '--removemissing', 'vg_ucs'])
> PARTITION-GPT:1301: (profile) run_cmd(['/sbin/vgreduce', '-a', '--removemissing', 'vg_ucs'])

so these have no effect

> PARTITION-GPT:1301: (profile) run_cmd(['/sbin/parted', '--script', '/dev/sda', 'unit', 'B', 'mkpart', '"BIOS Boot Partition"', '16777216', '25165823'])
> PARTITION-GPT:1301: (profile) run_cmd(['/sbin/parted', '-s', '/dev/sda', 'set', '1', 'bios_grub', 'on'])
> PARTITION-GPT:1301: (profile) run_cmd(['/sbin/parted', '--script', '/dev/sda', 'unit', 'B', 'mkpart', '"/boot"', '25165824', '562036735'])
> PARTITION-GPT:1301: (profile) run_cmd(['/sbin/mkfs.ext4', '/dev/sda2'])
> PARTITION-GPT:1301: (profile) run_cmd(['/sbin/parted', '--script', '/dev/sda', 'unit', 'B', 'mkpart', '"linux-swap"', '562036736', '11299454975'])
> PARTITION-GPT:1301: (profile) run_cmd(['/bin/mkswap', '/dev/sda3'])
> PARTITION-GPT:1301: (profile) run_cmd(['/sbin/parted', '--script', '/dev/sda', 'unit', 'B', 'mkpart', '"LVMPV"', '11299454976', '499973619711'])
> PARTITION-GPT:1301: (profile) run_cmd(['/sbin/parted', '-s', '/dev/sda', 'set', '4', 'lvm', 'on'])

now the old PV is visible again

> PARTITION-GPT:1301: (profile) run_cmd(['/sbin/pvcreate', '/dev/sda4'])

and this fails since no "-ff" is given

> PARTITION-GPT:1301: (profile) run_cmd(['/sbin/vgcreate', '--physicalextentsize', '4096.0k', 'vg_ucs', '/dev/sda4'])
> PARTITION-GPT:1301: (profile) run_cmd(['/sbin/vgextend', 'vg_ucs', '/dev/sda4'])
> PARTITION-GPT:1301: (profile) run_cmd(['/sbin/lvcreate', '-l', '116508', '--name', 'rootfs', 'vg_ucs'])

these all error out because of previous errors: missing PV, VG, LVM, ...

> PARTITION-GPT:1301: (profile) run_cmd(['/sbin/mkfs.ext4', '/dev/sda2'])
> PARTITION-GPT:1301: (profile) run_cmd(['/bin/mkswap', '/dev/sda3'])

these run fine

> PARTITION-GPT:1301: (profile) run_cmd(['/sbin/mkfs.ext4', '/dev/vg_ucs/rootfs'])

but this fails and the installation continues on the old FS leading to an fatal error much later...


In interactive-mode install_fresh_gpt() (which does the "vgc -an ; empty_gpt ; vgc -ay" stuff) is run in the right sequence, but in profile-mode it is run before the old LVM is fully removed.

So currently "create_partitiontable" must be given for an untouched HD, but must not be used if the HD already contains a GPT+LVM.

Adding "-ff" to "pvcreate" might be also a good idea.


Exactly the same error has happened at a customer site (see original bug), were one blade was installed multiple times to get the profile and scripts right.
Comment 1 Philipp Hahn univentionstaff 2014-02-05 18:04:37 CET
again :-(
Comment 2 Stefan Gohmann univentionstaff 2017-06-16 20:40:46 CEST
This issue has been filed against UCS 3. UCS 3 is out of the normal maintenance and many UCS components have vastly changed in UCS 4.

If this issue is still valid, please change the version to a newer UCS version otherwise this issue will be automatically closed in the next weeks.
Comment 3 Florian Best univentionstaff 2017-06-28 14:52:54 CEST
There is a Customer ID set so I set the flag "Enterprise Customer affected".
Comment 4 Stefan Gohmann univentionstaff 2017-08-08 07:11:20 CEST
This issue has been filed against UCS 3.2.

UCS 3.2 is out of maintenance and many UCS components have vastly 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 this issue. In this case please provide detailed information on how this issue is affecting you.