wipefs doesn't completely wipe zfs filesystem

[omkhar]

wipefs doesn't seem to wipe all the zfs filesystem bits from the disk.

1. Install Ubuntu Linux 20.04 /w zfs
2. Install Clear Linux 3004 /w defaults (destructive install) - Clear Linux install will fail
3. Run wipefs -a /dev/hda
4. Install Clear Linux 3004 /w defaults (destructive install) - Clear Linux install will fail
5. Run dd if=/dev/zero of=/dev/sda bs=1G
6. Install Clear Linux 3004 /w defaults (destructive install) - Clear Linux install will succeed

Further details and logs here: clearlinux/clr-installer#753

[karelzak]

What does it mean "does not completely wipe"?

man wipefs:

       wipefs can erase filesystem, raid or partition-table signatures (magic strings) from the specified device to make
       the signatures invisible for libblkid.  wipefs does not erase the filesystem itself nor any other data  from  the
       device.

It does not zeroize the device. The goal is to remove all stuff that is relevant for libblkid (blkid) to detect the FS, but nothing more.

[omkhar]

zfs leaves some additional metadata on the disk which seems to be causing an issue. Am I wrong in assuming that wipefs should wipe all traces of a zfs filesystem?

…

--oa

On Tue, Jan 5, 2021 at 8:55 AM Karel Zak ***@***.***> wrote: What does it mean "does not completely wipe"? man wipefs: wipefs can erase filesystem, raid or partition-table signatures (magic strings) from the specified device to make the signatures invisible for libblkid. wipefs does not erase the filesystem itself nor any other data from the device. It does not zeroize the device. The goal is to remove all stuff that is relevant for libblkid (blkid) to detect the FS, but nothing more. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1228 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFM52KSVEG5EUH6N3YOBCYDSYMK5BANCNFSM4VSFTZSA> .

[karelzak]

It wipes all traces which is libblkid able and want to detect :-)

libblkid need to optimize how it scans the device to avoid overhead. Unfortunately, ZFS is extremely variable with root block(s) locations. Now libblkid detects the 4 uberblocks to get a positive match.

Maybe we can extend the current behavior if BLKID_SUBLKS_MAGIC flags specified (used by wipefs) to read more locations. I'll add this to our TODO.

Anyway, for installers, it's probably a good idea to use dd(1) to wipe the first few MiBs from the beginning and the end of the device. I would recommend wipefs(8) as the second step to be sure that there is not remaining anything detectable on the device for udev.

[Nottt]

I'm still having this issue. and I don't know what to do? It's a big disk I don't want to rewrite everything. I tried wiping 1 MB of the end of the disk too and lsblk still detects it

[t-8ch]

@Nottt
Could you provide a concrete test protocol to reproduce the issue?

And/or provide blkid and wipefs logs with LIBBLKID_DEBUG=all?