SWRAID (dmraid) devices renamed to md126 and md127 ?

Topics about disk partitioning (fdisk, parted, gparted, partimage), Volumes Management (lvm, evms, dmraid), Storage, file systems, ...
dag
Posts: 2
Joined: 28 Jul 2010, 20:01

SWRAID (dmraid) devices renamed to md126 and md127 ?

Postby dag » 09 Mar 2011, 08:53

When restoring the GRUB MBR using SystemRescueCD, the two SWRAID devices, previously named /dev/md1 and /dev/md2 were named /dev/md126 and /dev/md127 instead.

I used grub to restore the GRUB MBR, however on reboot my devices were still called /dev/md126 and /dev/md127 and the boot failed because /dev/md1 was referenced (as /boot) in /etc/fstab.

Does anyone know who and why these devices were renamed ?
Is this due to SystemRescueCD, and if so, can we somehow prevent this behaviour ?
How can we rename these devices back to the original names ?

Any feedback welcome ;-)

Tuipveus
Posts: 101
Joined: 18 Nov 2006, 13:09
Contact:

Re: SWRAID (dmraid) devices renamed to md126 and md127 ?

Postby Tuipveus » 22 Mar 2011, 21:50

About same problem here. md0, md1, md2 are now md127 etc...

I just would like to have clean stable way to archive and restore whole system. This is not the way. :(

thurdy
Posts: 3
Joined: 03 Apr 2011, 16:05

Re: SWRAID (dmraid) devices renamed to md126 and md127 ?

Postby thurdy » 05 Apr 2011, 01:12

I have the same issue, the drives have been renamed.
md0 => md125; md1 => md126; md2 => md127.

I also have the same question on how to restore back to original state so I can boot the system.

gernot
Posts: 1121
Joined: 07 Apr 2010, 16:19

Re: SWRAID (dmraid) devices renamed to md126 and md127 ?

Postby gernot » 09 Apr 2011, 11:30

Solves this your problem?
viewtopic.php?f=4&p=11814

Gernot

gulikoza
Posts: 4
Joined: 19 Jul 2011, 09:34

Re: SWRAID (dmraid) devices renamed to md126 and md127 ?

Postby gulikoza » 19 Jul 2011, 09:52

PLEASE fix this and restore previous behavior so that md devices have their original minor numbers. Simply booting SRCD might leave the original system unbootable and fixing minor numbers manually after each boot is really PITA.

cercatrova
Posts: 2
Joined: 11 Oct 2011, 15:19

Re: SWRAID (dmraid) devices renamed to md126 and md127 ?

Postby cercatrova » 14 Dec 2011, 14:26

To help anyone who comes upon this thread as of December 2011, I'm running a completely up-to-date Ubuntu server 10.04.3 LTS with kernel 2.6.32-36 and using RAID1 for all partitions on /dev/sda and /dev/sdb (i.e. /dev/sda1 = /dev/sdb1, /dev/sda2 = /dev/sdb2, etc.). This includes /boot which is composed of /dev/sda1 and /dev/sdb1 and which normally appears as /dev/md0. I also have /dev/sdc1 and /dev/sdc2 partitions which are not mirrored. I boot into SystemRescueCd 2.4.0 from grub2 using an ISO image on /dev/sdc2. Indeed I find that the arrays are always assembed as /dev/md123, /dev/md124, etc. instead of /dev/md0, /dev/md1, etc. I find however that an array's preferred minor value in the superblock is not changed on disk unless I either (1) mount the array read-write or (2) run mdadm --detail on the array. Instead of using an mdadm.conf file, my solution is simply to set up an autorun script as /dev/sdc1/autorun to stop and reassemble the arrays with the proper preferred minor values before anything can happen to change them:

mdadm --stop /dev/md123
mdadm --assemble /dev/md0 --super-minor=0
mdadm --stop /dev/md124
mdadm --assemble /dev/md1 --super-minor=1
etc.

I stop and reassemble all of the arrays as a matter of safety. The only array I actually mount and write to regularly from SystemRescueCd is /dev/md0, in order to manually edit the "set default=" line in grub.cfg so that I can boot back into Ubuntu (the grub-reboot approach doesn't work if the /boot partition is part of a RAID array). It was this procedure that originally got me into trouble - I mounted /dev/md123 (the /boot partition) read-write, edited grub.cfg, and rebooted and then couldn't get back into Ubuntu because the partition's preferred minor value had been changed. So grub2 was looking for its root device as (md0) but the /boot partition was now (md123). I had to ask the colocation people to help - they did a set root=(md123) and set prefix=(md123)/grub at the grub prompt and were able to start Ubuntu. The problem corrected itself in Ubuntu because there is an /etc/mdadm/mdadm.conf file there that maps everything properly.

Although I'm using /dev/sdc and the ISO image approach, doing this from CD or USB flash should work equally well as long as you can work out the autorun issues. I haven't yet tested putting the ISO image and autorun script on one of the RAID1 partitions, but SystemRescueCd mounts the partition containing the ISO image at /livemnt/isostore read-only, so that part at least should not cause a problem. I seem to recall reading that the partition containing the autorun script is mounted read-write, so that might be problematic. However, if you stay away from using the /boot partition then at least you won't end up making your system unbootable.


Return to “Hard-disk partitioning and storage”

Who is online

Users browsing this forum: No registered users and 1 guest