F16: Raid1 /home failing to restart cleanly
'Chris Hall'
chris.hall.list at highwayman.com
Sat Apr 7 17:45:40 UTC 2012
Reindl Harald wrote (on Sat 07-Apr-2012 at 16:22 +0100):
> Am 07.04.2012 17:10, schrieb 'Chris Hall':
> >
> > I have a /home partition which is set up as a Software RAID1,
> > using /dev/md0.
> >
> > When I reboot the /dev/md0 fails to come up cleanly. So far it
> > has come back each time, but nearly every time it comes up with one
> > of the two members of the RAID array missing. I can mdadm /dev/md0
> > --re-add /dev/sdb3 -- and all is apparently well again. But I have
> > this partition as RAID for a reason, and it scares the bejazus out
> > of me each time :-(
> >
> > Any clues as to what spells I have failed to cast?
> that was discussed several times and is a bug you can workaround
> easy
> as you see below all raid-uuids are passed with "rd_MD_UUID=" as
> additional kernel-parameters, after that this will not happen again
Thanks for the suggestion. I fiddled with /etc/default/grub so that it says:
GRUB_CMDLINE_LINUX="rd.md.uuid=4f1c8224:cab0d0b2:f3ea7c36:7853abb8 rd.lvm=0 rd.dm=0 ....."
replacing an "rd.md=0" which was there before. That generates the following in grub.cfg:
menuentry 'Fedora Linux, with Linux 3.3.0-8.fc16.x86_64' --class fedora --class gnu-linux --class gnu --class os {
.....
linux /vmlinuz-3.3.0-8.fc16.x86_64 root=UUID=76b8f7f4-f9ba-47cb-9a4b-ac0ad8c33b8a ro rd.md.uuid=4f1c8224:cab0d0b2:f3ea7c36:7853abb8 rd.lvm=0 rd.dm=0 quiet SYSFONT=latarcyrheb-sun16 rhgb KEYTABLE=uk rd.luks=0 LANG=en_US.UTF-8
Unfortunately, this has not helped. The /dev/md0 came up with just one half running. All the stuff in the /var/log/messages which appears relevant:
Apr 7 17:34:04 hestia kernel: [ 3.342287] mdadm: sending ioctl 800c0910 to a partition!
Apr 7 17:34:04 hestia kernel: [ 3.342296] mdadm: sending ioctl 800c0910 to a partition!
Apr 7 17:34:04 hestia kernel: [ 3.342312] mdadm: sending ioctl 1261 to a partition!
Apr 7 17:34:04 hestia kernel: [ 3.342317] mdadm: sending ioctl 1261 to a partition!
Apr 7 17:34:04 hestia kernel: [ 3.347002] mdadm: sending ioctl 800c0910 to a partition!
Apr 7 17:34:04 hestia kernel: [ 3.347030] mdadm: sending ioctl 800c0910 to a partition!
Apr 7 17:34:04 hestia kernel: [ 3.347045] mdadm: sending ioctl 1261 to a partition!
Apr 7 17:34:04 hestia kernel: [ 3.347050] mdadm: sending ioctl 1261 to a partition!
Apr 7 17:34:04 hestia kernel: [ 3.364534] mdadm: sending ioctl 1261 to a partition!
Apr 7 17:34:04 hestia kernel: [ 3.364542] mdadm: sending ioctl 1261 to a partition!
Apr 7 17:34:04 hestia kernel: [ 3.460442] md: bind<sda3>
Apr 7 17:34:04 hestia kernel: [ 3.465396] md: raid1 personality registered for level 1
Apr 7 17:34:04 hestia kernel: [ 4.614820] md/raid1:md0: active with 1 out of 2 mirrors
Apr 7 17:34:04 hestia kernel: [ 4.614991] created bitmap (3 pages) for device md0
Apr 7 17:34:04 hestia kernel: [ 4.615737] md0: bitmap initialized from disk: read 1/1 pages, set 34 of 5120 bits
Apr 7 17:34:04 hestia kernel: [ 4.636179] md0: detected capacity change from 0 to 343596199936
Apr 7 17:34:04 hestia kernel: [ 4.645098] md0: unknown partition table
Apr 7 17:34:04 hestia kernel: [ 21.099317] mdadm: sending ioctl 1261 to a partition!
Apr 7 17:34:04 hestia kernel: [ 21.099318] mdadm: sending ioctl 1261 to a partition!
Apr 7 17:34:04 hestia kernel: [ 22.250574] mdadm: sending ioctl 800c0910 to a partition!
Apr 7 17:34:04 hestia kernel: [ 22.250583] mdadm: sending ioctl 800c0910 to a partition!
Apr 7 17:34:04 hestia kernel: [ 22.250598] mdadm: sending ioctl 1261 to a partition!
Apr 7 17:34:04 hestia kernel: [ 22.250603] mdadm: sending ioctl 1261 to a partition!
Apr 7 17:34:04 hestia kernel: [ 22.253646] mdadm: sending ioctl 1261 to a partition!
Apr 7 17:34:04 hestia kernel: [ 22.253655] mdadm: sending ioctl 1261 to a partition!
Apr 7 17:34:04 hestia kernel: [ 22.253869] mdadm: sending ioctl 1261 to a partition!
Apr 7 17:34:04 hestia kernel: [ 22.253875] mdadm: sending ioctl 1261 to a partition!
Apr 7 17:34:04 hestia kernel: [ 26.315777] EXT4-fs (md0): mounted filesystem with ordered data mode. Opts: (null)
...in this case it does not appear to have even looked at /dev/sdb3 -- the other half of the RAID1 !
Looking back through the logs from previous reboots I find:
Apr 6 14:39:47 hestia kernel: [ 12.383096] md: bind<sdb3>
Apr 6 14:39:47 hestia kernel: [ 12.427959] md: bind<sda3>
Apr 6 14:39:47 hestia kernel: [ 12.429449] md: kicking non-fresh sdb3 from array!
Apr 6 14:39:47 hestia kernel: [ 12.429460] md: unbind<sdb3>
Apr 6 14:39:47 hestia kernel: [ 12.429540] md: export_rdev(sdb3)
Apr 6 14:39:47 hestia kernel: [ 12.447895] md: raid1 personality registered for level 1
Apr 6 14:39:47 hestia kernel: [ 12.448519] md/raid1:md0: active with 1 out of 2 mirrors
Apr 6 14:39:47 hestia kernel: [ 12.478349] created bitmap (3 pages) for device md0
Apr 6 14:39:47 hestia kernel: [ 12.478752] md0: bitmap initialized from disk: read 1/1 pages, set 52 of 5120 bits
Apr 6 14:39:47 hestia kernel: [ 12.526149] md0: detected capacity change from 0 to 343596199936
Apr 6 14:39:47 hestia kernel: [ 12.579462] md0: unknown partition table
In passing... I think that things work better if I log out before rebooting.
Thanks,
Chris
More information about the users
mailing list