Hey I got lucky with a google search and found what would be a dupe if
it were ever finished.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=805821
Somebody else managed to track the problem down.
For some reason systemd is only watching for /dev/dm-* rather than the
long dmraid device names.
Am 13.01.20 um 01:10 schrieb Joshua Hudson:
> I double-checked with init=/bin/sh. All the devices already exist in
> /dev/mapper before /linuxrc shuts down the initrd copy of udev.
> systemd will never see the activation of a udev device because that's
> already done. They're all active.
>
Well,
I double-checked with init=/bin/sh. All the devices already exist in
/dev/mapper before /linuxrc shuts down the initrd copy of udev.
systemd will never see the activation of a udev device because that's
already done. They're all active.
That turned out to be really easy to track down. The reason you aren't
getting any notification of the raid array being activated is it was
already activated in initrd. It will not be activated a second time.
dmraid has some interesting principles in play here.
1) dmraid has its own idea of
Control: retitle -1 dmraid volumes are not marked as active, resulting
in time out
Am 12.01.20 um 20:49 schrieb Joshua Hudson:
>>> Dec 31 08:27:23 nova dmraid-activate[554]: ERROR: Cannot retrieve RAID
> set information for isw_cfbejbfeib_Volume1
>> Have you further investigated those error
>> Dec 31 08:27:23 nova dmraid-activate[554]: ERROR: Cannot retrieve RAID
set information for isw_cfbejbfeib_Volume1
> Have you further investigated those error messages?
I have now investigated and it's clearly spurious.
udev tries to run the following commands:
/sbin/dmraid-activate /dev/sda
Thanks for the log.
Seems there is something at odds with the RAID configuration:
Dec 31 08:27:23 nova dmraid-activate[553]: ERROR: Cannot retrieve RAID
set information for isw_cfbejbfeib_Volume1
Dec 31 08:27:23 nova dmraid-activate[554]: ERROR: Cannot retrieve RAID
set information for
Am 31.12.19 um 01:24 schrieb Joshua:
> Package: systemd
> Version: 241-7~deb10u2
> Severity: important
>
> Dear Maintainer,
>
>* What led up to the situation?
>
> apt-get install systemd-sysv && reboot
>
>* What was the outcome of this action?
>
> boots to emergency; journald spams
Control: tags -1 + moreinfo
Please provide a verbose debug log:
https://freedesktop.org/wiki/Software/systemd/Debugging/#index1h1
signature.asc
Description: OpenPGP digital signature
To let the gravity of the but sink in, this is the pair of scripts
that I jammed in front of systemd that got it to somehow behave
itself:
/sbin/init:
#!/bin/sh
echo "INIT: rc init is in startup"
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
/etc/rc.earlyboot || PS1='init#
Package: systemd
Version: 241-7~deb10u2
Severity: important
Dear Maintainer,
* What led up to the situation?
apt-get install systemd-sysv && reboot
* What was the outcome of this action?
boots to emergency; journald spams the console with errors, can't login as
nonroot, can't start X
11 matches
Mail list logo
