Re: Systemd-Probleme
On Fri, 13 Sep 2019 21:52:50 +0200
Sven Joachim <svenjoac@gmx.de> 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 to: