Partitions produced by the installer not properly unmounted?

  • Done
  • quality assurance status badge
Details
2 participants
  • Ludovic Courtès
  • Mathieu Othacehe
Owner
unassigned
Submitted by
Ludovic Courtès
Severity
important
L
L
Ludovic Courtès wrote on 21 Feb 2020 12:13
(address . bug-guix@gnu.org)
87lfownqgd.fsf@inria.fr
Hi Mathieu,

I noticed that partitions created by the installer appear to not be
properly unmounted, at least when running in the context of (gnu tests
install):

Toggle snippet (25 lines)
ludo@ribbon ~$ qemu-img convert -O raw /gnu/store/2d3s2nbb3j2c1hmkz52xds9rfbk4q3x3-installation /tmp/broken.raw
ludo@ribbon ~$ sudo losetup -P /dev/loop0 /tmp/broken.raw
ludo@ribbon ~$ sudo dmesg |tail -3
[10703.869334] kvm [8936]: vcpu0, guest rIP: 0xffffffffac073dad disabled perfctr wrmsr: 0xc2 data 0xffff
[10742.475623] kvm [8957]: vcpu0, guest rIP: 0xffffffffaf073dad disabled perfctr wrmsr: 0xc2 data 0xffff
[11774.318468] loop0: p1 p2 p3
ludo@ribbon ~$ sudo fdisk -l /dev/loop0
Disk /dev/loop0: 2.15 GiB, 2306867200 bytes, 4505600 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 213AE251-0E91-499E-9184-0CCEC6DA64C7

Dispositiu Start Final Sectors Size Tipus
/dev/loop0p1 2048 6143 4096 2M BIOS boot
/dev/loop0p2 6144 231423 225280 110M Intercanvi Linux
/dev/loop0p3 231424 4503551 4272128 2G Linux filesystem
ludo@ribbon ~$ sudo mount /dev/loop0p3 /mnt/usb
ludo@ribbon ~$ sudo dmesg |tail -3
[11774.318468] loop0: p1 p2 p3
[11803.975300] EXT4-fs (loop0p3): recovery complete
[11803.977277] EXT4-fs (loop0p3): mounted filesystem with ordered data mode. Opts: (null)

However, I’ve added logging in ‘umount-user-partitions’ in (gnu
installer parted), and the installer does seem to unmount partitions
correctly.

Could it be a side effect of the MS_MOVE dance in
1d02052067e04d7dd8fd1ec17557ca02a30b9bcf?

(I’m observing this on ‘wip-installer-tests’, roughly based on
117d8467be232bcc1b0136d04f362d95d975ca95.)

Thanks,
Ludo’.
M
M
Mathieu Othacehe wrote on 21 Feb 2020 16:27
(address . 39712@debbugs.gnu.org)(name . Ludovic Courtès)(address . ludo@gnu.org)
87h7zknepa.fsf@gmail.com
Hey Ludo,

Nice progress on that branch :)

Toggle quote (3 lines)
> Could it be a side effect of the MS_MOVE dance in
> 1d02052067e04d7dd8fd1ec17557ca02a30b9bcf?

Could be, I ran the following command on wip-installer-test branch:

Toggle snippet (3 lines)
make check-system TESTS=gui-installed-os

But it appears to get stuck at this step:

Toggle snippet (3 lines)
conversation expecting pattern ((quote pause))

I'll try to investigate further later on.

Thanks,

Mathieu
L
L
Ludovic Courtès wrote on 21 Feb 2020 21:43
(name . Mathieu Othacehe)(address . m.othacehe@gmail.com)(address . 39712@debbugs.gnu.org)
87d0a73c3x.fsf@gnu.org
Hi,

Mathieu Othacehe <m.othacehe@gmail.com> skribis:

Toggle quote (14 lines)
>> Could it be a side effect of the MS_MOVE dance in
>> 1d02052067e04d7dd8fd1ec17557ca02a30b9bcf?
>
> Could be, I ran the following command on wip-installer-test branch:
>
> make check-system TESTS=gui-installed-os
>
>
> But it appears to get stuck at this step:
>
> conversation expecting pattern ((quote pause))
>
> I'll try to investigate further later on.

Don’t investigate on that branch yet though, I have quite a lot of
changes that I’ll push soon. :-)

But I think the problem should show up even with “make check-system
TESTS=installed-os” on master.

Thanks,
Ludo’.
M
M
Mathieu Othacehe wrote on 22 Feb 2020 11:24
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 39712@debbugs.gnu.org)
875zfyvs15.fsf@gmail.com
Hey Ludo,

Toggle quote (3 lines)
> But I think the problem should show up even with “make check-system
> TESTS=installed-os” on master.

Well this does not involve the graphical installer, so I'm not sure to
understand.

Anyway, testing the installer in Qemu, I can reproduce a failure where
the first umount in "umount-cow-store" throws an exception (busy
device), when umounting a crypted partition.

That's probably what's bitting you, so to be continued!

Thanks,

Mathieu
L
L
Ludovic Courtès wrote on 22 Feb 2020 18:13
(name . Mathieu Othacehe)(address . m.othacehe@gmail.com)(address . 39712@debbugs.gnu.org)
87blpqy282.fsf@gnu.org
Hi,

Mathieu Othacehe <m.othacehe@gmail.com> skribis:

Toggle quote (3 lines)
>> But I think the problem should show up even with “make check-system
>> TESTS=installed-os” on master.

Hmm I’m not sure this is true.

Toggle quote (7 lines)
> Well this does not involve the graphical installer, so I'm not sure to
> understand.
>
> Anyway, testing the installer in Qemu, I can reproduce a failure where
> the first umount in "umount-cow-store" throws an exception (busy
> device), when umounting a crypted partition.

On current ‘wip-installer-test’
(0699b97f7df8708a000eb7bfb043c2cef6672dc3), you can run:

make check-system TESTS=gui-installed-os

(It should succeed.)

If you take the /gnu/store/…-installation item produced and mount it as
I showed before in this thread, you should see a “recovery complete”
message from the kernel.

Note that LUKS is not involved at all in this case, and ‘umount’ doesn’t
throw.

Ludo’.
L
L
Ludovic Courtès wrote on 24 Feb 2020 22:27
control message for bug #39712
(address . control@debbugs.gnu.org)
87blpnekwj.fsf@gnu.org
severity 39712 important
quit
M
M
Mathieu Othacehe wrote on 13 Mar 2020 16:52
Re: bug#39712: Partitions produced by the installer not properly unmounted?
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 39712-done@debbugs.gnu.org)
87pndgz1yu.fsf@gmail.com
This is fixed by 64704be417ab6f2788e8e3bc36fede1db35470e7.

Thanks,

Mathieu
Closed
?
Your comment

This issue is archived.

To comment on this conversation send an email to 39712@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 39712
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch