Debian 8 trava ao conectar HDD USB

0

Quando tento conectar meu disco rígido SATA via USB ao meu laptop com o Debian 8, o sistema trava, responde muito lentamente e executa ls / dev | grep sd * mostra entradas que variam de sdc1 a sdc99 que não estão presentes quando o HDD está desconectado.

Eu realmente preciso formatar o disco rígido porque uma instalação do Windows 10 falhou e agora não consigo inicializar a distribuição do Linux nem a instalação do Windows 7 que foi instalada originalmente.

Além disso, quando tento conectar o HDD ao meu laptop que executa o Windows 10, não consigo encontrá-lo em lugar nenhum, nem mesmo sob o gerenciamento de disco nas ferramentas administrativas.

Conforme solicitado, as últimas linhas das mensagens do syslog:

Jan 31 19:03:53 debian kernel: [   85.602048] scsi 4:0:0:0: Direct-Access        Mass  Storage Device        PQ: 0 ANSI: 0
Jan 31 19:03:53 debian kernel: [   85.602324] sd 4:0:0:0: Attached scsi generic sg2 type 0
Jan 31 19:03:53 debian kernel: [   85.602598] sd 4:0:0:0: [sdb] 488397166 512-byte logical blocks: (250 GB/232 GiB)
Jan 31 19:03:53 debian kernel: [   85.602732] sd 4:0:0:0: [sdb] Write Protect is off
Jan 31 19:03:53 debian kernel: [   85.602735] sd 4:0:0:0: [sdb] Mode Sense: 03 00 00 00
Jan 31 19:03:53 debian kernel: [   85.602865] sd 4:0:0:0: [sdb] No Caching mode page found
Jan 31 19:03:53 debian kernel: [   85.604123] sd 4:0:0:0: [sdb] Assuming drive cache: write through
Jan 31 19:03:53 debian kernel: [   85.664976]  sdb: sdb1 sdb2 sdb3 sdb4 < sdb5 sdb6 sdb7 sdb8 sdb9 sdb10 sdb11 sdb12 sdb13 sdb14 sdb15 sdb16 sdb17 sdb18 sdb19 sdb20 sdb21 sdb22 sdb23 sdb24 sdb25 sdb26 sdb27 sdb28 sdb29 sdb30 sdb31 sdb32 sdb33 sdb34 sdb35 sdb36 sdb37 sdb38 sdb39 sdb40 sdb41 sdb42 sdb43 sdb44 sdb45 sdb46 sdb47 sdb48 sdb49 sdb50 sdb51 sdb52 sdb53 sdb54 sdb55 sdb56 sdb57 sdb58 sdb59 sdb60 sdb61 sdb62 sdb63 sdb64 sdb65 sdb66 sdb67 sdb68 sdb69 sdb70 sdb71 sdb72 sdb73 sdb74 sdb75 sdb76 sdb77 sdb78 sdb79 sdb80 sdb81 sdb82 sdb83 sdb84 sdb85 sdb86 sdb87 sdb88 sdb89 sdb90 sdb91 sdb92 sdb93 sdb94 sdb95 sdb96 sdb97 sdb98 sdb99 sdb100 sdb101 sdb102 sdb103 sdb104 sdb105 sdb106 sdb107 sdb108 sdb109 sdb110 sdb111 sdb112 sdb113 sdb114 sdb115 sdb116 sdb117 sdb118 sdb119 sdb120 sdb121 sdb122 sdb123 sdb124 sdb125 sdb126 sdb127 sdb128 sdb129 sdb130 sdb131 sdb132 sdb133 sdb134 sdb135 sdb136 sdb137 sdb138 sdb139 sdb140 sdb141 sdb142 sdb143 sdb144 sdb145 sdb146 sdb147 sdb148 sdb149 sdb150 sdb151 sdb152 sdb153 sdb154 sdb155 sdb1<5>[   85.685268] sd 4:0:0:0: [sdb] Attached SCSI disk

E a saída de lsblk:

NAME     MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda        8:0    0 931,5G  0 disk 
├─sda1     8:1    0   500M  0 part 
├─sda2     8:2    0 155,8G  0 part 
├─sda3     8:3    0 488,3G  0 part 
├─sda4     8:4    0     1K  0 part 
├─sda5     8:5    0  46,6G  0 part /
├─sda6     8:6    0 186,3G  0 part /home
├─sda7     8:7    0  14,9G  0 part [SWAP]
├─sda8     8:8    0  38,3G  0 part 
└─sda9     8:9    0   954M  0 part /boot
sdb        8:16   0 232,9G  0 disk 
├─sdb1     8:17   0   100M  0 part 
├─sdb2     8:18   0  97,1G  0 part 
├─sdb3     8:19   0   450M  0 part 
├─sdb4     8:20   0     1K  0 part 
├─sdb5     8:21   0   4,7G  0 part 
├─sdb6     8:22   0     2G  0 part 
├─sdb7     8:23   0   4,7G  0 part 
├─sdb8     8:24   0     2G  0 part 
├─sdb9     8:25   0   4,7G  0 part 
├─sdb10    8:26   0     2G  0 part 
├─sdb11    8:27   0   4,7G  0 part 
├─sdb12    8:28   0     2G  0 part 
├─sdb13    8:29   0   4,7G  0 part 
├─sdb14    8:30   0     2G  0 part 
--- this repeats itself numerous times with sdb until: ---
├─sdb249 259:233  0   4,7G  0 part 
├─sdb250 259:234  0     2G  0 part 
├─sdb251 259:235  0   4,7G  0 part 
├─sdb252 259:236  0     2G  0 part 
├─sdb253 259:237  0   4,7G  0 part 
├─sdb254 259:238  0     2G  0 part 
└─sdb255 259:239  0   4,7G  0 part 
sr0       11:0    1   7,9G  0 rom  /media/cdrom0

Talvez eu deva mencionar também que selecionei uma instalação limpa ao tentar instalar o Windows 10 nessa unidade. Ele começou a instalar, mas ficou preso ao copiar os arquivos, então eu abortei. Provavelmente, a maior parte do disco foi apagada nesse momento, mas não todos. Por exemplo, eu ainda podia entrar no GRUB e me mostrava as opções para inicializar o Linux ou o Windows, mas não funcionava.

    
por Andreas Finkler 31.01.2016 / 18:36

1 resposta

2

A unidade /dev/sdb parece utilizável como um dispositivo de bloco 250GB ( 232GiB ) à primeira vista.

O Linux detectou 255 partições, que é o máximo suportado pelo kernel .

Se você adicionar os tamanhos de todas as partições mostradas em sua lsblk , obterá 1TB ( 935GiB ).

Você tem um disco rígido 1TB ou um disco rígido 250GB ?

250GB disco rígido

O Linux provavelmente está vendo todo o disco rígido, então ele pode apagar a tabela de partições para você. A tabela de partição atual está mentindo sobre ter 1TB de partições.

Zap o disco rígido para apagar a tabela de partição. Execute um dos seguintes comandos para fazer o zapping:

dd if=/dev/zero of=/dev/sdb bs=2M count=1

sgdisk /dev/sdb -Z

Redigite as partições em /dev/sdb usando este comando:

partprobe /dev/sdb

Você deve receber a seguinte mensagem de erro:

Error: /dev/sdb: unrecognised disk label

Este erro significa que a tabela de partições desapareceu, como pretendido. Você pode executar lsblk /dev/sdb novamente e ver algo assim:

# lsblk /dev/sdb
NAME     MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sdb        8:16   0 232,9G  0 disk

1TB disco rígido

Este é um caso estranho em que o Linux detectou que você tem apenas um dispositivo de bloco 250GB quando seu disco rígido é, na verdade, 1TB large.

Seu adaptador SATA para USB pode ser incompatível com o disco rígido que você está tentando usar ou talvez o Linux não tenha o driver correto para o adaptador.

Há uma possível explicação para este aqui .

Explicando a lentidão

Por que o seu computador ficou lento, o Linux provavelmente estava tentando coletar informações (sistemas de arquivos, UUIDs, etc.) de cada uma das partições detectadas, e havia 255 delas. Isso pode demorar um pouco e bloquear outros processos, o que tornaria seu computador lento.

    
por 31.01.2016 / 20:06