Systemd-Probleme

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Systemd-Probleme

ternaryd
Hi,

Vor einiger Zeit klagte ich auf dieser Liste
über ein NFS Problem mit einem alten Kernel auf
einer exotischen Hardware. Längere Zeit danach
fand ich heraus, daß dies ein bug im Kernel
(3.8.0) war.

Das ist ein powerpc-spe, für den es seit etwa
einem Jahr keine Unterstützung mehr in debian
gibt (Architektur hat keinen Maintainer mehr).
Diese Karte bootet mit einem U-Boot und
benötigt einen "device tree". Ich habe sehr
wenig Information über diese Hardware, sodaß
das Erstellen des device trees weitgehend ein
Ratespiel ist, bei dem ich von einer ähnlichen
Karte ausgegangen bin. Alles ist noch nicht
geklärt, aber mittlerweile ist es genug, daß
ich doch auch einen moderneren (4.19) kernel
kompilieren und booten kann. Das rootfs dabei
ist aber noch das von 2012.

Mittlerweile hab ich herausgefunden, daß es auf
snapshot.debian.org wenigstens eine Version von
2018 gibt und versuche nun, diese zu
installieren. Da der Unterscheid zwischen der
Version von 2012 und 2018 viel zu groß war, gab
es keine Möglichkeit, einfach in sources.list
die neue URL einzutragen. So habe ich den neuen
Kernel mit dem rootfs von 2012 gebootet, auf
der NFS-server Seite ein Verzeichnis mit
"debootstrap -foreign" initialisiert und konnte
dann (mit einiger Mühe) das rootfs von snapshot
in einem chroot installieren.

Der nächste Schritt war das Netzwerk und fstab
auf der neuen Installation so zu setzen, wie
dies vorher war, und dann dieses rootfs auf dem
NFS-Server zu exportieren (incl. exportfs -f),
um zu versuchen damit zu booten. Der
Bootvorgang beginnt ganz normal, doch endet er
mit:

Kernel panic - not syncing: Attempted to kill
init! exitcode=0x00007f00

Laut den logs auf der NFS-Serverseite wird das
Dateisystem geladen (authenticated mount
request from...). Ich habe gesehen,
daß /sbin/init auf systemd zeigt, und so
vermute ich, daß dieser nicht korrekt
initialisiert wurde und daher nicht startet
(sonst müßte ich doch irgend eine Ausgabe auf
dem terminal sehen, oder?)

Gibt es irgendeine Möglichkeit, selbst wenn
systemd nicht aktiv ist, über ein chroot den
systemd zu prüfen, ob er eingerichtet ist,
"potentiell" als ein init-Prozess zu
funktionieren? Oder vielleicht direkt in einer
Datei?

Danke,

Reply | Threaded
Open this post in threaded view
|

Re: Systemd-Probleme

Sven Joachim
Am 13.09.2019 um 11:33 schrieb ternaryd:

> Vor einiger Zeit klagte ich auf dieser Liste über ein NFS Problem mit
> einem alten Kernel auf einer exotischen Hardware. Längere Zeit danach
> fand ich heraus, daß dies ein bug im Kernel (3.8.0) war.
>
> Das ist ein powerpc-spe, für den es seit etwa einem Jahr keine
> Unterstützung mehr in debian gibt (Architektur hat keinen Maintainer
> mehr).

Nicht nur in Debian gibt es keine Unterstützung mehr, sondern auch
Upstream nicht, beginnend mit GCC 9 und Glibc 2.30.  Die Architektur ist
also tot.

> Der nächste Schritt war das Netzwerk und fstab auf der neuen
> Installation so zu setzen, wie dies vorher war, und dann dieses rootfs
> auf dem NFS-Server zu exportieren (incl. exportfs -f), um zu versuchen
> damit zu booten. Der Bootvorgang beginnt ganz normal, doch endet er
> mit:
>
> Kernel panic - not syncing: Attempted to kill init!
> exitcode=0x00007f00
>
> Laut den logs auf der NFS-Serverseite wird das Dateisystem geladen
> (authenticated mount request from...). Ich habe gesehen, daß
> /sbin/init auf systemd zeigt, und so vermute ich, daß dieser nicht
> korrekt initialisiert wurde und daher nicht startet (sonst müßte ich
> doch irgend eine Ausgabe auf dem terminal sehen, oder?)

Hast du in deinem Kernel alle Optionen aktiviert, die systemd braucht?
Siehe /usr/share/doc/systemd/README.gz.

> Gibt es irgendeine Möglichkeit, selbst wenn systemd nicht aktiv ist,
> über ein chroot den systemd zu prüfen, ob er eingerichtet ist,
> "potentiell" als ein init-Prozess zu funktionieren? Oder vielleicht
> direkt in einer Datei?

Du kannst "systemd --system --test" versuchen.

Viele Grüße,
Sven

Reply | Threaded
Open this post in threaded view
|

Re: Systemd-Probleme

ternaryd
On Fri, 13 Sep 2019 21:52:50 +0200
Sven Joachim <[hidden email]> wrote:

> Hast du in deinem Kernel alle Optionen
> aktiviert, die systemd braucht? Siehe
> /usr/share/doc/systemd/README.gz

Alle hab ich bei weitem nicht. Von der ersten
Gruppe (Kernel Config Options) fehlt CGROUPS
und FHANDLE. Bei den Crypto-Optionen fehlt
USER_API_HASH, weiß nicht, wozu ich die crypto
Sachen hier brauche.

DMIID kommt in der ganzen .config gar nicht
vor, und NET_NS auch nicht; da ist nur ein
NET_NSH (nicht gesetzt).

localed.service wird wohl nicht funktionieren,
denn von allen Paketen, die ich von snapshot
habe, war locales das einzige, welches nicht
installiert werden konnte, da die libc-Version
nicht übereinstimmt. Für mich ist das kein
Problem, doch könnte systemd mir das übel
nehmen?

Keine Ahnung was PrivateUsers ist, aber die
Option CONFIG_USER_NS ist auch nicht in meiner
.config.

Von den optionalen will ich eigentlich gar
nichts, aber das "strongly recommended"
beunruhigt ein wenig.

CONFIG_CGROUP_BPF hab ich auch nicht, aber
IPAdressDeny et al. werde ich nicht brauchen,
denn diese Kiste hat nur ein point-to-point zum
NFS Server und sonst keine weitere eth
Verbindung. Und da es U-Boot hat, hat es auch
kein UEFI.

Angst macht mir das mit CPUShares. Systemd darf
mir beim Realtime nicht dazwischen funken; ich
habe einen sehr engen Ablauf (1ms Zyklen) in
denen vieles gemacht werden muß, und da brauche
ich volle Kontrolle über die beiden Kerne der
CPU. Ist das optional?

Wenn ich das richtig verstanden habe, kann ich
einige Optionen fallen lassen, nur, daß dann
gewisse APIs nicht mehr verfügbar sind (was für
mich gerne OK ist).

Im ersten Vers steht bei CGROUPS, daß es OK ist,
wenn man alle controllers disabled. Heißt das,
daß ich die Option dann nicht einbauen muß?

So sollte mir eigentlich nur CONFIG_FHANDLE
fehlen. Bei welchen Optionen würdest du
vermuten, daß sie verhindern, daß der Kernel
ohne Panik seinen init Prozess bekommt?

Bei meinem ersten post hab ich erwähnt, daß ich
weiß, daß NFS importiert wurde (Nachricht auf
Server-Seite). Nun ist mir auf dem terminal
noch ein zweiter Hinweis aufgefallen: Udev hat
mir eth1 in eth6 umbenannt, es gibt aber unter
/etc/udev keine Dateien. Da ich glaube, daß
udev im user space läuft, mußte da schon etwas
von init (systemd) gemacht worden sein. Könnte
es sein, daß er einfach abgestürzt ist?

> Du kannst "systemd --system --test"
> versuchen.

Das hat leider nicht geklappt:

systemd: error while loading shared libraries:
R_PPC_REL24 relocation at 0x005ccd70 for symbol
`kmod_unref' out of range

Das mit dem "out of range" könnte aber mit dem
chroot zu tun haben. Welches Kernelmodul will
er mir da desinstallieren? Ich habe nur ein
einziges für den VME-Bus, von dem systemd wohl
eher nichts versteht. Der Rest ist fest in den
Kernel einkompiliert.

Am Ende hätte ich noch eine Frage. In den guten
alten Tagen war es /etc/inittab, wo man ttyS0
aktivieren konnte. Das hat jetzt auch systemd
übernommen? wie geht das dann da?

Reply | Threaded
Open this post in threaded view
|

Re: Systemd-Probleme

Martin Steigerwald
Hi.

ternaryd - 14.09.19, 00:04:19 CEST:

> On Fri, 13 Sep 2019 21:52:50 +0200
>
> Sven Joachim <[hidden email]> wrote:
> > Hast du in deinem Kernel alle Optionen
> > aktiviert, die systemd braucht? Siehe
> > /usr/share/doc/systemd/README.gz
>
> Alle hab ich bei weitem nicht. Von der ersten
> Gruppe (Kernel Config Options) fehlt CGROUPS
> und FHANDLE. Bei den Crypto-Optionen fehlt
> USER_API_HASH, weiß nicht, wozu ich die crypto
> Sachen hier brauche.
>
> DMIID kommt in der ganzen .config gar nicht
> vor, und NET_NS auch nicht; da ist nur ein
> NET_NSH (nicht gesetzt).

Einige Optionen tauchen da eventuell nur auf, wenn Du andere Optionen
bereits aktiviert hast, da hinter Unter-Optionen versteckt?

> Angst macht mir das mit CPUShares. Systemd darf
> mir beim Realtime nicht dazwischen funken; ich
> habe einen sehr engen Ablauf (1ms Zyklen) in
> denen vieles gemacht werden muß, und da brauche
> ich volle Kontrolle über die beiden Kerne der
> CPU. Ist das optional?

CPUShares dürfte nur dazwischen funken können, wenn Du Resourcen-Limits
setzt. Soweit ich weiß sind da standardmäßig keine Limits gesetzt. Ein
gewissen Overhead haben die CGroup-Sachen bestimmt, aber das dürfte
nicht so viel sein. Getestet habe ich das allerdings nie.


Wenn ich mir das so durchlese, wie Du zumindest einige der Kernel-
Optionen nicht möchtest und es ohnehin schon herausfordernd war, für das
System einen aktuelleren Kernel zu bauen, frage ich mich:

Brauchst Du auf dem System Systemd?

Nimm doch einfach Sysvinit, Runit oder irgendein anderes Init-System.

Wenn da eine Desktop-Umgebung drauf haben möchtest, wird ohne Systemd
etwas komplizierter. Geht aber auch. Auf einem Server läuft das rund,
solange Du keinen Dienst verwendest, der nur noch Systemd-Service-
Dateien mitbringt und keine Init-Skripte mehr, wie Knot Resolver – die
Alternative unbound läuft out of the box. Aber auch da dürfte es dank
init-d-script (siehe gleichnamige Manpage) nicht sonderlich schwer sein,
ein Init-Skript zu bauen, siehe z.B. "/etc/init.d/fio" in meinem fio-
Paket. Das könntest Du dann sogar dem Paketbetreuer zukommen lassen.

Ciao,
--
Martin


Reply | Threaded
Open this post in threaded view
|

Re: Systemd-Probleme

ternaryd
On Sat, 14 Sep 2019 09:51:18 +0200
Martin Steigerwald <[hidden email]> wrote:

> Einige Optionen tauchen da eventuell nur auf,
> wenn Du andere Optionen > bereits aktiviert
> hast, da hinter Unter-Optionen versteckt?

Genau. Da muß man dann länger suchen.

> CPUShares dürfte nur dazwischen funken
> können, wenn Du Resourcen-Limits setzt.
> Soweit ich weiß sind da standardmäßig keine
> Limits gesetzt. Ein gewissen Overhead haben
> die CGroup-Sachen bestimmt, aber das dürfte
> nicht so viel sein. Getestet habe ich das
> allerdings nie.

Bin mir nicht sicher, was systemd da mit
resourcen meint. Oder ist das das mit dem
setrlimit()? Verwende ich im Prinzip nicht,
aber ich nagle gewisse zeitkritische Prozesse
auf einen Kern und leite die anderen auf den
anderen um.

> Brauchst Du auf dem System Systemd?

Hm. Ich bin seit eh und je sehr glücklich ohne
systemd gewesen, aber der hat sich installiert,
obwohl ich alle Optionen eingestellt hatte, die
mir untergekommen sind um ein sysv init zu
bekommen. Ich hab zwar ein init, aber das ist
fake news, bloß ein link auf systemd.

> Nimm doch einfach Sysvinit, Runit oder
> irgendein anderes Init-System.

Bitte, bitte, Kochrezept! Beim Installieren der
Pakete nach dem bootstrap bin ich über ein
Paket gestolpert, welches sich wie "sysvinit"
anhörte und hab es promt auch installiert. Zu
sehen ist davon aber garnix.

> Wenn da eine Desktop-Umgebung drauf haben
> möchtest, wird ohne Systemd etwas
> komplizierter.

Desktop auf dieser Kiste? völlig undenkbar.
Nein, was die Benutzung angeht, läuft da ein
einziger Hauptprozess mit mehreren threads und
ein Sekundärprozess, der viel schläft. Und
doch das geht an die Grenze des Möglichen.

> solange Du keinen Dienst verwendest, der nur
> noch Systemd-Service- Dateien mitbringt und
> keine Init-Skripte mehr,

Freiwillig verwende ich so etwas bestimmt
nicht, weiß aber nicht, was mir beim update
von snapshot alles installiert wurde.

> wie Knot Resolver ...

Praktisch keine Netzwerkaktivität, die über NFS
und einige Befehlspakete (UDP) hinausgeht, und
alle Kommunikation auf einen einzigen anderen
Computer beschränkt. Die haben sogar einen
eigenen switch, sodaß man vom LAN gar
nicht zugreifen kann. Sogar exim und viele
andere Sachen hab ich ausgehebelt. Sind zwar
da, damit debian glücklich ist, aber die kommen
nie zum Laufen.

> Aber auch da dürfte es dank init-d-script
> (siehe gleichnamige Manpage) nicht sonderlich
> schwer sein, ein Init-Skript zu bauen,

init-scripts kann man einfach machen; sie
helfen aber nur, wenn man ein init zum Laufen
gebracht hat.

Wenn es eine saubere Möglichkeit gibt,
sysv-init statt systemd zu bekommen, ist das
meine Lösung für die nächsten n-Jahre.

Reply | Threaded
Open this post in threaded view
|

Re: Systemd-Probleme

ternaryd
In reply to this post by Sven Joachim
On Fri, 13 Sep 2019 21:52:50 +0200
Sven Joachim <[hidden email]> wrote:

> Hast du in deinem Kernel alle Optionen
> aktiviert, die systemd braucht?
> Siehe /usr/share/doc/systemd/README.gz.

Mittlerweile ja. Und systemd crashed immer noch
kurz nach dem boot.

Außerdem hab ich festgestellt, daß hier eine
software math emulation aktiv ist, welche etwa
4 mal so langsam ist wie die "normale" math
lib, die den SPE verwendet.

Gibt es noch weitere Ideen?

Reply | Threaded
Open this post in threaded view
|

Re: Systemd-Probleme

Dirk Paul Finkeldey
Am 16.09.19 um 14:17 schrieb ternaryd:

> On Fri, 13 Sep 2019 21:52:50 +0200
> Sven Joachim <[hidden email]> wrote:
>
>> Hast du in deinem Kernel alle Optionen
>> aktiviert, die systemd braucht?
>> Siehe /usr/share/doc/systemd/README.gz.
> Mittlerweile ja. Und systemd crashed immer noch
> kurz nach dem boot.
>
> Außerdem hab ich festgestellt, daß hier eine
> software math emulation aktiv ist, welche etwa
> 4 mal so langsam ist wie die "normale" math
> lib, die den SPE verwendet.
>
> Gibt es noch weitere Ideen?


In der Kernelconfig die option math emulation abstellen, bei PPC ab
Power3 sollte altivec soweit ich weiß aktiv sein.

Bei CPU für Raspberry ist es FPU, soweit ich weiß.


Gruß

Dirk

Reply | Threaded
Open this post in threaded view
|

Re: Systemd-Probleme

ternaryd
On Tue, 17 Sep 2019 04:03:46 +0200
Dirk Paul Finkeldey <[hidden email]>
wrote:

> In der Kernelconfig die option math emulation
> abstellen, bei PPC ab Power3 sollte altivec
> soweit ich weiß aktiv sein.

Darauf hatte ich immer schon geachtet. Und das
ist kein Altivec, sondern ein Freescale e500v2.
Der hat einen SPE (Signalprozessor), und damit
eine Ersatz-FPU.

Hab mittlerweile verstanden, daß dies nicht am
Kernel, sondern an diesem debian snapshot
liegt. Warum heißt die Architektur powerpcSPE,
wenn der SPE nicht verwendet wird? Außerdem
kann ich auf diesem Snapshot die Quellcodes
nicht finden. Wie's aussieht, gibt es powerpcspe
für debian schon seit eher 10 statt nur einem
Jahr nicht mehr.

Dazu kommt, daß systemd nicht zum Laufen zu
bekommen ist und sysvinit auch nicht
aktivierbar ist. Werde wohl bei der
Version prä-2012 bleiben müssen. Updates wird
es wohl sowieso nicht mehr geben.