This is easy to show. Create a disk image containing an ext3 filesystem and a single file:
$ guestfish -N fs:ext3 -n -m /dev/sda1 touch /hello-world : sync $ md5sum test1.img a1f6684a8a04d14f7599902bc0ab4aaa test1.img
- The guestfish -N option creates a prepared disk called
test1.imgin the current directory.
- The guestfish -n option turns off autosync, so the disk will not be cleanly unmounted after the command has finished.
-m /dev/sda1mounts the prepared filesystem
touchcreates a file on the prepared filesystem
syncis needed to write changes without unmounting the filesystem (so it is dirty).
md5sumcomputes the MD5 hash of the disk we’ve just created
Now let’s open the disk, mount it with the
-o ro option, and read the root directory:
$ guestfish -a test1.img run : mount-ro /dev/sda1 / : ll / total 17 drwxr-xr-x 3 root root 1024 Feb 3 17:49 . drwxr-xr-x 23 500 500 4096 Feb 3 17:50 .. -rw-r--r-- 1 root root 0 Feb 3 17:49 hello-world drwx------ 2 root root 12288 Feb 3 17:49 lost+found $ md5sum test1.img 8fab31ef115cb8a6edcbc71db61fcafc test1.img
-a test1.imgadds the prepared disk (
test1.img) to the libguestfs appliance, but note, not read-only
runstarts the appliance
mount-romounts the prepared filesystem with the
Notice the MD5 hash of the disk has changed!
Try repeating the second command and you’ll see that the MD5 hash stays the same.
It appears that because the filesystem is ext3 and was originally dirty,
mount -o ro reruns the journal and thus writes to the underlying disk. (It is possible also that it is merely updating the superblock to mark it clean, but in any case the point is that it is writing to the disk).
All of this is not unexpected, but it shows that you must use libguestfs add-drive-ro if you really want to look at a disk image without making any changes to it. That command uses qemu snapshots to ensure that any write operations never make it to the disk, but get discarded in an anonymous snapshot overlay.
If you use the
guestfish --ro option then any
-d drives are added read-only.