Hallo,
die autodetection unseres Software RAID1 will nicht so ganz funktionieren. Die beiden Platten hängen an sowas hier:
0000:00:1f.1 IDE interface: Intel Corp. 82801EB/ER (ICH5/ICH5R) Ultra \ ATA 100 Storage Controller (rev 02) 0000:00:1f.2 IDE interface: Intel Corp. 82801EB (ICH5) Serial ATA 150 \ Storage Controller (rev 02)
Ein manuelles Aktivieren funktioniert super mit:
fsr:/usr/src/linux-2.6.11# mdadm --assemble --auto /dev/md0 /dev/sda1 /dev/sdb1 mdadm: /dev/md0 has been started with 2 drives.
Die Partitionen der beiden Teile des Arrays sind mit Typ 0xfd markiert:
Disk /dev/sda: 80.0 GB, 80026361856 bytes 255 heads, 63 sectors/track, 9729 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System /dev/sda1 1 9729 78148161 fd Linux raid autodetect
Beim booten sagt dmesg u.a. folgendes:
libata version 1.10 loaded. ata_piix version 1.03 PCI: Setting latency timer of device 0000:00:1f.2 to 64 ata1: SATA max UDMA/133 cmd 0xEFF0 ctl 0xEFE6 bmdma 0xEF60 irq 18 ata2: SATA max UDMA/133 cmd 0xEFA8 ctl 0xEFE2 bmdma 0xEF68 irq 18 ata1: dev 0 cfg 49:2f00 82:346b 83:7d01 84:4003 85:3469 86:3c01 87:4003 88:207f ata1: dev 0 ATA, max UDMA/133, 156301488 sectors: lba48 ata1: dev 0 configured for UDMA/133 scsi0 : ata_piix ata2: dev 0 cfg 49:2f00 82:346b 83:7d01 84:4003 85:3469 86:3c01 87:4003 88:207f ata2: dev 0 ATA, max UDMA/133, 156301488 sectors: lba48 ata2: dev 0 configured for UDMA/133 scsi1 : ata_piix Vendor: ATA Model: ST380817AS Rev: 3.42 Type: Direct-Access ANSI SCSI revision: 05 Vendor: ATA Model: ST380817AS Rev: 3.42 Type: Direct-Access ANSI SCSI revision: 05
<snip>
md: raid0 personality registered as nr 2 md: raid1 personality registered as nr 3 md: raid5 personality registered as nr 4 raid5: automatically using best checksumming function: pIII_sse pIII_sse : 4420.000 MB/sec raid5: using function: pIII_sse (4420.000 MB/sec) md: md driver 0.90.1 MAX_MD_DEVS=256, MD_SB_DISKS=27
<snip>
md: Autodetecting RAID arrays. md: autorun ... md: ... autorun DONE.
<snip>
kobject_register failed for scsi_mod (-17) [<c01ef1ab>] kobject_register+0x5b/0x60 [<c012e251>] mod_sysfs_setup+0x51/0xc0 [<c012f3c1>] load_module+0x7a1/0xa70 [<c012f6e6>] sys_init_module+0x56/0x240 [<c010271f>] syscall_call+0x7/0xb SCSI device sda: 156301488 512-byte hdwr sectors (80026 MB) SCSI device sda: drive cache: write back SCSI device sda: 156301488 512-byte hdwr sectors (80026 MB) SCSI device sda: drive cache: write back sda: sda1 Attached scsi disk sda at scsi0, channel 0, id 0, lun 0 SCSI device sdb: 156301488 512-byte hdwr sectors (80026 MB) SCSI device sdb: drive cache: write back SCSI device sdb: 156301488 512-byte hdwr sectors (80026 MB) SCSI device sdb: drive cache: write back sdb: sdb1 Attached scsi disk sdb at scsi1, channel 0, id 0, lun 0 md: bug in file drivers/md/md.c, line 1513
md: ********************************** md: * <COMPLETE RAID STATE PRINTOUT> * md: ********************************** md0: md: **********************************
md: md0 stopped. md: bind<sdb1> md: bind<sda1>
Kann es sein, daß die Erkennung der Platten fehlschlägt und deswegen das RAID nicht konstruiert werden kann?
Tschau,
andre
Am Montag, den 02.05.2005, 23:47 +0200 schrieb André Schulze:
Hallo,
Hallo André
Ich weiß zwar nichts genaues über das verwendete System und kann daher nicht zielgerichtet drauflos argumentieren, aber wir können ja das Frage-/Antwortspiel spielen.
Dies hier kommt mir etwas merkwürdig vor:
kobject_register failed for scsi_mod (-17) [<c01ef1ab>] kobject_register+0x5b/0x60 [<c012e251>] mod_sysfs_setup+0x51/0xc0 [<c012f3c1>] load_module+0x7a1/0xa70 [<c012f6e6>] sys_init_module+0x56/0x240 [<c010271f>] syscall_call+0x7/0xb
Ist der Treiber für SCSI-Support fest einkompilert? Um welchen Kernel handelt es sich? Ist der Kernel selbst übersetzt oder von einer bestimmten Distribution?
Das folgende ist auch sehr merkwürdig:
md: bug in file drivers/md/md.c, line 1513
Ich bin nicht sicher was das sein könnte. Benutzt du udev auf diesem System? Damit könnte es unter Umständen Probleme geben. Jedenfalls gab/gibts einen Kernel-spezifischen Bug in Verbindung mit udev und Kerneln aus Debian. Hier die Fehlernummer für die dies lesen möchten:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=294404
Ansonsten kann ich ohne weitere Anhaltspunkte im Moment wenig zur Lösung beitragen.
MfG Carsten Luedtke
Carsten Luedtke schrieb:
Am Montag, den 02.05.2005, 23:47 +0200 schrieb André Schulze:
Hallo,
Hallo André
Hi Leute,
Ich weiß zwar nichts genaues über das verwendete System und kann daher nicht zielgerichtet drauflos argumentieren, aber wir können ja das Frage-/Antwortspiel spielen.
Es waer schoen zu wissen, um welche Distro+Kernel und evtl Patches verwendet wurden... evtl auch mal ungeschnipseltes dmesg...
Dies hier kommt mir etwas merkwürdig vor:
kobject_register failed for scsi_mod (-17) [<c01ef1ab>] kobject_register+0x5b/0x60 [<c012e251>] mod_sysfs_setup+0x51/0xc0 [<c012f3c1>] load_module+0x7a1/0xa70 [<c012f6e6>] sys_init_module+0x56/0x240 [<c010271f>] syscall_call+0x7/0xb
ACK
Ist der Treiber für SCSI-Support fest einkompilert? Um welchen Kernel handelt es sich? Ist der Kernel selbst übersetzt oder von einer bestimmten Distribution?
Es scheint, dass der sd_mod Modul "zu spaet" geladen wird, denn die eigentliche Erkennung der Partitionen findet erst nach dem md autodetect statt:
md: md driver 0.90.1 MAX_MD_DEVS=256, MD_SB_DISKS=27 <snip> md: Autodetecting RAID arrays. <snip> kobject_register failed for scsi_mod (-17) [...oops...] SCSI device sda: 156301488 512-byte hdwr sectors (80026 MB) SCSI device sda: drive cache: write back SCSI device sda: 156301488 512-byte hdwr sectors (80026 MB) SCSI device sda: drive cache: write back sda: sda1 Attached scsi disk sda at scsi0, channel 0, id 0, lun 0 SCSI device sdb: 156301488 512-byte hdwr sectors (80026 MB) SCSI device sdb: drive cache: write back SCSI device sdb: 156301488 512-byte hdwr sectors (80026 MB) SCSI device sdb: drive cache: write back sdb: sdb1 Attached scsi disk sdb at scsi1, channel 0, id 0, lun 0 md: bug in file drivers/md/md.c, line 1513
Die Reihenfolge kann ich hier erkennen: 1) sata 2) scsi devices 3) md 4) sd_mod 5) ?! woher kommt das
IMO sind 3 und 4 vertauscht.
Das folgende ist auch sehr merkwürdig:
md: bug in file drivers/md/md.c, line 1513
Ich hab darueber kurz gegoogelt aber nix handfestes gefunden...
Ich bin nicht sicher was das sein könnte. Benutzt du udev auf diesem System? Damit könnte es unter Umständen Probleme geben. Jedenfalls gab/gibts einen Kernel-spezifischen Bug in Verbindung mit udev und Kerneln aus Debian. Hier die Fehlernummer für die dies lesen möchten:
IMO hat es mit udev nix zutun, weil die autodetection waehrend des Bootvorgangs passiert, bevor udev gemounted wird. Der Report ist nur interessant in Konfigurationen, wo das RAID durch mdadm -A -s gestartet wird (im Runlevel 1)
AFAIK wurde das gefixt, mdadm-raid startet vor udev.
Ansonsten kann ich ohne weitere Anhaltspunkte im Moment wenig zur Lösung beitragen.
ACK
Mehr Info plz
MfG Carsten Luedtke
MfG -Dimitri aka Tristan-777
Am Tue den 03 May 2005 um 06:08:21PM +0200 schrieb Dimitri Puzin:
Carsten Luedtke schrieb:
Hallo Dimitri und Carsten,
danke für eure Hinweise, jetzt gehts, hier noch mal die Mail für's Archiv:
Dies hier kommt mir etwas merkwürdig vor:
kobject_register failed for scsi_mod (-17) [<c01ef1ab>] kobject_register+0x5b/0x60 [<c012e251>] mod_sysfs_setup+0x51/0xc0 [<c012f3c1>] load_module+0x7a1/0xa70 [<c012f6e6>] sys_init_module+0x56/0x240 [<c010271f>] syscall_call+0x7/0xb
ACK
Ähm, ja, google hat nix zu dem trace gebracht, ein ähnlichen trace hatte ich auch mit dem 3com modul bekommen.
Ist der Treiber für SCSI-Support fest einkompilert? Um welchen Kernel handelt es sich? Ist der Kernel selbst übersetzt oder von einer bestimmten Distribution?
Es scheint, dass der sd_mod Modul "zu spaet" geladen wird, denn die eigentliche Erkennung der Partitionen findet erst nach dem md autodetect statt:
Richtig, es ist ein Problem der Reihenfolge. Ich hatte übersehen, daß das sd_mod als _Modul_ kompiliert war, dementsprechend werden die Partitionen auf den SATA Platten zu spät erkannt, als daß sie von md gefunden werden könnten. Jetzt geht's.
Das folgende ist auch sehr merkwürdig:
md: bug in file drivers/md/md.c, line 1513
Ich hab darueber kurz gegoogelt aber nix handfestes gefunden...
Ich bin nicht sicher was das sein könnte. Benutzt du udev auf diesem System? Damit könnte es unter Umständen Probleme geben. Jedenfalls
Nein.
Vielleicht noch ein Hinweis zum Anlegen des RAID, man sollte auf jeden Fall ein mdadm --zero-superblock (oder so ähnlich) machen, denn der wird meiner Erfahrung nach nicht aktualisiert. Dies ist z.B. dann ein Problem, wenn man erst ein unpartitioniertes RAID gehabt hat und danach per mdadm --create /dev/md/d0 --auto=part ... ein partitioniertes RAID erzeugt. Der Superblock wird aber nicht verändert und beim Zusammensetzen des RAIDs wird dann nach wie vor ein unpartitioniertes RAID vom Kernel bereitgestellt und man kommt nicht an die darin liegenden Partitionen ran (z.B. /dev/md/d0p1).
Danke,
andre
lug-dd@mailman.schlittermann.de