Невозможно смонтировать файловую систему UDF, созданную с помощью mkudffs внутри тома luks

0

Я пытаюсь создать зашифрованную резервную копию Blu-Ray. Я создал и записал изображение, используя следующий грубый скрипт:

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

Когда скрипт закончился, я использовал следующую команду для записи его на M-Disc BD-R:

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

Ожог завершен без сбоев. Я могу открыть том luks, используя:

sudo cryptsetup luksOpen /dev/dvd mybackup

Который производит устройство /dev/mapper/mybackup; однако, когда я пытаюсь смонтировать его с помощью:

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

Я получаю следующую ошибку:

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.

Системный журнал содержит следующую ошибку:

[ 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)

Обновление 1

Используя следующие команды, я могу смонтировать образ, созданный скриптом:

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

Так что что-то идет не так, потому что это на диске.

Jon
источник

Ответы:

3

Наиболее вероятная причина сбоя - ограничение только для чтения. среды, когда она должна быть открыта для LUKE.

Приведенные ниже эксперименты показывают, что опция -r of cryptsetup делает свое дело:

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

Первая неверная теория:

Основное различие между оптическими носителями и файлами данных или дисковыми устройствами размер блока 2048 байт. Например. редакторы разделов запутались этим при проверке таблиц разделов изогибридных DVD. Может быть, LUKS аналогичным образом зависит от наличия одного и того же базового устройства размер блока с шифрованием и дешифрованием.

Если вы используете носитель BD-RE, вы можете попробовать, поможет ли он создать зашифрованная файловая система непосредственно в / dev / dvd, а не в файле ~ / Backup.img. (Производительность с большим произвольным доступом будет плохой. Ваши буферы ОЗУ могут отодвинуть другую виртуальную память и сделать ее с помощью программ действуют медленно. Синхронизация или размонтирование могут длиться довольно долго.

Если вы используете BD-R, то вы можете использовать BD-RE для создания образа а затем скопируйте его на носитель BD-R.

Если ничего не работает, я мог бы предложить функцию -external_filter в xorriso который зашифровывает содержимое файла, в то время как его помещают в ISO 9660 файловая система с открытым деревом каталогов. Не такая же конфиденциальность, как с LUKS, но менее экзотическая, с другой стороны.

(Почему в мире вы выбираете UDF? У вас есть Solaris или BSD?  машины, которые могут иметь драйверы UDF лучше, чем их подземные Драйверы ISO 9660? Или целевые системы чтения не могут использовать ext?)

След, который я должен был следовать:

Некоторые сообщения о проблемах в Интернете о LUKS и CD / DVD / BD советуют используйте опцию cryptsetup -r в качестве чудесного лекарства. (Т.е. только для чтения и не размер блока был бы камнем преткновения.)

Убедитесь, что оптические носители работают с LUKS:

Я попробовал BD-RE часть моего предложения по созданию на устройстве с блоками 2K (иначе секторы). BD-RE находится в / dev / sr4. Настройка как зашифрованный диск:

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

Чтобы избежать необходимости быть суперпользователем при запуске Xorriso, я даю появился файл устройства в группу "cdrom", где я являюсь членом:

chgrp cdrom /dev/dm-0

Использование xorriso для написания ISO. Вы должны сделать UDF и заполнить его:

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

Это чертовски медленно, возможно, из-за управления дефектами BD-RE, который xorriso не может влиять через уровень устройства шифрования. Я читаю по tar и (потому что он у меня есть) по xorriso:

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

Нет ошибок ввода / вывода, сообщается об ожидаемом размере содержимого ISO.

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

сообщает о совпадении MD5 сессии ISO. Так что это будет работать. Теперь кто-то должен будет вложить BD-R и скопировать BD-RE к нему.

Разница в размерах блоков дисковых файлов и BD не имеет значения:

Я должен был попробовать это первым. Но теперь я следовал твоему рецепту, кроме что я скопировал зашифрованное изображение на BD-RE (все еще слишком экономный для BD-R).

Оно работает. Я могу смонтировать BD-RE с помощью -t udf и скопировать содержимое файла в wc.

Таким образом, слух о параметре cryptsetup -r на носителе только для чтения быть единственной правдоподобной теорией.

Успех с CD-RW в качестве замены BD-R:

Я попытался использовать неформатированный CD-RW, который Linux считает доступным только для чтения.

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

Никогда не буду делать это снова. Диск был сброшен ядром. Один из Строки / var / log / messages говорят, что Linux пытался писать в него. Только хорошо, что это в коробке USB. Так что я мог бы восстановить его с помощью цикла питания.

С опцией -r все работает нормально:

sudo cryptsetup luksOpen -r /dev/sr4 mybackup
sudo mount -t udf /dev/mapper/mybackup /mnt/backup
tar cf - /mnt/backup | wc
Thomas Schmitt
источник
Я использую M-DISC , что является эквивалентом BD-R для длительного хранения. Я на самом деле следую это руководство , Причиной появления UDF является поддержка файлов & gt; 4 ГБ, что может случиться при резервном копировании домашних фильмов. Что касается размера блока, вы имеете в виду размер блока файловой системы UDF в LUKS?
Jon
Утверждение, что файловые системы BD должны быть UDF, совершенно неверно. Solaris и BSD имеют более чем 20-летние драйверы чтения ISO 9660, которые могут читать файлы данных только до 4 ГиБ - 1. Linux и MS-Windows могут хорошо читать файлы данных размером более 4 ГБ из файловой системы ISO 9660. Моя теория размера блока относится к размеру блока устройства (или файла), в котором создается зашифрованная UDF LUKS, в сравнении с размером блока носителя BD. Их различие может объяснить, почему он работает на диске, а не на BD.
Thomas Schmitt
1
Руководство ошибочно, утверждая, что ext4 не был «совместим с оптическими носителями» (в «LUKS / Blu-ray Objective»). Я только что создал ext4 на BD-RE, и он работает (хотя и шумно). Сообщение об ошибке монтирования для ext4-in-LUKS, показанное в руководстве, такое же, как и при использовании UDF-in-LUKS.
Thomas Schmitt
Я сделал обновления к своему ответу. Размер блока, кажется, не проблема. Но носитель только для чтения вполне может быть. То есть попробуйте параметр cryptsetup -r (я полагаю, с luksOpen).
Thomas Schmitt
0

Мне, наконец, удалось смонтировать зашифрованный bluray, сначала подключив считыватель к устройству цикла и запустив cryptsetup на последнем:

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

Зашифрованный bluray затем монтируется на /mnt/backup,

Я обнаружил это в старый отчет об ошибке Red Hat и не имею понятия, зачем нужно петлевое устройство, и подозреваю, что это может быть ошибкой, поскольку автоматическое монтирование с использованием графического интерфейса thunar дает сбой (можно было бы ожидать, что это сработает), что также упоминается в отчете об ошибках Red Hat, хотя и с рабочим столом Gnome. Также очень странно, что изображение, которое сгорает до синевы, может быть смонтировано без петлевого устройства.

Чтобы отменить вышесказанное, используйте следующее:

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

я открыл отчет об ошибках с cryptsetup на всякий случай это ошибка.

Jon
источник