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. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/569900 Title: partman sometimes creates partitions such that there is ambiguity between whether the superblock is on the disk device or the partition device -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
