Bug#701814: Re: Bug#701814: os-prober: damages XFS exported via iSCSI but not mounted locally; potential data loss
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 [cjwatson@debian.org]
Reply to: