All of lore.kernel.org
 help / color / mirror / Atom feed
From: Brian Candler <b.candler@pobox.com>
To: linux-raid@vger.kernel.org
Subject: Using mdadm instead of dmraid for BIOS-RAID root volume
Date: Tue, 08 Oct 2013 13:17:06 +0100	[thread overview]
Message-ID: <5253F7C2.2030401@pobox.com> (raw)

I have a number of systems with Ubuntu 12.04 and Intel BIOS-RAID 
mirrored pairs for the boot disk. These come up as dmraid, with the root 
filesystem on /dev/mapper/isw_XXXXXXXXXX_Volume0p1.

I would like to convert them to use mdadm instead (so for example I can 
monitor them with /proc/mdstat)

The mdadm version is 3.2.5, and the manpage says that dff and imsm 
metadata is supported. mdadm --examine confirms this:

|# mdadm --examine /dev/sda
/dev/sda:
           Magic : Intel Raid ISM Cfg Sig.
         Version : 1.1.00
     Orig Family : 8bc6b015
          Family : 8bc6b015
      Generation : 00000010
      Attributes : All supported
            UUID : 2ff8e106:XXXXXXXX:XXXXXXXX:XXXXXXXX
        Checksum : b92d117e correct
     MPB Sectors : 1
           Disks : 2
    RAID Devices : 1

   Disk00 Serial : S14CNEAXXXXXXXX
           State : active
              Id : 00000000
     Usable Size : 234435342 (111.79 GiB 120.03 GB)

[Volume0]:
            UUID : a7fb0d20:XXXXXXXX:XXXXXXXX:XXXXXXXX
      RAID Level : 1
         Members : 2
           Slots : [UU]
     Failed disk : none
       This Slot : 0
      Array Size : 222715904 (106.20 GiB 114.03 GB)
    Per Dev Size : 222716168 (106.20 GiB 114.03 GB)
   Sector Offset : 0
     Num Stripes : 869984
      Chunk Size : 64 KiB
        Reserved : 0
   Migrate State : idle
       Map State : uninitialized
     Dirty State : clean

   Disk01 Serial : S14CNEAXXXXXXXX
           State : active
              Id : 00000001
     Usable Size : 234435342 (111.79 GiB 120.03 GB)

|(ditto for /dev/sdb)

Since this machine is going to need a reinstall for an unrelated reason 
anyway, I thought as an experiment I'd first try to convert it to use 
mdadm at boot.

What I did was:

1. apt-get remove dmraid; apt-get autoremove

This gets rid of:

/lib/udev/rules.d/97-dmraid.rules
/usr/share/initramfs-tools/scripts/local-top/dmraid
/usr/share/initramfs-tools/hooks/dmraid

but we still have:

/lib/udev/rules.d/64-md-raid.rules
/usr/share/initramfs-tools/hooks/mdadm
/usr/share/initramfs-tools/scripts/mdadm-functions
/usr/share/initramfs-tools/scripts/local-premount/mdadm
/usr/share/initramfs-tools/scripts/init-premount/mdadm

2. /usr/share/mdadm/mkconf >/etc/mdadm/mdadm.conf

ARRAY metadata=imsm UUID=2ff8...
ARRAY /dev/md/Volume0 container=2ff8... member=0 UUID=...


However, after a reboot, the machine came up with /dev/sdb1 as its root. 
I was hoping for /dev/md/Volume0

3. Reboot with "raid=autodetect md=1"

No difference, although it did come up with /dev/sda1 as its root 
(possibly coincidental change)

4. After a few more failed experiments with kernel command line options, 
I tried to put it back using "apt-get install dmraid". However after 
that, further boots failed - the kernel panicked because it couldn't 
find the root partition with the given UUID. I guess this means that 
neither dmraid nor mdadm was able to assemble the volume.

The screen shows:

md: Scanned 0 and added 0 devices.
md: autorun ..
md: ... autorun DONE.
VFS: Cannot open root device "UUID=..." or unknown-block(0,0)
Please append a correct "root=" boot option; here are the available 
partitions
(then shows sda, sda1, sdb, sdb1 and a backtrace)

Unfortunately I cannot scroll back to see previous lines. I *can* boot 
the system in a crippled way with root=/dev/sda1 though.

Back at the shell, it looks like the dmraid volume is still present:

# dmraid -r
/dev/sdb: isw, "isw_XXXXXXXXXX", GROUP, ok, 234441646 sectors, data@ 0
/dev/sda: isw, "isw_XXXXXXXXXX", GROUP, ok, 234441646 sectors, data@ 0
# dmraid -s
*** Group superset isw_XXXXXXXXXX
--> Subset
name   : isw_XXXXXXXXXX_Volume0
size   : 222716160
stride : 128
type   : mirror
status : ok
subsets: 0
devs   : 2
spares : 0
# ls /dev/mapper
control
#

The machine is probably toast anyway, as it has written to /dev/sdb1 and 
/dev/sda1 independently.

Anyway, I'm not so worried about having broken this machine, as it 
needed a reinstall anyway, but I do wonder what would have been the 
correct way to get mdraid instead of dmraid at boot time for this root 
volume?

Thanks,

Brian.

             reply	other threads:[~2013-10-08 12:17 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-08 12:17 Brian Candler [this message]
2013-10-08 14:19 ` Using mdadm instead of dmraid for BIOS-RAID root volume Brian Candler
2013-10-08 18:36   ` Martin Wilck
2013-10-10  8:11     ` Brian Candler
2013-10-11 13:03     ` Brian Candler
2013-10-11 18:13       ` Martin Wilck
2013-10-11 19:49         ` Brian Candler
2013-10-13 16:44           ` Martin Wilck
2013-10-13 18:12             ` Brian Candler
2013-10-08 14:37 ` Jes Sorensen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5253F7C2.2030401@pobox.com \
    --to=b.candler@pobox.com \
    --cc=linux-raid@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.