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

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

Your message dated Mon, 01 May 2017 09:04:17 +0000
with message-id <E1d57Fh-0004cr-Bs@fasolo.debian.org>
and subject line Bug#860833: fixed in os-prober 1.75
has caused the Debian Bug report #860833,
regarding 50mounted-tests hangs at dmsetup when using biosgrub partition on a left over fat32 partition
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org

860833: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=860833
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message ---
Package: os-prober
Version: 1.74
Severity: important
X-Debbugs-CC: cjwatson@debian.orgivo.dedecker@ugent.be, pkern@debian.org

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.

--- End Message ---
--- Begin Message ---
Source: os-prober
Source-Version: 1.75

We believe that the bug you reported is fixed in the latest version of
os-prober, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 860833@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
Ivo De Decker <ivodd@debian.org> (supplier of updated os-prober package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)

Hash: SHA256

Format: 1.8
Date: Mon, 01 May 2017 09:55:33 +0200
Source: os-prober
Binary: os-prober-udeb os-prober
Architecture: source
Version: 1.75
Distribution: unstable
Urgency: medium
Maintainer: Debian Install System Team <debian-boot@lists.debian.org>
Changed-By: Ivo De Decker <ivodd@debian.org>
 os-prober  - utility to detect other OSes on a set of drives
 os-prober-udeb - utility to detect other OSes on a set of drives (udeb)
Closes: 853163 853927 860833
 os-prober (1.75) unstable; urgency=medium
   * Remove code using device mapper (Closes: #860833, #853927, #853163).
     This code doesn't work in d-i and it has some issues outside d-i. All
     architectures can use the grub-mount codepath, which was already the
     default anyway.
     This also removes the dependency on dmsetup.
 f612317b7f5f5bfc916a1c228dfa1a41d45b531a 1738 os-prober_1.75.dsc
 a8d0a562324bf2d1076426e0e482611f9ebe4d9b 26216 os-prober_1.75.tar.xz
 3042c501ba182580616417fd26a3934bf5fae3dc814bc4114f83c14f37ec9727 1738 os-prober_1.75.dsc
 f4ef620455c5ffc3545daf4f32861640a48b0b3b6edda72491eecc1818653446 26216 os-prober_1.75.tar.xz
 9e803f036da017d6e297d487dc47f941 1738 debian-installer optional os-prober_1.75.dsc
 acf4f8818af3cee051aa6f927a451e55 26216 debian-installer optional os-prober_1.75.tar.xz

Version: GnuPG v1


--- End Message ---

Reply to: