On Fri, June 26, 2009 7:25 pm, RUSSOTTO François-Xavier 200103 wrote: > Thank you for your answer Neil. > > I assumed that an update to the superblock checksumming routine was the > reason though I didn't find very much information about this update and > potential consequences on older systems. But, above all, I am very > surprised that the new mdadm does not even warn the user about potential > raid corruption when used on an old one.
Yes, I guess it might be possible to put some useful message somewhere... > > As you suggested, I tried recreating the array using option > --assume-clean. So, I booted a Sarge cdrom, checked that chunksize and > layout was default ones then I typed: > > $ mdadm --create /dev/md0 --level=raid5 --raid-devices=3 --auto=yes > --assume-clean /dev/sda2 /dev/sdb2 /dev/sdc2 > > And that worked! recreating the array without loss of data: I ran fsck on > /dev/md0, no error were reported, then mounted it to check that all data > was there; no pb. > > Then, I rebooted the server and... GOT A KERNEL PANIC AGAIN... this time > for: invalid uuid ! I patiently rebooted the Sarge cdrom again and tried > to reassemble the raid updating the uuid (which I fortunately backed up), > using: > > $ mdadm --assemble /dev/md0 --auto=yes --uuid=#old#:#uuid#:#back#:#up# > --update=uuid /dev/sda2 /dev/sdb2 /dev/sdc2 > > Then, I got an error from mdadm saying that option "uuid" for --update was > not valid! Only "sparc2.2", "summaries" and "resync" seams supported on > that version of mdadm (1.9.0). > > Now, I don't know what to do and would be grateful for any suggestion to > make my system boot again. Use --create --assume-clean again but add the --uuid= option there. If that doesn't work (and I'm not 100% sure it will), you will need to find a way to rebuild your initrd. NeilBrown -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
