Eu tenho um laptop Samsung (Chronos S7) com um disco rígido SATA de ônibus ata:1
, que é detectado como /dev/sda
, um SSD de 8GB on ata:2
, /dev/sdb
e vários outros dispositivos no resto da interface SATA.
O problema é que o disco SSD é
- soldado à placa principal (imóvel)
- interrompido (apenas fornece erros de E / S para qualquer operação)
- ele não aparece no BIOS (provavelmente porque está quebrado)
Agora este disco:
- atrasa a inicialização de três a cinco minutos, tentando detectar o disco com falha, o que é irritante;
- mas a coisa mais irritante é que o sistema falha ao suspender devido a
/dev/sdb
falha.
Observe que eu posso viver com o atraso na inicialização - o que me preocupa é a coisa de retomar / suspender.
Portanto, a pergunta é: posso dizer ao kernel para evitar mesmo investigar o dispositivo no ata: 2?
No kernel mais antigo (<3.0), quando eu ainda era capaz de cavar um pouco a fonte, havia um parâmetro de linha de comando do estilo hdb=ignore
que teria feito o truque.
Eu tentei todos os truques propostos abaixo com os parâmetros udev
e do libata:force
kernel, sem sucesso. Especificamente, o seguinte não funciona:
Adicionando a um dos seguintes
/etc/udev/rules.d/
arquivos (em execução inicial como00-ignoredisk.rules
ou atrasada como99-ignoredisk.rules
ou nos dois locais)SUBSYSTEMS=="scsi", DRIVERS=="sd", ATTRS{rev}=="SSD ", ATTRS{model}=="SanDisk iSSD P4 ", ENV{UDISKS_IGNORE}="1"
nem
KERNEL=="sdb", ENV{UDISKS_IGNORE}="1"
nem muitas soluções intermediárias - isso torna o disco não acessível após a inicialização, mas é analisado na inicialização e ainda é verificado durante a suspensão - causando falha na suspensão.
Editando os arquivos do sistema
/lib/udev/rules.d/60-persistent-storage.rules
(eudisks
,udisks2
) alterandoKERNEL=="ram*|loop*|fd*|nbd*|gnbd*|dm-|md", GOTO="persistent_storage_end"
para
KERNEL=="ram*|loop*|fd*|nbd*|gnbd*|dm-|md|sdb*", GOTO="persistent_storage_end"
novamente, isso tem algum efeito, mascarando o disco do espaço do usuário, mas o disco ainda está visível para o kernel.
A inicialização com todas as combinações possíveis (bem, muitas delas) dos
libata:force
parâmetros (encontrados por exemplo aqui ) para desativar o DMA, a velocidade mais baixa ou qualquer outra coisa sobre o disco com falha - não funciona. O parâmetro é usado, mas o disco ainda é analisado e falha.Completo
udevadm info -a -n /dev/sdb
colado em http://paste.ubuntu.com/6186145/smartctl -i /dev/sdb -T permissive
dá: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
o que está claramente errado. Mesmo assim:
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
(Dados SSD de http://ubuntuforums.org/showthread.php?t=1935699&p=11739579#post11739579 ).
/etc/fstab
? Porque o atraso na inicialização pode ser causado anteriormente pelo kernel ou pelo udev, que parece ser o caso, mas também mais tarde pelo fsck, ao lerfstab
.