/kind bug
What steps did you take and what happened:
I have the following disk layout for a disk in a Hetzner Bare Metal server :
|
|-- LVG
| |
| |-- Boot partition
| |
| |-- .... partition
| |
| |-- OS partition
|
....
The wipedisk script fails, when running in the context of that Hetzner Bare Metal server.
The script fails, trying to stop the RAID devices.
What did you expect to happen:
I expected the wipedisk script to run properly :).
Anything else you would like to add:
After investigating with @ashish1099, we found out that :
We need to first disable the LVM (Logical Volume Manager) using this command : vgchange -an. And then try stopping the RAID devices.
I'm attaching a snippet of an explanation by Claude :
While any LV in the VG is active, the dm devices are holders of the PV — they hold it open, which is exactly what makes mdadm --stop or wipefs on the layer below fail with EBUSY. Deactivating the VG removes those dm mappings, so the PV (and the md device beneath it, and the partition beneath that) is no longer held open. That's the entire reason it appears in a teardown sequence: it's the step that unbusies the lower layers.
Environment:
- cluster-api-provider-hetzner version:
- Kubernetes version: (use
kubectl version)
- OS (e.g. from
/etc/os-release):
/kind bug
What steps did you take and what happened:
I have the following disk layout for a disk in a
Hetzner Bare Metalserver :The wipedisk script fails, when running in the context of that
Hetzner Bare Metalserver.The script fails, trying to stop the
RAIDdevices.What did you expect to happen:
I expected the wipedisk script to run properly :).
Anything else you would like to add:
After investigating with @ashish1099, we found out that :
I'm attaching a snippet of an explanation by
Claude:Environment:
kubectl version)/etc/os-release):