A partição de troca não é reconhecida (a unidade de disco com UUID =… ainda não está pronta ou não está presente)

6
  • Acho que eu tinha uma partição de permuta criptografada, porque optei por criptografar meu diretório pessoal durante a instalação. Eu acredito que é o que a linha com /dev/mapper/cryptswap1 ... no meu /etc/fstab é tudo.
  • Eu fiz algo para bork minha troca porque na próxima inicialização, recebi uma mensagem (parafraseada):

    The disk drive for /dev/mapper/cryptswap1 is not ready yet or not present. Wait to continue. Press S to skip or M to manually recover.

    (Como uma nota lateral, pressionar S ou M pareceu não fazer nada diferente de apenas esperar.)

  • Veja o que tentei:

    1. Este tutorial sobre como corrigir a troca partição não montada. No entanto, no acima, o comando mkswap falha porque o dispositivo está ocupado.
    2. Então eu iniciei a partir de um USB ao vivo, executei o GParted para reformatar a partição de swap (que aparecia como um tipo de fs desconhecido) e chrooted no sistema quebrado para tentar esse tutorial novamente. Eu também ajustei /etc/initramfs-tools/conf.d/resume e /etc/fstab para refletir o novo UUID gerado da formatação da partição como uma troca. Isso ainda não funcionou; em vez de /dev/mapper/cryptswap1 não presente, "A unidade de disco com UUID = [UUID da partição swap] ainda não está pronta ou não está presente ..."
    3. Então eu decidi começar de novo como se eu nunca tivesse criado uma partição swap em primeiro lugar. A partir do Live USB, eu apaguei a partição swap completamente (que, mais uma vez apareceu no GParted como um tipo fs desconhecido), removi as entradas swap e cryptswap em /etc/fstab , bem como removi /etc/initramfs-tools/conf.d/resume e /etc/crypttab . Neste ponto, o sistema principal não deve ser considerado quebrado porque não há partição swap e nenhuma instrução para montar um, certo? Não recebi nenhum erro durante a inicialização. Eu segui as mesmas instruções para criar e criptografar a partição swap, começando com a criação de uma partição para a troca, embora eu ache que fdisk disse que uma reinicialização era necessária para ver as mudanças.
  • Eu estava confiante de que o 3º processo acima funcionaria, mas o problema ainda persiste.

  • Algumas informações relevantes ( /dev/sda8 é a partição swap):

    • /etc/fstab file:

      # /etc/fstab: static file system information.
      #
      # Use 'blkid' to print the universally unique identifier for a
      # device; this may be used with UUID= as a more robust way to name devices
      # that works even if disks are added and removed. See fstab(5).
      #
      # <file system> <mount point>   <type>  <options>       <dump>  <pass>
      proc            /proc           proc    nodev,noexec,nosuid 0       0
      # / was on /dev/sda6 during installation
      UUID=4c11e82c-5fe9-49d5-92d9-cdaa6865c991 /               ext4    errors=remount-ro 0       1
      # /boot was on /dev/sda5 during installation
      UUID=4031413e-e89f-49a9-b54c-e887286bb15e /boot           ext4    defaults        0       2
      # /home was on /dev/sda7 during installation
      UUID=d5bbfc6f-482a-464e-9f26-fd213230ae84 /home           ext4    defaults        0       2
      # swap was on /dev/sda8 during installation
      UUID=5da2c720-8787-4332-9317-7d96cf1e9b80 none            swap    sw              0       0
      /dev/mapper/cryptswap1 none swap sw 0 0
      
    • saída de sudo mount :

      /dev/sda6 on / type ext4 (rw,errors=remount-ro)
      proc on /proc type proc (rw,noexec,nosuid,nodev)
      sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
      none on /sys/fs/fuse/connections type fusectl (rw)
      none on /sys/kernel/debug type debugfs (rw)
      none on /sys/kernel/security type securityfs (rw)
      udev on /dev type devtmpfs (rw,mode=0755)
      devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620)
      tmpfs on /run type tmpfs (rw,noexec,nosuid,size=10%,mode=0755)
      none on /run/lock type tmpfs (rw,noexec,nosuid,nodev,size=5242880)
      none on /run/shm type tmpfs (rw,nosuid,nodev)
      /dev/sda5 on /boot type ext4 (rw)
      /dev/sda7 on /home type ext4 (rw)
      /home/undisclosed/.Private on /home/undisclosed type ecryptfs (ecryptfs_check_dev_ruid,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_unlink_sigs,ecryptfs_sig=cbae1771abd34009,ecryptfs_fnek_sig=7cefe2f59aab8e58)
      gvfs-fuse-daemon on /home/undisclosed/.gvfs type fuse.gvfs-fuse-daemon (rw,nosuid,nodev,user=undisclosed)
      
    • saída de sudo blkid (observe que /dev/sda8 está ausente):

      /dev/sda1: LABEL="SYSTEM" UUID="960490E80490CC9D" TYPE="ntfs" 
      /dev/sda2: UUID="D4043140043126C0" TYPE="ntfs" 
      /dev/sda3: LABEL="Shared" UUID="80F613E1F613D5EE" TYPE="ntfs" 
      /dev/sda5: UUID="4031413e-e89f-49a9-b54c-e887286bb15e" TYPE="ext4" 
      /dev/sda6: UUID="4c11e82c-5fe9-49d5-92d9-cdaa6865c991" TYPE="ext4" 
      /dev/sda7: UUID="d5bbfc6f-482a-464e-9f26-fd213230ae84" TYPE="ext4" 
      /dev/mapper/cryptswap1: UUID="41fa147a-3e2c-4e61-b29b-3f240fffbba0" TYPE="swap" 
      
    • saída de sudo fdisk -l :

      Disk /dev/mapper/cryptswap1 doesn't contain a valid partition table
      
      Disk /dev/sda: 320.1 GB, 320072933376 bytes
      255 heads, 63 sectors/track, 38913 cylinders, total 625142448 sectors
      Units = sectors of 1 * 512 = 512 bytes
      Sector size (logical/physical): 512 bytes / 512 bytes
      I/O size (minimum/optimal): 512 bytes / 512 bytes
      Disk identifier: 0xdec3fed2
      
         Device Boot      Start         End      Blocks   Id  System
      /dev/sda1   *        2048      409599      203776    7  HPFS/NTFS/exFAT
      /dev/sda2          409600   210135039   104862720    7  HPFS/NTFS/exFAT
      /dev/sda3       210135040   415422463   102643712    7  HPFS/NTFS/exFAT
      /dev/sda4       415424510   625141759   104858625    5  Extended
      /dev/sda5       415424512   415922175      248832   83  Linux
      /dev/sda6       415924224   515921919    49998848   83  Linux
      /dev/sda7       515923968   621389823    52732928   83  Linux
      /dev/sda8       621391872   625141759     1874944   82  Linux swap / Solaris
      
      Disk /dev/mapper/cryptswap1: 1919 MB, 1919942656 bytes
      255 heads, 63 sectors/track, 233 cylinders, total 3749888 sectors
      Units = sectors of 1 * 512 = 512 bytes
      Sector size (logical/physical): 512 bytes / 512 bytes
      I/O size (minimum/optimal): 512 bytes / 512 bytes
      Disk identifier: 0xaf5321b5
      
    • /etc/initramfs-tools/conf.d/resume file:

      RESUME=UUID=5da2c720-8787-4332-9317-7d96cf1e9b80
      
    • /etc/crypttab file:

      cryptswap1 /dev/sda8 /dev/urandom swap,cipher=aes-cbc-essiv:sha256
      
    • saída de sudo swapon -as :

      Filename                Type        Size    Used    Priority
      /dev/mapper/cryptswap1                  partition   1874940 0   -1
      
    • saída de sudo free -m :

                   total       used       free     shared    buffers     cached
      Mem:          1476       1296        179          0         35        671
      -/+ buffers/cache:        590        886
      Swap:         1830          0       1830
      

Então, como isso pode ser corrigido?

    
por ladaghini 14.08.2013 / 20:09

4 respostas

2

Eu tive o mesmo problema ao usar uma partição de troca criptografada. Nem a FAQ de troca geral, Solução do Puny Geek para a mensagem" cryptswap1 ainda não está pronta ou não está presente " nem A resposta de Braiam a esta questão resolveu o problema para mim - às vezes o troca estava disponível, às vezes não era. Depois de muitas reinicializações e algumas pesquisas, acho que descobri o motivo subjacente:

O caminho para a partição swap como /dev/sda3 é algumas vezes diferente, por exemplo %código%. Já que o arquivo /dev/sdb3 por padrão parece identificar a partição swap através deste caminho, às vezes ele a encontraria (se essa partição conseguir o mesmo caminho na inicialização) ou não (se a partição receber um caminho diferente no boot) .

Parece que eu não era o único com esse problema. disco / "> como descrito aqui , uma solução melhor seria vincular a partição de troca através de seu ID de unidade em vez de seu /etc/crypttab caminho. Isso pode ser encontrado executando

/dev/sd*

que lista os IDs do disco para todas as partições, incluindo a troca, que no meu caso foi

ls -l /dev/disk/by-id/

Verifique novamente em um programa como o Utilitário de Disco que a parte ata-TOSHIBA_MQ01UBD100_73JATD5GT-part3 -> ../../sdb3 desta linha é de fato a partição que você pretende usar para troca, já que isso (como eu disse antes) pode às vezes mudar nomes. Como sempre, tenha isso em mente:

Caution: fiddling with cryptsetup and disk devices is dangerous for data and OS. I personally made a full backup on a separate disk and then umplugged it to be sure it wouldn’t be involved in any mishap.

Em seguida, edite seu arquivo -> ../../sdb* usando o link de ID em vez do caminho "bruto", no meu caso, essa linha é

/etc/crypttab

Eu acho que esse método deve ser o padrão para novas instalações, pois aparentemente nunca é possível ter certeza dos cryptswap1 /dev/disk/by-id/ata-TOSHIBA_MQ01UBD100_73JATD5GT-part3 /dev/urandom swap,cipher=aes-cbc-essiv:sha256 caminhos ... o que eu acho um tanto preocupante, pois tenho a sensação de que há muito mais scripts e software fora que ainda dependem desses caminhos (em vez de IDs, rótulos ou UUIDs) para permanecerem iguais entre as reinicializações.

TODO:

Eu não verifiquei se a continuação da hibernação ainda funciona com essa configuração, pois isso parece depender de um UUID (que minha partição de swap não tinha), conforme declarado nesta página: link

Atualização:

A hibernação parece funcionar bem até agora. Espero que isso resolva esses problemas para os outros também!

    
por FriendFX 06.03.2014 / 12:48
1

Resposta curta:

Problema do UUID:

Você deve ter isso em /etc/crypttab :

cryptswap1 /dev/sda4 /dev/urandom swap,cipher=aes-cbc-essiv:sha256

e esta linha no final de /etc/fstab

/dev/mapper/cryptswap1 none swap sw 0 0

Certifique-se de não usar o uuid no arquivo cryptab.

Suspender problema:

Agora vamos usar um truque para normalizar o comportamento da troca logo antes de reiniciar ou desligar:

Crie um script /etc/init.d/cryptswap.sh com este conteúdo:

#!/bin/bash
/etc/init.d/cryptdisks-early restart

Torne-o executável com:

sudo chmod +x /etc/init.d/cryptswap.sh

Para fazer as coisas corretamente, vamos usar links e números para que sejam executados no momento certo, seja para reinicialização ou desligamento:

cd /etc/rc6.d
sudo ln -s ../init.d/cryptswap.sh S10cryptswap.sh
cd /etc/rc0.d
sudo ln -s ../init.d/cryptswap.sh S10cryptswap.sh

O importante aqui é o número 10 no nome porque o script deve ser executado antes do S40, que começa a fazer o swap; mais tarde, outro script removerá os dispositivos criptografados. O ponto é que a sequência original falha e precisamos da reinicialização para deixá-la passar sem problemas.

É isso aí!

Nota: este é um hack sujo, e pode acontecer que o reinício não seja capaz de consertar o que está acontecendo às vezes. Alguém entre os desenvolvedores responsáveis por swap e / ou cryptsetup deve ir fundo e ver por que, após a suspensão, a troca é deixada em um estado que faz com que swapoff /dev/mapper/cryptswap1 e /etc/init.d/cryptdisks-early stop falhem. Se você executar esses comandos, verá o swapoff reclamar sobre o cabeçalho do swapfile. Além disso, você verá cryptdisks-early enviando uma "falha" ao tentar parar /dev/mapper/cryptswap1 .

Redundância / histórico:

No começo eu pensei que o problema dele estava ligado ao comportamento do kernel pelo libblk, provavelmente um bug (não intencional). Parece que o problema é ter uma tabela de partições editada por diferentes "sistemas de arquivos". O kernel se recusa a preencher /dev/disk/by-uuid/ porque detecta várias assinaturas de sistemas de arquivos editando a tabela de partições. Isso pareceu importante, pois o script /usr/bin/ecryptfs-setup-swap usa o UUID para referenciar entradas que cria para /etc/crypttab .

A correção deve ser para recriar todas as partições do mesmo sistema de arquivos, inicializando em alguma mídia ao vivo. Veja: link

No entanto, isso não funciona porque o ecryptfs / crypttab "reformata" a partição de troca em cada inicialização; você não pode ver um uuid para a partição swap depois de executar o ecryptfs-setup-swap e reiniciar, porque você não deveria. Isso significa que, após a inicialização, a partição não será encontrada pelo crypttab se referenciada pelo uuid, como declarado na outra resposta.

Continuando, uma possível solução foi desistir do uso de uuids e apenas substituí-los em / etc / crypttab com uma notação diferente: somente / dev / sdXX funciona porque os outros são perdidos quando o mkswap é executado nos scripts do crypttab. É assim que os fóruns sugerem para resolver o problema. Isso é necessário.

Isso não funcionou totalmente embora. Eu especulei que havia algum bug no crypttab ( /etc/rcS.d/S26cryptdisks-early - > /etc/init.d/cryptdisks-early - > /lib/cryptsetup/cryptdisks.functions ). Então eu fui cavar lá e não encontrei nada. Na verdade, executar /etc/init.d/cryptdisks-early restart funciona bem, uma vez inicializado, o link /dev/mapper/cryptswap1 é gerado.

Uma correção possível que vi naquele momento, foi mover o swap para um "arquivo" que ocupa todo o espaço na partição swap. Isso é sujo, requer um ponto de montagem, etc. A idéia é que você criaria um arquivo do tamanho da partição inteira, que seria montado como um ext4 regular em say / swap, e o uso do arquivo criptografado como swap. Algo parecido com isto:

  1. No formato GParted como ext4; observe que isso formatará a partição e gerará um novo UUID; não use sudo mkswap /dev/sdXX , pois a partição será montada automaticamente se marcada como swap

  2. sudo mkdir /swap

  3. ls -l /dev/disk/by-uuid/

  4. sudo gedit /etc/fstab # adicionar UUID=XXXXXXXXXXXXXXXXXXXXXXXXX /swap ext4 defaults 0 2

  5. sudo mount /dev/sdXX /swap

  6. sudo dd if=/dev/zero of=/swap/swapfile bs=1024 count=800000

  7. sudo mkswap /swap/swapfile

  8. sudo swapon /swap/swapfile

  9. sudo ecryptfs-setup-swap

Mas eu odiava, então eu não tentei isso.

Outra possível correção que vi foi configurar manualmente, desistindo da geração automatizada de chaves aleatórias, assim: link

Depois de explorar um pouco o local do manual, de alguma forma eu consertei as coisas fazendo o que o /usr/bin/ecryptfs-setup-swap faz primeiro (confira para ver como funciona, apenas edite /etc/crypttab e /etc/fstab ) e execute manualmente o script que são executados na inicialização: /etc/init.d/cryptdisks-early restart ; Mas isso quebrou novamente. Repensando sobre a questão do currículo, encontrei o padrão. Ele quebra no reboot que segue uma suspensão e fica quebrado. Para refixá-lo, é preciso fazer um:

sudo /etc/init.d/cryptdisks-early restart

Depois disso, o swap é montado com sucesso e sem desperdício, desde que você não suspenda. É aqui que o roteiro proposto na resposta curta vem.

    
por nixahn 26.05.2014 / 15:13
1

Eu tive o mesmo problema e encontrei uma solução que funcionou para mim em esta postagem .

Basicamente:

  1. Abrir fstab:

    sudo gedit /etc/fstab
    
  2. Altere esta linha:

    /dev/mapper/cryptswap1 none swap sw 0 0
    

    para isso:

    /dev/mapper/cryptswap1 none swap sw,noauto 0 0
    
  3. Depois vá para

    sudo gedit /etc/rc.local
    

    e imediatamente antes

    exit 0
    

    adicione estas duas linhas:

     sleep 5
     swapon /dev/mapper/cryptswap1
    

Se você quiser verificar se o seu SWAP está realmente montado e funcionando, abra muitos aplicativos que consomem RAM e verifique-o através da digitação do terminal:

free -m
    
por VanPiro 07.01.2015 / 18:30
1

Use a"penas uma troca não criptografada

... e mantenha / home criptografado

Eu tentei a"lgumas das outras soluções sugeridas a"qui. Mesmo que eles funcionassem depois de uma reinicialização a" quente, todos eles falharam depois de um desligamento e reinício a" frio.

Isso nos diz que estamos lidando com um bug duplo:

  1. O UUID da unidade de troca é substituído pelo sistema de criptografia e
  2. Há um problema de tempo limite durante a" inicialização.

Esses pensamentos também são refletidos nos comentários do bug a"rquivado no Launchpad . No entanto, com a" mudança pendente do Upstart para o systemd, pouco é feito para resolver o bug nos sistemas LTS a"tuais.

Nesse ponto, os seguintes pensamentos passaram pela minha cabeça:

  1. Durante a" instalação do sistema, pedi para criptografar a"penas minha partição \home , nada mais.
  2. Os riscos envolvidos em não ter criptografado a" partição de troca são bastante limitados.
  3. Cabe à Canonical limpar seu a"to. Não vou perder mais tempo com isso.

Então, a"qui está a" minha solução para restaurar a" troca como uma troca normal e não criptografada sem ter que reinstalar todo o sistema operacional.

  1. Se a"inda não o fez, instale blkid : $ sudo a"pt-get install blkid
  2. Edite /etc/crypttab e exclua todo o cryptswap1 line: $ sudo nano /etc/crypttab
  3. Inicie o GParted no menu Configurações do sistema.
  4. Você verá uma partição com um ponto de exclamação. Esta deve ser a" partição swap defeituosa. Selecione-o cuidadosamente e reformate-o em uma partição linux-swap . Depois de ter a"plicado esta operação, você é informado sobre o novo UUID da partição de troca normal restaurada. Você tem a" oportunidade de salvar essas informações. Caso contrário, saiba que você sempre pode recuperar o novo UUID da linha de comando com blkid : $ sudo blkid
  5. Agora, é hora de restaurar /etc/fstab para sua a"ntiga glória: $ sudo nano /etc/fstab

    • Remova a" linha inteira contendo uma referência a" /dev/mapper/cryptswap1 .
    • Remova o comentário da a"ntiga linha swap removendo o hash # na frente de UUID=... .
    • Agora, substitua o a"ntigo UUID pelo novo obtido a"nteriormente.
    • Escreva o a"rquivo pressionando Ctrl + O e saia em nano com Ctrl + X .
  6. Uma vez feito isso, você já pode começar a" usar o novo swap não criptografado com: $ sudo swapon -a
  7. Esta solução sobrevive a" reinicializações a" quente e desligamento com reinicialização a" frio.
por Serge Stroobandt 02.05.2015 / 21:13