Die Eingabe von
$systemctl
hat unter anderem diesen Fehler ausgespuckt (ich wollte eigentlich nach etwas ganz anderem schauen):
● systemd-modules-load.service loaded failed failed Load Kernel Modules
Was bedeutet das? Und muss ich das korrigieren und wenn ja wie?
Vielen Dank im Voraus!
Naja, da wird es aber mal Zeit sich mit systemd zu beschäftigen!
Der Ursache kommst Du näher mit
systemctl status systemd-modules-load.service und lesen von hier
https://wiki.archlinux.org/index.php/Systemd#Troubleshooting
und hier
http://mywiki.bluelupo.net/index.php/Grundlegende_Kommandos_zu_systemd
Vielen Dank!
Und ja, Du hast Recht. Ich muss mich mit systemd beschäftigen (im Augenblick bin ich am falschen Rechner, kann also nicht weiter nach dem Fehler forschen). Aber ich habe mir die beiden Links zu Gemüte geführt. As always ;) ;) , ArchWiki ist prima.
Morgen werde ich berichten, was die Fehlererforschung erbracht hat.
Erst einmal dies:
<name>@<hostname>:~$ systemctl -l status systemd-modules-load.service
● systemd-modules-load.service - Load Kernel Modules
Loaded: loaded (/lib/systemd/system/systemd-modules-load.service; static)
Active: failed (Result: exit-code) since So 2014-11-02 08:47:39 CET; 10min ago
Docs: man:systemd-modules-load.service(8)
man:modules-load.d(5)
Process: 741 ExecStart=/lib/systemd/systemd-modules-load (code=exited, status=1/FAILURE)
Main PID: 741 (code=exited, status=1/FAILURE)
Nov 02 08:47:39 <hostname> systemd[1]: systemd-modules-load.service: main process exited, code=exited, status=1/FAILURE
Nov 02 08:47:39 <hostname> systemd[1]: Failed to start Load Kernel Modules.
Nov 02 08:47:39 <hostname>systemd[1]: Unit systemd-modules-load.service entered failed state.
Aber schlauer werde ich daraus noch nicht ... (?)
#!/bin/bash
if grep "modules-load" /proc/cmdline; then
echo " --- above /proc/cmdline"
fi
for i in /lib /usr/lib /usr/local/lib /etc /run ; do
if [ -d "$i/modules-load.d" ] ; then
cd $i/modules-load.d || continue
for j in * ; do
if [ -f "$j" ] ; then
echo "-------------------------------"
echo $i/modules-load.d/$j
cat $j
fi
done
fi
done
... Ich denke mal, da ist irgendwo eine Konfiguration ungültig/kaput.
Vielen Dank für den Input!
Ich hoffe, ich habe Dich richtig verstanden und das Script oben ausgeführt. Der Output im Terminal sieht folgendermassen aus:
/lib/modules-load.d/fuse.conf
fuse
/usr/lib/modules-load.d/*
cat: *: Datei oder Verzeichnis nicht gefunden
/etc/modules-load.d/cups-filters.conf
# Parallel printer driver modules loading for cups
# LOAD_LP_MODULE was 'yes' in /etc/default/cups
lp
ppdev
parport_pc
/etc/modules-load.d/loop.conf
loop
/etc/modules-load.d/modules.conf
# /etc/modules: kernel modules to load at boot time.
#
# This file contains the names of kernel modules that should be loaded
# at boot time, one per line. Lines beginning with "#" are ignored.
radeon
fglrx
Aber nun?
Bei Benutzung von Grafikkarten von Nvidia mit nouveau - oder respektive nvidia proprietary - braucht man gar nichts einzutragen. Wenn man beide benutzen will, gibt es einen Fehler. Ich frage mich ob das bei Radeon auch so ist? Mein output zeigt nur vbox:
/usr/lib/modules-load.d/virtualbox.conf
vboxnetflt
vboxnetadp
vboxdrv
/etc/modules-load.d/virtualbox.conf
# vboxdrv
# vboxnetflt
# vboxnetadp
Mit demselben Dateinamen (virtualbox.conf) in /etc überschreibe ich die Datei in /usr/lib/modules-load, so dass ich die Modue gar nicht lade im Moment.
Hm, Du meinst ich sollte mal probieren, die Datei /etc/modules zu leeren? Ich mach's mal und komme dann, hoffentlich ;), wieder zurück.
Kleine An- oder Bemerkung eines ziemlich Ahnungslosen: radeon UND fglrx ginge sowieso nicht zusammen. Vermutlich ist das eine Hinterlassenschaft meiner Grafiktreiberprobleme (und der damitverbundenen Folgeprobleme: kein Suspend ohne fglrx. Aber fglrx läuft nicht mit den neuesten kernel ... :-( ).
Das war's! Vielen Dank. Ich habe die beiden Zeilen in /etc/modules erst einmal herauskommentiert. Der output Deines Scripts sieht jetzt genauso aus wie vorher, nur dass 'radeon' und 'fglrx' ein '#' vorgestellt ist. Und die einfache Eingabe vo systemctl beklagt keine Fehler mehr :D
Und, wie man sieht, funktioniert der Rechner immer noch ;)
Kleine Frage noch: Sollte also/etc/modules schlicht leer sein (und wird es überhaupt noch gebraucht)?
die ganzen verzeichnisse
/etc/NAME.d/
also hier /etc/modules-load.d/
können leer sein. Sie können vom Admin - also dir - mit Dateien belegt werden, die den gleichen Namen haben können wie Dateien unter /usr/lib/NAME.d : Dann werden die von Deiner Distribution (siduction) verteilten Dateien ignoriert. (Ich wollte Dir diesen Umstand mit dem Beispiel virtualbox oben verdeutlichen). Das ist zB wunderhübsch auch zu benutzen mit udev im Verzeichnis: /etc/udev/rules.d
Vielen Dank. Das hatte ich schon so in Ansätzen verstanden. Es war mir nur nicht so klar, wie das mit gewissermassen "lebenswichtigen" Modulen ist. In /usr/lib/ habe ich bei mir nicht viele Unterverzeichnisse des Typs NAME.d gefunden. Gerade mal modules-load.d, tmp.d, binfmt.d und sysctl.de. Bis auf tmp.d sind alle leer.
Woher weiss der Rechner eigentlich, z.B., dass er radeon benutzen soll (und nicht ati oder fglrx)?
Unfair @ralul,
da lieferst Du dieses wunderbare Script, was den TE davon abhält sich mit systemd zu beschäftigen... ;)
Herzlichen Dank auch von mir! 8)
journalctl -b _PID=741
hätte ihn auch zu der Lösung gebracht, wenn er denn das verlinkte Arch-Wiki gelesen.
Du bist so gemein! :P Ich habe das ArchWiki sehr wohl gelesen. Aber dann eben das Script gesehen ... ;)
Fussnote:
Gibt es hier so eine Art Sammel systemd thread - wo man alle möglichen (und unmöglichen) Fragen stellen könnte? Aus dem - im ArchWiki zitierten - Fedorathread zum Thema hätte ich nämlich eine Frage betreffs 'service xyz stop/start/restart' ....
Apropos script:
Ich habe einfach nur reingeschaut in /lib/systemd/system/systemd-modules-load.service
Mal mit mc (midnight commander) browsen in der Konsole in den verdächtigen Verzeichnissen ...
Apropos systemd:
Da gibt es doch nicht viel zu lernen:
a) systemctl mask||enable||status|start SERVICE
b) journalctl
... mehr ist das doch nicht.
@ralul
Quote from: ralul on 2014/11/02, 19:06:28
Apropos systemd:
Da gibt es doch nicht viel zu lernen:
a) systemctl mask||enable||status|start SERVICE
b) journalctl
... mehr ist das doch nicht.
Doch
http://linux.xvx.cz/2014/06/systemd-cheatsheet.html
bevo
stimmt - ralul hat was ganz wesentliches vergessen:
systemctl stop $foo 8)
und ein paar Auswertungstools - viel mehr weiss ich auch nicht darüber und erstaunlicherweise reicht das für mich. Bei anderen mag das anders sein.
Quote from: melmarker on 2014/11/02, 21:28:34
stimmt - ralul hat was ganz wesentliches vergessen:
systemctl stop $foo 8)
Eher noch wichtiger:
systemctl isolate multi-user.target
um in den runlevel-3 - von früher so her bekannt - zu kommen. Aber mich würden auch noch einige Sachen interessieren: systemd-nspawn als chroot. Also an einem neuen Thread bezüglich systemd würde ich mich sicher beteiligen (vielleicht in Englisch?) zumal man zu dem Thema in den diversen Gentoo Foren nichts sagen kann ohne gleich eine zwei Jahre dauernden Hetzthread gegen LP aus zu lösen.
Quote from: ralul on 2014/11/03, 00:19:27
...
Also an einem neuen Thread bezüglich systemd würde ich mich sicher beteiligen (vielleicht in Englisch?)
...
Das wäre mir Recht, Sprache egal ... ;)
nennt mich ruhig ignorant - aber nach init 3 gehe ich mit init 3 :) - oder noch besser mit systemctl stop $DM :D