Booting from raid1 -- md: invalid raid superblock magic on sdb1

Booting from raid1 -- md: invalid raid superblock magic on sdb1

[David M. Strang]

Hello all --

I've read, and read, and read -- and I'm still not having ANY luck booting 
completely from a raid1 device.

This is my setup...

sda1 is booting, working great. I'm attempting to transition to a bootable 
raid1.

sdb1 is a 400GB partition -- it is type FD.

Disk /dev/sdb: 400.0 GB, 400088457216 bytes
2 heads, 4 sectors/track, 97677846 cylinders
Units = cylinders of 8 * 512 = 4096 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1               1    97677846   390711382   fd  Linux raid 
autodetect

I have created my raid1 mirror with the following command:

mdadm --create /dev/md_d0 -e1 -ap --level=1 --raid-devices=2 
missing,/dev/sdb1

The raid created correctly, I then partitioned md_d0 to match sda1.



Disk /dev/sda: 400.0 GB, 400088457216 bytes
2 heads, 4 sectors/track, 97677846 cylinders
Units = cylinders of 8 * 512 = 4096 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1    25000000    99999998   83  Linux
/dev/sda2        25000001    95677734   282710936   83  Linux
/dev/sda3        95677735    96177734     2000000   83  Linux
/dev/sda4        96177735    97677824     6000360   82  Linux swap / Solaris


Disk /dev/md_d0: 400.0 GB, 400088444928 bytes
2 heads, 4 sectors/track, 97677843 cylinders
Units = cylinders of 8 * 512 = 4096 bytes

      Device Boot      Start         End      Blocks   Id  System
/dev/md_d0p1   *           1    25000000    99999998   83  Linux
/dev/md_d0p2        25000001    95677734   282710936   83  Linux
/dev/md_d0p3        95677735    96177734     2000000   83  Linux
/dev/md_d0p4        96177735    97677843     6000436   82  Linux swap / 
Solaris


Here is my lilo.conf settings; I'm attempting to get it to mount md_d0 when 
the kernel starts. I realize that automount (type FD) no longer functions 
with a version-1 superblock.

#
# /etc/lilo.conf: lilo(8) configuration, see lilo.conf(5)
#

lba32
install=text
boot=/dev/sda
map=/boot/System.map
image=/vmlinuz
        label=CRUX
        root=/dev/sda1
        read-only
        append="quiet md=d0,/dev/sdb1"

# End of file


Without fail, every time the system boots -- I get the following message:

md: invalid raid superblock magic on sdb1

The odd thing is; if I login -- I can execute the following:

-(root@xenogenesis)-(~)- # mdadm -A /dev/md_d0 /dev/sdb1
mdadm: /dev/md_d0 has been started with 1 drive (out of 2).
-(root@xenogenesis)-(~)- # mdadm -E /dev/sdb1
/dev/sdb1:
          Magic : a92b4efc
        Version : 01.00
     Array UUID : 0d7a60d0:af2843fe:cde2a4dc:207bbd63
           Name : CRUX x64
  Creation Time : Sat Nov 26 03:24:23 2005
     Raid Level : raid1
   Raid Devices : 2

    Device Size : 781422744 (372.61 GiB 400.09 GB)
   Super Offset : 781422744 sectors
          State : clean
    Device UUID : 86be5e9e:b7c740ab:46bfb508:090a0e42
    Update Time : Sat Nov 26 04:03:43 2005
       Checksum : ebed5cb5 - correct
         Events : 168


   Array State : _U 1 failed
-(root@xenogenesis)-(~)- # mdadm -Q /dev/sdb1
/dev/sdb1: is not an md array
/dev/sdb1: device 1 in 2 device unknown raid1 array.  Use mdadm --examine 
for more detail.


I'm really confused; mdadm seems to recognize it and load it fine... why 
can't I get the kernel to load it?

-- David M. Strang 

Re: Booting from raid1 -- md: invalid raid superblock magic on sdb1

[David M. Strang]

