LINUX.ORG.RU
ФорумAdmin

Монтирование вложенных образов

 


0

2

Здравствуйте!

[root@bug20 mnt]# mount /tmp/test.img /mnt/backup/ -o loop -t squashfs -r
[root@bug20 mnt]# ls -l /mnt/backup/

итого 169344 -r--r--r-- 1 root root 524288000 Апр 23 13:11 sda1_backup.img

[root@bug20 mnt]# mount /mnt/backup/sda1_backup.img /mnt/bug -o loop -r -v

mount: подготовка к использованию устройства обратной связи /dev/loop1
mount: вы не указали тип файловой системы для /dev/loop1 я попробую тип ext4
mount: wrong fs type, bad option, bad superblock on /dev/loop1,
missing codepage or helper program, or other error
В некоторых случаях полезная информация может быть
найдена в syslog - попробуйте dmesg | tail или что-то в этом роде

если скопировать sda1_backup.img, например в /tmp, то оттуда монтируется нормально.
Что делаю не так?

Ответ на: комментарий от Pinkbyte

то же самое

[root@bug20 mnt]# losetup -f

/dev/loop1


[root@bug20 backup]# losetup /dev/loop1 sda1_backup.img
[root@bug20 backup]# losetup -a

/dev/loop0: [fd00]:5522 (/tmp/test.img)
/dev/loop1: [0700]:1 (/mnt/backup/sda1_backup.img)


[root@bug20 mnt]# mount /dev/loop1 /mnt/bug -r -v

mount: вы не указали тип файловой системы для /dev/loop1 я попробую тип ext4
mount: wrong fs type, bad option, bad superblock on /dev/loop1,
missing codepage or helper program, or other error
В некоторых случаях полезная информация может быть
найдена в syslog - попробуйте dmesg | tail или что-то в этом роде


[root@bug20 mnt]# dmesg | tail

EXT4-fs (loop1): INFO: recovery required on readonly filesystem
EXT4-fs (loop1): write access unavailable, cannot proceed
EXT4-fs (loop1): INFO: recovery required on readonly filesystem
EXT4-fs (loop1): write access unavailable, cannot proceed
EXT4-fs (loop2): INFO: recovery required on readonly filesystem
EXT4-fs (loop2): write access unavailable, cannot proceed
EXT4-fs (loop1): INFO: recovery required on readonly filesystem
EXT4-fs (loop1): write access unavailable, cannot proceed
EXT4-fs (loop1): INFO: recovery required on readonly filesystem
EXT4-fs (loop1): write access unavailable, cannot proceed

Man1980
() автор топика
Ответ на: то же самое от Man1980

write access unavailable, cannot proceed

.img - это случаем не ISO или squashfs-образ?

Похоже ФС на loop0 - ro, а в образе требуется изменение журнала(то есть запись) -> оно невозможно -> смонтировать ФС нельзя

Pinkbyte ★★★★★
()
Последнее исправление: Pinkbyte (всего исправлений: 1)
Ответ на: комментарий от Pinkbyte

Кстати, у меня такая же ситуация была с вложенными образами. Ext внутри squash. Всё монтировалось, разве что ext можно было примонтировать только ro, так как squash в ro монтировался.

generator ★★★
()
Ответ на: комментарий от Pinkbyte

.img - это случаем не ISO или squashfs-образ?

test.img (внешний, смонтировался) - squashfs-образ, как видно из листингов.
sda1_backup.img (внутренний, не смонтировался) - посекторный dd-образ раздела.

Похоже ФС на loop0 - ro, а в образе требуется изменение журнала(то есть запись) -> оно невозможно -> смонтировать ФС нельзя

Ну да, на loop0 - ro по определению, т.к. это squashfs.
Я ведь и loop1 тоже в режиме ro монтирую. Для чего требуется изменение?


P.S. Образы были созданы так:

mkdir empty-dir
mksquashfs empty-dir test.img -p 'sda1_backup.img f 444 root root dd if=/dev/sda1 bs=4M'

Man1980
() автор топика
Ответ на: комментарий от Man1980

А ты не монтируй в RO, а losetup делай в RO. А там и посмотришь, изменится что-то или нет.

YAR ★★★★★
()

что мешает указать тип файловой системы используя "-t" ?

vel ★★★★★
()
Ответ на: комментарий от Man1980

Ну да, на loop0 - ro по определению, т.к. это squashfs.

Я ведь и loop1 тоже в режиме ro монтирую. Для чего требуется изменение?

Иногда даже при монтировании в ro требуется доступ к устройству на запись. Например, для восстановления ФС после некорректного отмонтирования. Собственно, здесь это и происходит — дело именно в этом.

Я бы предложил либо пересоздать образ, либо через dm/LVM наложить на этот образ пустой файл (созданный в tmpfs) с возможностью записи в него — по-моему, так можно.

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от intelfx

Иногда даже при монтировании в ro требуется доступ к устройству на запись. Например, для восстановления ФС после некорректного отмонтирования. Собственно, здесь это и происходит — дело именно в этом.

Вы правы! Скопировал sda1_backup.img в /tmp. В режиме RO монтироваться также не захотел.
Смонтировал в RW - сразу размонтировал - заново запаковал в test.img - смонтировал test.img - смонтировал sda1_backup.img - OK!
Я бэкапил не отмонтированный раздел, похоже в этом причина.
Но стоит задача бэкапить раздел именно с работающей системы, со сжатием на лету. Чтобы потом можно было его смонтировать для просмотра, и возможно, при необходимости развернуть обратно.

Man1980
() автор топика
Ответ на: комментарий от Man1980

Но стоит задача бэкапить раздел именно с работающей системы

А это, вообще говоря, неверно. Твой бэкап происходит далеко не мгновенно. Представь себе ситуацию: между двумя моментами времени, соответствующими чтению таблицы инодов и чтению блоков содержимого некоего файла, этот файл успевает удалиться, а на его место пишется что-то другое. Получаем внутренне рассогласованное состояние: в бэкапе этот файл будет, но в нём будет мусор.

Проблема в рамках твоего подхода не решается. Я советую делать как-то совсем по-другому. Как именно — вопрос хороший. Например, делать снапшот средствами LVM и бэкапить уже его. Но тут ты починишь только внутреннюю рассогласованность; проблемы при монтировании останутся. Погугли на тему «backing up a running system».

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от intelfx

Спасибо за четкие и развернутые ответы.

Man1980
() автор топика
Ответ на: комментарий от goingUp

О, круто, не знал о такой фиче VFS. Только, боюсь, топикстартеру этот метод тоже не подойдёт, потому что он хочет бэкапить запущенную в данный момент систему (после fsfreeze она скорее всего встанет раком).

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от intelfx

Имелось в виду fsfreeze, LVM снапшот, unfreeze. По идее будет недолго. Программы, которые работали с файлами, подождут и возновят работу опять. Я так делал на облачном AWS. Там тоже снапшоты на блочном уровне.

goingUp ★★★★★
()
Последнее исправление: goingUp (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.