Problema ao desmontar o LVM no sistema LUKS quando a inicial USB não está presente

1

Estou tendo um problema bastante peculiar com a metade do Ubuntu do meu sistema. O TL; DR é que eu tenho o Ubuntu 14.04 usando um LVM na instalação do LUKS. / boot vive em uma partição não criptografada (/ sda3) enquanto swap e root ao vivo em um LVM dentro de uma partição LUKS (/ sda4). Eu fiz a configuração de um live-USB e o sistema funciona principalmente. No entanto, o comportamento do sistema depende se o USB original está presente ou não.

Se o USB estiver presente, o sistema inicializará em aproximadamente 3 segundos e será encerrado corretamente. Se o USB não estiver presente, o sistema criptografado será montado, mas o processo de login leva cerca de 60 segundos. No desligamento, o sistema afirma que a raiz está ocupada e não será desligada corretamente.

Não sei ao certo qual é o problema ou como resolvo o problema. Eu suspeito que o problema é o resultado de eu ter feito algo errado quando fiz o chroot do USB ao vivo para a nova instalação durante a configuração. Qualquer ajuda seria muito apreciada.

Estou incluindo o máximo de informações possível e peço desculpas se o restante deste post for desnecessariamente longo.

Saída durante o encerramento:

Se o USB ao vivo estiver presente, o desligamento prosseguirá normalmente:

wait-for-state stop/waiting
 * Stopping rsync daemon rsync [OK]
 * speech-dispatcher disabled: edit /etc/default/speech-dispatcher
 * Asking all remaining processes to terminate... [OK]
 * Killing all remaining processes... [OK]
ModemManager[971]: <info> Caught signal, shutting down...

ModemManager[971]: <info> ModemManager is shut down

nm-dispatcher.action: Caught signal 15, shutting down...
 * Deactivating swap... [OK]
 * Unmounting local filesystems... [OK]
 * sda4_crypt (busy)...
 * Stopping early crypto disks... [fail]
 * Stopping early crypto disks... [OK]
 * Will now halt
[ 155.0007241 reboot: Power down

O sistema é encerrado e não temos problemas.

Se o USB ao vivo não estiver presente, o desligamento prosseguirá como:

wait-for-state stop/waiting
 * Stopping rsync daemon rsync [OK]
 * speech-dispatcher disabled: edit /etc/default/speech-dispatcher
 * Asking all remaining processes to terminate... [OK]
 * Killing all remaining processes... [fail]
ModemManager[971]: <info> Caught signal, shutting down...

ModemManager[971]: <info> ModemManager is shut down

nm-dispatcher.action: Caught signal 15, shutting down...
 * Deactivating swap... [OK]
 * Unmounting local filesystems... [OK]
 * sda4_crypt (busy)...
 * Stopping early crypto disks... [fail]
 * Stopping early crypto disks... [OK]
mount: / is busy
 * Will now halt
[240.184072] INFO: task kworker/6:1:124 blocked for more than 120 seconds.
[240.184132]       Not tainted 3.19.0-47-generic #53~14.04.1-Ubuntu
[240.184176] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[240.184418] INFO: task alsa-sink-USB A:2037 blocked for more than 120 seconds.
[240.184469]       Not tainted 3.19.0-47-generic #53~14.04.1-Ubuntu
[240.184512] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[240.184710] INFO: task pulseaudio:2563 blocked for more than 120 seconds.
[240.184758]       Not tainted 3.19.0-47-generic #53~14.04.1-Ubuntu
[240.184802] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.

Neste ponto, o sistema justs continua a postar os erros acima em intervalos regulares e nunca é desligado corretamente. A única maneira de corrigir isso é desligando manualmente a máquina.

Configuração:

Eu sou o dual-boot do Windows 10 e Ubuntu 14.04 em um desktop. Antes de instalar o Ubuntu, instalei o Windows 10 e o criptografei usando o VeraCrypt. Estes dois usam / sda1 e / sda2. Eu então tentei instalar o Ubuntu a partir de um live-USB frouxamente seguindo estes dois guias:

[1] link

[2] link

Eu geralmente segui [1] e basicamente referenciei [2] para configurar um LVM. / boot está na partição não criptografada / sda3 enquanto swap e root estão em um LVM dentro de uma partição LUKS, / sda4. Tudo é feito usando UUIDs. Quando tudo estiver dito e pronto, meu sistema se parece com:

$ sudo lsblk -o name,uuid,mountpoint
NAME                          UUID                                   MOUNTPOINT
sda                                                                  
├─sda1                        16808C90808C784F                       
├─sda2                                                               
├─sda3                        41589165-270f-4be5-bbfd-7fe66112f485   /boot
└─sda4                        dd217bb3-30f3-496a-8dc9-12abc62e0b0f   
  └─sda4_crypt (dm-0)         BJA0uf-k4EW-SpaJ-GfTN-5orX-K5AM-IGuKcD 
    ├─MyVolume-swapvol (dm-1) 71149c9e-22b7-4349-8045-a632f2ff63c6   [SWAP]
    └─MyVolume-rootvol (dm-2) 1c5cf473-72a5-4066-b65e-2fdbe78fa231   /
sdb                                                                  
├─sdb1                        8EBC75B8BC759C01                       
└─sdb2                        D20877650877478D                       
sdc                                                                  
└─sdc1                        68463BC6463B9432                       
sdd                                                                  
└─sdd1                        B88407A8840767E8                       
sr0                                                                  

Conteúdo do fstab:

# <file system> <mount point>   <type>  <options>       <dump>  <pass>
UUID=1c5cf473-72a5-4066-b65e-2fdbe78fa231 /               ext4    errors=remount-ro 0       1
# /boot was on /dev/sda3 during installation
UUID=41589165-270f-4be5-bbfd-7fe66112f485 /boot           ext2    defaults        0       2
UUID=71149c9e-22b7-4349-8045-a632f2ff63c6 none            swap    sw              0       0

Conteúdo do crypttab:

sda4_crypt UUID=dd217bb3-30f3-496a-8dc9-12abc62e0b0f none luks,discard,lvm=MyVolume

Tanto quanto eu posso dizer, tudo acima parece correto. Eu suspeito que o problema não é com a montagem / desmontagem do sistema criptografado, mas sim com alguma estranha dependência com arquivos no live-USB. Isso parece implicar que algo deu errado com o Passos 6 do guia [1] quando eu fiz chroot do USB ao vivo para o sistema de arquivos criptografado. Os comandos relevantes (diretamente de [1]), a partir de dentro do live-USB são:

cd /mnt
mkdir root
mount /dev/mapper/root root
mount /dev/mapper/sda1 root/boot
chroot root
mount -t proc proc /proc
mount -t sysfs sys /sys

Ao fazer isso, mudei / sda1 e / dev / mapper / ... conforme necessário para o meu sistema.

Se isso é, de fato, algo em que algo deu errado, eu não tenho ideia de como diagnosticar o problema e muito menos corrigi-lo.

    
por abartolo 21.01.2016 / 08:19

0 respostas