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

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

-
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

On Saturday 26 November 2005 12:16:14, Guillaume Filion wrote:
> Le 05-11-26, =E0 11:18, David M. Strang a =E9crit :
> > 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 con=
fused=20
> by the whole process... :-/
>

Well, actually... I don't use an initrd. All my drivers are straight=20
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=20
from the kernel Documentation is perhaps what is throwing me awry.

-- David M. Strang=20

-
To unsubscribe from this list: send the line "unsubscribe linux-raid" i=
n
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

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

-
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

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

-
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

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



-
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

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

### 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;
-
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

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

-
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

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
-
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

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

-
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

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
-
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

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



-
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 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
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979

-
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

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
-
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

Lilo append= , A suggestion .

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?babyd r |
+----------------------------------------------------------- -------+
-
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: Lilo append= , A suggestion .

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
-
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: Lilo append= , A suggestion .

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
/ \
-
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