Isso não parece bom. Verifique com o dmesg se o kernel tem algum problema, mas esse comando pode falhar também. Muitas distribuições do Linux mostram mensagens do kernel no console 10, você pode ir lá com Ctrl-Alt-F10.
Estou executando o Ubuntu 10.10 em um laptop Dell D400. Estou inicializando e executando o sistema a partir de volumes LVM em uma unidade WD Scorpio Blue 2.5 "montada em um gabinete USB NexStar3.
Na maior parte, isso funciona muito bem. No entanto, após alguns dias, o sistema geralmente perderá o acesso à partição do sistema. Não tenho certeza do que exatamente acontece e é difícil diagnosticar porque não consigo acessar os utilitários de sistema pertinentes:
$ mount
bash: /bin/mount: Input/output error
$ ls
Bus error
$ tail /var/log/messages
bash: /usr/bin/tail: Input/output error
$ cat /var/log/messages
Segmentation fault
Mesmo o desligamento não pode ser feito corretamente:
$ sudo shutdown -h now
bash: /usr/bin/sudo: Input/output error
$ sudo halt
bash: /usr/bin/sudo: Input/output error
O único procedimento de recuperação que encontrei é uma reinicialização difícil mantendo o botão liga / desliga pressionado por alguns segundos.
Quando esse estado de erro está ativo, a luz do gabinete fica acesa. Normalmente pisca bastante constantemente.
Eu migrei os arquivos do sistema de uma unidade interna. Eu não estava tendo esses problemas antes da migração. Eu pareço lembrar que eles começaram logo depois.
Seguindo a sugestão de Gilles para fazer logging remoto, este syslog output:
<6>Aug 12 01:00:25 box kernel: [229825.120148] usb 1-5: reset high speed USB device using ehci_hcd and address 2
<3>Aug 12 01:00:26 box kernel: [229825.700267] usb 1-5: device not accepting address 2, error -71
<3>Aug 12 01:00:26 box kernel: [229825.758145] ehci_hcd 0000:00:1d.7: port 5 reset error -110
<3>Aug 12 01:00:26 box kernel: [229825.758160] hub 1-0:1.0: hub_port_status failed (err = -32)
<6>Aug 12 01:00:26 box kernel: [229825.960116] usb 1-5: USB disconnect, address 2
<6>Aug 12 01:00:26 box kernel: [229825.980062] sd 2:0:0:0: Device offlined - not ready after error recovery
<6>Aug 12 01:00:26 box kernel: [229825.980108] sd 2:0:0:0: [sdb] Unhandled error code
<6>Aug 12 01:00:26 box kernel: [229825.980112] sd 2:0:0:0: [sdb] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK
<6>Aug 12 01:00:26 box kernel: [229825.980118] sd 2:0:0:0: [sdb] CDB: Read(10): 28 00 31 b1 a0 35 00 00 20 00
<3>Aug 12 01:00:26 box kernel: [229825.980132] end_request: I/O error, dev sdb, sector 833724469
<3>Aug 12 01:00:26 box kernel: [229825.980167] Buffer I/O error on device dm-1, logical block 44564614
<4>Aug 12 01:00:26 box kernel: [229825.980171] lost page write due to I/O error on dm-1
<3>Aug 12 01:00:26 box kernel: [229825.984068] Aborting journal on device dm-4-8.
<3>Aug 12 01:00:26 box kernel: [229825.984100] Buffer I/O error on device dm-4, logical block 1081344
<4>Aug 12 01:00:26 box kernel: [229825.984104] lost page write due to I/O error on dm-4
<3>Aug 12 01:00:26 box kernel: [229825.984113] JBD2: I/O error detected when updating journal superblock for dm-4-8.
<3>Aug 12 01:00:26 box kernel: [229825.984181] Buffer I/O error on device dm-4, logical block 1675867
<4>Aug 12 01:00:26 box kernel: [229825.984185] lost page write due to I/O error on dm-4
<3>Aug 12 01:00:26 box kernel: [229825.984190] Buffer I/O error on device dm-4, logical block 1675868
<4>Aug 12 01:00:26 box kernel: [229825.984193] lost page write due to I/O error on dm-4
<3>Aug 12 01:00:26 box kernel: [229825.984200] Buffer I/O error on device dm-4, logical block 1684657
<4>Aug 12 01:00:26 box kernel: [229825.984204] lost page write due to I/O error on dm-4
<4>Aug 12 01:00:26 box kernel: [229825.984389] JBD2: Detected IO errors while flushing file data on dm-4-8
<43>Aug 12 01:00:26 box rsyslogd: /var/log/syslog
<43>Aug 12 01:00:26 box rsyslogd: /var/log/kern.log
<43>Aug 12 01:00:26 box rsyslogd: /var/log/messages
<2>Aug 12 01:00:26 box kernel: [229825.991754] EXT4-fs error (device dm-4): ext4_journal_start_sb: Detected aborted journal
<2>Aug 12 01:00:26 box kernel: [229825.991765] EXT4-fs (dm-4): Remounting filesystem read-only
<3>Aug 12 01:00:26 box kernel: [229826.136474] Buffer I/O error on device dm-1, logical block 44726233
<4>Aug 12 01:00:26 box kernel: [229826.136480] lost page write due to I/O error on dm-1
<3>Aug 12 01:00:26 box kernel: [229826.136487] Buffer I/O error on device dm-1, logical block 44726234
<4>Aug 12 01:00:26 box kernel: [229826.136491] lost page write due to I/O error on dm-1
<3>Aug 12 01:00:26 box kernel: [229826.144081] Aborting journal on device dm-1-8.
<3>Aug 12 01:00:26 box kernel: [229826.144099] Buffer I/O error on device dm-1, logical block 13139968
<4>Aug 12 01:00:26 box kernel: [229826.144103] lost page write due to I/O error on dm-1
<3>Aug 12 01:00:26 box kernel: [229826.144110] JBD2: I/O error detected when updating journal superblock for dm-1-8.
<0>Aug 12 01:00:26 box kernel: [229826.144124] journal commit I/O error
A décima linha do final, em 229825.991765, é onde o sistema de arquivos é remontado somente para leitura. Examinei o resto e não vi nada indicando que ele está totalmente desmontado, então é um pouco misterioso por que o próprio sistema se torna inacessível.
De qualquer forma, os erros do USB no começo parecem ser o motivo do acidente.
É provável que isso seja um problema com os controladores / controladores USB do laptop? Ou mais provável com o gabinete USB? Como posso saber?
Isso não parece bom. Verifique com o dmesg se o kernel tem algum problema, mas esse comando pode falhar também. Muitas distribuições do Linux mostram mensagens do kernel no console 10, você pode ir lá com Ctrl-Alt-F10.
É um problema de sono? Você pode tentar apm=off e acpi=off na linha do kernel para ver se ele mantém o chipset acordado. Verifique também as configurações da BIOS e certifique-se de que não está tentando colocar as coisas em suspensão.
Além disso, você pode verificar com hdparm se a unidade está tentando adormecer depois de um certo tempo. Não se lembre dos detalhes, pinfo hdparm ou man hdparm podem ajudar.
Erros de entrada / saída significam que há alguma perda de dados em andamento, o que significa que praticamente nenhuma informação referente a esse pipeline será confiável.
Eu ignoraria a parte do diagnóstico e consideraria os cenários de recuperação de dados.
Tags usb-drive external-hdd