That brings up the question: Any reason to get the partition table fixed up? Is this just a cosmetic issue? Alex On Mon, Dec 17, 2012 at 12:41 PM, Phil Turmel <philip@xxxxxxxxxx> wrote: > [Top-posting repaired. Please don't.] > > On 12/17/2012 12:26 PM, Alex Pientka wrote: >> On Mon, Dec 17, 2012 at 12:18 PM, Phil Turmel <philip@xxxxxxxxxx> wrote: >>> Hi Alex, >>> >>> On 12/17/2012 09:17 AM, Alex Pientka wrote: >>> >>> [trim /] >>>> >>>> /dev/md0: >>>> Version : 1.1 >>> >>> ^^^^^ >>> You've deliberately chosen a metadata version that places the superblock >>> at sector 0 of the given device. If that is a whole disk, it overwrites >>> the partition table. The default metadata is v1.2 (which places the >>> superblock at offset 4k) for this very reason. > >> I assume upgrading to v1.2 is not possible. The only other way would >> be to fail every raw device (one-by-one) and then create the fd >> partition on it, correct? > > You could put the array back on partitions if you like. I'd make a > complete backup, zero the superblocks, and use --create --assume-clean > to switch to v1.2 in place (with due care to maintain the device order > and data offsets). > > (Save the output of "mdadm -E /dev/sdXX" for each member device before > you start.) > > However, that fdisk can't understand the partition table shouldn't be > hurting anything, so I wouldn't make it a priority. > > BTW, partition type 'fd' is deprecated along with v0.90 metadata, as it > only impacts kernel non-initramfs autoassembly, and that only works with > DOS partition tables and v0.90 metadata. > > Phil -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
