Bug#969489: systemd: systemctl can hang up waiting for device nodes that are already mounted
I'd really rather not run systems at all but pulseaudio is just too broken now. On Friday, September 4, 2020, Joshua Hudson wrote: > I'm not convinced it's dmraid because udev reports the nodes up. It looks > like systems only thinks the first device name on the list is alive. > Unfortunately that name isn't stable across boots. > > On Fri, Sep 4, 2020, 12:58 PM Michael Biebl wrote: > >> On Thu, 3 Sep 2020 16:06:28 -0700 Joshua Hudson >> wrote: >> > Yeah dmraid's still in use. Is there a way to just get rid of all >> > those device units because they don't do anything right now except >> > cause problems? I've modified the boot order so systemd sees >> > everything already mounted. >> >> My recommendation would be to get rid of dmraid. >> It's dead upstream and unmaintained in Debian as well. >> You are bound to run into problems and it's only getting worse in the >> future. >> >> Michael >> >>
Bug#969489: systemd: systemctl can hang up waiting for device nodes that are already mounted
I'm not convinced it's dmraid because udev reports the nodes up. It looks like systems only thinks the first device name on the list is alive. Unfortunately that name isn't stable across boots. On Fri, Sep 4, 2020, 12:58 PM Michael Biebl wrote: > On Thu, 3 Sep 2020 16:06:28 -0700 Joshua Hudson > wrote: > > Yeah dmraid's still in use. Is there a way to just get rid of all > > those device units because they don't do anything right now except > > cause problems? I've modified the boot order so systemd sees > > everything already mounted. > > My recommendation would be to get rid of dmraid. > It's dead upstream and unmaintained in Debian as well. > You are bound to run into problems and it's only getting worse in the > future. > > Michael > >
Bug#969489: systemd: systemctl can hang up waiting for device nodes that are already mounted
On Thu, 3 Sep 2020 16:06:28 -0700 Joshua Hudson wrote: > Yeah dmraid's still in use. Is there a way to just get rid of all > those device units because they don't do anything right now except > cause problems? I've modified the boot order so systemd sees > everything already mounted. My recommendation would be to get rid of dmraid. It's dead upstream and unmaintained in Debian as well. You are bound to run into problems and it's only getting worse in the future. Michael signature.asc Description: OpenPGP digital signature
Bug#969489: systemd: systemctl can hang up waiting for device nodes that are already mounted
Control: reassign -1 dmraid Control: forcemerge -1 947806 Am 04.09.2020 um 01:06 schrieb Joshua Hudson: > Yeah dmraid's still in use. Is there a way to just get rid of all > those device units because they don't do anything right now except > cause problems? I've modified the boot order so systemd sees > everything already mounted. -- 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#969489: systemd: systemctl can hang up waiting for device nodes that are already mounted
Am 04.09.2020 um 00:58 schrieb Joshua Hudson: > I don't think it's a duplicate. #947806 is getting stuck waiting for > dmraid nodes to come up so filesystems can be mounted. Are you using dmraid? -- 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#969489: systemd: systemctl can hang up waiting for device nodes that are already mounted
Yeah dmraid's still in use. Is there a way to just get rid of all those device units because they don't do anything right now except cause problems? I've modified the boot order so systemd sees everything already mounted. On 9/3/20, Michael Biebl wrote: > Am 04.09.2020 um 00:58 schrieb Joshua Hudson: >> I don't think it's a duplicate. #947806 is getting stuck waiting for >> dmraid nodes to come up so filesystems can be mounted. > > Are you using dmraid? > > > -- > Why is it that all of the instruments seeking intelligent life in the > universe are pointed away from Earth? > >
Bug#969489: systemd: systemctl can hang up waiting for device nodes that are already mounted
I don't think it's a duplicate. #947806 is getting stuck waiting for dmraid nodes to come up so filesystems can be mounted. This #969489 is something took a dependency on an implicit unit that probably shouldn't have a dependency on that unit. On 9/3/20, Michael Biebl wrote: > Am 04.09.2020 um 00:10 schrieb Joshua Hudson: >> brw-rw 1 root disk 254, 2 Sep 3 14:51 >> /dev/mapper/isw_cfbejbfeib_Volume12 >> >> udevadm command output attached. >> >> The device isn't dead. It works when accessed directly by name. >> >> $ /sbin/swapon >> NAMETYPE SIZE USED PRIO >> /dev/mapper/isw_cfbejbfeib_Volume12 partition 32G 0B -2 >> > > Duplicate of #947806 ? > Are you still using dmraid? > > -- > Why is it that all of the instruments seeking intelligent life in the > universe are pointed away from Earth? > >
Bug#969489: systemd: systemctl can hang up waiting for device nodes that are already mounted
Am 04.09.2020 um 00:10 schrieb Joshua Hudson: > brw-rw 1 root disk 254, 2 Sep 3 14:51 /dev/mapper/isw_cfbejbfeib_Volume12 > > udevadm command output attached. > > The device isn't dead. It works when accessed directly by name. > > $ /sbin/swapon > NAMETYPE SIZE USED PRIO > /dev/mapper/isw_cfbejbfeib_Volume12 partition 32G 0B -2 > Duplicate of #947806 ? Are you still using dmraid? -- 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#969489: systemd: systemctl can hang up waiting for device nodes that are already mounted
brw-rw 1 root disk 254, 2 Sep 3 14:51 /dev/mapper/isw_cfbejbfeib_Volume12 udevadm command output attached. The device isn't dead. It works when accessed directly by name. $ /sbin/swapon NAMETYPE SIZE USED PRIO /dev/mapper/isw_cfbejbfeib_Volume12 partition 32G 0B -2 udevadm Description: Binary data
Bug#969489: systemd: systemctl can hang up waiting for device nodes that are already mounted
Am 03.09.20 um 19:46 schrieb Joshua: > [TIMEOUT] waiting for /dev/mapper/isw_cfbejbfeib_Volume12 -> Unit dev-mapper-isw_cfbejbfeib_Volume12.device: Description: /dev/mapper/isw_cfbejbfeib_Volume12 Instance: n/a Unit Load State: loaded Unit Active State: inactive State Change Timestamp: Thu 2020-09-03 10:01:32 PDT Inactive Exit Timestamp: Thu 2020-09-03 07:37:06 PDT Active Enter Timestamp: Thu 2020-09-03 07:37:11 PDT Active Exit Timestamp: Thu 2020-09-03 10:01:32 PDT Inactive Enter Timestamp: Thu 2020-09-03 10:01:32 PDT May GC: no Need Daemon Reload: no Transient: no Perpetual: no Garbage Collection Mode: inactive Slice: n/a CGroup: n/a CGroup realized: no Name: dev-mapper-isw_cfbejbfeib_Volume12.device Invocation ID: fe79d54b6cc84ae89e7ec472ebf56b0d Condition Timestamp: Thu 2020-09-03 10:41:53 PDT Condition Result: yes Assert Timestamp: Thu 2020-09-03 10:41:53 PDT Assert Result: yes Wants: dev-mapper-isw_cfbejbfeib_Volume12.swap (origin-file) BoundBy: dev-mapper-isw_cfbejbfeib_Volume12.swap (destination-file) Before: dev-mapper-isw_cfbejbfeib_Volume12.swap (destination-file) ReferencedBy: dev-mapper-isw_cfbejbfeib_Volume12.swap (destination-file) StopWhenUnneeded: no RefuseManualStart: no RefuseManualStop: no DefaultDependencies: yes OnFailureJobMode: replace IgnoreOnIsolate: yes Device State: dead The device state is dead. What's the output of udevadm info /sys/class/block/dm-* dm-* being your /dev/mapper/isw_cfbejbfeib_Volume12 device (ls -la /dev/mapper/isw_cfbejbfeib_Volume12 should point at the underlying dm device name) signature.asc Description: OpenPGP digital signature
