Package: os-prober
Version: 1.74
Severity: important
I'm using a recipe that includes this snippet:
1 1 1 free \
$iflabel{ gpt } \
$reusemethod{ } \
method{ biosgrub } \
This snippet is present in the following automated recipes:
The biosgrub method does not touch the partition in any way. It leaves the contents as is. If the installation is done in EFI mode, nothing is written to this BIOS partition. Which means that if there happened to be a fat32 partition that started on that sector (and was larger than 1 MB), the fat32 bits are still there after partman has run, in a way that confuses the lsblk command into thinking that the filesystem is "vfat"
This was always the case but it was not a problem with previous os-prober versions because there was no dmsetup being executed. Now, with the new dmsetup commands, this triggers problems because the mount point enters a weird state.
This is the error in the log when it tries to mount the partition the first time:
Apr 20 08:30:12 50mounted-tests: debug: mounting /dev/mapper/osprober-linux-nvme0n1p1 (/dev/nvme0n1p1) as vfat failed: mount: mounting /dev/mapper/osprober-linux-nvme0n1p1 on /var/lib/os-prober/mount failed: Input/output error
The first time os-prober runs, it gets this error and it then claims to have removed the device mapper entry. However, the next time os-prober runs (for some reason, during one d-i session, it runs 4 times) it hangs while running dmsetup create -r osprober-linux-nvme0n1p1
This hangs completely and never ends, a possible workaround is to kill the dmsetup command. After that, the next 2 os-prober runs detect that there's a problem and don't hang.
I believe this is quite an important issue as any machine that has a previously formatted vfat will completely hang while installing. Before you claim no machine will have a previously formatted vfat: the affected machine is a new "Non Windows" machine coming from HP with FreeDOS installed.
After a lot of debugging with Philipp Kern, we were able to find out that dmsetup was hanging on a udev cookie semaphore. The udev outside of the chroot is compiled udev_sync, and it doesn't have dmsetup rules, so it seems that it's not sending the dmsetup udevcomplete signal and thus dmsetup hangs forever. Another possible workaround then is to send the right dmsetup udevcomplete signal, and then installation proceeds.
It's not clear to me how the dmsetup code block would ever work without proper udev support outside the chroot. It's also not clear why the first time it fails sort of gracefully and then hangs very ungracefully the second time.