USB anexado SATA - tabela de partições não sendo lida na inicialização

Question

O Linux aparentemente não consegue identificar partições em um disco SATA conectado a USB, se o sistema for inicializado com o dito disco conectado. Isso faz com que as partições (e, portanto, sistemas de arquivos) sejam invisíveis, exigindo uma varredura de partição (partprobe, blockdev - -rereadpt, etc), um módulo UAS recarregar ou desconectar o drive & reconecte-o novamente. Nenhum desses é viável se o disco em questão for o dispositivo de inicialização, com ESP e sistema de arquivos raiz nele.

Alguns experimentos foram feitos. Resultados:

1. Conectando disco com host on-line e módulo UAS carregado - > funciona
2. Conectando disco com host on-line e UAS & módulos usb_storage NÃO carregados - > funciona
3. Com o disco conectado, inicializando o sistema a partir de outra unidade - > falha Partições não detectadas. Depois de dar tempo suficiente para resolver, o seguinte é observado: Ambos os módulos UAS e usb_storage carregados; / dev / sda e / sys / class / block / sda existem; Curiosamente, o lsblk não o lista , nem o / proc / partitions.
   1. A partir deste estado, descarregando e carregando novamente o módulo UAS - > funciona (lsblk lista, / dev / sda {1,2} são criados, tudo "normal")
   2. Também a partir desse estado, verificando novamente a partição via blockdev --rereadpt - > funciona
   3. A repetição do teste com e sem o módulo UAS pré-carregado via linha de comando do kernel produz o mesmo resultado.
4. Com o disco conectado, tente inicializar o sistema pelo mesmo disco - > falha (o sistema não inicializa. Soltou para salvar o shell.)
   1. Uma vez descartado no shell, tentando blockdev --rereadpt - > funciona
   2. A repetição do teste com e sem o módulo UAS pré-carregado via linha de comando do kernel produz o mesmo resultado.

Saída de dmesg | grep sd executada do caso de teste # 3 (aos 42 segundos foi executado um blockdev --rereadpt). A saída do mesmo do caso # 4 é idêntica.

[   13.831953] sd 6:0:0:0: [sda] Read Capacity(10) failed: Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[   13.831955] sd 6:0:0:0: [sda] Sense Key : Not Ready [current] 
[   13.831956] sd 6:0:0:0: [sda] Add. Sense: Logical unit is in process of becoming ready
[   13.832435] sd 6:0:0:0: [sda] Test WP failed, assume Write Enabled
[   13.832850] sd 6:0:0:0: [sda] Asking for cache data failed
[   13.832853] sd 6:0:0:0: [sda] Assuming drive cache: write through
[   15.038494] sd 6:0:0:0: [sda] Read Capacity(10) failed: Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[   15.038497] sd 6:0:0:0: [sda] Sense Key : Not Ready [current] 
[   15.038498] sd 6:0:0:0: [sda] Add. Sense: Logical unit is in process of becoming ready
[   15.039379] sd 6:0:0:0: [sda] Attached SCSI disk
[   42.833001] sd 6:0:0:0: [sda] 1953525168 512-byte logical blocks: (1.00 TB/932 GiB)
[   42.834148] sda: detected capacity change from 0 to 1000204886016
[   42.956764]  sda: sda1 sda2

Alguma dica? Presumo que o dispositivo demore um pouco para ficar pronto e pronto (a partir das mensagens Logical unit is in process of becoming ready ), e talvez a verificação da partição ocorra enquanto o dispositivo não está pronto, falhando ou obtendo dados inválidos. Eu não sei quando essa verificação acontece ou qual subsistema causa isso. Tem que fazer alguma coisa com o udev? Quaisquer outros possíveis culpados? No começo, pensei que, talvez, o carregamento do módulo sob demanda fizesse com que ele ficasse indisponível quando necessário. Então eu tentei forçá-lo a ser carregado - aparentemente algo que pode ser feito listando o nome do módulo na linha de comando do kernel - mas sem sucesso.

rootwait e rootdelay foram testados. Ambos falham em resolver o problema.

Acho interessante observar que um memory stick USB comum funciona para o objetivo pretendido de arrancar (ESP e sistema de arquivos raiz). Além disso, o disco SATA conectado a USB é detectado pelo BIOS, o executável UEFI (GRUB) encontrado & lançado, o GRUB leu e inicializou o kernel a partir dele, etc.

-

Antecedentes da pergunta:

Eu tenho um cabo USB para SATA que estou usando para conectar um disco rígido de 2,5 polegadas a uma máquina. A máquina é um pequeno servidor doméstico com 4 portas SATA internas, todas em uso para discos de membros RAIDZ. Eu pretendo arrancar a unidade externa e ter sistema de arquivos raiz lá. Até este ponto, eu tinha ESP e sistema de arquivos raiz em um pen drive de 8GB e funciona muito bem ... até que não. Descobri que um dispositivo USB irá muito rapidamente estragar suas calças se colocado na carga de trabalho que um típico sistema de arquivos raiz suporta, mesmo que logs journald sejam redirecionados para a RAM e tudo, exceto os processos essenciais, sejam executados em contêineres LXC , que têm seus sistemas de arquivos raiz no pool do ZFS.

    

Answer 1

Depois de um pouco mais de pesquisa, encontrei uma solução hack-ish para este problema. Está longe de ser perfeito, e não resolve a causa raiz, mas ao menos fará com que o sistema seja inicializável.

O hack é ter um script em initramfs que é executado antes de tentar montar o root, mas após a inicialização do dispositivo, e sleep s um momento antes de executar blockdev --rereadpt .

Em um sistema baseado no Debian, simplesmente coloque o seguinte arquivo em /etc/initramfs-tools/scripts/local-top/rereadpt :

#!/bin/sh
PREREQ=""

prereqs()
{
    echo "$PREREQ"
}

case $1 in
# get pre-requisites
prereqs)
    prereqs 
    exit 0
    ;;
esac

sleep 5
blockdev --rereadpt /dev/<yourdisknode>

Você pode usar /dev/sda nomes como esse se o seu ambiente de site tiver um único disco SCSI, ou /dev/disk/by-id/... ou qualquer outra lógica para garantir que você está acionando a nova verificação na unidade correta.

ATUALIZAÇÃO: Se você não quiser que update-initramfs execute o script mencionado toda vez que ele reconstruir a imagem (mesmo que, supostamente, não deva ??), você não deve omitir a prereqs e case snippet no início