[wiregate] Avahi, hald Errors

[vlamers]

Hi,

ich habe auf meinem WG Probleme mit dem hald und Avahi-Daemon. Dadurch mit pulseaudio und owserver.

der Thread ist nur dazu da dass ich makki nicht per PM zuspamen muss.

folgendes konnte ich bisher feststellen (trägt evtl zur Problemlösung bei):
- Probleme mit root-Berechtigungen (War UID 11xxx), manuell auf 0 gesetzt. root zu allen möglichen gruppen hinzugefügt (war keine Gruppe)
- dbus sollte laufen
- hal-daemon scheint die größten Probleme zu machen. Auch durch mehrstündiges googeln kein Lichtblick bei mir...
- Avahi hängt an hald
- dbus kann nicht empfangen, senden oder ähnliches (hier wäre ein tipp welche berechtigungen ich da setzen muss gut).

dbus, hal, avahi wurden deinstalliert und neu installiert (leider ohne erfolg)

Ich werde den Thread updaten sobald ich was neues versucht habe.

Gruß vlamers

[makki]

Da ist schon wieder irgendwas grob vermurkst, root hat die uid/gid 0, das stimmt "aus der Box" alles, hal, dbus & avahi können dann auch wunderbar miteinander sprechen..

Ohne Details, was genau mit was überschrieben wurde, ist das ne Nadel im Heuhaufen

Makki

[vlamers]

Ich glaub dass ist zumindest ein Fehler der damit zusammenhängt:

> apt-get install hal --reinstall -y Paketlisten werden gelesen... Abhängigkeitsbaum wird aufgebaut... Lese Status-Informationen ein... Die folgenden zusätzlichen Pakete werden installiert: hal-info libdirectfb-extra libhal-storage1 libsmbios-bin libsmbios2 libsplashy1 libx86-1 pm-utils powermgmt-base radeontool uswsusp vbetool Vorgeschlagene Pakete: gnome-device-manager libsmbios-doc cpufrequtils splashy Die folgenden NEUEN Pakete werden installiert: hal hal-info libdirectfb-extra libhal-storage1 libsmbios-bin libsmbios2 libsplashy1 libx86-1 pm-utils powermgmt-base radeontool uswsusp vbetool debconf: Schiebe die Paket-Konfiguration auf, da apt-utils nicht installiert ist 0 aktualisiert, 13 neu installiert, 0 zu entfernen und 0 nicht aktualisiert. Es müssen noch 0B von 1963kB an Archiven heruntergeladen werden. Nach dieser Operation werden 5132kB Plattenplatz zusätzlich benutzt. Wähle vormals abgewähltes Paket libhal-storage1. (Lese Datenbank ... 70615 Dateien und Verzeichnisse sind derzeit installiert.) Entpacke libhal-storage1 (aus .../libhal-storage1_0.5.11-8_i386.deb) ... Wähle vormals abgewähltes Paket libsmbios2. Entpacke libsmbios2 (aus .../libsmbios2_2.0.3.dfsg-1_i386.deb) ... Wähle vormals abgewähltes Paket hal-info. Entpacke hal-info (aus .../hal-info_20080508+git20080601-1_all.deb) ... Wähle vormals abgewähltes Paket powermgmt-base. Entpacke powermgmt-base (aus .../powermgmt-base_1.30+nmu1_i386.deb) ... Wähle vormals abgewähltes Paket pm-utils. Entpacke pm-utils (aus .../pm-utils_1.1.2.4-1_all.deb) ... Wähle vormals abgewähltes Paket hal. Entpacke hal (aus .../archives/hal_0.5.11-8_i386.deb) ... Wähle vormals abgewähltes Paket libdirectfb-extra. Entpacke libdirectfb-extra (aus .../libdirectfb-extra_1.0.1-11_i386.deb) ... Wähle vormals abgewähltes Paket libsmbios-bin. Entpacke libsmbios-bin (aus .../libsmbios-bin_2.0.3.dfsg-1_i386.deb) ... Wähle vormals abgewähltes Paket libsplashy1. Entpacke libsplashy1 (aus .../libsplashy1_0.3.13-3+lenny1_i386.deb) ... Wähle vormals abgewähltes Paket libx86-1. Entpacke libx86-1 (aus .../libx86-1_1.1+ds1-2_i386.deb) ... Wähle vormals abgewähltes Paket radeontool. Entpacke radeontool (aus .../radeontool_1.5-5_i386.deb) ... Wähle vormals abgewähltes Paket uswsusp. Entpacke uswsusp (aus .../uswsusp_0.7-1.2_i386.deb) ... Wähle vormals abgewähltes Paket vbetool. Entpacke vbetool (aus .../vbetool_1.0-3_i386.deb) ... Verarbeite Trigger für man-db ... /usr/bin/mandb: Der von Man benutzte Nutzer »man« existiert nicht Richte libhal-storage1 ein (0.5.11-8) ... Richte libsmbios2 ein (2.0.3.dfsg-1) ... Richte hal-info ein (20080508+git20080601-1) ... Richte powermgmt-base ein (1.30+nmu1) ... .udevdb or .udev presence implies active udev. Aborting MAKEDEV invocation. Richte pm-utils ein (1.1.2.4-1) ... Richte hal ein (0.5.11-8) ... Reloading system message bus config...Failed to open connection to system message bus: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. invoke-rc.d: initscript dbus, action "force-reload" failed. Starting Hardware abstraction layer: haldinvoke-rc.d: initscript hal, action "start" failed. dpkg: Fehler beim Bearbeiten von hal (--configure): Unterprozess post-installation script gab den Fehlerwert 1 zurück Richte libdirectfb-extra ein (1.0.1-11) ... Richte libsmbios-bin ein (2.0.3.dfsg-1) ... Richte libsplashy1 ein (0.3.13-3+lenny1) ... Richte libx86-1 ein (1.1+ds1-2) ... Richte radeontool ein (1.5-5) ... Richte uswsusp ein (0.7-1.2) ... debconf: kann Frontend nicht initialisieren: Dialog debconf: (TERM ist nicht gesetzt, das Dialog-Frontend kann daher nicht verwendet werden.) debconf: greife zurück auf das Frontend: Readline Konfiguriere uswsusp --------------------

Kein geeigneter Swap-Bereich für Software-Suspend gefunden

Um das System in den Ruhezustand versetzen zu können, benötigt uswsusp eine Swap-Partition oder -Datei, in die der Schnappschuss des Systems gespeichert wird. Dafür scheint kein solcher Platz vorhanden zu sein.

Sie sollten eine Swap-Partition oder -Datei erstellen, falls möglich doppelt so groß wie der physische RAM des Systems.

Führen Sie dann »dpkg-reconfigure uswsusp« aus oder bearbeiten Sie die Konfigurationsdatei manuell.

Richte vbetool ein (1.0-3) ... Fehler traten auf beim Bearbeiten von: hal E: Sub-process /usr/bin/dpkg returned an error code (1)

Gruß

Edit:
kleines update. Ich denke es hängt alles am hal-daemon. Und der funktioniert nicht weil???:

Mar  9 15:00:38 wiregate619 hald[21712]: 15:00:38.630 [I] hald.c:669: hal 0.5.11
Mar  9 15:00:38 wiregate619 hald[21712]: 15:00:38.631 [I] hald.c:678: Will daemonize
Mar  9 15:00:38 wiregate619 hald[21712]: 15:00:38.632 [I] hald.c:679: Becoming a daemon
Mar  9 15:00:38 wiregate619 hald[21713]: 15:00:38.635 [I] hald_dbus.c:5381: local server is listening at unix:abstract=/var/run/hald/dbus-Ndw7fWJXEK,guid=4d239e13aaa6aea0fbf715624f5a0d06
Mar  9 15:00:38 wiregate619 hald[21713]: 15:00:38.645 [E] hald_dbus.c:5747: dbus_bus_get(): Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
root@wiregate619:/etc#
root@wiregate619:/etc# cd /var/run/hal/
root@wiregate619:/var/run/hal# ls
root@wiregate619:/var/run/hal# cd /var/run/hald
-bash: cd: /var/run/hald: Datei oder Verzeichnis nicht gefunden

**censored***

[vlamers]

Ich habe versucht mit lshal den hal-daemon zu ner genaueren Fehler beschreibung zu überreden. Hat leider nicht wirklich geklappt:

root@wiregate619:/var/run# lshal
error: dbus_bus_get: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.

das syslog spricht dazu:

Mar  9 20:19:08 wiregate619 hald[11259]: 20:19:08.803 [E] hald_dbus.c:5747: dbus_bus_get(): Did not receive a reply. Possible causes include: the remote application di$
Mar  9 20:19:13 wiregate619 hald[11342]: 20:19:13.644 [I] hald.c:669: hal 0.5.11
Mar  9 20:19:13 wiregate619 hald[11342]: 20:19:13.645 [I] hald.c:678: Will daemonize
Mar  9 20:19:13 wiregate619 hald[11342]: 20:19:13.645 [I] hald.c:679: Becoming a daemon
Mar  9 20:19:13 wiregate619 hald[11343]: 20:19:13.649 [I] hald_dbus.c:5381: local server is listening at unix:abstract=/var/run/hald/dbus-w862zEAkRn,guid=f2d4468449b5a$
Mar  9 20:19:13 wiregate619 hald[11343]: 20:19:13.653 [E] hald_dbus.c:5747: dbus_bus_get(): Did not receive a reply. Possible causes include: the remote application di$
Mar  9 20:20:05 wiregate619 hald[12222]: 20:20:05.330 [I] hald.c:669: hal 0.5.11
Mar  9 20:20:05 wiregate619 hald[12222]: 20:20:05.331 [I] hald.c:678: Will daemonize
Mar  9 20:20:05 wiregate619 hald[12222]: 20:20:05.332 [I] hald.c:679: Becoming a daemon
Mar  9 20:20:05 wiregate619 hald[12223]: 20:20:05.334 [I] hald_dbus.c:5381: local server is listening at unix:abstract=/var/run/hald/dbus-twOxrE1F19,guid=e3898674f50e5$
Mar  9 20:20:05 wiregate619 hald[12223]: 20:20:05.337 [E] hald_dbus.c:5747: dbus_bus_get(): Did not receive a reply. Possible causes include: the remote application di$

mehr ist aus der Kiste nicht raus zu quetschen.

Hat jemand vielleicht noch nen Tipp, wie ich das ganze debuggen kann.

Gruß Volker

[makki]

Ach Mönsch, man kann den hald doch auch einfach in ruhe lassen, statt ihn versuchen zu reinstallieren
Swap gibbet z.B. halt keinen, das hat schon seine Richtigkeit..

Also, hab grade nochmal geschaut aber sorry, so macht das keinen Spass!
Das ist schon wieder total vermurkst, eine detaillierte Änderungsliste oder kapitulation meinerseits.. Das sind z.B. irgenwelche Squeezebox-Sachen wild verteilt, mit user aber ohne existierende Gruppe, ohne Debian-Paket, da kann man nichts nachvollziehen

Ich vermute ja eher, das der Murks vom letzten da restored wurde, so sieht jedenfalls ansatzweise kein WG aus (und auch kein Debian lenny)

Makki

[vlamers]

Also

Restored würde /etc/wiregate, /etc/default/pulse und mpd, asound.conf und der komplette www Ordner.
Die /etc/passwd wurde wiederhergestellt, da in der originalen der root User UID 11xxxxxx
Hatte. Daher der squeezebox User, mit squeezebox hab ich ansonsten nix am Hut.


Den hal kann man natürlich in ruhe lassen, wenn man avahi anders starten kann.?

[makki]

Die /etc/passwd wurde wiederhergestellt,

Das erklärt einiges.. Das gehärt mal wirklich zu den wenigen Dingen an denen man nicht fummeln sollte..
(Die installation der Pakete legt die User ggfs. an, welche UID die bekommen ist nicht 100% deterministisch)

Die richtige - mit an Sicherheit grenzender Wahrscheinlichkeit - müsste ich am Montag im Büro an einem aktuell frisch produzierten nochmal prüfen, anbei.
Für alle User die darin nicht existieren, muss man die *richtige uid* übernehmen oder nachträgliches am besten *vorher* deinstallieren und danach wieder installieren.

da in der originalen der root User UID 11xxxxxx

Nö, die hat er woanders her bekommen. Auch das werde ich nochmal prüfen aber im aktuell verwendeten Image hat root immernoch die uid 0, da ist was anderes schiefgelaufen..

Makki

[vlamers]

oh dass hätte ich klar stellen sollen! mit original meinte ich bevor ich die passwd drüber kopiert hab. nicht den auslieferungszustand.

ich werde heut bzw morgen mal testen ob ich dass iwie hin bekomme.

Danke!

Gruß Volker

[vlamers]

Hi,

also die passwd wieder auf Original Zustand zu setzen, hatte leider nicht den gewünschten Erfolg.

Gruß

[vlamers]

Hallo,

da ich immer noch auf der Suche bin noch ne frage zum Auslieferungszustand:

Sind in den iptables rules vorhanden? (Bei mir ist die leer)(kann das daran liegen dass mDNS ein Fehler bringt)

unter /etc/network/interfaces:

- hotplug aktiviert?
- rest per DHCP?

Gruß und Danke

[makki]

iptables sind leer

/etc/network/interfaces

# The loopback network interface
auto lo eth0
iface lo inet loopback
	allow-hotplug eth0

# The primary network interface
iface eth0 inet dhcp

Makki

[vlamers]

OK Danke.

Dann wars dass nicht...

Ich such weiter

Gruß