Bug#917124: systemd: local-fs.target fails with result 'dependency'

[Michael Biebl]

Am 23.12.18 um 01:40 schrieb Michael Biebl:
> Am 23.12.18 um 01:28 schrieb Ben Caradoc-Davies:
>> Dec 23 13:07:52 ripley lvm2-activation-generator: lvmconfig failed
>> Dec 23 13:07:52 ripley lvm2-activation-generator: Activation generator 
>> failed.
>> Dec 23 13:07:52 ripley systemd[376]: 
>> /lib/systemd/system-generators/lvm2-activation-generator failed with exit 
>> status 1.
> 
> That looks suspicious.
> This generator is provided by lvm2. CCing their maintainers.


This particular error turned out to be a red herring.
It was introduced by the latest lvm2 version but is not related to this
particular failure.

Just documenting this here to avoid people chasing the wrong issue.


Regards,
Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#917124: systemd: local-fs.target fails with result 'dependency'

[Ben Caradoc-Davies]

On 23/12/2018 15:43, Michael Biebl wrote:

Ok, first of all thanks for the information you provided so far.


You are welcome. Thank you for the quick turnaround and detailed 
instructions.



I doubt it's a but in systemd itself, it's just the recipient of a
device not showing up properly.
The issue is really between the interaction of udev and lvm2.
I suppose if you keep systemd at 239-15 and upgrade udev to 240-1, you
still get the failure. Can you confirm that?


Yes, the failure is observed for systemd 239-15 with udev 240-1.


And vice versa, systemd 240-1 together with udev 239-15 should also not
be problematic.


Yes, no failure for systemd 240-1 with udev 239-15. The only oddity is 
the two minute hang at shutdown after systemd upgrade, as shown in the 
earlier photo. We can deal with that later if it persists. Boot proceeds 
normally.



For some reason, lvm devices (logical volumes) are not properly initialized.
When you are dropped into the rescue shell, can you check the following:
Determine the device name for your lvm logical volume. Check the output
of lvdisplay. It should say Block device 253:?
Then check the state of the device in the udev db
udevadm info /sys/class/block/dm-? (? being the number you determined
earlier).
Paste that output please.


In rescue shell after boot (systemd 239-15 with udev 240-1):

# udevadm info /sys/class/block/dm-2
P: /devices/virtual/block/dm-2
N: dm-2
L: 0
E: DEVPATH=/devices/virtual/block/dm-2
E: DEVNAME=/dev/dm-2
E: DEVTYPE=disk
E: MAJOR=253
E: MINOR=2
E: SUBSYSTEM=block
E: USEC_INITIALIZED=9715169
E: DM_UDEV_DISABLE_SUBSYSTEM_RULES_FLAG=1
E: DM_UDEV_DISABLE_DISK_RULES_FLAG=1
E: DM_UDEV_DISABLE_OTHER_RULES_FLAG=1
E: DM_UDEV_RULES=1
E: DM_UDEV_RULES_VSN=2
E: net.ifnames=0
E: SYSTEMD_READY=0
E: TAGS=:systemd:

Compare with normal boot (systemd 240-1 with udev 239-15):

# udevadm info /sys/class/block/dm-2
P: /devices/virtual/block/dm-2
N: dm-2
S: disk/by-id/dm-name-vg-home
S: 
disk/by-id/dm-uuid-LVM-SiqeiwSeAj9MM50Phu717igDgDlF5NIq0N9nmHNGMYuvfy7LFfYfUQpyivO394C5

S: disk/by-label/Home
S: disk/by-uuid/39303d70-dd06-4356-b413-efcb35f8cd4c
S: mapper/vg-home
S: vg/home
E: DEVLINKS=/dev/mapper/vg-home /dev/disk/by-id/dm-name-vg-home 
/dev/disk/by-id/dm-uuid-LVM-SiqeiwSeAj9MM50Phu717igDgDlF5NIq0N9nmHNGMYuvfy7LFfYfUQpyivO394C5 
/dev/vg/home /dev/disk/by-label/Home 
/dev/disk/by-uuid/39303d70-dd06-4356-b413-efcb35f8cd4c

E: DEVNAME=/dev/dm-2
E: DEVPATH=/devices/virtual/block/dm-2
E: DEVTYPE=disk
E: DM_LV_NAME=home
E: DM_NAME=vg-home
E: DM_STATE=ACTIVE
E: DM_SUSPENDED=0
E: DM_TABLE_STATE=LIVE
E: DM_UDEV_DISABLE_LIBRARY_FALLBACK_FLAG=1
E: DM_UDEV_PRIMARY_SOURCE_FLAG=1
E: DM_UDEV_RULES=1
E: DM_UDEV_RULES_VSN=2
E: 
DM_UUID=LVM-SiqeiwSeAj9MM50Phu717igDgDlF5NIq0N9nmHNGMYuvfy7LFfYfUQpyivO394C5

E: DM_VG_NAME=vg
E: ID_FS_LABEL=Home
E: ID_FS_LABEL_ENC=Home
E: ID_FS_TYPE=ext4
E: ID_FS_USAGE=filesystem
E: ID_FS_UUID=39303d70-dd06-4356-b413-efcb35f8cd4c
E: ID_FS_UUID_ENC=39303d70-dd06-4356-b413-efcb35f8cd4c
E: ID_FS_VERSION=1.0
E: MAJOR=253
E: MINOR=2
E: SUBSYSTEM=block
E: TAGS=:systemd:
E: USEC_INITIALIZED=12329587
E: net.ifnames=0

Kind regards,

--
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

Bug#917124: systemd: local-fs.target fails with result 'dependency'

[Michael Biebl]

Control: retitle -1 lvm2 logical volumes are not properly initialized

Am 23.12.18 um 01:38 schrieb Ben Caradoc-Davies:
>> Can you provide a verbose debug log as requested in my previous reply?
> 
> "journalctl -alb" output attached to my previous email. Please let me
> know if you require

Ok, first of all thanks for the information you provided so far.
I doubt it's a but in systemd itself, it's just the recipient of a
device not showing up properly.

The issue is really between the interaction of udev and lvm2.

I suppose if you keep systemd at 239-15 and upgrade udev to 240-1, you
still get the failure. Can you confirm that?
And vice versa, systemd 240-1 together with udev 239-15 should also not
be problematic.

For some reason, lvm devices (logical volumes) are not properly initialized.

When you are dropped into the rescue shell, can you check the following:

Determine the device name for your lvm logical volume. Check the output
of lvdisplay. It should say Block device 253:?

Then check the state of the device in the udev db

udevadm info /sys/class/block/dm-? (? being the number you determined
earlier).

Paste that output please.



-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#917124: systemd: local-fs.target fails with result 'dependency'

[Axel Beckert]

Hi,

Michael Biebl wrote:
> Am 23.12.18 um 01:28 schrieb Ben Caradoc-Davies:
> > Dec 23 13:07:52 ripley lvm2-activation-generator: lvmconfig failed
> > Dec 23 13:07:52 ripley lvm2-activation-generator: Activation generator 
> > failed.
> > Dec 23 13:07:52 ripley systemd[376]: 
> > /lib/systemd/system-generators/lvm2-activation-generator failed with exit 
> > status 1.
> 
> That looks suspicious.

Indeed.

> This generator is provided by lvm2. CCing their maintainers.
> Maybe they have an idea what's failing for you and/or can help you debug it.

It's especially not an issue systemd 240-1: Due to this bug report
showing up in apt-listbugs, I didn't upgrade systemd to 240-1 (but
upgraded udev and lvm2) and I also saw messages like that in my syslog
several times during the upgrade:

Dec 23 03:03:24 c-cactus2 systemd[1]: Stopping realtime filesystem monitoring 
program using inotify...
Dec 23 03:03:24 c-cactus2 systemd[1]: Stopped realtime filesystem monitoring 
program using inotify.
Dec 23 03:03:47 c-cactus2 systemd[1]: Reloading.
Dec 23 03:03:47 c-cactus2 lvm2-activation-generator: lvmconfig failed
Dec 23 03:03:47 c-cactus2 lvm2-activation-generator: Activation generator 
failed.
Dec 23 03:03:47 c-cactus2 systemd[12099]: 
/lib/systemd/system-generators/lvm2-activation-generator failed with exit 
status 1.
Dec 23 03:03:47 c-cactus2 systemd[1]: lvm2-lvmetad.socket: Socket unit 
configuration has changed while unit has been running, no open socket file 
descriptor left. The socket unit is not functional until restarted.
Dec 23 03:03:47 c-cactus2 systemd[1]: Starting Garbage Collection for rkt...
Dec 23 03:03:47 c-cactus2 systemd[1]: Started Garbage Collection for rkt.
Dec 23 03:03:47 c-cactus2 systemd[1]: Reloading.
Dec 23 03:03:47 c-cactus2 lvm2-activation-generator: lvmconfig failed
Dec 23 03:03:47 c-cactus2 lvm2-activation-generator: Activation generator 
failed.
Dec 23 03:03:47 c-cactus2 systemd[12197]: 
/lib/systemd/system-generators/lvm2-activation-generator failed with exit 
status 1.
Dec 23 03:03:47 c-cactus2 systemd[1]: lvm2-lvmetad.socket: Socket unit 
configuration has changed while unit has been running, no open socket file 
descriptor left. The socket unit is not functional until restarted.
Dec 23 03:03:47 c-cactus2 systemd[1]: Starting Garbage Collection for rkt...
Dec 23 03:03:47 c-cactus2 systemd[1]: Started Garbage Collection for rkt.
Dec 23 03:03:48 c-cactus2 systemd[1]: Reloading.
Dec 23 03:03:48 c-cactus2 systemd[12253]: 
/lib/systemd/system-generators/lvm2-activation-generator failed with exit 
status 1.
Dec 23 03:03:48 c-cactus2 lvm2-activation-generator: lvmconfig failed
Dec 23 03:03:48 c-cactus2 lvm2-activation-generator: Activation generator 
failed.
Dec 23 03:03:48 c-cactus2 systemd[1]: lvm2-lvmetad.socket: Socket unit 
configuration has changed while unit has been running, no open socket file 
descriptor left. The socket unit is not functional until restarted.
Dec 23 03:03:48 c-cactus2 systemd[1]: Starting Garbage Collection for rkt...
Dec 23 03:03:48 c-cactus2 systemd[1]: Started Garbage Collection for rkt.
Dec 23 03:03:48 c-cactus2 systemd[1]: Reloading.
Dec 23 03:03:48 c-cactus2 lvm2-activation-generator: lvmconfig failed
Dec 23 03:03:48 c-cactus2 lvm2-activation-generator: Activation generator 
failed.
Dec 23 03:03:48 c-cactus2 systemd[12304]: 
/lib/systemd/system-generators/lvm2-activation-generator failed with exit 
status 1.
Dec 23 03:03:48 c-cactus2 systemd[1]: lvm2-lvmetad.socket: Socket unit 
configuration has changed while unit has been running, no open socket file 
descriptor left. The socket unit is not functional until restarted.
Dec 23 03:03:48 c-cactus2 systemd[1]: Starting Garbage Collection for rkt...
Dec 23 03:03:48 c-cactus2 systemd[1]: Started Garbage Collection for rkt.
Dec 23 03:03:48 c-cactus2 systemd[1]: Reloading.
Dec 23 03:03:48 c-cactus2 lvm2-activation-generator: lvmconfig failed
Dec 23 03:03:48 c-cactus2 lvm2-activation-generator: Activation generator 
failed.
Dec 23 03:03:48 c-cactus2 systemd[12340]: 
/lib/systemd/system-generators/lvm2-activation-generator failed with exit 
status 1.
Dec 23 03:03:48 c-cactus2 systemd[1]: lvm2-lvmetad.socket: Socket unit 
configuration has changed while unit has been running, no open socket file 
descriptor left. The socket unit is not functional until restarted.
Dec 23 03:03:49 c-cactus2 systemd[1]: Starting Garbage Collection for rkt...
Dec 23 03:03:49 c-cactus2 systemd[1]: Started LVM2 poll daemon.
Dec 23 03:03:49 c-cactus2 systemd[1]: Started Garbage Collection for rkt.
Dec 23 03:03:49 c-cactus2 systemd[1]: Reloading.
Dec 23 03:03:49 c-cactus2 lvm2-activation-generator: lvmconfig failed
Dec 23 03:03:49 c-cactus2 lvm2-activation-generator: Activation generator 
failed.
Dec 23 03:03:49 c-cactus2 systemd[12405]: 
/lib/systemd/system-generators/lvm2-activation-generator failed with exit 
status 1.
Dec 23 03:03:49 c-cactus2 systemd[1]: lvm2-lvmetad.socket: Socket unit 
configuration has changed while unit has been 

Bug#917124: systemd: local-fs.target fails with result 'dependency'

[Ben Caradoc-Davies]

On 23/12/2018 13:43, Michael Biebl wrote:

Am 23.12.18 um 01:38 schrieb Ben Caradoc-Davies:

On 23/12/2018 13:11, Michael Biebl wrote:

Am 23.12.18 um 00:58 schrieb Ben Caradoc-Davies:

Failure was seen with linux-image-4.19.0-1-amd64 4.19.9-1. (Needed to
boot an 4.18.0-3-amd64 initramfs to get a working system.)

So 4.18 works and 4.19 fails?


No, 239-15 works with either kernel, and 240-1 fails, only tested with
the 4.19 kernel. Downgrading to 239-15 makes 4.19 bootable.


Then I don't understand your reply above, where you said you downgraded
to a 4.18.0-3-amd64 initramfs to get a working system.

Can you please elaborate what you meant with the above.


I have three installed kernels:

linux-image-4.18.0-2-amd64 -> 4.18.10-2+b1
linux-image-4.18.0-3-amd64 -> 4.18.20-2
linux-image-4.19.0-1-amd64 -> 4.19.9-1

I upgraded systemd to 240-1, which caused the initramfs for 
linux-image-4.19.0-1-amd64 to be rebuilt to include systemd 240-1 and be 
unbootable, so I booted linux-image-4.18.0-3-amd64 and made the bug 
report. The system information gathered by reportbug is misleading 
because it implies that problem was observed with 4.18.20-2, the running 
kernel at the time of the report, which is not the kernel running when 
the failure was observed. My remark was only to correct this misinformation.


Kind regards,

--
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

Bug#917124: systemd: local-fs.target fails with result 'dependency'

[Ben Caradoc-Davies]

On 23/12/2018 13:40, Michael Biebl wrote:

Am 23.12.18 um 01:28 schrieb Ben Caradoc-Davies:

Dec 23 13:07:52 ripley lvm2-activation-generator: lvmconfig failed
Dec 23 13:07:52 ripley lvm2-activation-generator: Activation generator failed.
Dec 23 13:07:52 ripley systemd[376]: 
/lib/systemd/system-generators/lvm2-activation-generator failed with exit 
status 1.

That looks suspicious.
This generator is provided by lvm2. CCing their maintainers.
Maybe they have an idea what's failing for you and/or can help you debug it.


Those messages also appear with systemd 239-15, which boots without 
problem. For example, from journalctl after downgrade:


Dec 23 13:23:07 ripley kernel: random: cryptsetup: uninitialized urandom 
read (2 bytes read)
Dec 23 13:23:07 ripley kernel: random: lvm: uninitialized urandom read 
(4 bytes read)
Dec 23 13:23:07 ripley kernel: random: lvm: uninitialized urandom read 
(4 bytes read)

Dec 23 13:23:07 ripley kernel: Btrfs loaded, crc32c=crc32c-intel
Dec 23 13:23:07 ripley kernel: EXT4-fs (dm-1): mounted filesystem with 
ordered data mode. Opts: (null)
Dec 23 13:23:07 ripley systemd[1]: systemd 239 running in system mode. 
(+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP 
+LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLK

Dec 23 13:23:07 ripley systemd[1]: Detected architecture x86-64.
Dec 23 13:23:07 ripley systemd[1]: Set hostname to .
Dec 23 13:23:07 ripley lvm2-activation-generator: lvmconfig failed
Dec 23 13:23:07 ripley lvm2-activation-generator: Activation generator 
failed.
Dec 23 13:23:07 ripley systemd[423]: 
/lib/systemd/system-generators/lvm2-activation-generator failed with 
exit status 1.

Dec 23 13:23:07 ripley kernel: random: crng init done
Dec 23 13:23:07 ripley kernel: random: 2 urandom warning(s) missed due 
to ratelimiting
Dec 23 13:23:07 ripley systemd[1]: Created slice 
system-systemd\x2dcryptsetup.slice.

Dec 23 13:23:07 ripley systemd[1]: Created slice User and Session Slice.

Kind regards,

--
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

Bug#917124: systemd: local-fs.target fails with result 'dependency'

[Michael Biebl]

Am 23.12.18 um 01:28 schrieb Ben Caradoc-Davies:
> Dec 23 13:07:52 ripley lvm2-activation-generator: lvmconfig failed
> Dec 23 13:07:52 ripley lvm2-activation-generator: Activation generator failed.
> Dec 23 13:07:52 ripley systemd[376]: 
> /lib/systemd/system-generators/lvm2-activation-generator failed with exit 
> status 1.

That looks suspicious.
This generator is provided by lvm2. CCing their maintainers.
Maybe they have an idea what's failing for you and/or can help you debug it.



Regards,
Michael


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#917124: systemd: local-fs.target fails with result 'dependency'

[Michael Biebl]

Am 23.12.18 um 01:38 schrieb Ben Caradoc-Davies:
> On 23/12/2018 13:11, Michael Biebl wrote:
>> Am 23.12.18 um 00:58 schrieb Ben Caradoc-Davies:
>>> Failure was seen with linux-image-4.19.0-1-amd64 4.19.9-1. (Needed to
>>> boot an 4.18.0-3-amd64 initramfs to get a working system.)
>> So 4.18 works and 4.19 fails?
> 
> No, 239-15 works with either kernel, and 240-1 fails, only tested with
> the 4.19 kernel. Downgrading to 239-15 makes 4.19 bootable.

Then I don't understand your reply above, where you said you downgraded
to a 4.18.0-3-amd64 initramfs to get a working system.

Can you please elaborate what you meant with the above.

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#917124: systemd: local-fs.target fails with result 'dependency'

[Ben Caradoc-Davies]

On 23/12/2018 13:11, Michael Biebl wrote:

Am 23.12.18 um 00:58 schrieb Ben Caradoc-Davies:

Failure was seen with linux-image-4.19.0-1-amd64 4.19.9-1. (Needed to
boot an 4.18.0-3-amd64 initramfs to get a working system.)

So 4.18 works and 4.19 fails?


No, 239-15 works with either kernel, and 240-1 fails, only tested with 
the 4.19 kernel. Downgrading to 239-15 makes 4.19 bootable.



Can you provide a verbose debug log as requested in my previous reply?


"journalctl -alb" output attached to my previous email. Please let me 
know if you require



Can you share more details about your cryptsetup configuration?


An unexciting LVM/LUKS configuration with a single PV, single VG, and 
two LVs (root and home), alongside non-LUKS boot and efi:


# lsblk
NAME   MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda  8:00 232.9G  0 disk
├─sda1   8:1094M  0 part  /boot/efi
├─sda2   8:20   572M  0 part  /boot
└─sda3   8:30 232.2G  0 part
  └─sda3_crypt 253:00 232.2G  0 crypt
├─vg-root  253:1028G  0 lvm   /
└─vg-home  253:20 204.3G  0 lvm   /home

# cat /etc/crypttab
sda3_crypt UUID=79581759-44e0-49e0-9b31-118a456d8415 none luks,discard

I also have in /etc/lvm/lvm.conf:
issue_discards = 1

fstab is attached to the original report.

# cat /etc/fstab
/dev/mapper/vg-root /   ext4 
noatime,errors=remount-ro   0   1
/dev/sda2   /boot   ext4 
noatime,errors=remount-ro   0   2
/dev/sda1   /boot/efi   vfatnoatime,umask=077 
   0   2
/dev/mapper/vg-home /home   ext4 
noatime,errors=remount-ro   0   2

[...]

One possible cause might be my many, many masked services. Could 
local-fs.target be trying to start one of these?:


$ ls -al /etc/systemd/system
total 44
drwxr-xr-x 11 root root 4096 Dec 21 09:18  ./
drwxr-xr-x  5 root root 4096 Dec 23 13:18  ../
lrwxrwxrwx  1 root root9 Apr 15  2017  anacron-resume.service -> 
/dev/null

lrwxrwxrwx  1 root root9 Apr 15  2017  anacron.service -> /dev/null
lrwxrwxrwx  1 root root9 Jun  3  2017  anacron.timer -> /dev/null
lrwxrwxrwx  1 root root9 Dec  8  2017  apparmor.service -> /dev/null
lrwxrwxrwx  1 root root9 Oct 16 09:52  apt-daily-upgrade.service -> 
/dev/null
lrwxrwxrwx  1 root root9 May  5  2017  apt-daily-upgrade.timer -> 
/dev/null

lrwxrwxrwx  1 root root9 Apr 15  2017  apt-daily.service -> /dev/null
lrwxrwxrwx  1 root root9 Apr 15  2017  apt-daily.timer -> /dev/null
lrwxrwxrwx  1 root root9 Apr 15  2017  atd.service -> /dev/null
lrwxrwxrwx  1 root root9 Apr 15  2017  avahi-daemon.service -> /dev/null
lrwxrwxrwx  1 root root9 Apr 15  2017  avahi-daemon.socket -> /dev/null
lrwxrwxrwx  1 root root9 Dec 12  2017  bluetooth.service -> /dev/null
lrwxrwxrwx  1 root root9 Apr 15  2017  bluetooth.target -> /dev/null
lrwxrwxrwx  1 root root9 Apr 17  2017  colord.service -> /dev/null
lrwxrwxrwx  1 root root9 Apr 15  2017  cron.service -> /dev/null
lrwxrwxrwx  1 root root   42 Nov 27  2017 
dbus-fi.w1.wpa_supplicant1.service -> 
/lib/systemd/system/wpa_supplicant.service
lrwxrwxrwx  1 root root9 Apr 15  2017  dbus-org.bluez.service -> 
/dev/null
lrwxrwxrwx  1 root root9 Apr 15  2017 
dbus-org.freedesktop.Avahi.service -> /dev/null
lrwxrwxrwx  1 root root   40 Apr 15  2017 
dbus-org.freedesktop.ModemManager1.service -> 
/lib/systemd/system/ModemManager.service
lrwxrwxrwx  1 root root   53 Apr 15  2017 
dbus-org.freedesktop.nm-dispatcher.service -> 
/lib/systemd/system/NetworkManager-dispatcher.service
lrwxrwxrwx  1 root root   43 Jul  9  2017 
dbus-org.freedesktop.thermald.service -> 
/lib/systemd/system/thermald-custom.service
lrwxrwxrwx  1 root root   35 Oct  8 10:21  display-manager.service -> 
/lib/systemd/system/lightdm.service

lrwxrwxrwx  1 root root9 Apr 15  2017  exim4.service -> /dev/null
drwxr-xr-x  2 root root 4096 Apr 15  2017  getty.target.wants/
drwxr-xr-x  2 root root 4096 Jul 27  2017  graphical.target.wants/
lrwxrwxrwx  1 root root   30 Apr 15  2017  iptables.service -> 
/etc/iptables/iptables.service

drwxr-xr-x  2 root root 4096 Apr 15  2017  local-fs.target.wants/
drwxr-xr-x  2 root root 4096 Dec 21 09:41  multi-user.target.wants/
drwxr-xr-x  2 root root 4096 Feb 23  2018  network-online.target.wants/
lrwxrwxrwx  1 root root9 Oct 12 18:12  postgresql.service -> /dev/null
lrwxrwxrwx  1 root root9 Oct 12 18:13 'postgresql@11-main.service' 
-> /dev/null

lrwxrwxrwx  1 root root9 Apr 15  2017  pppd-dns.service -> /dev/null
drwxr-xr-x  2 root root 4096 Apr 15  2017  printer.target.wants/
lrwxrwxrwx  1 root root9 Apr 15  2017  remote-fs.target -> /dev/null
lrwxrwxrwx  1 root root9 Apr 15  2017  rpcbind.target -> /dev/null
lrwxrwxrwx  1 root root9 Apr 15  2017  rsync.service -> /dev/null
lrwxrwxrwx  1 root 

Bug#917124: systemd: local-fs.target fails with result 'dependency'

[Michael Biebl]

Am 23.12.18 um 00:58 schrieb Ben Caradoc-Davies:
> Failure was seen with linux-image-4.19.0-1-amd64 4.19.9-1. (Needed to
> boot an 4.18.0-3-amd64 initramfs to get a working system.)

So 4.18 works and 4.19 fails?

> Attached photo shows console after failure. Plymouth LUKS passphrase
> entry has succeeded, but boot then hangs. Console displayed with keypress.


Can you provide a verbose debug log as requested in my previous reply?
Can you share more details about your cryptsetup configuration?


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#917124: systemd: local-fs.target fails with result 'dependency'

[Michael Biebl]

control: tags -1 + moreinfo

Am 23.12.18 um 00:35 schrieb Ben Caradoc-Davies:
> Package: systemd
> Version: 240-1
> Severity: critical
> Justification: breaks the whole system
> 
> Dear Maintainer,
> 
> after upgrade to systemd 240-1, local-fs.target fails with result 
> 'dependency',
> causing boot failure. Failure occurs for non-root LUKS/LVM filesystem.

Are you dropped into a rescue-shell?
If not, please add systemd.debug_shell to the kernel command line.
This will give you a debug shell on tty9.

Once you are in a shell, please get the output of
systemctl status
journalctl -alb





-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature