Estou tentando criar um backup blu-ray criptografado. Eu criei e queimei a imagem usando o seguinte script bruto:

imgsize=23000M
imgfile=~/backup.img
imgloop=`sudo losetup -f`
truncate -s $imgsize $imgfile
sudo losetup $imgloop $imgfile
sudo cryptsetup luksFormat --cipher aes-xts-plain64 $imgloop
sudo cryptsetup luksOpen $imgloop mybackup
sudo mkudffs /dev/mapper/mybackup
if [ ! -d "/mnt/backup" ]; then
    sudo mkdir /mnt/backup
fi
sudo mount /dev/mapper/mybackup /mnt/backup

# Now copy all files that are part of the backup
echo "Copy files to backup to /mnt/backup. Type 'ready' when done";
while read line; do
    echo "$line";
    if [ "$line" == "ready" ]; then
        break;
    fi
done

sudo umount /mnt/backup
sudo cryptsetup luksClose /dev/mapper/mybackup
sudo losetup -d $imgloop

Quando o script terminou, usei o seguinte comando para gravá-lo em um M-Disc BD-R:

growisofs -dvd-compat -Z /dev/dvd=backup.img

A gravação foi concluída sem falha. Consigo abrir o volume luks usando:

sudo cryptsetup luksOpen /dev/dvd mybackup

O que produz o dispositivo /dev/mapper/mybackup; no entanto, quando tento montá-lo com:

sudo mount -t udf /dev/mapper/mybackup /mnt/backup

Estou tendo o erro a seguir:

mount: /dev/mapper/mybackup is write-protected, mounting read-only
mount: wrong fs type, bad option, bad superblock on /dev/mapper/mybackup,
       missing codepage or helper program, or other error

       In some cases useful info is found in syslog - try
       dmesg | tail or so.

O syslog contém o seguinte erro:

[ 2334.880043] UDF-fs: warning (device dm-3): udf_load_vrs: No anchor found
[ 2334.880046] UDF-fs: warning (device dm-3): udf_fill_super: No partition found (1)

Atualização 1

Usando os seguintes comandos, posso montar a imagem produzida pelo script:

sudo cryptsetup luksOpen backup.img mybackup
sudo mount -t udf /dev/mapper/mybackup /mnt/backup

Então, algo está errado porque está no disco.

A razão mais provável para a falha é a rescisão somente leitura do meio quando ele deve ser aberto para LUKS.

As experiências abaixo indicam que a opção -r de cryptsetup faz o truque:

sudo cryptsetup luksOpen -r /dev/dvd mybackup
sudo mount -t udf /dev/mapper/mybackup /mnt/backup

Primeira teoria errada:

A principal diferença entre mídia ótica e arquivos de dados ou dispositivos de disco é o tamanho do bloco de 2048 bytes. Por exemplo, os editores de partição ficam confusos com isso ao inspecionar as tabelas de partição de DVDs iso-híbridos. Talvez o LUKS esteja similarmente dependendo de ter o mesmo tamanho de bloco de dispositivo subjacente com criptografia e descriptografia.

Se você usa mídia BD-RE, pode tentar ajudar a criar o sistema de arquivos criptografado diretamente em / dev / dvd, e não no arquivo ~ / backup.img. (O desempenho com acesso aleatório pesado será ruim. Seus buffers de RAM podem afastar outras memórias virtuais e fazer com que seus programas funcionem lentamente. A sincronização ou a quantidade podem durar muito tempo.

Se você usa o BD-R, pode usar um BD-RE para criar a imagem e copiá-lo para a mídia BD-R.

Se nada funcionar, eu poderia oferecer o recurso -external_filter do xorriso, que criptografaria o conteúdo do arquivo enquanto ele fosse colocado em um sistema de arquivos ISO 9660 com árvore de diretórios em texto não criptografado. Não é a mesma privacidade de LUKS, mas menos exótica, por outro lado.

(Por que no mundo você opta por UDF? Você tem máquinas Solaris ou BSD que podem ter drivers UDF melhores que seus drivers subterrâneos ISO 9660? Ou os sistemas de leitores direcionados não podem usar ext?)

O rastreamento que eu deveria ter seguido:

Alguns relatórios de problemas na web sobre LUKS e CD / DVD / BD recomendam o uso da opção cryptsetup -r como cura milagrosa. (Ou seja, somente leitura e não o tamanho do bloco seria a pedra de tropeço.)

Verifique se a mídia ótica funciona com LUKS:

Tentei a parte BD-RE da minha proposta para criar em um dispositivo com blocos de 2K (também conhecidos como setores). O BD-RE está em / dev / sr4. Configurando-o como disco criptografado:

/sbin/cryptsetup luksFormat --cipher aes-xts-plain64 /dev/sr4
sudo /sbin/cryptsetup luksOpen /dev/sr4 mybdre

Para evitar a necessidade de ser superusuário ao executar o xorriso, dou o arquivo de dispositivo emergente ao grupo "cdrom" em que sou membro:

chgrp cdrom /dev/dm-0

Usando xorriso para escrever um ISO. Você faria um UDF e o preencheria:

xorriso -for_backup -outdev stdio:/dev/mapper/mybdre -blank as_needed -map /some_directory /

Isso é muito lento, possivelmente devido ao Gerenciamento de Defeitos do BD-RE, que o xorriso não pode influenciar através da camada do dispositivo de criptografia. Eu verifico por tar e (porque o tenho) por xorriso:

sudo mount /dev/mapper/mybdre /mnt/iso
tar cf - /mnt/iso | wc

Sem erros de E / S, o tamanho esperado do conteúdo ISO é relatado.

sudo umount /mnt/iso
xorriso -for_backup -indev stdio:/dev/mapper/mybdre -check_media --

relata a correspondência MD5 da sessão ISO. Então isso funcionaria. Agora alguém teria que investir um BD-R e copiar o BD-RE para ele.

A diferença de tamanho de bloco dos arquivos de disco e do BD não importa:

Eu deveria ter tentado isso primeiro. Mas agora eu segui sua receita, exceto que copiei a imagem criptografada em um BD-RE (ainda muito econômico para o BD-R).

Funciona. Posso montar o BD-RE com -t udf e tar o conteúdo do arquivo no wc.

Portanto, o boato sobre a opção cryptsetup -r na mídia somente leitura parece ser a única teoria plausível que resta.

Sucesso com um CD-RW como substituto de um BD-R:

Eu tentei com um CD-RW não formatado que é considerado pelo Linux como somente leitura.

sudo cryptsetup luksOpen /dev/sr4 mybackup
sudo mount -t udf /dev/mapper/mybackup /mnt/backup

Nunca mais o fará. A unidade foi derrubada pelo kernel. Uma das linhas / var / log / messages diz que o Linux tentou gravar nele. Só é bom em uma caixa USB. Então eu poderia recuperá-lo por um ciclo de energia.

Com a opção -r funciona bem:

sudo cryptsetup luksOpen -r /dev/sr4 mybackup
sudo mount -t udf /dev/mapper/mybackup /mnt/backup
tar cf - /mnt/backup | wc

Finalmente consegui montar o bluray criptografado primeiro mapeando o leitor para um dispositivo de loop e fazendo com que o conjunto de criptografia funcionasse no último:

sudo losetup /dev/loop0 /dev/dvd
sudo cryptsetup luksOpen /dev/loop0 myvolume
sudo mount /dev/mapper/myvolume /mnt/backup

O bluray criptografado é então montado em /mnt/backup.

Eu descobri isso em um antigo relatório de bug da Red Hat e não tenho idéia do porquê o dispositivo de loop é necessário e suspeito que possa ser um bug, pois a montagem automática usando o gui in thunarfalha (seria de esperar que funcionasse), que também é o que o Red O relatório de erros de chapéu menciona, embora na área de trabalho do Gnome. Também é muito estranho que a imagem que queima no bluray possa ser montada sem o dispositivo de loop.

Para reverter o acima, use o seguinte:

sudo umount /mnt/backup
sudo cryptsetup luksClose myvolume
sudo losetup -d /dev/loop0

Abri um relatório de erro com cryptsetup , caso seja um erro.