Over a decade later... but this might help someone. There is a way around this mess, with some caveats. You can set the block device to readonly using blockdev. This works as desired a lot of the time. However, sometimes (or perhaps everytime certain filesystems need to replay the journal), the will cause the kernel to refuse to mount the filesystem. The way around this is to, as mentioned above, replay the journal to ram. As far as I know, no filesystems support this natively. What can be done is to use dm-snapshot to create a snapshot of the block device with the cow file residing on a tmpfs. Then mount the snapshot device's filesystem as readonly. In this case the log will be replayed to ram.
The caveat here is that, when in this state, the underlying block device should not be written to. So effectively the block device is locked up until the snapshot device is removed. A scenario where this might be an issue is as follows. You have a harddrive with isos on an ext4 filesystem that you use to grub iso loopback mount to boot from. When booting one of the isos, you use the snapshot setup with this filesystem because you don't know if its part of a hibernation image or not. When the livecd is up and running, you will not be able to modify the filesystem (you can write to it, but all changes are in ram and will be lost). That's as it should be if the filesystem is part of a hibernation image, but it might be more likely that its not. And in that case, it might be confusing why this restriction exists. What would be good is to have code that can detect if the system has a hibernation image or even better if the filesystem was mounted while a hibernation happened (not sure if that's possible). Then the snapshot work around could be done only when needed. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/41624 Title: Replaying journals of other OS's filesystems, by mounting them, is unsafe Status in iso-scan package in Ubuntu: Triaged Status in linux package in Ubuntu: Won't Fix Status in lupin package in Ubuntu: Triaged Status in partman-basicfilesystems package in Ubuntu: Fix Released Status in os-prober package in Debian: Fix Released Bug description: I have just done a clean install of recent dapper (20060426.1 live i386) on my main testbed machine. The automatic volume discovery system has not only found the filesystems from various of the other installations (which is not quite so bad) but has dug into my LVM system and found the fs for a frozen Xen image ! This kind of thing can cause serious data loss. Modern journalling filesystems go even more badly wrong than traditional fs's if they are accessed by two running systems in an interleaved fashion, which is what results if Dapper automatically finds and mounts these filesystems, replaying the journal, while a frozen (whether by a VM like Xen or by ordinary hibernation) image has them mounted. In the current setup I think it would be easy to cause disaster simply by installing dapper twice on the same machine and then continuously hibernating one while using the other. More complex schemes are also possible. All of these filesystems discovered in this way should be made read- only unless it can be somehow known that it's safe to make them r/w. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/iso-scan/+bug/41624/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
