Dotaz: chybová hlášení systemd

[Jitka]

Ahoj všem.

Jsem tu nová a s linuxem teprve začínám. Vyrostla jsem na windows, ale protože jsem zvídavá, zatoužila jsem poznat i něco jiného. Jako moje první distro jsem si zcela čistě náhodně vybrala archlinux. Po jeho instalaci mi zatím "asi" vše funguje, ale během bootování se mi na obrazovce několikrát, asi 6x, objeví hlášení:

"Failed to start Load kernel modules" a že bližší informace se dozvím prohlédnutím "systemctl status systemd-modules-load.service"

Po zadání uvedeného příkazu se mi ukáže velké množství informací, ve kterých se vůbec nevyznám.

Poradíte mi, jak se v tomto orientovat, a jak případně tato chybová hlášení odstanit, tedy odstranit jejich příčinu?

Děkuji a hezký večer. Jitka

Odpovědi

[Petr Šobáň]

Jednoduše si to přečíst a pochopit.....

Až je pochopíš tak budeš vědět jak je odstranit.

PS. Skopíruj je sem někdo ti je vysvětlí....

[Andrej]

Mám podezření, že tohle je Nupac.

[Petr Šobáň]

Taky mám takové pochybnosti, ale nechtěl jsem být drzý.

Uvidíme.........

[k3dAR]

pokud to nediktoval nekomu kdo umi psat, tak to Nupac neni ;)

[Pavel 'TIGER' Růžička]

Převlékl si šaty a vcítil se do ženské role, takže je to Nupac. :)

[k3dAR]

vyjmenoval si vlastnosti kterych neni Nupac schopen a stale to nevysvetluje to ze by tato jeho osobnnost narozdil od vsech desitek jeho dalsich osobnosti umela najednou psat ;)

[Andrej]

Bez té konkrétní chybové hlášky můžu jedině říct, že jsem si zapomněl doma křišťálovou kouli.

Když jsem selhání zmíněné systemd unit viděl posledně, bylo to tím, že v jednom ze souborů v /usr/lib/modules-load.d/* byl kernelový modul, který se na daném stroji nedařilo načíst — matně si vzpomínám, že souvisel s hardwarovou kryptografii, ale procesor byl Westmere, takže nic. Jindy to bylo tím, že jsem si někam do /etc/modules-load.d/* přidal modul, který se nedařilo načíst — například proto, že se kvůli nějakému dočasnému bugu po aktualizaci kernelu nepřekompiloval některý modul z AUR a podobně. Řešením bylo (a) odstranit řádku s modulem, který nefungoval, nebo (b) nainstalovat modul, který chyběl.

[Jitka]

Ahoj. Omlouvám se, ale byla jsem teď hodně zaneprázdněná a tak posílám výpis až nyní:

[vrtule@pc][~]%systemctl status systemd-modules-load.service
● systemd-modules-load.service - Load Kernel Modules
   Loaded: loaded (/usr/lib/systemd/system/systemd-modules-load.service; static; vendor preset: 
   Active: failed (Result: start-limit-hit) since St 2016-11-16 12:35:45 CET; 6min ago
     Docs: man:systemd-modules-load.service(8)
           man:modules-load.d(5)
  Process: 341 ExecStart=/usr/lib/systemd/systemd-modules-load (code=exited, status=1/FAILURE)
 Main PID: 341 (code=exited, status=1/FAILURE)
lines 1-7/7 (END)

Nějak se v tom moc neorientuji... Poradíte mi?

Moc díky a hezký den.

[Andrej]

Zdá se, že to (zatím) přesně pasuje na tento návod.

Pokud journalctl -b -u systemd-modules-load neřekne, který přesně modul selhal, lze zkusit (pod rootem) všechny požadované moduly manuálně načíst, například takto:

for file in /{etc,usr/lib}/modules-load.d/*.conf; do
  while read module; do
    modprobe "$module" || echo "Selhal modul ${module} v souboru ${file}."
  done < "${file}"
done

Většinou stačí modul, který selhává, jednoduše vynechat. Aby konfigurace nezmizela při další aktualizaci balíčků vlastnících soubory v /usr/lib/modules-load.d/, nejlepší bude příslušný soubor zduplikovat do /etc/modules-load.d/ s vynecháním selhávajícího modulu. Tedy například takto:

grep -v nějaký_modul \
  < /usr/lib/modules-load.d/nějaký_soubor.conf \
  > /etc/modules-load.d/nějaký_soubor.conf

Tohle všechno je popsané v man modules-load.d.

[Matlák]

Tady to už někdo řešil, jednoduše postupem podle Archwiki. Jinak je to moc obecná hláška, ideální by bylo sem výpis příkazu přiložit.

[Jitka]

Díky za radu. Zkusím se na to podívat. Snad z toho budu moudrá...

[j]

Nebo vymen distro za neco, kde neni systemd ... prevazne to pak zadny chyby hlasat nebude (rozhodne ne v default instalaci) a kdyz, tak naprosto jasny = je videt co chce.

[Andrej]

Tohle je ale korunovaná hovadina, kterou je dobré přidat na seznam důvodů, proč zakázat anonymy na ABCLinuxu.

Ve fosilních distrech bez systemd to nejčastěji „fungovalo“ tak, že se chyby ignorovaly a schovávaly a nehlásily se v podstatě vůbec. To je ze všech možností ta nejhorší. Temná minulost, do které je lepší se nevracet.

systemd jasně říká, co selhalo a co to chce. Jenom je potřeba si to přečíst.

[Josef Kufner]

Ono systemd sice hodně chyb řeší, ale také přidává docela nové a mnohem zábavnější zážitky.

[lertimir]

Ve většině případů ano. pokud ale diky něčemu nazamrzne systém celý a pak správce zjistí že není posledních 15 minut. Ale souhlasím s tebou, že řeší toho hodně.

[Peter Golis]

Pokiaľ by zamrzol celý systém, tak hádam že kelner o tom napíše ako panic. Alebo sa niečo za posledné desaťročia zmenilo?

[lertimir]

Náš zbohatlík o tom asi moc psát nebude, ale k těm logům viz

[Peter Golis]

To akože odkazuješ na štrukturovaný kernel panic? To je aj na troling slabé.

[pavlix]

Mimochodem to zdaleka nebylo naposledy, co se mi celý log sesypal.

[k3dAR]

hovadina to neni(i kdyz v danem pripade to asi neni nejvhodnejsi reseni), pokud systemd jasne rika co selhalo, proc navrhujes rucne pres smycku jak retard nacitat po jednom jednotlive moduly, ale proc se nezeptas toho genialniho systemd aby ti jasne rekl kterej modul selhal? ;)

[Andrej]

A modprobe jsi už někdy použil? Fakt nevím, co jiného na to říct. Vinit v tomto případě systemd jako takový je nesmysl.

Tohle je způsobené (když už to musím rozebrat polopatě) špatným návrhem příslušné systemd unit pro explicitní načítání modulů. Podle mě by měla existovat dynamicky generovaná systemd unit pro každý modul, který se explicitně načítá (podtrhuji explicitně). Pak by bylo hned vidět, který modul selhal. Navíc by takové uspořádání bylo mnohem bližší (paralelnímu) způsobu fungování systemd jako celku. Dokud bude explicitní načítání modulů seskupené do jediné systemd unit, která ani pořádně neloguje, povede to k nejasnostem tohoto druhu.

Proto jsem zmiňoval možnosti, jak manuálně ověřit, který modul selže.

[k3dAR]

jasne je nesmysl ze by za to mohl systemd, protoze za to muze spatne systemd unit... predtim systemd jasne rika co selhale, takze co selhalo si uzivatel musi rucne zjistit sam... no uz radeji prestan chlastat :)

[Andrej]

Pokud jsi nepochopil psaný text (a zjevně ne), nevzdávej to. Zkus si ho přečíst znova. A znova. A ještě. A třeba to jednou zvládneš.

[k3dAR]

goto #50

[Andrej]

Výborně! Jen houšť!

[Pavel 'TIGER' Růžička]

To záleželo na tom, jak člověk měl nastavené výpisy. Nebyl problém zapnout rozšířené výpisy, které zobrazily každou chybovou hlášku. A když něco nefungovalo, stačilo nakouknout do /var/log, a chyba se mohla odstranit. Systemd sice hodně věcí řeší, ale také je rozlezlej v systému jako virus. Když porovnám Debian a Devuan, tak Devuan je stále přímější a čitelnější.

[j]

Pise anonymni tupec ... systemd zadny funkcni logy nema, a zadnej init system neselhava proste proto ... protoze je to JEN init.

[Krása]

Vlákno bylo přesunuto do samostatné diskuse.