[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#860833: 50mounted-tests hangs at dmsetup when using biosgrub partition on a left over fat32 partition

Hi Ivo,

(thanks for the cc)

Ivo De Decker <ivodd@debian.org> (2017-04-23):
> Thanks for investigating this in detail.
> The changes introduced in os-prober 1.72 (just before the freeze) are
> meant to provide a fix for #701814, which has been around for quite some
> time. The dmsetup patch was tested on a regular installation. There
> probably wasn't that much testing in d-i, which explains why your
> investigation shows it probably don't work at all. The issue doesn't show
> up that often, because the code path isn't used in most cases (see below).

I had tried to reproduce setups from reporters to debug this further but
unfortunately I wasn't successful…

> The dmsetup code will only be used when grub-mount doesn't work on the
> device.  This means the dmsetup code path is only used when there is a
> partition that can't be mounted by grub-mount (that was the case in
> #853277). Your tests show something similar: there is a partition that
> cannot be mounted by grub-mount, which means the dmsetup path is used. And
> that seems to be broken (at least in d-i).

It's nice to know which part(s) doesn't work, this is good news.

> Given that grub-mount should be able to handle almost all common cases and
> that the dmsetup path probably doesn't work at all in d-i, my proposal
> would be to remove (or disable) the dmsetup code path and only rely on
> grub-mount.

ACK, ignoring something we can't grub-mount looks like a better idea than
just waiting forever. We can still try and find a solution for those cases
later on, and think of backporting it once it's been tested for a while.

> This will still fix the original issue in #701814, and it will fix the
> issues with the dmsetup code path (there is also #853927 and #853163). The
> 'cost' of this change would be that devices which contain a partition that
> can't be mounted by grub-mount, but can be mounted by the kernel, will no
> longer be probed for other operating systems. I don't know if there are
> common examples like that. Another option is to revert to the original
> code path without dmsetup, but that would reintroduce #701814.

I think reverting to the previous breakage shouldn't happen at all…


Attachment: signature.asc
Description: Digital signature

Reply to: