RAID 5 array keeps dropping drive on boot

I've got a simple setup with three IDE drives where two disks share a
30mb RAID1 partition for /boot and all three share a 590GB RAID5
array for /

My mdadm.conf looks like this:

DEVICE partitions
ARRAY /dev/md1 level=raid5 num-devices=3 UUID=4b22b17d:
06048bd3:ecec156c:31fabbaf
devices=/dev/hda3,/dev/hdc3,/dev/hdg2
ARRAY /dev/md0 level=raid1 num-devices=2
UUID=7d5c8486:35fff755:f5d34fc2:a12f1f81
devices=/dev/hda1,/dev/hdc1

The UUIDs check out with the devices, and indeed /dev/md0 works
fine. /dev/md1 used to work perfectly, but read on :-p

All the raid partitions are type 0xfd RAID auto-detect.

Recently I had to replace hdc because it crashed. When I got the new
drive, I copied the partition table from hda (using cfdisk) and
hotadded it to md0 and md1.

The problem is that /dev/md1 starts without /dev/hdc3 whenever I boot
the system, so I have to resynchronize each time.

The raid info for /dev/hda3 and /dev/hdg2 is the same, that is

/dev/hda3:
Magic : a92b4efc
Version : 00.90.00
UUID : 4b22b17d:06048bd3:ecec156c:31fabbaf
Creation Time : Tue Jun 7 13:03:54 2005
Raid Level : raid5
Raid Devices : 3
Total Devices : 2
Preferred Minor : 1

Update Time : Mon Nov 7 23:28:38 2005
State : clean
Active Devices : 2
Working Devices : 2
Failed Devices : 1
Spare Devices : 0
Checksum : b0ce8bf5 - correct
Events : 0.366671

Layout : left-symmetric
Chunk Size : 64K

Number Major Minor RaidDevice State
this 0 3 3 0 active sync /dev/hda3

0 0 3 3 0 active sync /dev/hda3
1 1 0 0 1 faulty removed
2 2 34 2 2 active sync /dev/hdg2


/dev/hdc3 doesn't agree to this - it shows all drives as being online.
I just tried rebooting during a synchronization (had to move the
computer), and the state of /dev/hdc3 is now:

/dev/hdc3:
Magic : a92b4efc
Version : 00.90.00
UUID : 4b22b17d:06048bd3:ecec156c:31fabbaf
Creation Time : Tue Jun 7 13:03:54 2005
Raid Level : raid5
Raid Devices : 3
Total Devices : 3
Preferred Minor : 1

Update Time : Mon Nov 7 23:23:24 2005
State : clean
Active Devices : 2
Working Devices : 3
Failed Devices : 1
Spare Devices : 1
Checksum : b0ce8a68 - correct
Events : 0.366603

Layout : left-symmetric
Chunk Size : 64K

Number Major Minor RaidDevice State
this 3 22 3 3 spare /dev/hdc3

0 0 3 3 0 active sync /dev/hda3
1 1 0 0 1 faulty removed
2 2 34 2 2 active sync /dev/hdg2
3 3 22 3 3 spare /dev/hdc3

....but it's not synching.

/proc/mdstat shows

Personalities : [raid1] [raid5]
md0 : active raid1 hda1[0] hdc1[1]
48064 blocks [2/2] [UU]

md1 : active raid5 hda3[0] hdg2[2]
585585152 blocks level 5, 64k chunk, algorithm 2 [3/2] [U_U]

unused devices:

Note that md0, although using hdc, doesn't have any problems and that
hdc doesn't show up as spare on md1.

All three drives are the same model, and they're less than half a
year old.

dmesg says the following:

....
devfs_mk_dev: could not append to parent for md/1
md: md1 stopped.
md: bind
md: bind
raid5: device hda3 operational as raid disk 0
raid5: device hdg2 operational as raid disk 2
raid5: allocated 3164kB for md1
raid5: raid level 5 set md1 active with 2 out of 3 devices, algorithm 2
RAID5 conf printout:
--- rd:3 wd:2 fd:1
disk 0, o:1, dev:hda3
disk 2, o:1, dev:hdg2

I'm a little unsure about that "could not append to parent" part.
Maybe that's the culprit somehow? Then md0 should also be broken
since its output is

devfs_mk_dev: could not append to parent for md/0
md: md0 stopped.
md: bind
md: bind
md: raid1 personality registered as nr 3
raid1: raid set md0 active with 2 out of 2 mirrors

....but it works perfectly.

My thoughts about possible explanations are:

-md drops hdc3 silently at boot ofr some reason. I believe this would
constitute a grave bug

-perhaps hdc3 has weird information in the raid superblock - I've
tried zeroing it before adding though.

-hda3 or hdg2 has information in their superblock that sets that
drive as faulty and that information doesn't get reset after a sync


I've seen two or three posts concerning what seems to me to be the
same problem when I searched through the mailing list archive - I
just tried but could only find one, with the subject line:

RAID-1 mirror keeps mysteriously dropping one partition on boot



I'm running a Debian Sarge system with a 2.6.12-1-k7 stock kernel
(taken from unstable).

mdadm is version 1.9.0 (04 feb. 2005)

I'm all out of ideas atm, so any pointers at all would be greatly
appreciated.

Troels

-
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: RAID 5 array keeps dropping drive on boot

On Monday November 7, marvin@fnuck.dk wrote:
> I've got a simple setup with three IDE drives where two disks share a
> 30mb RAID1 partition for /boot and all three share a 590GB RAID5
> array for /
>
> My mdadm.conf looks like this:
>
> DEVICE partitions
> ARRAY /dev/md1 level=raid5 num-devices=3 UUID=4b22b17d:
> 06048bd3:ecec156c:31fabbaf
> devices=/dev/hda3,/dev/hdc3,/dev/hdg2
> ARRAY /dev/md0 level=raid1 num-devices=2
> UUID=7d5c8486:35fff755:f5d34fc2:a12f1f81
> devices=/dev/hda1,/dev/hdc1

You should remove the "devices=" sections. They aren't causing a
problem in this case, but they could if you happened to change the
name of a device (plug it in somewhere different).

>
> The UUIDs check out with the devices, and indeed /dev/md0 works
> fine. /dev/md1 used to work perfectly, but read on :-p
>
> All the raid partitions are type 0xfd RAID auto-detect.

Are you sure? Really really sure? Particularly hdc3. What is it's
type. Could you
fdisk -l /dev/hdc
just to convince me? Because your problem REALLY looks like the
partition type isn't 0xfd...
You gave lots of detail, which is excellent, and from all that detail,
I cannot see any other possible explanation.

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: RAID 5 array keeps dropping drive on boot

On Nov 8, 2005, at 00:13 , Neil Brown wrote:

> On Monday November 7, marvin@fnuck.dk wrote:
>
>> I've got a simple setup with three IDE drives where two disks share a
>> 30mb RAID1 partition for /boot and all three share a 590GB RAID5
>> array for /
>>
>> My mdadm.conf looks like this:
>>
>> DEVICE partitions
>> ARRAY /dev/md1 level=raid5 num-devices=3 UUID=4b22b17d:
>> 06048bd3:ecec156c:31fabbaf
>> devices=/dev/hda3,/dev/hdc3,/dev/hdg2
>> ARRAY /dev/md0 level=raid1 num-devices=2
>> UUID=7d5c8486:35fff755:f5d34fc2:a12f1f81
>> devices=/dev/hda1,/dev/hdc1
>>
>
> You should remove the "devices=" sections. They aren't causing a
> problem in this case, but they could if you happened to change the
> name of a device (plug it in somewhere different).
>
>
>>
>> The UUIDs check out with the devices, and indeed /dev/md0 works
>> fine. /dev/md1 used to work perfectly, but read on :-p
>>
>> All the raid partitions are type 0xfd RAID auto-detect.
>>
>
> Are you sure? Really really sure? Particularly hdc3. What is it's
> type. Could you
> fdisk -l /dev/hdc
> just to convince me? Because your problem REALLY looks like the
> partition type isn't 0xfd...
> You gave lots of detail, which is excellent, and from all that detail,
> I cannot see any other possible explanation.
>

Unfortunately I'm sure;

Device Boot Start End Blocks Id System
/dev/hdc1 1 6 48163+ fd Linux raid
autodetect
/dev/hdc2 7 30 192780 82 Linux swap /
Solaris
/dev/hdc3 31 36481 292792657+ fd Linux raid
autodetect

The table is identical to the one hda uses.

Originally I created the RAID partitions with the Debian Sarge
installer - and it's worked great up until I replaced hdc.

I just did a little more googling and found this:

http://groups.google.com/group/linux.debian.maint.boot/brows e_thread/
thread/c8d20fc20603b120/46104bd9670312b6?lnk=st&q=raid+dropp ing
+partition+boot&rnum=3#46104bd9670312b6

which describes a Debian installation on a drive structure similar to
mine(except I don't use LVM on top of the RAID5).

It states that it could be a problem having more than one primary
partition for software raid on a drive because mdadm would write a
raid superblock to the disk device and cause chaos.

I checked the drives, and it looked like this:

mdadm: No super block found on /dev/hda (Expected magic a92b4efc, got
00000000)
mdadm: No super block found on /dev/hdc (Expected magic a92b4efc, got
00000000)
mdadm: No super block found on /dev/hdg (Expected magic a92b4efc, got
70e7710e)

So I think I should be safe. Still, all partitions on the drives are
primary partitions. Could that be the explanation?

Regards, Troels
-
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: RAID 5 array keeps dropping drive on boot

On Tuesday November 8, marvin@fnuck.dk wrote:
>
> Unfortunately I'm sure;
>
> Device Boot Start End Blocks Id System
> /dev/hdc1 1 6 48163+ fd Linux raid
> autodetect
> /dev/hdc2 7 30 192780 82 Linux swap /
> Solaris
> /dev/hdc3 31 36481 292792657+ fd Linux raid
> autodetect

Ok, thanks.
So I read your original email again and see:

> I just tried rebooting during a synchronization (had to move the
> computer), and the state of /dev/hdc3 is now:
....
> ...but it's not synching.

I wouldn't expect it to be syncing. You rebooted during a recovery
(onto a spare). This is quite different from a resync (after a crash,
or on a newly created array).
If you reboot during a recovery, you have to start the recovery again
at the start.

Have you actually had the array completely recoverred since swapping
hdc?

>
> So I think I should be safe. Still, all partitions on the drives are
> primary partitions. Could that be the explanation?

No, I don't think you are facing this issue.

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: RAID 5 array keeps dropping drive on boot

> So I read your original email again and see:
>
>
>> I just tried rebooting during a synchronization (had to move the
>> computer), and the state of /dev/hdc3 is now:
>>
> ...
>
>> ...but it's not synching.
>>
>
> I wouldn't expect it to be syncing. You rebooted during a recovery
> (onto a spare). This is quite different from a resync (after a crash,
> or on a newly created array).
> If you reboot during a recovery, you have to start the recovery again
> at the start.
>

Okay, I wasn't sure about that part though - but isn't it supposed to
show up as a spare at least?

Anyway...

> Have you actually had the array completely recoverred since swapping
> hdc?
>

Definitely. I even had the computer running for a couple of days on a
fully restored raid.

All in all I have made 4 or 5 syncs now, each taking about 9 hours.
And I've made sure to shut down the computer cleanly afterwards.


Also, when hdc3 is marked faulty on the superblock on hda3 and hdg2,
shouldn't hdc3's superblock be updated? It seems to me that hdc3 gets
thoroughly ignored.

Since hdc3 is in mdadm.conf I've been under the impression that mdadm
should at least say that it's missing.

Regards, Troels
-
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: RAID 5 array keeps dropping drive on boot

On Tuesday November 8, marvin@fnuck.dk wrote:
>
> All in all I have made 4 or 5 syncs now, each taking about 9 hours.
> And I've made sure to shut down the computer cleanly afterwards.
>

Ok. Can you give me a complete boot log, rather than the edited
version. There might be something important in there.

>
> Also, when hdc3 is marked faulty on the superblock on hda3 and hdg2,
> shouldn't hdc3's superblock be updated? It seems to me that hdc3 gets
> thoroughly ignored.

When hdc3 is marked faulty, it is assumed that it *is* faulty and so
md never tried to write to it again. In particular it does not try to
write a superblock to it. It simply writes a superblock to all
working devices, recording the hdc3 is faulty, and increasing the
event count, so that if hdc3 isn't actually completely faulty, it's
superblock will now be out of date.

>
> Since hdc3 is in mdadm.conf I've been under the impression that mdadm
> should at least say that it's missing.

When would it say that? You aren't using mdadm to assemble the
arrays, you are using auto-detect.
If you use
mdadm --monitor ...

It will warn you about any degraded arrays, whether the device that is
missing is mentioned in mdadm.conf or not.

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: RAID 5 array keeps dropping drive on boot

On Nov 8, 2005, at 01:25 , Neil Brown wrote:

> On Tuesday November 8, marvin@fnuck.dk wrote:
>
>>
>> All in all I have made 4 or 5 syncs now, each taking about 9 hours.
>> And I've made sure to shut down the computer cleanly afterwards.
>>
>>
>
> Ok. Can you give me a complete boot log, rather than the edited
> version. There might be something important in there.
>
>

Okay. This log starts with a sync, after which I reboot to see if the
disk will stay in the RAID.

Note that hdc at this point is placed on a PCI IDE controller, so
it's called hde, i.e. we have hda3, hde3 and hdg2 as disks in md1.
compare with md0, which is hda1 and hde1 and gets detected properly.


Oct 29 20:15:09 localhost kernel: RAID5 conf printout:
Oct 29 20:15:09 localhost kernel: --- rd:3 wd:2 fd:1
Oct 29 20:15:09 localhost kernel: disk 0, o:1, dev:hda3
Oct 29 20:15:09 localhost kernel: disk 1, o:1, dev:hde3
Oct 29 20:15:09 localhost kernel: disk 2, o:1, dev:hdg2
Oct 29 20:15:09 localhost kernel: ..<6>md: syncing RAID array md1
Oct 29 20:15:09 localhost kernel: md: minimum _guaranteed_
reconstruction speed: 1000 KB/sec/disc.
Oct 29 20:15:09 localhost kernel: md: using maximum available idle IO
bandwith (but not more than 200000 KB/sec) for reconstruction.
Oct 29 20:15:09 localhost kernel: md: using 128k window, over a total
of 292792576 blocks.
Oct 30 04:03:05 localhost kernel: md: md1: sync done.
Oct 30 04:03:05 localhost kernel: RAID5 conf printout:
Oct 30 04:03:05 localhost kernel: --- rd:3 wd:3 fd:0
Oct 30 04:03:05 localhost kernel: disk 0, o:1, dev:hda3
Oct 30 04:03:05 localhost kernel: disk 1, o:1, dev:hde3
Oct 30 04:03:05 localhost kernel: disk 2, o:1, dev:hdg2
Oct 30 04:22:42 localhost kernel: Kernel logging (proc) stopped.
Oct 30 04:22:42 localhost kernel: Kernel log daemon terminating.
Oct 30 04:24:44 localhost kernel: klogd 1.4.1#17, log source = /proc/
kmsg started.
Oct 30 04:24:44 localhost kernel: Inspecting /boot/
System.map-2.6.12-1-k7
Oct 30 04:24:44 localhost kernel: Loaded 27770 symbols from /boot/
System.map-2.6.12-1-k7.
Oct 30 04:24:44 localhost kernel: Symbols match kernel version 2.6.12.
Oct 30 04:24:44 localhost kernel: No module symbols loaded - kernel
modules not enabled.
Oct 30 04:24:44 localhost kernel: Linux version 2.6.12-1-k7
(horms@tabatha.lab.ultramonkey.org) (gcc version 4.0.2 20050917
(prerelease) (Debian 4.0.1-8)) #1 Tue Sep 27 13:22:07 JST 2005
Oct 30 04:24:44 localhost kernel: BIOS-provided physical RAM map:
Oct 30 04:24:44 localhost kernel: BIOS-e820: 0000000000000000 -
00000000000a0000 (usable)
Oct 30 04:24:44 localhost kernel: BIOS-e820: 00000000000f0000 -
0000000000100000 (reserved)
Oct 30 04:24:44 localhost kernel: BIOS-e820: 0000000000100000 -
000000001bff0000 (usable)
Oct 30 04:24:44 localhost kernel: BIOS-e820: 000000001bff0000 -
000000001bff3000 (ACPI NVS)
Oct 30 04:24:44 localhost kernel: BIOS-e820: 000000001bff3000 -
000000001c000000 (ACPI data)
Oct 30 04:24:44 localhost kernel: BIOS-e820: 00000000ffff0000 -
0000000100000000 (reserved)
Oct 30 04:24:44 localhost kernel: 0MB HIGHMEM available.
Oct 30 04:24:44 localhost kernel: 447MB LOWMEM available.
Oct 30 04:24:44 localhost kernel: On node 0 totalpages: 114672
Oct 30 04:24:44 localhost kernel: DMA zone: 4096 pages, LIFO batch:1
Oct 30 04:24:44 localhost kernel: Normal zone: 110576 pages, LIFO
batch:31
Oct 30 04:24:44 localhost kernel: HighMem zone: 0 pages, LIFO batch:1
Oct 30 04:24:44 localhost kernel: DMI 2.2 present.
Oct 30 04:24:44 localhost kernel: ACPI: RSDP (v000
VIA694 ) @ 0x000f6bc0
Oct 30 04:24:44 localhost kernel: ACPI: RSDT (v001 VIA694 AWRDACPI
0x42302e31 AWRD 0x00000000) @ 0x1bff3000
Oct 30 04:24:44 localhost kernel: ACPI: FADT (v001 VIA694 AWRDACPI
0x42302e31 AWRD 0x00000000) @ 0x1bff3040
Oct 30 04:24:44 localhost kernel: ACPI: DSDT (v001 VIA694 AWRDACPI
0x00001000 MSFT 0x0100000c) @ 0x00000000
Oct 30 04:24:44 localhost kernel: ACPI: BIOS age (2000) fails cutoff
(2001), acpi=force is required to enable ACPI
Oct 30 04:24:44 localhost kernel: ACPI: Disabling ACPI support
Oct 30 04:24:44 localhost kernel: Allocating PCI resources starting
at 1c000000 (gap: 1c000000:e3ff0000)
Oct 30 04:24:44 localhost kernel: Built 1 zonelists
Oct 30 04:24:44 localhost kernel: Kernel command line: root=/dev/md1 ro
Oct 30 04:24:44 localhost kernel: Local APIC disabled by BIOS -- you
can enable it with "lapic"
Oct 30 04:24:44 localhost kernel: mapped APIC to ffffd000 (01382000)
Oct 30 04:24:44 localhost kernel: Initializing CPU#0
Oct 30 04:24:44 localhost kernel: PID hash table entries: 2048
(order: 11, 32768 bytes)
Oct 30 04:24:44 localhost kernel: Detected 651.493 MHz processor.
Oct 30 04:24:44 localhost kernel: Using tsc for high-res timesource
Oct 30 04:24:44 localhost kernel: Console: colour VGA+ 80x25
Oct 30 04:24:44 localhost kernel: Dentry cache hash table entries:
65536 (order: 6, 262144 bytes)
Oct 30 04:24:44 localhost kernel: Inode-cache hash table entries:
32768 (order: 5, 131072 bytes)
Oct 30 04:24:44 localhost kernel: Memory: 446436k/458688k available
(1692k kernel code, 11660k reserved, 721k data, 176k init, 0k highmem)
Oct 30 04:24:44 localhost kernel: Checking if this processor honours
the WP bit even in supervisor mode... Ok.
Oct 30 04:24:44 localhost kernel: Calibrating delay loop... 1282.04
BogoMIPS (lpj=641024)
Oct 30 04:24:44 localhost kernel: Security Framework v1.0.0 initialized
Oct 30 04:24:44 localhost kernel: SELinux: Disabled at boot.
Oct 30 04:24:44 localhost kernel: Mount-cache hash table entries: 512
Oct 30 04:24:44 localhost kernel: CPU: After generic identify, caps:
0183f9ff c1c3f9ff 00000000 00000000 00000000 00000000 00000000
Oct 30 04:24:44 localhost kernel: CPU: After vendor identify, caps:
0183f9ff c1c3f9ff 00000000 00000000 00000000 00000000 00000000
Oct 30 04:24:44 localhost kernel: CPU: L1 I Cache: 64K (64 bytes/
line), D cache 64K (64 bytes/line)
Oct 30 04:24:44 localhost kernel: CPU: L2 Cache: 512K (64 bytes/line)
Oct 30 04:24:44 localhost kernel: CPU: After all inits, caps:
0183f9ff c1c3f9ff 00000000 00000020 00000000 00000000 00000000
Oct 30 04:24:44 localhost kernel: Intel machine check architecture
supported.
Oct 30 04:24:44 localhost kernel: Intel machine check reporting
enabled on CPU#0.
Oct 30 04:24:44 localhost kernel: CPU: AMD Athlon(tm) Processor
stepping 01
Oct 30 04:24:44 localhost kernel: Enabling fast FPU save and
restore... done.
Oct 30 04:24:44 localhost kernel: Checking 'hlt' instruction... OK.
Oct 30 04:24:44 localhost kernel: checking if image is initramfs...it
isn't (bad gzip magic numbers); looks like an initrd
Oct 30 04:24:44 localhost kernel: Freeing initrd memory: 4820k freed
Oct 30 04:24:44 localhost kernel: NET: Registered protocol family 16
Oct 30 04:24:44 localhost kernel: PCI: PCI BIOS revision 2.10 entry
at 0xfb270, last bus=1
Oct 30 04:24:44 localhost kernel: PCI: Using configuration type 1
Oct 30 04:24:44 localhost kernel: mtrr: v2.0 (20020519)
Oct 30 04:24:44 localhost kernel: ACPI: Subsystem revision 20050309
Oct 30 04:24:44 localhost kernel: ACPI: Interpreter disabled.
Oct 30 04:24:44 localhost kernel: Linux Plug and Play Support v0.97
(c) Adam Belay
Oct 30 04:24:44 localhost kernel: pnp: PnP ACPI: disabled
Oct 30 04:24:44 localhost kernel: PnPBIOS: Scanning system for PnP
BIOS support...
Oct 30 04:24:44 localhost kernel: PnPBIOS: Found PnP BIOS
installation structure at 0xc00fbfa0
Oct 30 04:24:44 localhost kernel: PnPBIOS: PnP BIOS version 1.0,
entry 0xf0000:0xbfd0, dseg 0xf0000
Oct 30 04:24:44 localhost kernel: PnPBIOS: 10 nodes reported by PnP
BIOS; 10 recorded by driver
Oct 30 04:24:44 localhost kernel: PCI: Probing PCI hardware
Oct 30 04:24:44 localhost kernel: PCI: Probing PCI hardware (bus 00)
Oct 30 04:24:44 localhost kernel: Boot video device is 0000:01:00.0
Oct 30 04:24:44 localhost kernel: PCI: Using IRQ router VIA
[1106/0686] at 0000:00:07.0
Oct 30 04:24:44 localhost kernel: VFS: Disk quotas dquot_6.5.1
Oct 30 04:24:44 localhost kernel: Dquot-cache hash table entries:
1024 (order 0, 4096 bytes)
Oct 30 04:24:44 localhost kernel: devfs: 2004-01-31 Richard Gooch
(rgooch@atnf.csiro.au)
Oct 30 04:24:44 localhost kernel: devfs: boot_options: 0x0
Oct 30 04:24:44 localhost kernel: Initializing Cryptographic API
Oct 30 04:24:44 localhost kernel: PCI: Disabling Via external APIC
routing
Oct 30 04:24:44 localhost kernel: isapnp: Scanning for PnP cards...
Oct 30 04:24:44 localhost kernel: isapnp: No Plug & Play device found
Oct 30 04:24:44 localhost kernel: PNP: PS/2 controller doesn't have
AUX irq; using default 0xc
Oct 30 04:24:44 localhost kernel: PNP: PS/2 Controller [PNP0303] at
0x60,0x64 irq 112
Oct 30 04:24:44 localhost kernel: serio: i8042 AUX port at 0x60,0x64
irq 12
Oct 30 04:24:44 localhost kernel: serio: i8042 KBD port at 0x60,0x64
irq 1
Oct 30 04:24:44 localhost kernel: Serial: 8250/16550 driver
$Revision: 1.90 $ 48 ports, IRQ sharing enabled
Oct 30 04:24:44 localhost kernel: io scheduler noop registered
Oct 30 04:24:44 localhost kernel: io scheduler anticipatory registered
Oct 30 04:24:44 localhost kernel: io scheduler deadline registered
Oct 30 04:24:44 localhost kernel: io scheduler cfq registered
Oct 30 04:24:44 localhost kernel: RAMDISK driver initialized: 16 RAM
disks of 8192K size 1024 blocksize
Oct 30 04:24:44 localhost kernel: NET: Registered protocol family 2
Oct 30 04:24:44 localhost kernel: IP: routing cache hash table of
4096 buckets, 32Kbytes
Oct 30 04:24:44 localhost kernel: TCP established hash table entries:
16384 (order: 5, 131072 bytes)
Oct 30 04:24:44 localhost kernel: TCP bind hash table entries: 16384
(order: 4, 65536 bytes)
Oct 30 04:24:44 localhost kernel: TCP: Hash tables configured
(established 16384 bind 16384)
Oct 30 04:24:44 localhost kernel: RAMDISK: cramfs filesystem found at
block 0
Oct 30 04:24:44 localhost kernel: RAMDISK: Loading 4820KiB [1 disk]
into ram disk... |^H/^H-^H\^H|^H/^H-^H\^H|^H/^H-^H\^H|^H/^H-^H\^H|^H/
^H-^H\^H|^H/^H-^H\^H|^H/^H-^H\^H|^H/^H-^H\^H|^H/^H-^H\^H|^H/ ^H-^H\^H|
^H/^H-^H\^H|^H/^H-^H\^H|^H/^H-^H\^H|^H/^H-^H\^H|^H/^H-^H\^H| ^H/^H-^H
\^H|^H/^H-^H\^H|^H/^H-^H\^H|^H/^H-^H\^H|^H/^H-^H\^H|^H/^H-^H \^H|^H/^H-
^H\^H|^H/^H-^H\^H|^H/^H-^H\^H|^H/^H-^H\^H|^H/^H-^H\^H|^H/^H- ^H\^H|^H/
^H-^H\^H|^H/^H-^H\^H|^H/^H-^H\^H|^H/^H-^H\^H|^H/^H-^H\^H|^H/ ^H-^H\^H|
^H/^H-^H\^H|^H/^H-^H\^H|^H/^H-^H\^H|^H/^H-^H\^H|^H/^H-^H\^H| ^H/^H-^H
\^H|^H/^H-^H\^H|^H/^H-^H\^H|^H/^H-^H\^H|^H/^H-^H\^H|^H/^H-^H \^H|^H/^H-
^H\^H|^H/^H-^H\^H|^H/^H-^H\^H|^H/^H-^H\^H|^H/^H-^H\^H|^H/^H- ^H\^H|^H/
^H-^H\^H|^H/^H-^H\^H|^H/^H-^H\^H|^H/^H-^H\^H|^H/^H-^H\^H|^H/ ^H-^H\^H|
^H/^H-^H\^H|^H/^H-^H\^H|^H/^H-^H\^H|^H/^H-^H\^H|^H/^H-^H\^H| ^H/^H-^H
\^H|^H/^H-^H\^H|^H/^H-^H\^H|^H/^H-^H\^H|^H/^H-^H\^H|^H/^H-^H \^H|^H/^H-
^H\^H|^H/^H-^H\^H|^H/^H-^H\^H|^H/^H-^H\^H|^H/^H-^H\^H|^H/^H- ^H\^H|^H/
^H-^H\^H|^H/^H-^H\^H|^H/^Hdone.
Oct 30 04:24:44 localhost kernel: VFS: Mounted root (cramfs
filesystem) readonly.
Oct 30 04:24:44 localhost kernel: Freeing unused kernel memory: 176k
freed
Oct 30 04:24:44 localhost kernel: Capability LSM initialized
Oct 30 04:24:44 localhost kernel: NET: Registered protocol family 1
Oct 30 04:24:44 localhost kernel: raid5: measuring checksumming speed
Oct 30 04:24:44 localhost kernel: 8regs : 980.000 MB/sec
Oct 30 04:24:44 localhost kernel: 8regs_prefetch: 824.000 MB/sec
Oct 30 04:24:44 localhost kernel: 32regs : 668.000 MB/sec
Oct 30 04:24:44 localhost kernel: 32regs_prefetch: 596.000 MB/sec
Oct 30 04:24:44 localhost kernel: pII_mmx : 1744.000 MB/sec
Oct 30 04:24:44 localhost kernel: p5_mmx : 2328.000 MB/sec
Oct 30 04:24:44 localhost kernel: raid5: using function: p5_mmx
(2328.000 MB/sec)
Oct 30 04:24:44 localhost kernel: md: md driver 0.90.1
MAX_MD_DEVS=256, MD_SB_DISKS=27
Oct 30 04:24:44 localhost kernel: md: raid5 personality registered as
nr 4
Oct 30 04:24:44 localhost kernel: SCSI subsystem initialized
Oct 30 04:24:44 localhost kernel: libata version 1.11 loaded.
Oct 30 04:24:44 localhost kernel: Uniform Multi-Platform E-IDE driver
Revision: 7.00alpha2
Oct 30 04:24:44 localhost kernel: ide: Assuming 33MHz system bus
speed for PIO modes; override with idebus=xx
Oct 30 04:24:44 localhost kernel: VP_IDE: IDE controller at PCI slot
0000:00:07.1
Oct 30 04:24:44 localhost kernel: PCI: Via IRQ fixup for
0000:00:07.1, from 255 to 0
Oct 30 04:24:44 localhost kernel: VP_IDE: chipset revision 16
Oct 30 04:24:44 localhost kernel: VP_IDE: not 100%% native mode: will
probe irqs later
Oct 30 04:24:44 localhost kernel: VP_IDE: VIA vt82c686a (rev 22) IDE
UDMA66 controller on pci0000:00:07.1
Oct 30 04:24:44 localhost kernel: ide0: BM-DMA at 0xc000-0xc007,
BIOS settings: hda:DMA, hdb:pio
Oct 30 04:24:44 localhost kernel: Probing IDE interface ide0...
Oct 30 04:24:44 localhost kernel: hda: ST3300831A, ATA DISK drive
Oct 30 04:24:44 localhost kernel: ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Oct 30 04:24:44 localhost kernel: PDC20268: IDE controller at PCI
slot 0000:00:09.0
Oct 30 04:24:44 localhost kernel: PCI: Found IRQ 15 for device
0000:00:09.0
Oct 30 04:24:44 localhost kernel: PCI: Sharing IRQ 15 with 0000:00:07.2
Oct 30 04:24:44 localhost kernel: PCI: Sharing IRQ 15 with 0000:00:07.3
Oct 30 04:24:44 localhost kernel: PDC20268: chipset revision 2
Oct 30 04:24:44 localhost kernel: PDC20268: 100%% native mode on irq 15
Oct 30 04:24:44 localhost kernel: ide2: BM-DMA at 0xdc00-0xdc07,
BIOS settings: hde:pio, hdf:pio
Oct 30 04:24:44 localhost kernel: ide3: BM-DMA at 0xdc08-0xdc0f,
BIOS settings: hdg:pio, hdh:pio
Oct 30 04:24:44 localhost kernel: Probing IDE interface ide2...
Oct 30 04:24:44 localhost kernel: hde: ST3300831A, ATA DISK drive
Oct 30 04:24:44 localhost kernel: ide2 at 0xcc00-0xcc07,0xd002 on irq 15
Oct 30 04:24:44 localhost kernel: Probing IDE interface ide3...
Oct 30 04:24:44 localhost kernel: hdg: ST3300831A, ATA DISK drive
Oct 30 04:24:44 localhost kernel: ide3 at 0xd400-0xd407,0xd802 on irq 15
Oct 30 04:24:44 localhost kernel: Probing IDE interface ide1...
Oct 30 04:24:44 localhost kernel: Probing IDE interface ide4...
Oct 30 04:24:44 localhost kernel: Probing IDE interface ide5...
Oct 30 04:24:44 localhost kernel: hda: max request size: 1024KiB
Oct 30 04:24:44 localhost kernel: hda: 586072368 sectors (300069 MB)
w/8192KiB Cache, CHS=36481/255/63, UDMA(66)
Oct 30 04:24:44 localhost kernel: hda: cache flushes supported
Oct 30 04:24:44 localhost kernel: /dev/ide/host0/bus0/target0/lun0:
p1 p2 p3
Oct 30 04:24:44 localhost kernel: hde: max request size: 1024KiB
Oct 30 04:24:44 localhost kernel: hde: 586072368 sectors (300069 MB)
w/8192KiB Cache, CHS=36481/255/63, UDMA(100)
Oct 30 04:24:44 localhost kernel: hde: cache flushes supported
Oct 30 04:24:44 localhost kernel: /dev/ide/host2/bus0/target0/lun0:
p1 p2 p3
Oct 30 04:24:44 localhost kernel: hdg: max request size: 1024KiB
Oct 30 04:24:44 localhost kernel: hdg: 586072368 sectors (300069 MB)
w/8192KiB Cache, CHS=36481/255/63, UDMA(100)
Oct 30 04:24:44 localhost kernel: hdg: cache flushes supported
Oct 30 04:24:44 localhost kernel: /dev/ide/host2/bus1/target0/lun0:
p1 p2
Oct 30 04:24:44 localhost kernel: devfs_mk_dev: could not append to
parent for md/1
Oct 30 04:24:44 localhost kernel: md: md1 stopped.
Oct 30 04:24:44 localhost kernel: md: bind
Oct 30 04:24:44 localhost kernel: md: bind
Oct 30 04:24:44 localhost kernel: raid5: device hda3 operational as
raid disk 0
Oct 30 04:24:44 localhost kernel: raid5: device hdg2 operational as
raid disk 2
Oct 30 04:24:44 localhost kernel: raid5: allocated 3164kB for md1
Oct 30 04:24:44 localhost kernel: raid5: raid level 5 set md1 active
with 2 out of 3 devices, algorithm 2
Oct 30 04:24:44 localhost kernel: RAID5 conf printout:
Oct 30 04:24:44 localhost kernel: --- rd:3 wd:2 fd:1
Oct 30 04:24:44 localhost kernel: disk 0, o:1, dev:hda3
Oct 30 04:24:44 localhost kernel: disk 2, o:1, dev:hdg2
Oct 30 04:24:44 localhost kernel: kjournald starting. Commit
interval 5 seconds
Oct 30 04:24:44 localhost kernel: EXT3-fs: mounted filesystem with
ordered data mode.
Oct 30 04:24:44 localhost kernel: Adding 192772k swap on /dev/hda2.
Priority:-1 extents:1
Oct 30 04:24:44 localhost kernel: Unable to find swap-space signature
Oct 30 04:24:44 localhost kernel: Adding 240932k swap on /dev/hdg1.
Priority:-2 extents:1
Oct 30 04:24:44 localhost kernel: EXT3 FS on md1, internal journal
Oct 30 04:24:44 localhost kernel: Generic RTC Driver v1.07
Oct 30 04:24:44 localhost kernel: device-mapper: 4.4.0-ioctl
(2005-01-12) initialised: dm-devel@redhat.com
Oct 30 04:24:44 localhost kernel: devfs_mk_dev: could not append to
parent for md/0
Oct 30 04:24:44 localhost kernel: md: md0 stopped.
Oct 30 04:24:44 localhost kernel: md: bind
Oct 30 04:24:44 localhost kernel: md: bind
Oct 30 04:24:44 localhost kernel: md: raid1 personality registered as
nr 3
Oct 30 04:24:44 localhost kernel: raid1: raid set md0 active with 2
out of 2 mirrors
Oct 30 04:24:44 localhost kernel: kjournald starting. Commit
interval 5 seconds
Oct 30 04:24:44 localhost kernel: EXT3 FS on md0, internal journal
Oct 30 04:24:44 localhost kernel: EXT3-fs: mounted filesystem with
ordered data mode.
Oct 30 04:24:44 localhost kernel: Unable to find swap-space signature
Oct 30 04:24:44 localhost kernel: parport_pc: VIA 686A/8231 detected
Oct 30 04:24:44 localhost kernel: parport_pc: probing current
configuration
Oct 30 04:24:44 localhost kernel: parport_pc: Current parallel port
base: 0x0
Oct 30 04:24:44 localhost kernel: parport_pc: VIA parallel port
disabled in BIOS
Oct 30 04:24:44 localhost kernel: PCI: Found IRQ 11 for device
0000:00:0a.0
Oct 30 04:24:44 localhost kernel: 3c59x: Donald Becker and others.
www.scyld.com/network/vortex.html
Oct 30 04:24:44 localhost kernel: 0000:00:0a.0: 3Com PCI 3c905B
Cyclone 100baseTx at 0xe000. Vers LK1.1.19
Oct 30 04:24:44 localhost kernel: Creative EMU10K1 PCI Audio Driver,
version 0.20a, 13:28:40 Sep 27 2005
Oct 30 04:24:44 localhost kernel: PCI: Found IRQ 10 for device
0000:00:0c.0
Oct 30 04:24:44 localhost kernel: emu10k1: EMU10K1 rev 7 model 0x8027
found, IO at 0xe400-0xe41f, IRQ 10
Oct 30 04:24:44 localhost kernel: ac97_codec: AC97 codec, id: TRA35
(TriTech TR A5)
Oct 30 04:24:44 localhost kernel: usbcore: registered new driver usbfs
Oct 30 04:24:44 localhost kernel: usbcore: registered new driver hub
Oct 30 04:24:44 localhost kernel: USB Universal Host Controller
Interface driver v2.2
Oct 30 04:24:44 localhost kernel: PCI: Found IRQ 15 for device
0000:00:07.2
Oct 30 04:24:44 localhost kernel: PCI: Sharing IRQ 15 with 0000:00:07.3
Oct 30 04:24:44 localhost kernel: PCI: Sharing IRQ 15 with 0000:00:09.0
Oct 30 04:24:44 localhost kernel: uhci_hcd 0000:00:07.2: VIA
Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller
Oct 30 04:24:44 localhost kernel: uhci_hcd 0000:00:07.2: new USB bus
registered, assigned bus number 1
Oct 30 04:24:44 localhost kernel: uhci_hcd 0000:00:07.2: irq 15, io
base 0x0000c400
Oct 30 04:24:44 localhost kernel: hub 1-0:1.0: USB hub found
Oct 30 04:24:44 localhost kernel: hub 1-0:1.0: 2 ports detected
Oct 30 04:24:44 localhost kernel: PCI: Found IRQ 15 for device
0000:00:07.3
Oct 30 04:24:44 localhost kernel: PCI: Sharing IRQ 15 with 0000:00:07.2
Oct 30 04:24:44 localhost kernel: PCI: Sharing IRQ 15 with 0000:00:09.0
Oct 30 04:24:44 localhost kernel: uhci_hcd 0000:00:07.3: VIA
Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (#2)
Oct 30 04:24:44 localhost kernel: uhci_hcd 0000:00:07.3: new USB bus
registered, assigned bus number 2
Oct 30 04:24:44 localhost kernel: uhci_hcd 0000:00:07.3: irq 15, io
base 0x0000c800
Oct 30 04:24:44 localhost kernel: hub 2-0:1.0: USB hub found
Oct 30 04:24:44 localhost kernel: hub 2-0:1.0: 2 ports detected
Oct 30 04:24:44 localhost kernel: Linux agpgart interface v0.101 (c)
Dave Jones
Oct 30 04:24:44 localhost kernel: agpgart: Detected VIA KX133 chipset
Oct 30 04:24:44 localhost kernel: agpgart: AGP aperture is 4M @
0xdb000000
Oct 30 04:24:44 localhost kernel: pci_hotplug: PCI Hot Plug PCI Core
version: 0.5
Oct 30 04:24:44 localhost kernel: shpchp: acpi_shpchprm:get_device
PCI ROOT HID fail=0x1001
Oct 30 04:24:44 localhost kernel: Linux video capture interface: v1.00
Oct 30 04:24:44 localhost kernel: bttv: driver version 0.9.15 loaded
Oct 30 04:24:44 localhost kernel: bttv: using 8 buffers with 2080k
(520 pages) each for capture
Oct 30 04:24:44 localhost kernel: bttv: Bt8xx card found (0).
Oct 30 04:24:44 localhost kernel: PCI: Found IRQ 12 for device
0000:00:0b.0
Oct 30 04:24:44 localhost kernel: PCI: Sharing IRQ 12 with 0000:00:0b.1
Oct 30 04:24:44 localhost kernel: bttv0: Bt878 (rev 17) at 0000:00:0b.
0, irq: 12, latency: 32, mmio: 0xdb405000
Oct 30 04:24:44 localhost kernel: bttv0: using: *** UNKNOWN/GENERIC
*** [card=0,autodetected]
Oct 30 04:24:44 localhost kernel: bttv0: gpio: en=00000000,
out=00000000 in=003fffff [init]
Oct 30 04:24:44 localhost kernel: tveeprom(bttv internal): Huh, no
eeprom present (err=-121)?
Oct 30 04:24:44 localhost kernel: bttv0: using tuner=-1
Oct 30 04:24:44 localhost kernel: bttv0: i2c: checking for MSP34xx @
0x80... not found
Oct 30 04:24:44 localhost kernel: bttv0: i2c: checking for TDA9875 @
0xb0... not found
Oct 30 04:24:44 localhost kernel: bttv0: i2c: checking for TDA7432 @
0x8a... not found
Oct 30 04:24:44 localhost kernel: bttv0: i2c: checking for TDA9887 @
0x86... not found
Oct 30 04:24:44 localhost kernel: bttv0: registered device video0
Oct 30 04:24:44 localhost kernel: bttv0: registered device vbi0
Oct 30 04:24:44 localhost kernel: bt878: AUDIO driver version 0.0.0
loaded
Oct 30 04:24:44 localhost kernel: bt878: Bt878 AUDIO function found (0).
Oct 30 04:24:44 localhost kernel: PCI: Found IRQ 12 for device
0000:00:0b.1
Oct 30 04:24:44 localhost kernel: PCI: Sharing IRQ 12 with 0000:00:0b.0
Oct 30 04:24:44 localhost kernel: bt878(0): Bt878 (rev 17) at 00:0b.
1, irq: 12, latency: 32, memory: 0xdb406000
Oct 30 04:24:44 localhost kernel: btaudio: driver version 0.7 loaded
[digital+analog]
Oct 30 04:24:44 localhost kernel: gameport: EMU10K1 is pci0000:00:0c.
1/gameport0, io 0xe800, speed 1242kHz
Oct 30 04:24:44 localhost kernel: input: PC Speaker
Oct 30 04:24:44 localhost kernel: PCI: Found IRQ 11 for device
0000:00:0a.0
Oct 30 04:24:44 localhost kernel: NET: Registered protocol family 17
Oct 30 04:24:44 localhost kernel: NET: Registered protocol family 10
Oct 30 04:24:44 localhost kernel: Disabled Privacy Extensions on
device c032f880(lo)
Oct 30 04:24:44 localhost kernel: IPv6 over IPv4 tunneling driver
Oct 30 04:24:49 localhost kernel: eth0: no IPv6 routers present

And then I do yet another hotadd:

Oct 30 04:56:42 localhost kernel: md: bind
Oct 30 04:56:42 localhost kernel: RAID5 conf printout:
Oct 30 04:56:42 localhost kernel: --- rd:3 wd:2 fd:1
Oct 30 04:56:42 localhost kernel: disk 0, o:1, dev:hda3
Oct 30 04:56:42 localhost kernel: disk 1, o:1, dev:hde3
Oct 30 04:56:42 localhost kernel: disk 2, o:1, dev:hdg2
Oct 30 04:56:42 localhost kernel: ..<6>md: syncing RAID array md1
Oct 30 04:56:42 localhost kernel: md: minimum _guaranteed_
reconstruction speed: 1000 KB/sec/disc.
Oct 30 04:56:42 localhost kernel: md: using maximum available idle IO
bandwith (but not more than 200000 KB/sec) for reconstruction.
Oct 30 04:56:42 localhost kernel: md: using 128k window, over a total
of 292792576 blocks.

...and then it gets boring :-)


Regards, Troels



-
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: RAID 5 array keeps dropping drive on boot

On Tuesday November 8, marvin@fnuck.dk wrote:
>
> On Nov 8, 2005, at 01:25 , Neil Brown wrote:
>
> > On Tuesday November 8, marvin@fnuck.dk wrote:
> >
> >>
> >> All in all I have made 4 or 5 syncs now, each taking about 9 hours.
> >> And I've made sure to shut down the computer cleanly afterwards.
> >>
> >>
> >
> > Ok. Can you give me a complete boot log, rather than the edited
> > version. There might be something important in there.
> >
> >
>
> Okay. This log starts with a sync, after which I reboot to see if the
> disk will stay in the RAID.
>
> Note that hdc at this point is placed on a PCI IDE controller, so
> it's called hde, i.e. we have hda3, hde3 and hdg2 as disks in md1.
> compare with md0, which is hda1 and hde1 and gets detected properly.
>

Thanks.
You are booting with a ramdisk which loads various modules including
raid, and then attempts to assemble the raid arrays.
It is not using auto-detect to assemble the arrays (so the partition
type is irrelevant).
It is not using 'raidstart' to assemble the arrays (which is good, and
raid start is broken).
So it must be using mdadm (or mdassemble).

Can you find that ramdisk (probably in /boot/initrd* somewhere), mount
it, (-t cramfs -o loop) and look inside it.
Look particularly for /etc/mdadm.conf. but look around for anything
else that might be related to md or raid.

.... actually, you said which distribution you were using (Debian) so I
should be able to figure it out from that... Hm.. mkinitrd in pretty
broken in debian wrt mdadm :-(
You should find some script called 'md-1script' or something like that
which has something like

mdadm -A /dev/md1 -R -u 4b22b17d:06048bd3:ecec156c:31fabbaf /dev/hda3 /dev..

This is probably broken.

Maybe if you just run mkinitrd again while the array is fully working,
it might boot properly next time.
Someone needs to fix Debian's mkinitrd script....

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: RAID 5 array keeps dropping drive on boot

On Nov 8, 2005, at 02:55 , Neil Brown wrote:



> Can you find that ramdisk (probably in /boot/initrd* somewhere), mount
> it, (-t cramfs -o loop) and look inside it.
> Look particularly for /etc/mdadm.conf. but look around for anything
> else that might be related to md or raid.
>
> ... actually, you said which distribution you were using (Debian) so I
> should be able to figure it out from that... Hm.. mkinitrd in pretty
> broken in debian wrt mdadm :-(
> You should find some script called 'md-1script' or something like that
> which has something like
>
> mdadm -A /dev/md1 -R -u 4b22b17d:06048bd3:ecec156c:31fabbaf /
> dev/hda3 /dev..
>
> This is probably broken.
>

Ah. In the file etc/script I found the line

mdadm -A /dev/md1 -R -u 4b22b17d:06048bd3:ecec156c:31fabbaf /dev/
hda3 /dev/hdg2

-wouldn't the best thing just be to add /dev/hdc3 there?

I'm terribly sorry, but it seems I've been wasting your time on

a) a Debian-specific question and

b) a problem I've caused myself.

You see, originally I was using a 2.4.17 kernel when the old drive
crashed, but when I tried resyncing, the system froze.
Therefore I upgraded to the 2.6.12 kernel which had no problems
syncing...but of course only hda3 and hdg2 were active at the time of
installation, so the last drive didn't make it into the initrd image.

However, you've been incredibly helpful. You've solved my problem,
thanks!

Troels
-
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: RAID 5 array keeps dropping drive on boot

On Tuesday November 8, marvin@fnuck.dk wrote:
>
> Ah. In the file etc/script I found the line
>
> mdadm -A /dev/md1 -R -u 4b22b17d:06048bd3:ecec156c:31fabbaf /dev/
> hda3 /dev/hdg2
>
> -wouldn't the best thing just be to add /dev/hdc3 there?
>

Yes, however a cramfs filesystem is write-only. "Just adding it here"
is easier said than done. "mkinitrd" should try to create a brand new
cramfs filesystem for you, and might get it right.

>
> However, you've been incredibly helpful. You've solved my problem,
> thanks!

My pleasure. You've helped me learn something about they ways people
(i.e. Debian mkinitrd in this case) misused my creations (mdadm), and
that should help me to make them better - or at least better
documented - in future.

All the best,

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