UltraBay HDD benansprucht /dev/sda für sich und degradiert interne HDD zu /dev/sdb

[maui_muc]

Hallo Leute,

ich hab hier ein seltsames Phänomen mit meinem T60 2007WX1. Gebe ich im laufenden Betrieb meine Backup HDD in den UltraBay Schacht, dann wird die Platte als /dev/sdb erkannt.
Befindet sich die Festplatte jedoch schon vor dem einschalten im UltraBay Schacht wird sie als /dev/sda eingehängt und die interne HDD mit wird zu /dev/sdb degradiert. Außerdem beschwert sich Ubuntu 11.04 beim Start (schon im Grafik-Modus) darüber, dass ein Gerät nicht bereit wäre was sich mit <M> überspringe ließe, oder so. Ist leider nur sehr kurz zu sehen.
Das ist ziemlich nervig und hsdpa kommt auch nicht klar damit.
Die Einträge aus dem Syslog hab ich unten angehängt. Sie sind so gut wie identisch lediglich ein UDA/33 fall-back ist komisch.

Gibts dafür eine Lösung?

Viele Grüße

Stefan

Nur so am Rande: Es erfolgt keine Benachrichtigungn im Syslog wenn ich den Eject-Schalter vom UltraBay-Schacht betätige während die HDD eingesetzt ist. Ist das normal?

Also sdb:

[ 8770.092864] ACPI: \_SB_.PCI0.IDE0.PRIM.MSTR - docking
[ 8770.093036] ata1: exception Emask 0x10 SAct 0x0 SErr 0x0 action 0xe frozen
[ 8770.093045] ata1: ACPI event
[ 8771.492109] ata1: soft resetting link
[ 8771.656914] ata1.00: ATA-7: HTS721060G9SA00, MC3IC10H, max UDMA/100
[ 8771.656922] ata1.00: 117210240 sectors, multi 0: LBA48 
[ 8771.656932] ata1.00: limited to UDMA/33 due to 40-wire cable
[ 8771.672764] ata1.00: configured for UDMA/33
[ 8771.672777] ata1: EH complete
[ 8771.672984] scsi 0:0:0:0: Direct-Access     ATA      HTS721060G9SA00  MC3I PQ: 0 ANSI: 5
[ 8771.673413] sd 0:0:0:0: Attached scsi generic sg1 type 0
[ 8771.673602] sd 0:0:0:0: [sdb] 117210240 512-byte logical blocks: (60.0 GB/55.8 GiB)
[ 8771.673733] sd 0:0:0:0: [sdb] Write Protect is off
[ 8771.673740] sd 0:0:0:0: [sdb] Mode Sense: 00 3a 00 00
[ 8771.673798] sd 0:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[ 8771.695736]  sdb: sdb1
[ 8771.696263] sd 0:0:0:0: [sdb] Attached SCSI disk

Als sda:

[  406.700874] ACPI: \_SB_.PCI0.IDE0.PRIM.MSTR - docking
[  406.701044] ata1: exception Emask 0x10 SAct 0x0 SErr 0x0 action 0xe frozen
[  406.701053] ata1: ACPI event
[  407.372112] ata1: soft resetting link
[  407.536921] ata1.00: ATA-7: HTS721060G9SA00, MC3IC10H, max UDMA/100
[  407.536929] ata1.00: 117210240 sectors, multi 0: LBA48 
[  407.552818] ata1.00: configured for UDMA/100
[  407.552831] ata1: EH complete
[  407.553049] scsi 0:0:0:0: Direct-Access     ATA      HTS721060G9SA00  MC3I PQ: 0 ANSI: 5
[  407.553476] sd 0:0:0:0: Attached scsi generic sg0 type 0
[  407.553647] sd 0:0:0:0: [sda] 117210240 512-byte logical blocks: (60.0 GB/55.8 GiB)
[  407.553779] sd 0:0:0:0: [sda] Write Protect is off
[  407.553786] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[  407.553844] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[  407.572697]  sda: sda1
[  407.573237] sd 0:0:0:0: [sda] Attached SCSI disk

 

[blafoo]

Nö ne wirkliche Lösung so erstmal nicht.

Könntest schaun das du Grub udn Fstab auf UUID`s umstellst, dann ist das Problem zwar prinzipiell noch vorhanden aber dein System juckt es nicht mehr.

UUID= Einmalig kennung deiner HDD. Also egal ob die an SDA oder SDB laeuft, die UUID is gleich. Somit passt das alles.

Problem hab ich seit Jahren in verschiedenster Kombination und das ist die schnellste / einfachste möglichkeit.

Grüße

 

[linrunner]

Naja, "seltsam" ist es nur solange man es nicht kennt. Ist wohl eher ein Fall von "works as designed" (EDITH: der Kernel sucht, wenn ich nicht irre, parallel nach Geräten und das schnellere gewinnt). Wie blafoo schon schrieb, solltest Du eine /etc/fstab mit UUIDs benutzen. Ubuntu macht das bei der Installation standardmäßig (warum wohl?). Die UUIDs ermittelst Du einfach per

sudo blkid

Die plattenbezogenen Einstellungen von TLP verstehen seit 0.3.0 auch "Disk IDs" (aus /dev/disk/by-id). Diese ermittelst Du per

tlp diskid

Weitere Einzelheiten siehe Einstellungen.

 

[rumbero]

Gebe ich im laufenden Betrieb meine Backup HDD in den UltraBay Schacht, dann wird die Platte als /dev/sdb erkannt.
Befindet sich die Festplatte jedoch schon vor dem einschalten im UltraBay Schacht wird sie als /dev/sda eingehängt und die interne HDD mit wird zu /dev/sdb degradiert.

Ich habe hier zwar "nur" ein Debian laufen, aber das sollte eigentlich auch bei Ubuntu funktionieren:

Im Gegensatz zur internen Systemplatte wird im T60/T61 die Ultrabay noch über IDE angebunden, und darin befindliche SATA-Platten werden über eine IDE/SATA-Bridge angesprochen. Beim Systemstart werden zuerst alle vorhandenen Platten am IDE-Controller eingebunden, und erst danach die Platten am nativen SATA-Controller. Wenn beim Systemstart also eine Platte im Ultrabay steckt, wird sie deswegen noch vor der internen Systemplatte automatisch zuerst als /dev/sda eingebunden.

Um diesen Mechanismus grundsätzlich zu verhindern, trage das Modul ata_piix in der Konfigurationsdatei /etc/modprobe.d/blacklist.conf ein, und aktualisiere anschliessend mit update-initramfs -k all -u die den jeweilig installierten Kerneln zugehörigen /boot/initrd.img* Init-RAM-Disks. Dadurch wird im ersten Schriitt verhindert, dass während des Bootvorgangs beim Laden des Kernels das Vorhandensein von IDE-Geräten geprüft wird.

Wir laden das derart ausgeschlossene Modul jedoch nachträglich mittels der Konfigurationsdatei /etc/rc.local, welche bei Vorhandensein im letzten Schritt des Bootvorgangs automagisch ausgeführt wird. Diese Datei (zur Not neu anlegen, falls nicht bereits vorhanden) sollte dann folgenden Eintrag enthalten:

#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.

/sbin/modprobe ata_piix

# Make sure that the script will "exit 0" on success or any other value on error.
exit 0

Auf diese Art und Weise kann genau diese lästige Unart der verwürfelten Platteneinbindung endgültig gelöst werden.

Falls Du LVM nutzen solltest, und auf der Ultrabay-Platte vorhandene Logical Volumes automatisch aktiviert haben möchtest, dann füge statt dem obengenannten Einzeiler /sbin/modprobe ata_piix folgenden Eintrag hinzu:

/sbin/modprobe ata_piix && /sbin/vgscan

# enable still inactive logical volumes if any is found

for LVOL in $(/sbin/lvscan | /bin/grep inactive | /usr/bin/cut -d\/ -f3 | /usr/bin/sort -u)
do  
    [ "$(/bin/echo $LVOL)" != "" ] && /sbin/vgchange -a y $LVOL
done

Außerdem beschwert sich Ubuntu 11.04 beim Start (schon im Grafik-Modus) darüber, dass ein Gerät nicht bereit wäre was sich mit <M> überspringe ließe, oder so. Ist leider nur sehr kurz zu sehen.

Welches Gerät denn? Schau doch mal in die Ausgabe von dmesg oder in /var/log/syslog nach genaueren Anhaltspunkten.

Wenn es das ist, was ich vermute, dann ist eventuell die Ultrabay-Platte gemeint? Ich musste mal an der Ultrabay-Platte einen Jumper setzen, um sie auf das Geschwindigkeitsniveau von SATA-I zu zwingen, da sie meist schon vom BIOS noch vor dem eigentlichen Booten des Kernels nicht korrekt angesprochen werden konnte. Es handelte sich um eine Seagate Momentus 500GB mit SATA-II, und die ausschlaggebende Info fand ich damals hier: http://seagate.custkb.com/seagate/crm/selfservice/search.jsp?DocId=193775&Hilite=jumper

 

[linrunner]

@rumbero: Danke für die Erklärung. Man lernt nie aus ...

 

[rumbero]

Man lernt nie aus ...

Das ist sowohl der Fluch als auch die Schönheit von Linux.

 

[blafoo]

Das mit sda / sdb fix via Kernel / Image mag helfen. Aber ich finde die UUID lösung doch schöner.

Alleine aus der Tatsache herraus das man "flexibler ist"

Meine SATA-Platte ausm Lappy dient durchaus mal als "Erste-Hilfe-Kit". Mit uuid steck ich sie einfach an den neuen Rechner und die Möhre bootet ohne zu Meckern durch

Und vor / nachteile hat die UUID bzw deine Lösung keine.

Ergo du must entscheiden welches du schöner findest.

Grüße

 

[rumbero]

Das mit sda / sdb fix via Kernel / Image mag helfen. Aber ich finde die UUID lösung doch schöner.

Hatte mich übrigens bereits vorher in diesem Zusammenhang mit dem UUID-Ansatz auseinandergesetzt, und mich dann aber doch dagegen entschieden. Mich stört daran sehr, dass einem Eintrag wie "UUID=F8A4FA3BA4F9FC46" in der /etc/fstab im Vergleich zu "/dev/sdc1" schlicht jegliche intuitive Verständlichkeit abgeht. Das mag gut für DAU's sein, denen das sowieso egal ist und die froh sind, wenn alles automagisch und ohne Notwendigkeit eigener Eingriffe vonstatten geht. Aber das ist IMHO einfach nicht mehr wirklich admin-freundlich.

 

[yatpu]

du kannst auch labels anstelle von uuids nehmen und den einzelnen dateisystemen aussagekräftige namen verpassen. das ist etwas übersichtlicher, aber nicht ganz so sicher wie der weg mit den uuids, da 2 dateisysteme durchaus mal zufällig denselben namen haben können.

wie so oft: viele wege führen nach rom

 

[blafoo]

Jops!

Es gibt, zum Glück, unter Linux tausende von Wege das Ziel zu erreichen.

Du musst halt schauen welcher weg für dich selber das beste ist.

Ich nutzte am Server, wo alle Platten immer gleich sind, immer nur sdX.

Aber das Problem von oben, ist mit UUID doch am schönsten zu regeln! *Vorsicht Persöhnliche Meinung!*

Grüße

 

[buddabrod]

Fall ich mich nicht täusche macht Fedora 15 bereits das "persistent mapping". Da kann man dann beruhigt wieder auf die nette /dev/sdxn Schreibweise wechseln

Habe bei Speicherkarten nun schon /dev/sdi erreicht xD

 

[Schnitzel2k8]

Fall ich mich nicht täusche macht Fedora 15 bereits das "persistent mapping". Da kann man dann beruhigt wieder auf die nette /dev/sdxn Schreibweise wechseln

Habe bei Speicherkarten nun schon /dev/sdi erreicht xD

und nach sdz explodiert dann der Rechner beim nächsten Speichermedium

 

[buddabrod]

und nach sdz explodiert dann der Rechner beim nächsten Speichermedium

Aber hallo!

Ich bin wirklich gespannt was dann passiert. Vielleicht gehts dann mit sdaa1 weiter