touch-packages team mailing list archive

[Bug Watch Updater <1444402@xxxxxxxxxxxxxxxxxx>]

Launchpad has imported 8 comments from the remote bug at
https://bugs.freedesktop.org/show_bug.cgi?id=89383.

If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://help.launchpad.net/InterBugTracking.

------------------------------------------------------------------------
On 2015-03-01T21:25:59+00:00 Tpgxyz wrote:

Log story short.

After update to systemd-219, dracut during live iso boot was not able to
mount devices for further switch root, whereby booting iso in live mode
was not possible. An example:

LOOPDEV=$( losetup -f )
losetup -r $LOOPDEV /live/media/LiveOS/squashfs.img
mount -n -t squashfs -o ro $LOOPDEV /live/distrib

After a deep digging, and getting system to boot into a real root simple
mount command was not mounting anything.

mount -n -t squashfs -o ro
/media/OpenMandriva_2015.0/LiveOS/squashfs.img /media/test

Applying those patches fixed issue:
https://bugzilla.gnome.org/show_bug.cgi?id=743891

Reply at:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1444402/comments/0

------------------------------------------------------------------------
On 2015-03-03T14:39:39+00:00 Tpgxyz wrote:

Bump. System is unbootable with 219 release. Raising importance.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1444402/comments/1

------------------------------------------------------------------------
On 2015-03-05T10:44:24+00:00 Tpgxyz wrote:

Looks like that applying this patch:
https://abf.io/openmandriva/systemd/blob/master/0001-Revert-core-mount-add-dependencies-to-dynamically-mo.patch

allows to mount devices.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1444402/comments/2

------------------------------------------------------------------------
On 2015-04-03T10:50:49+00:00 Tpgxyz wrote:

Ping anyone ?

Reply at:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1444402/comments/3

------------------------------------------------------------------------
On 2015-04-19T04:51:36+00:00 胡祖仪 wrote:

(In reply to Tomasz Paweł Gajc from comment #2)
> Looks like that applying this patch:
> https://abf.io/openmandriva/systemd/blob/master/0001-Revert-core-mount-add-
> dependencies-to-dynamically-mo.patch
> 
> allows to mount devices.

Thank you very much, this patch helps me, I am doubt why upstream don't
fix this problem.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1444402/comments/6

------------------------------------------------------------------------
On 2015-04-22T13:28:34+00:00 Grey-8 wrote:

This is a bad bug.

Please see my report on the Arch Linux bug tracker on it here:
https://bugs.archlinux.org/task/44658#comment134665

This report is using systemd from Arch's [testing] repo which seems to
be version 219 with some patches applied by the Arch maintainers which
try to address this bug: systemd 219-6,
https://www.archlinux.org/packages/testing/x86_64/systemd/

In summary, even when the bug has been "fixed" (allowing mounts to be
made again) there are cases when systemd is unmounting things it should
not be when the user runs umount (seems like it unmounts ALL mounts
associated with a device whenever any mount associated with that device
is umounted).

A bug that breaks filesystem mouting/unmounting seems particularly
critical. Whatever new logic 219 introduced that created this bug should
probably be reverted from the systemd release until all the mounting and
unmounting corner cases can be tested and covered.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1444402/comments/7

------------------------------------------------------------------------
On 2015-04-23T16:02:20+00:00 Bastien-g wrote:

Another use case to complement the report:

- system is a home server running Arch linux, full disk encrypted with dmcrypt/LUKS and remotely unlocked via dropbear_initrd_encrypt [1]
- it was updated today with the latest systemd packages ({lib}systemd{-sysvcompat} 219-5) and latest linux-lts (3.14.39), therefore the initramfs was rebuilt with mkinitcpio.

What happens: after rebooting I am locked out at the initramfs stage
with the following error messages:

- on client trying to ssh in dropbear_initrd:
    Device /dev/disk/by-id/wwn-<redacted_id>-part3 doesn't exist or access denied.

- on server:
   Running systemd 219
(dropbear initialization sequence, everything is ok)
    Starting dropbear
    [123] Apr 23 09:43:56 Running in background
(try to connect remotely via SSH)
    Pubkey auth succeeded for 'root' with key xxx from 192.xxx
    syslogin_perform_logout: logout(pts/0) returned an error: No such file or directory
    Exit (root) Disconnect received
    ERROR: device '/dev/mapper/lvm-archroot' not found. Skipping fsck.
    ERROR: Unable to find rot device '/dev/mapper/lvm-archroot'
    You are being dropped to a recovery shell

If I don't try to login via SSH there is a 15 seconds delay between
[123] line and the first ERROR; there is no mean whatsoever to unlock
dropbear locally as used to be the case ("enter passphrase for /dev/disk
/by-id/wwn-<redacted_id>-part" used to be displayed).

My kernel command line is BOOT_IMAGE=/vmlinuz-linux-lts root=/dev/mapper
/lvm-archroot rw quiet cryptdevice=/dev/disk/by-
id/wwn-<redacted_id>-part3:crypt ip=192.168.1.xxx::192.168.1.254::arch-
medion:eth0:none

[1] https://wiki.archlinux.org/index.php/Dm-
crypt/Specialties#Remote_unlocking_of_the_root_.28or_other.29_partition

Reply at:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1444402/comments/8

------------------------------------------------------------------------
On 2015-04-23T16:10:40+00:00 Tpgxyz wrote:

Created attachment 115298
Proposed patch

With this patch systemd does not umounts manually mounted devices

Reply at:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1444402/comments/9


** Changed in: systemd
       Status: Unknown => Confirmed

** Changed in: systemd
   Importance: Unknown => Critical

** Bug watch added: GNOME Bug Tracker #743891
   https://bugzilla.gnome.org/show_bug.cgi?id=743891

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1444402

Title:
  While sbuilding, systemd loops attempting to umount the underlay

Status in systemd:
  Confirmed
Status in systemd package in Ubuntu:
  New

Bug description:
  I recently hit ENOSPC which turned out to be the result of various
  syslogs from the current and previous boots totalling up to 30G.

  They were filled with messages like

  Apr 15 11:22:35 vivid systemd[1]: Unit var-lib-schroot-union-underlay-vivid\x2damd64\x2d5d4f7453\x2d9a95\x2d4a6a\x2d9aee\x2d9394923bf734.mount is bound to inactive unit dev-disk-by\x2duuid-980689ca\x2de7d9\x2d4a99\x2d8230\x2d33b8b6e917cd.device. Stopping, too.
  Apr 15 11:22:35 vivid systemd[1]: Unmounting /var/lib/schroot/union/underlay/vivid-amd64-5d4f7453-9a95-4a6a-9aee-9394923bf734...
  Apr 15 11:22:35 vivid umount[31795]: umount: /var/lib/schroot/union/underlay/vivid-amd64-5d4f7453-9a95-4a6a-9aee-9394923bf734: target is busy
  Apr 15 11:22:35 vivid umount[31795]: (In some cases useful info about processes that
  Apr 15 11:22:35 vivid umount[31795]: use the device is found by lsof(8) or fuser(1).)
  Apr 15 11:22:35 vivid systemd[1]: var-lib-schroot-union-underlay-vivid\x2damd64\x2d5d4f7453\x2d9a95\x2d4a6a\x2d9aee\x2d9394923bf734.mount mount process exited, code=exited status=32
  Apr 15 11:22:35 vivid systemd[1]: Failed unmounting /var/lib/schroot/union/underlay/vivid-amd64-5d4f7453-9a95-4a6a-9aee-9394923bf734.
  Apr 15 11:22:35 vivid systemd[1]: Unit var-lib-schroot-union-underlay-vivid\x2damd64\x2d5d4f7453\x2d9a95\x2d4a6a\x2d9aee\x2d9394923bf734.mount is bound to inactive unit dev-disk-by\x2duuid-980689ca\x2de7d9\x2d4a99\x2d8230\x2d33b8b6e917cd.device. Stopping, too.
  Apr 15 11:22:35 vivid systemd[1]: Unmounting /var/lib/schroot/union/underlay/vivid-amd64-5d4f7453-9a95-4a6a-9aee-9394923bf734...
  Apr 15 11:22:35 vivid systemd[1]: Unmounted /var/lib/schroot/union/underlay/vivid-amd64-5d4f7453-9a95-4a6a-9aee-9394923bf734.
  Apr 15 11:22:35 vivid systemd[1]: Unit var-lib-schroot-union-underlay-vivid\x2damd64\x2d5d4f7453\x2d9a95\x2d4a6a\x2d9aee\x2d9394923bf734.mount entered failed state.

  looping constantly for the duration of any builds in sbuild.

  Why is systemd trying to do this?

  laney@vivid> apt-cache policy systemd
  systemd:
    Installed: 219-7ubuntu1
    Candidate: 219-7ubuntu1
    Version table:
   *** 219-7ubuntu1 0
          500 http://sherwood/ubuntu/ vivid/main amd64 Packages
          100 /var/lib/dpkg/status

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1444402/+subscriptions