[walkaround] lvm+systemd, Boot hängt

Alle weiteren Dienste, die nicht in die drei oberen Foren gehören.
Antworten
rendegast
Beiträge: 15041
Registriert: 27.02.2006 16:50:33
Lizenz eigener Beiträge: MIT Lizenz

[walkaround] lvm+systemd, Boot hängt

Beitrag von rendegast » 04.06.2017 17:25:49

stretch/testing
Booten fällt nach minutenlangen timeouts in den Rettungsmodus.
Ein Symptom scheinen eine Reihe wohl hängengebliebene Prozesse
systemd-udevd -> 'lvm pvscan --cache --activate ay --major MA --minor MI'

Diese Dinger kommen aus der 69-lvm-metad.rules,
kein Zusammenhang mit lvm2-pvscan@.service, dessen Format wäre
'lvm pvscan --cache --activate ay MA:MI'

Ein 'pvscan' gibt Fehler derart
WARNING: Device /dev/sdXY not initialized in udev database even after waiting 10000000 microseconds.
Das erklärt schonmal meine erste Pause beim Booten.

Ich habe einen Zusammenhang vermutet
systemd-udevd <-?-> pvscan --cache --activate <-?-> lvmetad
und es mit einem Start des lvmetad vor dem udevd versucht, damit der die vom pvscan ermittelten Daten aufnehmen kann.

Code: Alles auswählen

[Unit]
Before=systemd-udevd.service
Das hat aber nicht gefruchtet, das Problem tritt in der initrd auf, dort gibt es noch keinen lvmetad.


Es scheint wohl eher an den separaten Aufrufen per lvm-device (bei mir 17) zu liegen.
Mein walkaround:
1) Die separaten Aufrufe erstmal deaktiviert, /etc/udev/rules.d/69-lvm-metad.rules, eine modifizierte Kopie,
die dann auch statt des Originals in der initrd landet:

Code: Alles auswählen

...
#RUN+="/sbin/lvm pvscan --cache --activate ay --major $major --minor $minor", ENV{LVM_SCANNED}="1"
# 20170604, stretch, Problem lvmetad <->? pvscan --cache [--activate] <->? systemd-udevd
#   Auswirkung: boot-timeout, verbleibende udevd-pvscan-Prozesse
RUN+="/bin/echo DUMMY /sbin/lvm pvscan --cache --activate ay --major $major --minor $minor"
...

2) Ein Ersatz für den Aufruf, /etc/initramfs-tools/scripts/init-top/zz_lokal_lvm2_pvscan
(Vorlage die Skripte /usr/share/initramfs-tools/.../lvm2, ausführbar):

Code: Alles auswählen

#!/bin/sh

PREREQ="mdadm mdrun multipath"

prereqs()
{
	echo "$PREREQ"
}

case $1 in
# get pre-requisites
prereqs)
	prereqs
	exit 0
	;;
esac

if [ ! -e /sbin/lvm ]; then
	exit 0
fi

# 20170604, nach udev (mit dummy-activate.rule)
# scripts/* aus etc/ werden wohl ohnehin nach denen aus share/, hier speziell init-top/udev eingeordenet ('ORDER'),
# dennoch mal lieber als "zz_..."
lvm pvscan
lvm pvscan --cache --activate ay

exit 0
-> 'update-initramfs -u -kall'

toi toi toi, die VG wird jetzt ratzfatz aktiviert.




3) Damit die frühere Funktion der 69-lvm-metad.rules im laufenden System bereitsteht:
Verlinkung des Originals unter leicht geändertem Namen
/etc/udev/rules.d/69-lvm-metad_ORIGINAL.rules -> /lib/udev/rules.d/69-lvm-metad.rules
Das scheint erstmal hinreichend und problemlos, sollte aber im Auge behalten werden.
----------------------------
EDIT Aua wegen 3),
Ich hatte das nur theoretisch überlegt, aber den Test noch nicht gemacht.
Der Link
/etc/udev/rules.d/69-lvm-metad_ORIGINAL.rules -> /lib/udev/rules.d/69-lvm-metad.rules
landet (als Datei) in der initrd, führt dort tatsächlich zum Aufhängen des boot-Vorgangs!
Also maximal ein Link
/lib/udev/rules.d/69-lvm-metad_ORIGINAL.rules -> 69-lvm-metad.rules
(Leider halt in /lib, das ist unschön)
mfg rendegast
-----------------------
Viel Eifer, viel Irrtum; weniger Eifer, weniger Irrtum; kein Eifer, kein Irrtum.
(Lin Yutang "Moment in Peking")

rendegast
Beiträge: 15041
Registriert: 27.02.2006 16:50:33
Lizenz eigener Beiträge: MIT Lizenz

Re: [walkaround] lvm+systemd, Boot hängt

Beitrag von rendegast » 05.06.2017 21:23:29

Anmerkung,
ein weiteres Ergebnis meiner Versuche,
der Debianhaveged startet sicher, wenn er eine zusätzliche Bedingung
/etc/systemd/system/haveged.service.d/walkaround.conf

Code: Alles auswählen

[Unit]

#After=local-fs.target                NEIN, nicht ausreichend
After=network-pre.target
bekommt.


Im default

Code: Alles auswählen

...
After=apparmor.service systemd-random-seed.service
Before=sysinit.target shutdown.target
...
versucht er es (hier) zu früh:
...
(irgendwo hier wird haveged ohne Meldung aufgerufen)
...
Jun 05 18:38:29 debian systemd[1]: Reached target Network (Pre).
Jun 05 18:38:29 debian systemd[1]: haveged.service: Failed to run 'start' task: No such file or directory
Jun 05 18:38:29 debian systemd[1]: Failed to start Entropy daemon using the HAVEGE algorithm.
Jun 05 18:38:29 debian systemd[1]: haveged.service: Unit entered failed state.
Jun 05 18:38:29 debian systemd[1]: haveged.service: Failed with result 'resources'.
Jun 05 18:38:29 debian systemd[1]: Starting LVM2 metadata daemon...
im Erfolgsfall durch die Änderung:
...
Jun 05 18:46:43 debian systemd[1]: Reached target Network (Pre).
Jun 05 18:46:43 debian systemd[1]: Started Entropy daemon using the HAVEGE algorithm.

...
Jun 05 18:46:43 debian systemd[1]: Reached target System Initialization.
...
Jun 05 18:46:43 debian systemd[1]: Reached target Paths.
...
Jun 05 18:46:43 debian systemd[1]: Reached target Sockets.
Jun 05 18:46:43 debian systemd[1]: Reached target Basic System.
...
Jun 05 18:46:43 debian haveged[552]: haveged: ver: 1.9.1; arch: x86; vend: ; build: (gcc 6.2.1 ITV); collect: 128K
Jun 05 18:46:43 debian haveged[552]: haveged: cpu: (VC); data: 64K (V); inst: 64K (V); idx: 39/40; sz: 59215/59215
Jun 05 18:46:43 debian haveged[552]: haveged: tot tests(BA8): A:1/1 B:1/1 continuous tests(B): last entropy estimate 8.00252
Jun 05 18:46:43 debian haveged[552]: haveged: fills: 0, generated: 0

...
mfg rendegast
-----------------------
Viel Eifer, viel Irrtum; weniger Eifer, weniger Irrtum; kein Eifer, kein Irrtum.
(Lin Yutang "Moment in Peking")

Antworten