[arch-releng] [PATCH 1/1] explicitly detach loop device on umount

Wed Apr 22 00:05:42 UTC 2015

On 04/21/2015 07:43 PM, Christian Hesse wrote:
> Gerardo Exequiel Pozzi <vmlinuz386 at gmail.com> on Tue, 2015/04/21 19:23:
>> On 04/21/2015 02:57 AM, Christian Hesse wrote:
>>> From: Christian Hesse <mail at eworm.de>
>>>
>>> I see cases where a stale loop device stays around and fills up my
>>> partition as image file is still in use and does not get unlinked.
>>>
>>> Explicitly detach loop device on umount to fix that.
>>>
>>> Signed-off-by: Christian Hesse <mail at eworm.de>
>>> ---
>>>  archiso/mkarchiso       | 2 +-
>>>  configs/releng/build.sh | 2 +-
>>>  2 files changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/archiso/mkarchiso b/archiso/mkarchiso
>>> index 0da02b0..bc82786 100755
>>> --- a/archiso/mkarchiso
>>> +++ b/archiso/mkarchiso
>>> @@ -59,7 +59,7 @@ _mount_airootfs() {
>>>  
>>>  _umount_airootfs() {
>>>      _msg_info "Unmounting '${work_dir}/mnt/airootfs'"
>>> -    umount "${work_dir}/mnt/airootfs"
>>> +    umount -d "${work_dir}/mnt/airootfs"
>>>      _msg_info "Done!"
>>>      rmdir "${work_dir}/mnt/airootfs"
>>>      trap - EXIT HUP INT TERM
>>> diff --git a/configs/releng/build.sh b/configs/releng/build.sh
>>> index 5590163..86cdb08 100755
>>> --- a/configs/releng/build.sh
>>> +++ b/configs/releng/build.sh
>>> @@ -190,7 +190,7 @@ make_efiboot() {
>>>      cp ${work_dir}/iso/EFI/shellx64_v2.efi ${work_dir}/efiboot/EFI/
>>>      cp ${work_dir}/iso/EFI/shellx64_v1.efi ${work_dir}/efiboot/EFI/
>>>  
>>> -    umount ${work_dir}/efiboot
>>> +    umount -d ${work_dir}/efiboot
>>>  }
>>>  
>>>  # Build airootfs filesystem image
>>>
>>
>> Hi Chris,
> 
> Hi Gerardo, hi Pierre,
> 
> (Pierre, CCing you as you build the official media.)
> 
>> Weird, I never experienced such thing, maybe some kind of race
>> condition. I guess should be reported to upstream.
> 
> I had some problems with systemd 219... It 'magically' umounts loop mounts,
> which breaks archiso.

Oh systemd-219, I personally reverted back temporary to 218 in my two
main systemd (I can do directly since I do not use remote journal
feature (gnutls soname rebuild)).

In any case, at least archiso boots fine with 219.

Thanks.

> 
> # truncate -s 1G /tmp/test.img
> # mkfs.ext4 /tmp/test.img
> [...]
> # mount -o loop /tmp/test.img /mnt/tmp
> 
> systemd umounts the image as it thinks it is inactive:
> 
> Apr 20 08:54:28 leda systemd[1]: Unit mnt-tmp.mount is bound to inactive
> unit. Stopping, too.
> Apr 20 08:54:28 leda systemd[1]: Unmounting /mnt/tmp...
> Apr 20 08:54:28 leda systemd[1]: Unmounted /mnt/tmp.
> 
> However manually assigning a loop device and mounting that works just fine in
> most cases. (However I saw a user instance of systemd doing similar things...
> So it still broke from time to time.)
> 
> # losetup -f /tmp/test.img
> # losetup -a
> /dev/loop0: [0034]:695793 (/tmp/test.img)
> # mount /dev/loop0 /mnt/tmp
> 
> I applied these upstream patches to systemd 219-5 to fix the problem and get
> better information on further problems:
> 
> --- start first patch ----
> From 628c89cc68ab96fce2de7ebba5933725d147aecc Mon Sep 17 00:00:00 2001
> From: Lennart Poettering <lennart at poettering.net>
> Date: Fri, 27 Feb 2015 21:55:08 +0100
> Subject: core: rework device state logic
> 
> This change introduces a new state "tentative" for device units. Device
> units are considered "plugged" when udev announced them, "dead" when
> they are not available in the kernel, and "tentative" when they are
> referenced in /proc/self/mountinfo or /proc/swaps but not (yet)
> announced via udev.
> 
> This should fix a race when device nodes (like loop devices) are created
> and immediately mounted. Previously, systemd might end up seeing the
> mount unit before the device, and would thus pull down the mount because
> its BindTo dependency on the device would not be fulfilled.
> 
> --- start second patch ----
> From 98f738b62047229af4a929d7996e2ab04253b02c Mon Sep 17 00:00:00 2001
> From: Colin Walters <walters at verbum.org>
> Date: Tue, 17 Feb 2015 13:47:34 -0500
> Subject: unit: When stopping due to BindsTo=, log which unit caused it
> 
> I'm trying to track down a relatively recent change in systemd
> which broke OSTree; see https://bugzilla.gnome.org/show_bug.cgi?id=743891
> 
> Systemd started to stop sysroot.mount, and this patch should help
> me debug why at least.
> 
> While we're here, "break" on the first unit we find that will
> deactivate, as there's no point in further iteration.
> 
> --- start third patch ----
> From 5bd4b173605142c7be493aa4d958ebaef21f421d Mon Sep 17 00:00:00 2001
> From: Lennart Poettering <lennart at poettering.net>
> Date: Wed, 25 Feb 2015 22:05:14 +0100
> Subject: unit: use weaker dependencies between mount and device units in
>  --user mode
> 
> When running in user mode unmounting of mount units when a device
> vanishes is unlikely to work, and even if it would work is already done
> by PID 1 anyway. HEnce, when creating implicit dependencies between
> mount units and their backing devices, created a Wants= type dependency
> in --user mode, but leave a BindsTo= dependency in --system mode.
> --- end patches ---
> 
> I can work with loop device just fine now. However loop devices are no longer
> detached automatically. Not sure if systemd caused this or any other change
> happened.
> 
>> Anyway I will push the patch, thank you.
> 
> Thanks!
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/arch-releng/attachments/20150421/4184a639/attachment-0001.asc>