On Sun, Mar 24, 2013 at 01:29:54PM +0100, Ivo De Decker wrote: > Is there still a reason to keep trying the regular mount? Are there cases > where grub-mount is expected to fail? Maybe only trying grub-mount could be > the default.
grub-mount is only available on architectures where GRUB has been ported; that's quite a few nowadays, but not all. Furthermore os-prober is used on some other distributions and I don't know if they all have grub-mount available. But it's true that to some extent I was mostly being conservative in falling back to mount, and maybe we could do something better in terms of working out whether grub-mount can reasonably be expected to be available. > Also, why did grub-mount fail in this case? Was grub-common not installed? The > os-prober udeb depends on grub-mount-udeb (on the architectures where fuse is > available), but os-prober doesn't depend on grub-common (the package shipping > grub-mount). There isn't even a recommends or suggests. I think os-prober was actually being invoked via some bit of GRUB in this case, so that seems an unlikely cause. More likely, I suspect, grub-mount hasn't worked out how to talk to iSCSI devices. > When grub-mount fails, os-prober sets the device read-only and tries to mount > it. It looks like the error reported in this bug was caused by setting the > device read-only, not by mounting it. The mount didn't change anything, > because the device was read-only. The mount probably would have changed the > filesystem (by replaying the journal) if the device was not read-only. > > A fix for this could be to create a read-only linear device with device-mapper > and mounting that, instead of setting the device read-only. That way, the > device itself doesn't have to be changed. This can only work if device mapper > is available. Indeed. If you can figure out how to make this work reliably, this would be a nice general fix. I hadn't realised that blockdev had the potential to trip this kind of breakage when I wrote that code. -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
