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