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 commit cf01ec9257)
mr10.0
parent
6b4a46435e
commit
c354c120b2
Loading…
Reference in new issue