bootolási folyamatban valami hiba {megoldva}

Ubuntu Linux

Sziasztok.

Mezei Ubuntun forgattam egy kernelt, majd azon elmélkedtem, hogy egy külső USB-s egeret is fel kellene ismernem.
Itt kezdődött a gond, nem kellett volna.

Az egeret a jelenlegi forgatással sem sikerült felismertetnem, holott lsusb látja. De nem az egér a gond itt most, hanem ez:

Bootoláskor az UDEV valami érdekességet jelez, idézem a végét.

"
[ 23.086071] systemd-udevd[5178]: failed to execute '/lib/udev/socket:@/org/freedesktop/hal/udev_event' 'socket:@/org/freedesktop/hal/udev_event': No such file or directory
[ 23.650765] systemd-udevd[5192]: failed to execute '/lib/udev/socket:@/org/freedesktop/hal/udev_event' 'socket:@/org/freedesktop/hal/udev_event': No such file or directory
[ 23.699534] EXT4-fs (sda5): mounted filesystem with ordered data mode. Opts: (null)
[ 23.700329] systemd-udevd[5196]: failed to execute '/lib/udev/socket:@/org/freedesktop/hal/udev_event' 'socket:@/org/freedesktop/hal/udev_event': No such file or directory
[ 23.763266] kjournald starting. Commit interval 5 seconds
[ 23.763528] EXT3-fs (sda6): using internal journal
[ 23.763532] EXT3-fs (sda6): mounted filesystem with writeback data mode
[ 26.082227] init: avahi-cups-reload main process (5307) terminated with status 1
[ 32.219715] init: failsafe main process (5223) killed by TERM signal
[ 33.903000] ttyS0: LSR safety check engaged!
[ 33.904109] ttyS0: LSR safety check engaged!
[ 33.905517] ttyS2: LSR safety check engaged!
[ 33.906562] ttyS2: LSR safety check engaged!
[ 36.043510] init: gdm main process (5475) killed by TERM signal
"

Ezután rendben bejön a GDM, a rendszer kifogástalanul működik, viszont 12 másodpercen keresztül listázza az ehhez hasonlatos sorokat:
[ 23.086071] systemd-udevd[5178]: failed to execute '/lib/udev/socket:@/org/freedesktop/hal/udev_event' 'socket:@/org/freedesktop/hal/udev_event': No such file or directory

Google előszed a hibaüzenetre, erre kijön az, hogy a halat (Hardware Abstraction Layer) le kell szednem:

apt-get remove hal

Kérdésem rövid.
Ez mi?
Mitől jött?
Miért?
Volt már valakinek hasonló?
Tényleg megoldódik a remove hal-lal minden?

  • 1903 megtekintés

( NevemTeve | 2015. 09. 25., p – 17:20 )

(troll)Szerintem Slackware a helyes megfejtés. Vagy valamilyen BSD(/troll)

( locsemege v | 2015. 09. 26., szo – 00:39 )

Fedorához az utolsó HAL fordítás 4.5 éve volt, a mai systemd, udev világba nem kell.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( luisex v | 2015. 09. 26., szo – 06:55 )

Szia,
Bocs, hogy ide kontárkodok, de hadd kérdezzem meg, minek kellett a kernelt újrafordítanod? Illetve, miért nem a default opcióival forgattad?
Üdv,
LuiseX

( bzs v | 2015. 09. 26., szo – 12:59 )

Közben alakult a dolog, rájöttem, hogy a fenti problémának köze sincs a kernelforgatásomhoz, mert egy korábbi, a distribbel szállított kernellel ugyanaz a HAL-probléma jön elő.

Most arra próbálok rájönni, minek kell nekem a HAL, mit gyorsít ha gyorsít, minek gyorsítja ha esetleg nem is kell..

---
--- A gond akkor van, ha látszólag minden működik. ---
---

A HAL (ahogy a neve mutatja) egy absztrakciós réteg. Ad(ott) egy relatíve fix és absztrakt API-t, aztán ő meg megoldja, hogy random rendszeren random kernelverziónál a hardvereket hogyan is kell kezelni. Gyorsítani szerintem semmit nem gyorsított, inkább elfedte mondjuk pl. az X elől, hogy a billentyűzet és az egér kezelése hogyan változott az évek során a kernelben.
https://en.wikipedia.org/wiki/HAL_(software)

Amúgy mostanra a HAL-t kidobták kb. mindenhonnan, a kérdés csak az, hogy mennyire elavult (és ezért még HAL-t használó) cuccok vannak még a gépeden.
https://bugs.launchpad.net/ubuntu/+source/squeeze/+bug/1221254

Na ugye! Mondom, hogy ma már nem kell. Gondolom, upgrade-elted évek óta a gépet, s ott maradt. Fedora egyébként ilyenkor jellemzően letakarítja, ami gondot okozna. Tudom, nem Fedoráról beszélünk, csak nekem arról van tapasztalatom.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE