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 -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
