Ich habe einen Samsung-Laptop (Chronos s7) mit einer SATA-Festplatte am Bus ata:1, die als /dev/sda8G-SSD erkannt ata:2wird /dev/sdb, und verschiedene andere Geräte an der restlichen SATA-Schnittstelle.
Das Problem ist, dass die SSD-Platte ist
- mit der Hauptplatine verlötet (unbeweglich)
- kaputt (es gibt nur I / O-Fehler für jede Operation)
- es erscheint nicht im BIOS (wahrscheinlich, weil es kaputt ist)
Nun diese Scheibe:
- verzögert den Startvorgang um drei bis fünf Minuten beim Versuch, die fehlerhafte Festplatte zu untersuchen, was ärgerlich ist;
- Am ärgerlichsten ist jedoch, dass das System aufgrund eines
/dev/sdbFehlers nicht angehalten werden kann .
Beachten Sie, dass ich mit der Verzögerung beim Booten leben kann - was mich beunruhigt, ist die Sache mit dem Fortsetzen / Anhalten.
Die Frage ist also: Kann ich dem Kernel mitteilen, dass er das Gerät nicht einmal auf ata: 2 testen soll?
In einem älteren Kernel (<3.0) gab es, als ich noch ein bisschen in die Quelle graben konnte, einen Befehlszeilenparameter des Stils hdb=ignore, der den Trick getan hätte.
Ich habe alle unten vorgeschlagenen Tricks mit udevund libata:forceKernel-Parametern ausprobiert , ohne Erfolg. Im Einzelnen funktioniert Folgendes nicht:
Hinzufügen
/etc/udev/rules.d/einer Datei zu einer der folgenden Dateien (bei vorzeitiger Ausführung wie00-ignoredisk.rulesoder zu einem späteren Zeitpunkt99-ignoredisk.rulesoder an beiden Stellen)SUBSYSTEMS=="scsi", DRIVERS=="sd", ATTRS{rev}=="SSD ", ATTRS{model}=="SanDisk iSSD P4 ", ENV{UDISKS_IGNORE}="1"Noch
KERNEL=="sdb", ENV{UDISKS_IGNORE}="1"Weder viele Zwischenlösungen - Dadurch kann auf die Festplatte nach dem Start nicht zugegriffen werden, sie wird jedoch beim Start geprüft und beim Anhalten immer noch überprüft - was dazu führt, dass das Anhalten fehlschlägt.
Ändern der Systemdateien
/lib/udev/rules.d/60-persistent-storage.rules(undudisks,udisks2)KERNEL=="ram*|loop*|fd*|nbd*|gnbd*|dm-|md", GOTO="persistent_storage_end"zu
KERNEL=="ram*|loop*|fd*|nbd*|gnbd*|dm-|md|sdb*", GOTO="persistent_storage_end"Auch hier hat dies einige Auswirkungen, da die Festplatte vor dem Benutzerbereich maskiert wird, die Festplatte jedoch weiterhin für den Kernel sichtbar ist.
Boote mit allen möglichen Kombinationen (na ja, viele von ihnen) des
libata:forceParameters (zB gefunden hier , um zu deaktivieren DMA, niedriger Geschwindigkeit oder was auch immer wegen der fehlerhaften Festplatte) --- funktioniert nicht. Der Parameter wird verwendet, aber der Datenträger wird noch geprüft und fällt aus.Vollständig
udevadm info -a -n /dev/sdbeingefügt an http://paste.ubuntu.com/6186145/smartctl -i /dev/sdb -T permissivegibt:root@samsung-romano:/home/romano# smartctl -i /dev/sdb -T permissive smartctl 5.43 2012-06-30 r3573 [x86_64-linux-3.8.0-31-generic] (local build) Copyright (C) 2002-12 by Bruce Allen, http://smartmontools.sourceforge.net Vendor: /1:0:0:0 Product: User Capacity: 600,332,565,813,390,450 bytes [600 PB] Logical block size: 774843950 bytes >> Terminate command early due to bad response to IEC mode pagewas eindeutig falsch ist. Dennoch:
root@samsung-romano:/home/romano# fdisk -b 512 -C 970 -H 256 -S 63 /dev/sdb fdisk: unable to read /dev/sdb: Input/output error
(SSD-Daten von http://ubuntuforums.org/showthread.php?t=1935699&p=11739579#post11739579 ).
/etc/fstab? Denn die Verzögerung beim Booten könnte früher durch den Kernel oder udev verursacht werden, was anscheinend der Fall ist, aber auch später durch fsck beim Lesenfstab.