Je Samsung un ordinateur portable (chronos s7) avec un disque dur SATA sur le bus ata:1
, ce qui est détecté comme /dev/sda
, un 8G SSD ata:2
, /dev/sdb
et divers autres dispositifs sur le reste de l' interface SATA.
Le problème est que le disque SSD est
- soudé à la carte principale (inamovible)
- éclaté (il donne juste des erreurs d'E / S pour toute opération)
- il n'apparaît pas dans le bios (probablement parce qu'il est cassé)
Maintenant ce disque:
- retarde le démarrage de trois à cinq minutes en essayant de sonder le disque défaillant, ce qui est ennuyeux;
- mais le plus ennuyeux est que le système ne parvient pas à suspendre en raison d'une
/dev/sdb
défaillance.
Notez que je peux vivre avec le retard au démarrage --- ce qui m'inquiète, c'est la reprise / suspension.
La question est donc: puis-je dire au noyau d'éviter même de sonder le périphérique sur ata: 2?
Dans un noyau plus ancien (<3.0), quand j'étais encore capable de creuser un peu dans la source, il y avait un paramètre de ligne de commande du style hdb=ignore
qui aurait fait l'affaire.
J'ai essayé toutes les astuces proposées ci-dessous avec udev
et libata:force
les paramètres du noyau, en vain. Plus précisément, les éléments suivants ne fonctionnent pas:
Ajout à l'un des
/etc/udev/rules.d/
fichiers suivants (en début d'exécution comme00-ignoredisk.rules
ou tardivement99-ignoredisk.rules
ou aux deux endroits)SUBSYSTEMS=="scsi", DRIVERS=="sd", ATTRS{rev}=="SSD ", ATTRS{model}=="SanDisk iSSD P4 ", ENV{UDISKS_IGNORE}="1"
ni
KERNEL=="sdb", ENV{UDISKS_IGNORE}="1"
ni beaucoup de solutions intermédiaires --- cela rend le disque inaccessible après le démarrage, mais il est testé au démarrage, et toujours vérifié lors de la suspension --- provoquant l'échec de la suspension.
Modification des fichiers système
/lib/udev/rules.d/60-persistent-storage.rules
(etudisks
,udisks2
) modificationKERNEL=="ram*|loop*|fd*|nbd*|gnbd*|dm-|md", GOTO="persistent_storage_end"
à
KERNEL=="ram*|loop*|fd*|nbd*|gnbd*|dm-|md|sdb*", GOTO="persistent_storage_end"
encore une fois, cela a un certain effet, masquant le disque de l'espace utilisateur, mais le disque est toujours visible pour le noyau.
Le démarrage avec toutes les combinaisons possibles (enfin, beaucoup d'entre elles) des
libata:force
paramètres (trouvés par exemple ici ) afin de désactiver le DMA, la vitesse inférieure ou quoi que ce soit sur le disque défaillant --- ne fonctionne pas. Le paramètre est utilisé, mais le disque est toujours sondé et échoue.udevadm info -a -n /dev/sdb
Collé complet sur http://paste.ubuntu.com/6186145/smartctl -i /dev/sdb -T permissive
donne: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 page
ce qui est clairement faux. Cependant:
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
(Données SSD de http://ubuntuforums.org/showthread.php?t=1935699&p=11739579#post11739579 ).
/etc/fstab
? Parce que le retard au démarrage pourrait être causé plus tôt par le noyau ou udev, ce qui semble être le cas, mais aussi plus tard par fsck, lors de la lecturefstab
.