А если ручками через losetup забиндить?

то же самое

[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

write access unavailable, cannot proceed

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

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

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

.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'

generator, я тоже в ro пытаюсь монтировать

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

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

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

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

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

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

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

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

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

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

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

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

Но тут ты починишь только внутреннюю рассогласованность; проблемы при монтировании останутся.

Можно так https://rwmj.wordpress.com/2010/06/09/freezing-filesystems/

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

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