Comment 96 for bug 569900

Por favor, lenguaje en Español

> Date: Wed, 26 Jan 2011 17:24:36 +0000
> From: <email address hidden>
> To: <email address hidden>
> Subject: [Bug 569900] Re: partman sometimes creates partitions such that there is ambiguity between whether the superblock is on the disk device or the partition device
>
> 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 subscribed to Ubuntu
> ubuntu-10.04.2.
> 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
>
> Status in “grub2” package in Ubuntu:
> Invalid
> Status in “partman-base” package in Ubuntu:
> Fix Released
> Status in “grub2” source package in Lucid:
> Invalid
> Status in “partman-base” source package in Lucid:
> Fix Released
> Status in “grub2” source package in Maverick:
> Invalid
> Status in “partman-base” source package in Maverick:
> Fix Released
>
> Bug description:
> Binary package hint: mdadm
>
> In a KVM, I can do this just fine:
>
> * Using 2 virtual disk images
> * Install Lucid Server amd64
> * Both disks partitioned to just one large Linux raid partition
> * RAID1 these two together, /dev/md0
> * Put / on an ext4 filesystem on /dev/md0
> * Install
>
> The above works.
>
> However, I have spent my entire weekend trying to get 10.04 on a RAID1
> of two 500GB SATA disks, without success.
>
> I partitioned them the same as above. And conducted the install.
>
> When I boot into the new system, I get dropped to an initramfs shell.
>
> I can see that /dev/md0 exists, and is in the process of resyncing.
>
> I try to "mount /dev/md0 /root" and I get:
> mount: mounting /dev/md0 on /root/ failed: Invalid argument
>
> Also, see something else that's odd... My /dev/md0 looks "correct",
> in that it's composed of /dev/sda1 and /dev/sdb1. However, I also see
> a /dev/md0p1, which is composed of /dev/sda and /dev/sdb (the whole
> disks?). Furthermore, if I go into /dev/disk/by-uuid, there is only
> one symlink there, pointing to /dev/md0p1. And this UUID is what is
> in fact in grub as the root device. That looks quite wrong.
>
> This looks pretty release-critical, to me, as it's affecting RAID
> installs of the server.
>
> TEST CASE: The above problem should arise when attempting a RAID
> install on any disk whose size is between 1048576*n+512 and
> 1048576*n+65535 bytes, for integer values of n. In order to reproduce
> this, the root filesystem should be created on a RAID array whose
> member devices extend all the way to the end of the disk (i.e. accept
> the default size for the partition in the installer).
>
> To validate this from -proposed (once available), please note that you
> will need to use a netboot installation image and boot with apt-
> setup/proposed=true on the kernel command line.
>
>