You just pulled an old desktop or a decommissioned server out of the closet, plugged in a USB stick with the Proxmox VE installer, and booted it up. Instead of a clean disk selection screen, you're staring at a warning about an existing ZFS pool, or the installer picks up a partition table from whatever ran on that box five years ago. Maybe it lets you install anyway, and then your new Proxmox host boots into a GRUB rescue prompt, or zpool status shows a phantom pool you never created.
None of that is a Proxmox bug. It's leftover disk metadata — old ZFS labels, LVM signatures, RAID superblocks, or a stale GPT table — sitting in places the installer and the Linux kernel both check automatically. This guide walks through clearing all of that out before you install, so the disk you hand to Proxmox VE is actually blank.
What You Will Learn
By the end of this tutorial you'll know how to identify which disks on a machine still carry old filesystem or RAID metadata, and how to remove each type safely: ZFS pool labels, LVM physical volume signatures, Linux RAID (mdadm) superblocks, and the partition table itself. You'll also see how to do this from inside the Proxmox installer's own debug shell, which matters if you're working on bare metal with no other OS handy.
What Is This Feature?
"Wiping" a disk in this context doesn't mean formatting it in the usual sense. It means removing the small blocks of metadata that tools like ZFS, LVM, and mdadm write to a disk to identify it as theirs. ZFS, for example, writes four copies of a label near the start and end of every disk in a pool. LVM writes a physical volume signature. A Linux software RAID array writes a superblock. These are usually just a few kilobytes each, but the kernel and userspace tools scan for them automatically at boot and during installation.
That's the root of the problem. A drive can look completely empty in a file manager and still have a ZFS label sitting at sector 0. The Proxmox installer, the Linux kernel's device mapper, and zfsutils-linux will all notice that label and try to do something with it — import the pool, refuse to let you partition the disk, or show a confusing warning during install.
Why Would You Use It?
This comes up constantly in two situations. First, repurposing hardware: an old TrueNAS box, an Unraid server, a Windows machine with a software RAID array, or even a previous Proxmox VE install that used ZFS. Second, reinstalling Proxmox on the same drive after testing a different storage layout — say you tried ZFS RAID10 and want to switch to a single ext4 disk instead. In both cases the old metadata doesn't just disappear when you reformat.
I've seen this bite people hardest with ZFS specifically. Even after a full reinstall with ext4 selected, an old ZFS label sitting in the last few megabytes of the disk can cause zpool import to list a "ghost" pool from months ago, or make a future ZFS install think there's already data there. It's not dangerous, exactly, but it's confusing, and it's avoidable in about two minutes of work.
Prerequisites
You'll need one of the following: a machine already booted into the Proxmox VE installer (using its debug/rescue shell), an existing Proxmox VE host you're about to reinstall, or a Linux live USB such as SystemRescue if you want to prep the disk before even starting the installer. Any of these gives you a root shell, which is all this actually requires.
You should also know which physical disk you're targeting before you run anything here. Every command below is destructive to the disk it's pointed at, and Linux device names like /dev/sda aren't guaranteed to stay consistent between boots on a system with multiple drives. Double-check with lsblk before touching anything, and if you're not sure, unplug every drive except the one you're wiping.
Step-by-Step Tutorial
Step 1: Get a Shell
If you're wiping the disk from inside the Proxmox VE installer itself, reboot from your install media, and at the boot menu choose Advanced Options, then Install Proxmox VE (Graphical, Debug Mode) or the terminal UI equivalent. The installer will drop you into a debug console at several points during startup. Press Ctrl+D to move past each checkpoint until you reach a normal root shell, before the disk selection screen appears.
If you're doing this from an already-installed Proxmox host that you're about to reinstall or repurpose, just SSH in or use the Shell button in the web UI — no debug mode needed, since the system is already fully booted.
Step 2: Identify the Target Disk
Run this before doing anything else:
lsblk -o NAME,SIZE,FSTYPE,LABEL,MOUNTPOINTLook at the FSTYPE and LABEL columns. A value like zfs_member or linux_raid_member tells you exactly what kind of metadata you're dealing with, which determines which command you need in the next step. If a disk shows a mountpoint, unmount it first with umount /dev/sdX1 (or the appropriate partition number) — none of the wipe commands work reliably on a mounted or actively-used disk.
Step 3: Clear ZFS Labels (If Present)
If lsblk showed zfs_member, or if zpool import lists a pool you don't recognize, clear the label with:
zpool labelclear -f /dev/sdXDo this for every disk that was part of the old pool, not just one. ZFS pools spread their labels across all member disks, and clearing only one leaves the others still advertising membership in a pool that no longer fully exists.
Step 4: Clear LVM Signatures (If Present)
If the disk was previously used as an LVM physical volume — common on Debian, Ubuntu, or CentOS installs that used LVM by default — clear it with:
wipefs -a /dev/sdXwipefs is actually the general-purpose tool here, and it also handles plain filesystem signatures (ext4, xfs, ntfs) and GPT/MBR partition table markers, not just LVM. It's usually the only command you need for a disk that doesn't have ZFS or RAID on it.
Step 5: Clear RAID Superblocks (If Present)
For a disk that was part of a Linux software RAID array (mdadm), the superblock survives a simple wipefs in some configurations, so clear it explicitly:
mdadm --zero-superblock /dev/sdXIf the array is still assembled and active, stop it first with mdadm --stop /dev/mdX, otherwise the kernel will just reassemble the array on the next scan and the superblock will come right back.
Step 6: Zero Out the Partition Table Areas
Even after the steps above, run wipefs -a /dev/sdX one more time on the whole disk (not a partition) to catch the GPT or MBR partition table itself. GPT disks keep a backup header at the very end of the disk, which wipefs alone sometimes misses. For full peace of mind, zero out the last few megabytes directly:
dd if=/dev/zero of=/dev/sdX bs=1M count=10 seek=$(( $(blockdev --getsz /dev/sdX) / 2048 - 10 ))That command finds the disk size in 512-byte sectors, converts it to megabytes, and writes ten zeroed megabytes starting ten megabytes before the end. It looks intimidating, but it's just "zero out the last 10 MB." You can skip this step for a disk that only ever had ext4 or NTFS on it — it mainly matters for old GPT-partitioned drives.
Step 7: Verify
Run lsblk -o NAME,SIZE,FSTYPE,LABEL one more time. The FSTYPE and LABEL columns should now be empty for the disk you wiped. If they're still showing something, re-check which specific device node you actually targeted — it's easy to wipe /dev/sda when the drive you meant is /dev/sdb.
Commands Explained
| Command | What it does |
|---|---|
lsblk -o NAME,SIZE,FSTYPE,LABEL,MOUNTPOINT | Lists block devices with their filesystem type, label, and current mount status, so you can see what's on a disk before touching it. |
zpool labelclear -f /dev/sdX | Removes ZFS's on-disk pool labels from a device. The -f flag forces removal even if ZFS thinks the pool might still be active. |
wipefs -a /dev/sdX | Scans a device for known filesystem, RAID, and partition-table signatures and erases all of them in one pass. |
mdadm --zero-superblock /dev/sdX | Erases the metadata mdadm uses to recognize a disk as part of a software RAID array. |
mdadm --stop /dev/mdX | Deactivates an assembled RAID array so its member disks can be safely modified. |
blockdev --getsz /dev/sdX | Prints the size of a disk in 512-byte sectors, used here to calculate where the last few megabytes begin. |
dd if=/dev/zero of=/dev/sdX bs=1M count=10 seek=N | Writes zeroed data to a disk starting at a specific offset — in this case, near the end, to remove a backup GPT header. |
Common Errors
You'll run into a handful of predictable errors doing this. wipefs: error: /dev/sda: probing initialization failed: Device or resource busy almost always means the disk or one of its partitions is still mounted, or is an active member of an mdadm array or LVM volume group. Unmount it, or stop the array with mdadm --stop, and try again.
cannot open '/dev/sda': no such pool or dataset available from zpool labelclear just means there's no ZFS label on that device — nothing to do here, move on to wipefs.
If you run wipefs -a on the whole disk before clearing individual RAID or LVM signatures, you can end up with a disk that looks clean under lsblk but still confuses mdadm --assemble --scan or vgscan on the next boot, because those tools cache device information separately. Running mdadm --zero-superblock and zpool labelclear first, then wipefs last, avoids this ordering problem.
Troubleshooting
If a "ghost" ZFS pool keeps showing up in zpool import even after you've wiped what you thought was every disk, run zpool import by itself with no arguments — it lists every disk it thinks belongs to that pool, including ones you may have forgotten were part of the original array. Wipe each one.
If the Proxmox installer still refuses to select a disk after wiping it, reboot before continuing. The kernel caches partition table information in memory, and a stale in-memory view can persist even after the on-disk data is gone. A reboot forces a fresh read.
On NVMe drives specifically, blkdiscard /dev/nvmeXn1 is worth running as a final step. It issues a TRIM command that tells the drive's controller the entire address range is unused, which clears data at the hardware level rather than just overwriting the parts a partition table would occupy. It's fast — a few seconds on most NVMe drives — and it's the closest thing to a factory-reset for flash storage.
Best Practices
Pull every drive except the one you're wiping if the machine has more than one installed, especially the first time you do this. It removes any chance of hitting the wrong /dev/sdX letter, which can silently reassign itself between boots.
Wipe RAID and ZFS metadata before running a general wipefs -a on the whole disk, not after — the ordering avoids the stale-cache issue described above.
Keep a note of drive serial numbers if you're managing more than a couple of disks. lsblk -o NAME,SERIAL,SIZE will show them, and matching a serial number to a physical drive is far more reliable than trusting that /dev/sdb means the same physical disk it did last time you looked.
Don't bother with a full dd if=/dev/zero of=/dev/sdX bs=1M across the entire disk unless you have a specific reason to securely erase old data for privacy reasons. It works, but on a large spinning disk it can take hours, and clearing just the metadata regions gets Proxmox a clean install in seconds.
Frequently Asked Questions
Do I need to do this on a brand-new, unused drive?
No. A drive straight from the factory has no filesystem or RAID metadata to clear. This only matters for disks that previously held ZFS, LVM, RAID, or another OS installation.
Will this delete my data?
Yes, permanently. These commands remove the metadata that makes a filesystem or RAID array recognizable, and in most practical terms that means the data on it is no longer recoverable through normal means. Back up anything you need first.
Can I do this from the Proxmox installer without a separate live USB?
Yes. The installer's debug mode, described in Step 1, drops you into a full root shell with all the tools you need already available.
My disk shows no FSTYPE in lsblk but the installer still complains. What's wrong?
Reboot the machine. As mentioned in the troubleshooting section, the kernel sometimes holds onto a stale in-memory partition table even after the on-disk data has been cleared.
Is zpool labelclear safe to run if I'm not sure the disk has a ZFS label?
Yes — if there's no label, it simply reports that there's nothing to clear and exits without changing anything.
Conclusion
This is a five-minute job that saves you from some genuinely confusing troubleshooting later — the kind where nothing about your fresh Proxmox install looks wrong until zpool status or a boot-time RAID scan turns up something you don't remember creating. Check what's on a disk with lsblk, clear ZFS labels, LVM signatures, and RAID superblocks with their specific tools, finish with a general wipefs -a, and the Proxmox VE installer will treat the disk exactly like the blank one it now actually is.