[jabberwcky]

> But right now we're just trying to make a device appear functionally empty so that we can re-install an OS without remnants of any previous installation getting in the way

The only portable, reliable, robust way to accomplish this is wiping the drive. If the original author had issued a secure erase, they would not have encountered any subsequent difficulties, all of which were due to partially erasing the device.

[wtallis]

> The only portable, reliable, robust way to accomplish this

That's setting the bar too high. If we're comfortable with solutions that will work on all mainstream PC platforms including Macs, then it is sufficient to overwrite partition tables with zeros. I have never heard of an OS installer that scans for deleted partitions, and worrying about the possibility of such a thing causing problems is unreasonable.

[jabberwcky]

GPT along with most filesystems store a bunch of stuff at random places around the disk, for many filesystems it's even configurable.

The most usual problem with your approach is recreating a set of partition tables exactly matching the old tables, while failing to wipe out a filesystem signature buried halfway into the disk. One reboot later, and magic header bytes start to be recognized as valid filesystems by whatever OS installer or BIOS utility you happen to be using. Even worse if you're been taking some hacky shotgun approach to blowing holes in the drive by zeroing out random sectors that belong to one of those recognized filesystems.

So once again,

> The only portable, reliable, robust way to accomplish this is wiping the drive

[wtallis]

> GPT along with most filesystems store a bunch of stuff at random places around the disk, for many filesystems it's even configurable.

This is not remotely accurate. GPT is at the beginning of the disk, with a backup copy at the end of the disk. Wiping the GPT makes the layout of filesystem structures within partitions completely irrelevant. Wiping the primary GPT at the beginning of the disk is usually (possibly always) sufficient to make an OS installer believe the disk to be empty. The backup GPT at the end of the disk is something I've only seen used by manual partitioning tools that are more powerful and complex than the automatic partitioning tools that are part of OS installers.

> The most usual problem with your approach is recreating a set of partition tables exactly matching the old tables, while failing to wipe out a filesystem signature buried halfway into the disk. One reboot later, and magic header bytes start to be recognized as valid filesystems by whatever OS installer or BIOS utility you happen to be using.

Rebooting and re-detecting everything between partitioning and mkfs is not part of any ordinary OS installation procedure. Do you have any evidence that this failure mode can actually occur in practice with real shipping operating systems?

Remember, for the purposes of this hypothetical, we have to assume that at least one of the user or the OS installler is actually trying to make the process work. You can't assume that they're both trying to interfere with the process and are both going out of their way to cause problems.

[jabberwcky]

> This is not remotely accurate

At least Ext4 repeats the complete superblock at the beginning of every block group, so yes, it is not only remotely accurate, but entirely accurate. In the case of GPT, Linux requires explicit command line options to enable alternative GPT use, but do you know this is true for all systems in existence and all versions of Linux?

> Rebooting and re-detecting everything between partitioning and mkfs is not part of any ordinary OS installation procedure

Yes, I've personally bumped into this on desktop and unattended server installs - numerous times.

But you're externalizing the onus to prove cases where some hacky approach won't ever break when there is a vastly simpler way to avoid this entire class of problem. This is exactly the reverse of sound logic -- I'm offering you concrete real world examples of why you should avoid the hack and you're simply ignoring them

At this point I'm considering this not only to be offering up worst-practice advice, but actively trolling. Possibly the worst case of "a little knowledge is dangerous" I've seen recently. Regards

[wtallis]

> Yes, I've personally bumped into this on desktop and unattended server installs - numerous times.

Name and shame, please. Because your spurious complaints about SSD write endurance haven't exactly established your credibility, and you do otherwise seem to be postulating that non-standard nonsensical actions will somehow insert themselves into the process under discussion.

> I'm offering you concrete real world examples of why you should avoid the hack and you're simply ignoring them

No, you're not offering any concrete real-world examples. You're offering hypothetical examples of how a malicious user might be able to trip up a non-specific hypothetical automated OS installer.

> At this point I'm considering this not only to be offering up worst-practice advice, but actively trolling. Possibly the worst case of "a little knowledge is dangerous" I've seen recently. Regards

You are the one who called something "bad advice" but three comments later have yet to prove that it could ever fail in practice. I'm not trolling, and I'm not saying that a dd to the first 1GB of a drive is the best way to clean a drive. I'm just taking exception to your unfounded claims about what "could" go wrong.

[jabberwcky]

You are literally commenting on the thread for a blog post describing the mess that occurs when a drive is incorrectly erased. JFC