Festplattenerkennung von Etch

[laomedon]

Hallo Leute...

seit kurzem habe ich debian etch installiert und habe probleme mit der hdd erkennung;
also das system bootet schon ordnungsgemäß... nur wird die platte mal als hda und mal als hde erkannt, immer in abwechselung mit dem cdrom
da ich /boot auf eigene part. installiert habe, muss ich immer mit mount oder fstab korrigieren...

physikalisch ist der cdrom an dem ersten ide100 port angeschlossen und die hdd an dem raid bus controller via vt6410 ata133. (gigabyte board)

mit ubuntu 6.10 war es kein problem... die platte war immer als hde erkannt worden.

hat jemand eine ahnung voran es liegen konnte? (währe ich sehr dankbar)!

viele grüße, peter

[Six]

Hallo und willkommen im df.de!

Dein Problem entsteht aus dem Umstand, daß die Platte an einem PCI-Controller hängt und das CD-ROM an einem Onboard-Controller. Da es reine Glückssache ist, welcher der beiden Chips sich zuerst meldet und dementsprechend welches Modul zuerst geladen wird, kann man dem Problem auf zweierlei Art entgegentreten.

1) Man kompiliert die Unterstützung für einen der beiden Controller fest in den Kernel und für den anderen als Modul. Dann wird immer zuerst der einkompilierte Controller erkannt.

2) Man benutzt sogn. "persistent Identifiers". Das ist die Methode, die Ubuntu und Mandrake benutzen, und zwar sogn. UUIDs. Es geht auch mit sogn. Labels; diese Methode verwenden Red Hat/Fedora und SUSE. Es gibt nur den Unterschied, daß Labels häufiger nicht eindeutig sind, während UUIDs selten nicht eindeutig sind, funktional werden beide gleich gehandhabt.

Diese Sidux-Seite erklärt ganz nett, wie es geht: http://manual.sidux.com/de/part-uuid-de.htm

PS: die Seite unterschlägt leider, daß man mit dem Befehl blkid evtl. existierende UUIDs/Label ermitteln kann.

[laomedon]

halo six,

danke für den sehr hilfreichen support!

habe mich für den schnellen weg über fstab mich entschlossen, und es funktioniert zumind. mit dem booten;
die hdd allerdings wird immer noch mal als hda oder hde bezeichnet... /boot wird aber sauber erkannt

so sieht es bei mir aus:

]# /etc/fstab: static file system information.
#
# <file system> <mount point> <type> <options> <dump> <pass>
proc /proc proc defaults 0 0
/dev/mapper/vg_dom0-lvroot / ext3 defaults,errors=remount-ro 0 1
#/dev/hde1 /boot ext3 defaults 0 2
/dev/disk/by-uuid/f250ee05-eea3-4599-8945-d51c99805292 /boot ext3 defaults 0 2
/dev/mapper/vg_dom0-lvhome /home ext3 defaults 0 2
/dev/mapper/vg_dom0-lvtmp /tmp ext3 defaults 0 2
/dev/mapper/vg_dom0-lvusr /usr ext3 defaults 0 2
/dev/mapper/vg_dom0-lvvar /var ext3 defaults 0 2
/dev/mapper/vg_dom0-lvswap none swap sw 0 0
#/dev/hda /media/cdrom0 udf,iso9660 user,noauto 0 0
#/dev/fd0 /media/floppy0 auto rw,user,noauto 0 0
#/dev/sda1 /media/usb0 auto rw,user,noauto 0 0

BY-UUID
insgesamt 0
drwxr-xr-x 2 root root 80 2007-03-23 09:57 .
drwxr-xr-x 6 root root 120 2007-03-23 09:57 ..
lrwxrwxrwx 1 root root 10 2007-03-23 09:56 f250ee05-eea3-4599-8945-d51c99805292 -> ../../hde1
lrwxrwxrwx 1 root root 10 2007-03-23 09:57 F4DB-142F -> ../../sda1

BY-ID
insgesamt 0
drwxr-xr-x 2 root root 160 2007-03-23 09:57 .
drwxr-xr-x 6 root root 120 2007-03-23 09:57 ..
lrwxrwxrwx 1 root root 9 2007-03-23 09:56 ata-WDC_WD800BB-00CAA1_WD-WCA8E5412308 -> ../../hde
lrwxrwxrwx 1 root root 10 2007-03-23 09:56 ata-WDC_WD800BB-00CAA1_WD-WCA8E5412308-part1 -> ../../hde1
lrwxrwxrwx 1 root root 10 2007-03-23 09:56 ata-WDC_WD800BB-00CAA1_WD-WCA8E5412308-part2 -> ../../hde2
lrwxrwxrwx 1 root root 10 2007-03-23 09:56 ata-WDC_WD800BB-00CAA1_WD-WCA8E5412308-part3 -> ../../hde3
lrwxrwxrwx 1 root root 9 2007-03-23 09:57 usb-Kingston_DataTraveler_2.0 -> ../../sda
lrwxrwxrwx 1 root root 10 2007-03-23 09:57 usb-Kingston_DataTraveler_2.0-part1 -> ../../sda1

BLKID
/dev/hde1: UUID="f250ee05-eea3-4599-8945-d51c99805292" SEC_TYPE="ext2" TYPE="ext3"
/dev/mapper/vg_guests-lvvm--edgy--proto--gdm: UUID="a61676a6-7bb1-4267-bb8e-f635dc6d7fad" SEC_TYPE="ext2" TYPE="ext3"
/dev/mapper/vg_guests-lvvm--edgy--proto--swap: TYPE="swap"
/dev/mapper/vg_guests-lvvm--debian--proto--swap: TYPE="swap"
/dev/mapper/vg_guests-lvvm--edgy--nagios: UUID="edddd239-13f0-4877-a93f-0b9dc6e8e1e6" SEC_TYPE="ext2" TYPE="ext3"
/dev/mapper/vg_guests-lvvm--edgy--firewall: UUID="edddd239-13f0-4877-a93f-0b9dc6e8e1e6" SEC_TYPE="ext2" TYPE="ext3"
/dev/mapper/vg_dom0-lvtmp: UUID="f73167a3-a512-4504-b63f-d65f9bae7f97" SEC_TYPE="ext2" TYPE="ext3"
/dev/mapper/vg_guests-lvvm--edgy--proto: UUID="8df4aac0-c427-4c30-937a-34d9666e5854" SEC_TYPE="ext2" TYPE="ext3"
/dev/mapper/vg_guests-lvvm--debian--proto: UUID="c61f178d-5305-489e-aa5f-41d0d1fc4422" SEC_TYPE="ext2" TYPE="ext3"
/dev/mapper/vg_guests-lvvm--edgy--nagios--swap: TYPE="swap"
/dev/mapper/vg_dom0-lvhome: UUID="22289d95-a5fe-4a22-8301-8ce041b73b04" SEC_TYPE="ext2" TYPE="ext3"
/dev/mapper/vg_dom0-lvusr: UUID="2a2c2f00-cc3d-4101-9eb9-eb4177cbf3c9" SEC_TYPE="ext2" TYPE="ext3"
/dev/mapper/vg_dom0-lvvar: UUID="5faf560e-43bb-4bcf-a3a5-5e8a985ac128" SEC_TYPE="ext2" TYPE="ext3"
/dev/mapper/vg_guests-lvbackup: UUID="104b53db-5b3d-4359-8c15-ba2be2c867ca" SEC_TYPE="ext2" TYPE="ext3"
/dev/mapper/vg_guests-lvvm--edgy--firewall--swap: TYPE="swap"
/dev/mapper/vg_dom0-lvswap: TYPE="swap"
/dev/mapper/vg_dom0-lvroot: UUID="bc290476-98a9-48a1-a393-3548ae2669d8" SEC_TYPE="ext2" TYPE="ext3"
/dev/sda1: LABEL="KINGSTON" UUID="F4DB-142F" TYPE="vfat"

wie ich schon sagte: die platte wird immer noch mal als hda oder hde bezeichnet...
es handelt sich übrigens um ein onboard raid kontroller von GA-8GPNXP Duo

und wenn wir dabei sind, habe ich noch etwas:
was beduetet der error im syslog: hde(oder a):dma_intr:error=0x84 { DriveStatusError BadCRC }
status=0x51 { DriveReady SeekComplete Error }

seit ich den kernel mit noapic apm=off und acpi=off boote bekomme ich den error nicht
ist das die lösung und warum?

viele grüße, peter

[Six]

halo six,

danke für den sehr hilfreichen support!

habe mich für den schnellen weg über fstab mich entschlossen, und es funktioniert zumind. mit dem booten;
die hdd allerdings wird immer noch mal als hda oder hde bezeichnet... /boot wird aber sauber erkannt

Ja, das ist richtig. Die hardwareseitige Zuweisung ist ja genau das Problem, daß wir mit persistent Identifiers lösen wollten. Die ändert sich natürlich nicht, d. h. mal so, mal so bleibt uns erhalten Das System kümmert sich aber nicht länger drum, weil es nun auf die IDs achtet und nicht mehr auf die Hardwarekennzeichnung.

und wenn wir dabei sind, habe ich noch etwas:
was beduetet der error im syslog: hde(oder a):dma_intr:error=0x84 { DriveStatusError BadCRC }
status=0x51 { DriveReady SeekComplete Error }

seit ich den kernel mit noapic apm=off und acpi=off boote bekomme ich den error nicht
ist das die lösung und warum?

viele grüße, peter

Scheiß-FakeRAIDs. Sorry, aber....grrr. Nun zu deiner Frage: Das weiß ich nicht. Wenn du mit deinem Workaround nicht zufrieden bist, dann empfehle ich, einen neuen Thread in "andere Hardwareprobleme" zu eröffnen.

[laomedon]

...nicht zufrieden????????
also lieber six... man muß nicht alle antworten wissen... sondern wo man fragen soll
Du hast mich sehr geholfen.. und nun kann ich mit der xen config weitermachen!
googeln bezüglich badCRC hat mich bis lang leider nicht weiter gebracht.. werde mit neuen thread versuchen

hast Du übrigens erfahrung mit xen problemchen in kombi mit xorg?... hätte mal was gaaaanz feines

[rendegast]

seit ich den kernel mit noapic apm=off und acpi=off boote bekomme ich den error nicht

vielleicht stattdessen mit

Code: Alles auswählen

pci=nommconf

(habe ich im Gentoo-Wiki gefunden, hat bei mir geholfen (nForce4-4x))