On 04/21/2015 07:43 PM, Christian Hesse wrote: > Gerardo Exequiel Pozzi <[email protected]> on Tue, 2015/04/21 19:23: >> On 04/21/2015 02:57 AM, Christian Hesse wrote: >>> From: Christian Hesse <[email protected]> >>> >>> 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 <[email protected]> >>> --- >>> 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 <[email protected]> > 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 <[email protected]> > 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 <[email protected]> > 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! >
signature.asc
Description: OpenPGP digital signature
