Gerardo Exequiel Pozzi on Tue, 2015/04/21 19:23:

On 04/21/2015 02:57 AM, Christian Hesse wrote:

...

From: Christian Hesse

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 --- 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. # 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 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 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 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! -- main(a){char*c=/* Schoene Gruesse */"B?IJj;MEH" "CX:;",b;for(a/* Chris get my mail address: */=0;b=c[a++];) putchar(b-1/(/* gcc -o sig sig.c && ./sig */b/42*2-3)*42);}

Gerardo Exequiel Pozzi on Tue, 2015/04/21 21:05:

On 04/21/2015 07:43 PM, Christian Hesse wrote:

...

Gerardo Exequiel Pozzi on Tue, 2015/04/21 19:23:

...

On 04/21/2015 02:57 AM, Christian Hesse wrote:

...

From: Christian Hesse

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 --- 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.

Looks like systemd 219-6 addresses this issue. -- main(a){char*c=/* Schoene Gruesse */"B?IJj;MEH" "CX:;",b;for(a/* Chris get my mail address: */=0;b=c[a++];) putchar(b-1/(/* gcc -o sig sig.c && ./sig */b/42*2-3)*42);}