Noticed while debugging the EFI situation, that wipefs calls might fail, like: | # wipefs -a /dev/nvme0n1 | wipefs: error: /dev/nvme0n1: probing initialization failed: Device or resource busy Using the force option, we *could* get past this error: | # wipefs -af /dev/nvme0n1 | /dev/nvme0n1: 8 bytes were erased at offset 0x00000200 (gpt): 45 46 49 20 50 41 52 54 | /dev/nvme0n1: 8 bytes were erased at offset 0x3a38b2de00 (gpt): 45 46 49 20 50 41 52 54 | /dev/nvme0n1: 2 bytes were erased at offset 0x000001fe (PMBR): 55 aa But quoting from wipe2fs(8): | -f, --force | Force erasure, even if the filesystem is mounted. This is required in order to erase a partition-table signature on a block device. So while this would work, there might be unexpected side effects. Instead let's use a different approach: if we remove the LVM signatures *before* running wipefs, it behaves as expected: | root@grml ~ # pvs | PV VG Fmt Attr PSize PFree | /dev/nvme0n1p3 ngcp lvm2 a-- <232.41g <222.41g | root@grml ~ # vgs | VG #PV #LV #SN Attr VSize VFree | ngcp 1 1 0 wz--n- <232.41g <222.41g | root@grml ~ # lvs | LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert | root ngcp -wi-a----- 10.00g | root@grml ~ # wipefs -a /dev/nvme0n1 | wipefs: error: /dev/nvme0n1: probing initialization failed: Device or resource busy | 1 root@grml ~ # vgremove -ff ngcp | Logical volume "root" successfully removed | Volume group "ngcp" successfully removed | root@grml ~ # pvremove /dev/nvme0n1p3 --force --force --yes | Labels on physical volume "/dev/nvme0n1p3" successfully wiped. | root@grml ~ # wipefs -a /dev/nvme0n1 | /dev/nvme0n1: 8 bytes were erased at offset 0x00000200 (gpt): 45 46 49 20 50 41 52 54 | /dev/nvme0n1: 8 bytes were erased at offset 0x3a38b2de00 (gpt): 45 46 49 20 50 41 52 54 | /dev/nvme0n1: 2 bytes were erased at offset 0x000001fe (PMBR): 55 aa | /dev/nvme0n1: calling ioctl to re-read partition table: Success FTR, when using wipefs' --force option, it still leaves behind the LVM signatures anyways: | root@grml ~ # pvs | PV VG Fmt Attr PSize PFree | /dev/nvme0n1p3 ngcp lvm2 a-- <232.41g <222.41g | root@grml ~ # vgs | VG #PV #LV #SN Attr VSize VFree | ngcp 1 1 0 wz--n- <232.41g <222.41g | root@grml ~ # lvs | LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert | root ngcp -wi-a----- 10.00g | root@grml ~ # wipefs -a /dev/nvme0n1 | wipefs: error: /dev/nvme0n1: probing initialization failed: Device or resource busy | 1 root@grml ~ # wipefs -af /dev/nvme0n1 | /dev/nvme0n1: 8 bytes were erased at offset 0x00000200 (gpt): 45 46 49 20 50 41 52 54 | /dev/nvme0n1: 8 bytes were erased at offset 0x3a38b2de00 (gpt): 45 46 49 20 50 41 52 54 | /dev/nvme0n1: 2 bytes were erased at offset 0x000001fe (PMBR): 55 aa | root@grml ~ # pvs | PV VG Fmt Attr PSize PFree | /dev/nvme0n1p3 ngcp lvm2 a-- <232.41g <222.41g | root@grml ~ # vgs | VG #PV #LV #SN Attr VSize VFree | ngcp 1 1 0 wz--n- <232.41g <222.41g | root@grml ~ # lvs | LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert | root ngcp -wi-a----- 10.00g So we'd still have to wipe the LVM signatures, while enabling wipefs' --force option could lead to unexpected behaviors. Verified with: | root@grml ~ # wipefs --version | wipefs from util-linux 2.36.1 | root@grml ~ # uname -a | Linux web01a 5.10.0-6-amd64 #1 SMP Debian 5.10.28-1 (2021-04-09) x86_64 GNU/Linux | root@grml ~ # lvm version | head -3 | LVM version: 2.03.11(2) (2021-01-08) | Library version: 1.02.175 (2021-01-08) | Driver version: 4.43.0 Change-Id: Ie4f7b2797d2dcfc27601792d6102a765e4c60c47 (cherry picked from commitmr10.0.1cf01ec9257) (cherry picked from commitc354c120b2)
parent
8760258c48
commit
70058f0fe9
Loading…
Reference in new issue