Comment 95 for bug 569900

There are other way to get this bug too and it will haunt us back in the future and not only within Ubuntu

It hit me when partitionising with fdisk -u /dev/sdx but not with fdisk /dev/sdx because the first fits tightly to the end of the drive, the second leaves some space. The same happened when using GPT through cfdisk (not sure, its been a while).

All in all it shouldn't be wrong to use a tightly fitting partition table. The real problem here is that a 0.9 superblock can not be reliably source to either a device or a partition (or a LVM, actually I can imagine scenarios where its not only about drive or partition but in addition about other mappings like LVM, crypt, hey, even a stupidily placed part of a filesystem could qualify as a superblock). Until now it worked because scanning for superblock accidentially used a less error prone sequence for scanning (in fact even then the scanning usually ran head first into a wall but accidentially this didn't get through to the user)

In short: Placing vital information at the end of a bunch of sectors and hoping for a successful poking-around by the startup is stupid and prone for error.

Everyone should use front-aligned superblocks, that is version 1.1 and/or 1.2 because every known mapping (LVM, MD, Crypt, filesystems) are able to preserve lead-in-gaps and deliver this vital information to the next layer. Not so for for lead-out-gaps.