On Saturday 26 November 2005 12:16:14, Guillaume Filion wrote:
> Le 05-11-26, à 11:18, David M. Strang a écrit :
> > md: invalid raid superblock magic on sdb1
>
> Did you include the md and raid1 modules in mkinirtd.conf?
>
> I'll admit that while I have my root on a raid1 device, I'm a bit confused 
> by the whole process... :-/
>

Well, actually... I don't use an initrd. All my drivers are straight 
compiled into the kernel.

> I found this document particularly helpful:
> http://xtronics.com/reference/SATA-RAID-Debian.htm
>

Good document, I've looked at that one a bit too. It seems that the md.txt 
from the kernel Documentation is perhaps what is throwing me awry.

-- David M. Strang 

-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Booting from raid1 -- md: invalid raid superblock magic on sdb1

[David M. Strang]

On Saturday 26 November 2005 11:14:46, David M. Strang wrote:
> sdb1 is a 400GB partition -- it is type FD.
>
> Disk /dev/sdb: 400.0 GB, 400088457216 bytes
> 2 heads, 4 sectors/track, 97677846 cylinders
> Units = cylinders of 8 * 512 = 4096 bytes
>
>    Device Boot      Start         End      Blocks   Id  System
> /dev/sdb1               1    97677846   390711382   fd  Linux raid 
> autodetect
>

OK, I've dumped the autodetect raid type. It seems it's pointless on v1.0 
superblocks -- it was just generating an 'extra' error.

Disk /dev/sdb: 400.0 GB, 400088457216 bytes
2 heads, 4 sectors/track, 97677846 cylinders
Units = cylinders of 8 * 512 = 4096 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1               1    97677846   390711382   83  Linux


> Here is my lilo.conf settings; I'm attempting to get it to mount md_d0 
> when the kernel starts. I realize that automount (type FD) no longer 
> functions with a version-1 superblock.
>
> #
> # /etc/lilo.conf: lilo(8) configuration, see lilo.conf(5)
> #
>
> lba32
> install=text
> boot=/dev/sda
> map=/boot/System.map
> image=/vmlinuz
>         label=CRUX
>         root=/dev/sda1
>         read-only
>         append="quiet md=d0,/dev/sdb1"
>
> # End of file
>
>
> Without fail, every time the system boots -- I get the following message:
>
> md: invalid raid superblock magic on sdb1
>

This still persists. Are there some patches to the kernel or something that 
I need for it to recognize v1.0 superblocks? I'm running Linux v2.6.14.3

As I mentioned before, mdadm can state the array w/o any issues at all...

-- David M. Strang 

Re: Booting from raid1 -- md: invalid raid superblock magic on sdb1

[David M. Strang]

On Saturday 26 November 2005 14:03:35, David M. Strang wrote:
> On Saturday 26 November 2005 11:14:46, David M. Strang wrote:
> > sdb1 is a 400GB partition -- it is type FD.
> >
> > Disk /dev/sdb: 400.0 GB, 400088457216 bytes
> > 2 heads, 4 sectors/track, 97677846 cylinders
> > Units = cylinders of 8 * 512 = 4096 bytes
> >
> >    Device Boot      Start         End      Blocks   Id  System
> > /dev/sdb1               1    97677846   390711382   fd  Linux raid 
> > autodetect
> >
> OK, I've dumped the autodetect raid type. It seems it's pointless on v1.0 
> superblocks -- it was just generating an 'extra' error.
>
> Disk /dev/sdb: 400.0 GB, 400088457216 bytes
> 2 heads, 4 sectors/track, 97677846 cylinders
> Units = cylinders of 8 * 512 = 4096 bytes
>
>    Device Boot      Start         End      Blocks   Id  System
> /dev/sdb1               1    97677846   390711382   83  Linux
>
> > Here is my lilo.conf settings; I'm attempting to get it to mount md_d0 
> > when the kernel starts. I realize that automount (type FD) no longer 
> > functions with a version-1 superblock.
> >
> > #
> > # /etc/lilo.conf: lilo(8) configuration, see lilo.conf(5)
> > #
> >
> > lba32
> > install=text
> > boot=/dev/sda
> > map=/boot/System.map
> > image=/vmlinuz
> >         label=CRUX
> >         root=/dev/sda1
> >         read-only
> >         append="quiet md=d0,/dev/sdb1"
> >
> > # End of file
> >
> >
> > Without fail, every time the system boots -- I get the following 
> > message:
> >
> > md: invalid raid superblock magic on sdb1
> >
>
> This still persists. Are there some patches to the kernel or something 
> that I need for it to recognize v1.0 superblocks? I'm running Linux 
> v2.6.14.3
>
> As I mentioned before, mdadm can state the array w/o any issues at all...

Please forgive me for pinging you direct on this Neil; but I fear you are 
the only one who can answer it.

I am a bit considered by this in the startup log:

Nov 26 21:47:35 xenogenesis kernel: md: raid1 personality registered as nr 3
Nov 26 21:47:35 xenogenesis kernel: md: md driver 0.90.2 MAX_MD_DEVS=256, 
MD_SB_DISKS=27
Nov 26 21:47:35 xenogenesis kernel: md: bitmap version 3.39

While mdadm lets me start a v1.0 superblock; I fear that I missing some 
level of kernel patch.

Nov 26 21:47:35 xenogenesis kernel: md: Loading md_d0: /dev/sdb1
Nov 26 21:47:35 xenogenesis kernel: md: invalid raid superblock magic on 
sdb1
Nov 26 21:47:35 xenogenesis kernel: md: sdb1 has invalid sb, not importing!
Nov 26 21:47:35 xenogenesis kernel: md: md_import_device returned -22

-(root@xenogenesis)-(/usr/src/linux-2.6.14.3/drivers/md)- # mdadm -A 
/dev/md_d0 /dev/sdb1
mdadm: /dev/md_d0 has been started with 1 drive (out of 2).
-(root@xenogenesis)-(/usr/src/linux-2.6.14.3/drivers/md)- # mdadm --detail 
/dev/md_d0
/dev/md_d0:
        Version : 01.00.02
  Creation Time : Sat Nov 26 10:20:11 2005
     Raid Level : raid1
     Array Size : 390711372 (372.61 GiB 400.09 GB)

I've searched the linux-raid archive; but all the patches I see that might 
be relevent, have long been applied to the tree.

-- David M. Strang 

Re: Booting from raid1 -- md: invalid raid superblock magic on sdb1

[David M. Strang]

On Saturday 26 November 2005 23:32:51, David M. Strang wrote
> Please forgive me for pinging you direct on this Neil; but I fear you are 
> the only one who can answer it.
>
> I am a bit considered by this in the startup log:
>
> Nov 26 21:47:35 xenogenesis kernel: md: raid1 personality registered as nr 
> 3
> Nov 26 21:47:35 xenogenesis kernel: md: md driver 0.90.2 MAX_MD_DEVS=256, 
> MD_SB_DISKS=27
> Nov 26 21:47:35 xenogenesis kernel: md: bitmap version 3.39
>
> While mdadm lets me start a v1.0 superblock; I fear that I missing some 
> level of kernel patch.
>
> Nov 26 21:47:35 xenogenesis kernel: md: Loading md_d0: /dev/sdb1
> Nov 26 21:47:35 xenogenesis kernel: md: invalid raid superblock magic on 
> sdb1
> Nov 26 21:47:35 xenogenesis kernel: md: sdb1 has invalid sb, not 
> importing!
> Nov 26 21:47:35 xenogenesis kernel: md: md_import_device returned -22

Just a quick update; I've been putting forth some due diligence on this --  
and it appears basically, that do_mounts_md.c is an antique. I've added a 
small debug line to md.c under md_import_device; and then also traced thru 
the do_mounts_md.c code; and basically the crux of the situation is 
do_mounts_md.c doesn't evaluate the superblock of the device and set 
SET_ARRAY_INFO for persistent superblocks. So, everything defaults to the 
legacy superblock type. (Superblock v0.90.x)

-- David M. Strang

Re: Booting from raid1 -- md: invalid raid superblock magic on sdb1

[Neil Brown]

On Sunday November 27, dstrang@shellpower.net wrote:
> 
> Just a quick update; I've been putting forth some due diligence on this --  
> and it appears basically, that do_mounts_md.c is an antique. I've added a 
> small debug line to md.c under md_import_device; and then also traced thru 
> the do_mounts_md.c code; and basically the crux of the situation is 
> do_mounts_md.c doesn't evaluate the superblock of the device and set 
> SET_ARRAY_INFO for persistent superblocks. So, everything defaults to the 
> legacy superblock type. (Superblock v0.90.x)

Yes, do_mounts_md assumes v0.90. 
The following patch will allow you to specify the version in the
kernel parameters, something like
   md=d0,v1.0,/dev/sda,/dev/sdb

(though I haven't tested it).
However I'm not at all convinced that I want to go down this path.

It is not at all hard to create an initramfs which runs mdadm to do
the right thing.  With mdadm-2.2 (to be released soonish), it will be
even easier.
e.g. you just need mdassemble, busybox, and a script called init
similar to:
  #!/bin/sh
  mkdir /proc; mount -t proc proc /proc
  if [ -n "$rootuuid" ]
  then arg=--uuid=$rootuuid
  else arg=--super-minor=0
  fi
  mdassemble -cpartitions $a --auto=part /dev/mda
  mount /dev/mda1 /root
  umount /proc
  cd /root
  rm -rf /bin
  mount --move . /
  chroot . /sbin/init

and with a more-recent busybox, the last few lines become just
"swap_root /root" (or something like that).
As it stands, this will not work with mdadm-2.1 as /dev won't have
names for all the devices in /proc/partitions.  mdadm-2.2 will remove
that necessity, though you can also add
{ read a ; read a;
  while read maj min b name
  do mknod /dev/$name b $maj $min
  done
} < /proc/partitions

if you want to try it now.
(For more complete instructions:
  Create a directory.
  In that directory create a directory 'bin' containing statically
  linked 'busybox' as 'sh' and 'mdassemble' as 'mdassemble'.
  In that directory also put the above script called 'init'.
  Make sure all files and directories are executable.
  run
    cpio -o -H newc . | gzip --best > ../init.cpio.gz
  Tell your boot loader (e.g. lilo or grub) that the init.cpio.gz file
  should be used as an initrd.
  Optionally add (append) a kernel parameter 
    rootuuid=UUID:OFYO:URRO:OOT:ARRA:Y :-)
)

In general I would rather steer away from do_mounts_md.c assembling
root md arrays, and steer towards using mdadm in an initramfs.  That
doesn't mean that I won't submit the following patch into a future
kernel, but it does mean that I might not....

NeilBrown


Signed-off-by: Neil Brown <neilb@suse.de>

### Diffstat output
 ./init/do_mounts_md.c |   26 +++++++++++++++++++++++---
 1 file changed, 23 insertions(+), 3 deletions(-)

diff ./init/do_mounts_md.c~current~ ./init/do_mounts_md.c
--- ./init/do_mounts_md.c~current~	2005-11-28 08:09:13.000000000 +1100
+++ ./init/do_mounts_md.c	2005-11-28 08:40:19.000000000 +1100
@@ -19,6 +19,7 @@ static struct {
 	int partitioned;
 	int pers;
 	int chunk;
+	int vers_major, vers_minor;
 	char *device_names;
 } md_setup_args[MAX_MD_DEVS] __initdata;
 
@@ -78,6 +79,10 @@ static int __init md_setup(char *str)
 	}
 	if (ent >= md_setup_ents)
 		md_setup_ents++;
+
+	md_setup_args[ent].vers_major = 0;
+	md_setup_args[ent].vers_minor = 90;
+
 	switch (get_option(&str, &level)) {	/* RAID Personality */
 	case 2: /* could be 0 or -1.. */
 		if (level == 0 || level == LEVEL_LINEAR) {
@@ -100,7 +105,19 @@ static int __init md_setup(char *str)
 		}
 		/* FALL THROUGH */
 	case 1: /* the first device is numeric */
-		str = str1;
+		if (str[0]=='v' && str[1] == '0')
+			;
+		else if (str[0]=='v' && str[1] == '1') {
+			md_setup_args[ent].vers_major = 1;
+			md_setup_args[ent].vers_minor = 0;
+			if (str[2]=='.' && str[3] == '0')
+				md_setup_args[ent].vers_minor = 0;
+			if (str[2]=='.' && str[3] == '1')
+				md_setup_args[ent].vers_minor = 1;
+			if (str[2]=='.' && str[3] == '2')
+				md_setup_args[ent].vers_minor = 2;
+		} else
+			str = str1;
 		/* FALL THROUGH */
 	case 0:
 		md_setup_args[ent].pers = 0;
@@ -130,6 +147,7 @@ static void __init md_setup_drive(void)
 		char *devname;
 		mdu_disk_info_t dinfo;
 		char name[16], devfs_name[16];
+		mdu_array_info_t ainfo;
 
 		minor = md_setup_args[ent].minor;
 		partitioned = md_setup_args[ent].partitioned;
@@ -182,7 +200,10 @@ static void __init md_setup_drive(void)
 					"array %s\n", name);
 			continue;
 		}
-		if (sys_ioctl(fd, SET_ARRAY_INFO, 0) == -EBUSY) {
+		ainfo.raid_disks = 0; /* flag just setting version */
+		ainfo.major_version = md_setup_args[ent].vers_major;
+		ainfo.minor_version = md_setup_args[ent].vers_minor;
+		if (sys_ioctl(fd, SET_ARRAY_INFO, (long)&ainfo) == -EBUSY) {
 			printk(KERN_WARNING
 			       "md: Ignoring md=%d, already autodetected. (Use raid=noautodetect)\n",
 			       minor);
@@ -192,7 +213,6 @@ static void __init md_setup_drive(void)
 
 		if (md_setup_args[ent].pers) {
 			/* non-persistent */
-			mdu_array_info_t ainfo;
 			ainfo.level = pers_to_level(md_setup_args[ent].pers);
 			ainfo.size = 0;
 			ainfo.nr_disks =0;

Re: Booting from raid1 -- md: invalid raid superblock magic on sdb1

[David M. Strang]

On Sunday November 27 2005 16:56:47, NeilBrown wrote:
> Yes, do_mounts_md assumes v0.90.
> The following patch will allow you to specify the version in the
> kernel parameters, something like
>    md=d0,v1.0,/dev/sda,/dev/sdb
>
> (though I haven't tested it).
> However I'm not at all convinced that I want to go down this path.
>

Nov 27 20:06:53 xenogenesis kernel: md: Skipping autodetection of RAID 
arrays. (raid=noautodetect)
Nov 27 20:06:53 xenogenesis kernel: md: Unknown device name: v1.0

I need to dig into this a bit more; but it didn't care for that syntax too 
much.

> It is not at all hard to create an initramfs which runs mdadm to do
> the right thing.  With mdadm-2.2 (to be released soonish), it will be
> even easier.

> In general I would rather steer away from do_mounts_md.c assembling
> root md arrays, and steer towards using mdadm in an initramfs.  That
> doesn't mean that I won't submit the following patch into a future
> kernel, but it does mean that I might not....

This could be my own ingorance of how initrd works; but I'm looking to boot 
completely from a raid1 mirror -- and have NO 'normal' partitions. Is this 
possible with initrd? I've been doing quite a bit of reading, and most of 
this is me being lead down the path of how crappy 'software assisted' 
hardware raids are. I have a TYAN S5350-1U board -- it came with the TARO 
SO-DIMM M8110 SATA raid controller... well, this controller is based off the 
Adaptec AIC-8110 chipset. From all my digging, short of the basic binary 
only drivers available from download this controller doesn't work for beans 
in Linux. So, I've defaulted to the onboard SATA controller.. and while it 
has a raid controller (6300ESB) it's one of 'software assisted raids' -- I 
saw the dmraid option; but the advice I found was that unless you are dual 
booting to another OS, it makes a lot more sense to use the software raid 
(md) -- I have a quite successful 28 disk raid5 software raid running here 
(many thanks to Neil, for his tweaks to mdadm and advice on recovering it 
each time failure occured) -- so I felt quite confident in md + mdadm. 
Essentially, the end goal -- is if either drive fails, the system should not 
go down. So, I invoked the paritioned MD route; and created it on top of a 
single large partition for each drive. I'm still working out bootloader 
bugs...

So, excuse the rambling -- but in a nutshell, will the following 
configuration work with initrd?

400GB --> single partition --> /dev/sda1    \
                                                                   |---  
/dev/md_d0 ---> 4 partitions
400GB --> single partition --> /dev/sdb1    /

(I hope my ascii drawing comes out in the list!)

Is that feasible with an initrd? Since I'm not intending to have any 
standard partitions.

-- David M. Strang 

Re: Booting from raid1 -- md: invalid raid superblock magic on sdb1

[Ross Vandegrift]

On Sun, Nov 27, 2005 at 09:11:02PM -0500, David M. Strang wrote:
> + mdadm. Essentially, the end goal -- is if either drive fails, the system 
> should not go down. So, I invoked the paritioned MD route; and created it 
> on top of a single large partition for each drive. I'm still working out 
> bootloader bugs...
> 
> So, excuse the rambling -- but in a nutshell, will the following 
> configuration work with initrd?

Yes, you can absolutely boot from RAID1 with initrd.  If you're not an
initrd wizard it will be difficult.  You'll need to make sure that
your initrd has all the necessary device files, the modules for md,
the mdadm binary, and any shared libraries that your mdadm is built
against.

If you're using Debian, mkinitrd can build you an initrd that has
everything needed and works.  It has a few config files in /etc/ that
let you control how things get built, and a cool -k switch that leaves
the temporary directory around so you can easily examine the initrd.

Can't really speak for other distros.  Are you compiling your own
kernels?  If so, I'd strongly suggest abandoning initrd.  It's easy as
pie to boot off md if you have the drivers built into the kernel.
But I do understand that it might not be practical for you to build
your own kernel.



-- 
Ross Vandegrift
ross@lug.udel.edu

"The good Christian should beware of mathematicians, and all those who
make empty prophecies. The danger already exists that the mathematicians
have made a covenant with the devil to darken the spirit and to confine
man in the bonds of Hell."
	--St. Augustine, De Genesi ad Litteram, Book II, xviii, 37

Re: Booting from raid1 -- md: invalid raid superblock magic on sdb1

[David M. Strang]

On Sunday 27 November 2005 21:20:22, Ross Vandegrift wrote:
> Yes, you can absolutely boot from RAID1 with initrd.  If you're not an
> initrd wizard it will be difficult.  You'll need to make sure that
> your initrd has all the necessary device files, the modules for md,
> the mdadm binary, and any shared libraries that your mdadm is built
> against.
>
> If you're using Debian, mkinitrd can build you an initrd that has
> everything needed and works.  It has a few config files in /etc/ that
> let you control how things get built, and a cool -k switch that leaves
> the temporary directory around so you can easily examine the initrd.
>
> Can't really speak for other distros.  Are you compiling your own
> kernels?  If so, I'd strongly suggest abandoning initrd.  It's easy as
> pie to boot off md if you have the drivers built into the kernel.
> But I do understand that it might not be practical for you to build
> your own kernel.

Russ --

I use CRUX (http://www.crux.nu) -- I compile my own kernel; from my breif 
exploration of initrd -- which debian has about a trillion web pages 
dedicated to raids and initrd -- the feeling / impression I had was that 
initrd is mostly used if you cannot compile full support into the kernel.

My concern is, I want to do it the 'right way' -- to me, that is a pure 
kernel boot -- the problem is, the current kernel does not facilitate 
booting raids with superblock1 -- not via automount (which Neil has 
previously said he is quite against), and not natively via do_mounts_md.c. 
Neil has put together a small patch (may need some spit and polish; the 
hardcoded workaround from Raphael is currently working) but said he is 
hesistant to submit it for addition to a future kernel. I don't want to go 
about doing things the wrong way, and journey down the path of being 
'unsupported'. It seems to me, there could be some huge benefits of putting 
some of the mdadm assemble.c code into do_mounts_md.c; I have no issue using 
a workaround / hack for immediate use -- but as I mentioned before, I don't 
want to start a bad habit so to speak. If there is a proper way, I'd rather 
learn (use) it.

-- David M. Strang 

Re: Booting from raid1 -- md: invalid raid superblock magic on sdb1

[Ross Vandegrift]

On Sun, Nov 27, 2005 at 09:33:38PM -0500, David M. Strang wrote:
> I use CRUX (http://www.crux.nu) -- I compile my own kernel; from my breif 
> exploration of initrd -- which debian has about a trillion web pages 
> dedicated to raids and initrd -- the feeling / impression I had was that 
> initrd is mostly used if you cannot compile full support into the kernel.

Well, more generally, it's used when something needs to happen before
the kernel can mount your root partiton.  Sometimes this means DHCPing
for an IP and mounting an NFS drive, it often means loading kernel
modules.  In your case, it means using mdadm to start the RAID
devices.

http://www.faqs.org/docs/evms/x3834.html that link is pretty helpful
information on how to build an initrd manually.  It's aimed at people
using EVMS, but the general lessons it teaches about building the
image are generally sound.

-- 
Ross Vandegrift
ross@lug.udel.edu

"The good Christian should beware of mathematicians, and all those who
make empty prophecies. The danger already exists that the mathematicians
have made a covenant with the devil to darken the spirit and to confine
man in the bonds of Hell."
	--St. Augustine, De Genesi ad Litteram, Book II, xviii, 37

Re: Booting from raid1 -- md: invalid raid superblock magic on sdb1

[David M. Strang]

On Sunday 27 November 2005 22:08:04, Ross Vandegrift wrote:
> Well, more generally, it's used when something needs to happen before
> the kernel can mount your root partiton.  Sometimes this means DHCPing
> for an IP and mounting an NFS drive, it often means loading kernel
> modules.  In your case, it means using mdadm to start the RAID
> devices.
>
> http://www.faqs.org/docs/evms/x3834.html that link is pretty helpful
> information on how to build an initrd manually.  It's aimed at people
> using EVMS, but the general lessons it teaches about building the
> image are generally sound.

Thanks! I've used EVMS in the past... I was trying to grow my raid5. It 
looks like it would have done the job, except it was going to take a week... 
I opted to go the backup, recreate, and restore route.

-- David M. Strang

Re: Booting from raid1 -- md: invalid raid superblock magic on sdb1

[Bill Davidsen]

David M. Strang wrote:

> I've read, and read, and read -- and I'm still not having ANY luck 
> booting completely from a raid1 device.
>
> This is my setup...
>
> sda1 is booting, working great. I'm attempting to transition to a 
> bootable raid1.
>
> sdb1 is a 400GB partition -- it is type FD.
>
> Disk /dev/sdb: 400.0 GB, 400088457216 bytes
> 2 heads, 4 sectors/track, 97677846 cylinders
> Units = cylinders of 8 * 512 = 4096 bytes
>
>   Device Boot      Start         End      Blocks   Id  System
> /dev/sdb1               1    97677846   390711382   fd  Linux raid 
> autodetect
>
> I have created my raid1 mirror with the following command:
>
> mdadm --create /dev/md_d0 -e1 -ap --level=1 --raid-devices=2 
> missing,/dev/sdb1
>
> The raid created correctly, I then partitioned md_d0 to match sda1. 

I hope that's a typo... you need to partition sdb, not the md_d0 raid 
device.

-- 
bill davidsen <davidsen@tmr.com>
  CTO TMR Associates, Inc
  Doing interesting things with small computers since 1979

Re: Booting from raid1 -- md: invalid raid superblock magic on sdb1

[David M. Strang]

Bill Davidsen wrote:
> I hope that's a typo... you need to partition sdb, not the md_d0 raid 
> device.
> 

That's not a typo; md_d0 is a partitionable md device.

-- David

Lilo append= , A suggestion .

[Mr. James W. Laferriere]

 	Hello Neil & All ,
 	I'll bet I am going to get harassed over this , but ...

 	The present form (iirc) of the lilo append statement is

 	append="md=d0,/dev/sda,/dev/sdb"

 	I am wondering how difficult the below would be to code ?
 	This allows a (relatively) short strings to be append'd
 	instead of the sometimes large listing of devices .

 	append="md=d0,UUID=e9e0f605:9ed694c2:3e2002c9:0415c080"

 	Ok ,  I got my asbestos brithes on .  Have at it ;-) .
 		Tia ,  JimL
-- 
+------------------------------------------------------------------+
| James   W.   Laferriere | System    Techniques | Give me VMS     |
| Network        Engineer | 3542 Broken Yoke Dr. |  Give me Linux  |
| babydr@baby-dragons.com | Billings , MT. 59105 |   only  on  AXP |
|  http://www.asteriskhelpdesk.com/cgi-bin/astlance/r.cgi?babydr   |
+------------------------------------------------------------------+

Re: Lilo append= , A suggestion .

[Neil Brown]

On Monday February 13, babydr@baby-dragons.com wrote:
>  	Hello Neil & All ,
>  	I'll bet I am going to get harassed over this , but ...
> 
>  	The present form (iirc) of the lilo append statement is
> 
>  	append="md=d0,/dev/sda,/dev/sdb"
> 
>  	I am wondering how difficult the below would be to code ?
>  	This allows a (relatively) short strings to be append'd
>  	instead of the sometimes large listing of devices .
> 
>  	append="md=d0,UUID=e9e0f605:9ed694c2:3e2002c9:0415c080"
> 
>  	Ok ,  I got my asbestos brithes on .  Have at it ;-) .

This is just the job for an initramfs.  They are *really*easy* to
make, and very flexible.  mdadm-2.2 and later come with a little
script which (tested on Debian) makes a simple initramfs which
will recognise a kernel parameter (as passed by lilo's 'append')
like
        rootuuid=97e58306:2c85fd85:2346b91e:aaca5fee

and will assemble the appropriate array a /dev/md_d0 and will then
mount a filesystem of there as root.  If it doesn't do exactly what
you want, it is fairly easy to modify.

NeilBrown

Re: Lilo append= , A suggestion .

[Luca Berra]

On Mon, Feb 13, 2006 at 09:12:42PM -0700, Mr. James W. Laferriere wrote:
>	Hello Neil & All ,
>	I'll bet I am going to get harassed over this , but ...
>
>	The present form (iirc) of the lilo append statement is
>
>	append="md=d0,/dev/sda,/dev/sdb"
>
>	I am wondering how difficult the below would be to code ?
>	This allows a (relatively) short strings to be append'd
>	instead of the sometimes large listing of devices .
>
>	append="md=d0,UUID=e9e0f605:9ed694c2:3e2002c9:0415c080"
>
>	Ok ,  I got my asbestos brithes on .  Have at it ;-) .
>		Tia ,  JimL
what about all the past threads about in-kernel autodetection?

L.

-- 
Luca Berra -- bluca@comedia.it
        Communication Media & Services S.r.l.
 /"\
 \ /     ASCII RIBBON CAMPAIGN
  X        AGAINST HTML MAIL
 / \