O víkendu 11. a 12. května lze navštívit Maker Faire Prague, festival plný workshopů, interaktivních činností a především nadšených a zvídavých lidí.
Byl vydán Fedora Asahi Remix 40, tj. linuxová distribuce pro Apple Silicon vycházející z Fedora Linuxu 40.
Představena byla služba Raspberry Pi Connect usnadňující vzdálený grafický přístup k vašim Raspberry Pi z webového prohlížeče. Odkudkoli. Zdarma. Zatím v beta verzi. Detaily v dokumentaci.
Byla vydána verze R14.1.2 desktopového prostředí Trinity Desktop Environment (TDE, fork KDE 3.5). Přehled novinek v poznámkách k vydání, podrobnosti v seznamu změn.
Dnešním dnem lze již také v Česku nakupovat na Google Store (telefony a sluchátka Google Pixel).
Apple představil (keynote) iPad Pro s čipem Apple M4, předělaný iPad Air ve dvou velikostech a nový Apple Pencil Pro.
Richard Biener oznámil vydání verze 14.1 (14.1.0) kolekce kompilátorů pro různé programovací jazyky GCC (GNU Compiler Collection). Jedná se o první stabilní verzi řady 14. Přehled změn, nových vlastností a oprav a aktualizovaná dokumentace na stránkách projektu. Některé zdrojové kódy, které bylo možné přeložit s předchozími verzemi GCC, bude nutné upravit.
Free Software Foundation zveřejnila ocenění Free Software Awards za rok 2023. Vybráni byli Bruno Haible za dlouhodobé příspěvky a správu knihovny Gnulib, nováček Nick Logozzo za front-end Parabolic pro yt-dlp a tým Mission logiciels libres francouzského státu za nasazování svobodného softwaru do praxe.
Před 10 lety Microsoft dokončil akvizici divize mobilních telefonů společnosti Nokia a pod značkou Microsoft Mobile ji zanedlouho pohřbil.
Fedora 40 release party v Praze proběhne v pátek 17. května od 18:30 v prostorách společnosti Etnetera Core na adrese Jankovcova 1037/49, Praha 7. Součástí bude program kratších přednášek o novinkách ve Fedoře.
Mám podezření, že tohle je Nupac.
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.
[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.
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
.
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.
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.
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š.
Vlákno bylo přesunuto do samostatné diskuse.
Tiskni Sdílej: