Sie sind nicht angemeldet.

[gelöst] Probleme nach baselayout-2 und openrc

Lieber Besucher, herzlich willkommen bei: GentooForum.de. Falls dies Ihr erster Besuch auf dieser Seite ist, lesen Sie sich bitte die Hilfe durch. Dort wird Ihnen die Bedienung dieser Seite näher erläutert. Darüber hinaus sollten Sie sich registrieren, um alle Funktionen dieser Seite nutzen zu können. Benutzen Sie das Registrierungsformular, um sich zu registrieren oder informieren Sie sich ausführlich über den Registrierungsvorgang. Falls Sie sich bereits zu einem früheren Zeitpunkt registriert haben, können Sie sich hier anmelden.

Ignatz

Schüler

  • »Ignatz« ist männlich
  • »Ignatz« ist der Autor dieses Themas

Beiträge: 134

  • Nachricht senden

1

20.12.2008, 14:31

Probleme nach baselayout-2 und openrc

Hallo,

ich habe ein Upgrade auf baselayout-2 und openrc nach dem bekannten Migrationsleitfaden durchgeführt. Das Sytem startet auch und ich kann wie gewohnt arbeiten, jedoch gibt es ein paar "Schönheitsflecken".

Beim Start gibt es keinen Bootsplash mehr sondern nur noch die Konsole mit ihren Meldungen. Wo ist der Bootsplash hin?

Der Start wird nach der Meldung

Quellcode

 
1

...waiting for uevents to be processed
für ca. 1 Minute unterbrochen. Dabei kommen Meldungen wie

Quellcode

 
1

devfs waiting through uevents...
Danach kommt eine Timeout-Meldung und der Bootvorgang läuft weiter.
Da ich annahm, in Zeiten von udev wird devfs nicht mehr benötigt, habe ich kurzerhand devfs aus /etc/init.d/ gelöscht. Der Startvorgang wird trotzdem bis zum Timeout unterbrochen und ich habe anschließend in KDE keine Konsole mehr

Quellcode

 
1

[Konsole kann kein PTY (Pseudo Teletype) öffnen. Dies liegt wahrscheinlich an einem Fehler in der Einrichtung der PTY-Geräte. Konsole benötigt Lese- und Schreibzugriff auf die PTY-Geräte.
Wird wohl mit dem Löschen von devfs zusammenhängen.
Wo kann ich devfs wieder herbekommen? Bzw. brauche ich es noch, oder ist mein udev nicht richtig eingerichtet?

Zuguterletzt gibt es noch eine Fehlermeldung beim Shutdown bzw. Reboot bei der der Vorgang abbricht und ich muss händisch eingreifen (per Magic-SysRq).
Diese Fehlermeldung ist mir zu umfangreich, um sie abzuschreiben, deshalb vorerst die Frage: Gibt es ein Log, in dem der Boot-Vorgang bzw. Shutdown aufgezeichnet wird, so dass ich die richtigen Fehlermeldungen posten kann?

Das ist jetzt allerhand auf einmal, deshalb lasse ich es erstmal gut sein. Diverse Ausgaben reiche ich gern nach.

Gruß,
Ignatz

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »Ignatz« (20.12.2008, 22:45)

josef.95

OSI Layer 8

Beiträge: 7 674

  • Nachricht senden

2

20.12.2008, 16:08

Vermutlich gibt es ein paar Ungereimtheiten in der /etc/rc.conf
diese Datei wahr bei alten Baselayout unter /etc/conf.d/rc zu finden, evtl gab es hier bei der Migration einen fehler!?
Überprüfe dies nochmal, wenn du nicht weiterkommst poste sie hier.

MfG

Ignatz

Schüler

  • »Ignatz« ist männlich
  • »Ignatz« ist der Autor dieses Themas

Beiträge: 134

  • Nachricht senden

3

20.12.2008, 16:15

Hallo Josef,

die rc.conf habe ich schon durchgesehen, aber ich wüsste nicht, was ich dort noch verändern müsste.
Ich hänge sie mal an.

Was meinst du zu der devfs-Geschichte?
»Ignatz« hat folgende Datei angehängt:
  • rc.conf.txt (4,03 kB - 5 mal heruntergeladen - zuletzt: 16.05.2010, 16:25)

josef.95

OSI Layer 8

Beiträge: 7 674

  • Nachricht senden

4

20.12.2008, 17:03

ich vermute mal da es im Bereich
#rc_hotplug="*"
usw zu suchen ist, ich hänge dir mal eine Standard/Beispiel /etc/rc.conf mit an.

MfG
»josef.95« hat folgende Datei angehängt:
  • rc.conf.txt (5,13 kB - 9 mal heruntergeladen - zuletzt: 10.05.2011, 04:06)

Ignatz

Schüler

  • »Ignatz« ist männlich
  • »Ignatz« ist der Autor dieses Themas

Beiträge: 134

  • Nachricht senden

5

20.12.2008, 17:13

Die angehängte Standard-Datei dürfte noch von einem älteren Baselayout sein. Denn Solche Sachen wie

Quellcode

 
1

rc_device_tarball="NO"
gibt es n der neuen nicht mehr.
Ich habe rc_hotplug="*" auch schon angeschalten, das brachte überhaupt keine Veränderung.

Ich bin also leider noch nicht weiter gekommen...

josef.95

OSI Layer 8

Beiträge: 7 674

  • Nachricht senden

6

20.12.2008, 17:28

Die von mir angehängte rc.conf kommt von einem aktuellen einwandfrei startendem gentoo mit openrc-0.3.0-r1
in der steht aber auch zb
rc_hotplug="YES"
usw

viel Erfolg

Ignatz

Schüler

  • »Ignatz« ist männlich
  • »Ignatz« ist der Autor dieses Themas

Beiträge: 134

  • Nachricht senden

7

20.12.2008, 17:44

Hallo Josef,

ich habe deine rc.conf probiert. Leider ändert sich überhaupt nichts an den geschilderten Problemen.
Ich nutze übrigens aktuell die openrc-0.4.0. Vielleicht deshalb die etwas veränderte rc.conf, diese war nach der Installation vorhanden.

Gruß,
Ignatz

[EDIT]
in dmesg habe ich folgende Meldungen gefunden, die wahrscheinlich mit dem Bootsplash zu tun haben:

Quellcode

 
1
2
3
4
5
6
7
8
9
10

uvesafb: mode switch failed (eax=0x34f, err=0). Trying again with default timings.
uvesafb: mode switch failed (eax=0x34f, err=0). Trying again with default timings.
[fglrx] It's not necessary to adjust system aperture on this ASIC 
[fglrx] It's not necessary to adjust system aperture on this ASIC 
uvesafb: mode switch failed (eax=0x34f, err=0). Trying again with default timings.
uvesafb: mode switch failed (eax=0x34f, err=0). Trying again with default timings.
[fglrx] It's not necessary to adjust system aperture on this ASIC 
[fglrx] It's not necessary to adjust system aperture on this ASIC 
uvesafb: mode switch failed (eax=0x34f, err=0). Trying again with default timings.
uvesafb: mode switch failed (eax=0x34f, err=0). Trying again with default timings.


Wenn es nichts mit dem Upgrade auf baselayout-2.0 und openrc zu tun hat, dann eventuell mit dem Update auf den neuesten ATI-Treiber (Version 8.561), der zeitgleich hereingeschneit ist?

[EDIT_2]
Leider nein, ich habe den vorhergehenden ATI-Treiber versucht, gleiches Problem. Es bleibt also aktuell, auch dieses Problem hat mit dem Upgrade auf baselayout-2.0 und openrc zu tun.

Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von »Ignatz« (20.12.2008, 18:20)

bell

Erleuchteter

  • »bell« ist männlich

Beiträge: 3 128

  • Nachricht senden

8

20.12.2008, 20:24

Wg. diesem Thread habe ich mal auf openrc-0.4.0 aktualisiert. Davor hatte ich 0.3.0. Ich muss sagen, es ist (wieder mal) vieles zwischen den Versionen passiert. Ich berichte hier mal.

Ich hatte auch das Problem mit Devfs. Das kam (wahrscheinlich) davon, dass udev mit dem Fehler "udev uses addon code which is deprecated any may not be available in the future" ausgestiegen ist. Update auf sys-fs/udev-135-r2 (vorher 133) hat geholfen.

Zwei Fehler, die ich nicht lösen konnte sind:
- WLAN muss ich nach dem Hochfahren neu starten (restart) Aus dem Default-Runlevel geht es irgendwie nicht richtig. (Keine IP)
- Beim Runterfahren bleibt der PC bei "INIT: no more processes left in this runlevel" stehen und muss manuell ausgeschaltet werden.

Da ich zZ. wenig Zeit habe, die Bugs weiter zu verfolgen, werde ich wohl zurück auf 0.3.0 gehen.

Boot-Spash habe ich auf diesem Rechner noch nicht (letzte Woche frisch installiert), hatte auf dem alten Rechner mit 0.3.0 keine Probleme damit.
Auch wenn Open-Source kostenlos ist, ist sie nicht umsonst. Dein Preis ist Dein Engagement und Mitarbeit an OS-Projekten.
Wenn Du keinen Preis bezahlen willst, bist Du die Ware. Und das ist nicht Open Source, geschweigedenn frei.

Ignatz

Schüler

  • »Ignatz« ist männlich
  • »Ignatz« ist der Autor dieses Themas

Beiträge: 134

  • Nachricht senden

9

20.12.2008, 21:20

Hallo bell,

dieser Tipp war tatsächlich die Lösung fast aller Probleme. Ich habe jetzt auch ein Downgrade auf openrc-0.3.0 durchgeführt.
Der Rechner startet wieder normal, die Konsole funktioniert, selbst den Hänger beim herunterfahren habe ich nicht mehr.
Einzig der Bootsplash ist noch weg und beim Shutdown erscheinen kurz irgendwelche Warnmeldungen, die aber anscheinend nicht weiter stören.

Danke!

Bleibt für mich immer noch die Frage, wo bzw. in welchem Logfile kann ich die Boot-/Shutdown-Meldungen finden um sie in Ruhe zu studieren. Das flimmert sonst alles zu schnell vorbei.

Ich setze den Thread trotzdem auf gelöst, da die übrigen Probleme zweitrangig sind. Bin aber immer noch für jeden Hinweis offen!

Übrigens nutze ich für das Netzwerk schon lange den Networkmanager in Verbindung mit dem knetworkmanager unter KDE. Damit hatte ich noch nie! Probleme.

Gruß,
Ignatz

josef.95

OSI Layer 8

Beiträge: 7 674

  • Nachricht senden

10

21.12.2008, 00:31

Zitat von »Ignatz«

Bleibt für mich immer noch die Frage, wo bzw. in welchem Logfile kann ich die Boot-/Shutdown-Meldungen finden um sie in Ruhe zu studieren. Das flimmert sonst alles zu schnell vorbei.
Ich dacht du hättest dich heute mal ausführlich mit der rc.conf beschäftigt?

Zitat

# rc_logger launches a logging daemon to log the entire rc process to
# /var/log/rc.log
# NOTE: Linux systems require the devfs service to be started before
# logging can take place and as such cannot log the sysinit runlevel.
rc_logger="YES"
Ergebnis ist dann die /var/log/rc.log (siehe Anhang)
Diese log entstand unter openrc-0.4.0 funktioniert hier einwandfrei
EDIT: Auch der Bootsplash geht hier korrekt, allerdings unter nvidia

PS: Viel Spaß noch mit dem Networkmanager ;)

MfG
»josef.95« hat folgende Datei angehängt:
  • rc-log.txt (10,15 kB - 2 mal heruntergeladen - zuletzt: 21.12.2008, 10:44)

Ignatz

Schüler

  • »Ignatz« ist männlich
  • »Ignatz« ist der Autor dieses Themas

Beiträge: 134

  • Nachricht senden

11

21.12.2008, 10:56

Hallo Josef,

ja, dieses Log habe ich eingerichtet. Es ist jedoch eigenartig, denn es scheint nicht vollständig zu sein. Darin stehen nur die Erfolgsmeldungen und keinerlei Fehlermeldungen! Übrigens auch in deinem Log - aber vielleicht gibt es bei dir ja nur Erfolge ;)
Ich sehe (inzwischen nur noch beim Shutdown) jedoch Fehlermeldungen bzw. Warnhinweise, die ich anschließend im Log nicht finde. Gibt es auch die Möglichkeit beim Shutdown einen Screenshot zu machen? Außer natürlich mit der Digitalkamera :D

Der Bootsplash funktioniert nach einem remerge der splashutils inzwischen auch wieder.

Ganz offensichtlich gibt es mit openrc noch einige Probleme aber, naja, es ist eben noch testing.

Du hast jetzt openrc-0.4.0 und alles funktioniert bestens? Eventuell müssen andere Programme, die keine direkten Abhängigkeiten sind, auf neuere (=testing) Versionen aktualisiert werden, damit alles funzt. Allerdings möchte ich vermeiden, mein ganzes System auf testing zu setzen. Ist das bei dir eigentlich der Fall?

Gruß,
Ignatz

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »Ignatz« (21.12.2008, 11:33)

Ignatz

Schüler

  • »Ignatz« ist männlich
  • »Ignatz« ist der Autor dieses Themas

Beiträge: 134

  • Nachricht senden

12

21.12.2008, 12:04

OK! Da ich so schnell nicht aufgeben will, habe ich nochmal auf openrc-0.4.0 aktualisiert.

Beim Start erscheinen die folgenden Meldungen:

Quellcode

 
1
2
3
4
5
6
7
8

...waiting for uevents to be processed
   devfs: waiting for udev
   devfs: waiting for udev
   devfs: waiting for udev
   devfs: waiting for udev
   devfs: waiting for udev
devadm settle timeout of 60 seconds reached, the event queue contents:
'/sys/devices/pci0000:00/0000:00:1d.2/usb4/4--1/4-1:1.0/hci0 [877]

Danach geht der Bootvorgang normal weiter.
Dann ist da noch die Meldung:

Quellcode

 
1
2

device-mapper uses addon code which is deprecated
and may not be available in the future


Was soll das? devfs wartet auf udev?!?! Ich denke ent- oder weder?
Fehlt eine udev-Regel für devfs? Beißt sich da nicht der Hund in den Schwanz? Oder kann ich rausfinden, welches usb-Gerät das ist und dafür eine udev-Regel anlegen?
Google kann mit dieser Meldung rein garnichts anfangen! Ich übrigens auch nicht!

@Josef: Was ist bei deinem System anders?

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »Ignatz« (21.12.2008, 12:18)

josef.95

OSI Layer 8

Beiträge: 7 674

  • Nachricht senden

13

21.12.2008, 12:42

Zitat von »Ignatz«

OK! Da ich so schnell nicht aufgeben will, habe ich nochmal auf openrc-0.4.0 aktualisiert.
Hehe, dies wahr nicht meine Absicht dich wieder zum testing Zweig zu ermuntern ;)

Ja bei mir ist es ein komplett testing System, daher ist es auch meine Vermutung das bei dir einige benötigte Versions-Abhängigkeiten noch fehlen, eventuell ist es das Paket "sysvinit" !? dies ist aber nur mal so geraten!

Sachen wie diese jetzt wahren auch unter anderem einst mit der Grund warum ich auf komplett testing gewechselt bin. ich bin der Meinung man sollte entweder nahezu komplett bei stable bleiben oder aber komplett auf testing wechseln, diese Mischsysteme sind nicht immer ganz leicht zu handhaben. Es kommt bei einem stable System aber sicher auch stark drauf an was für Pakete man auf testig setzt, bei System Paketen sollte man da vorsichtig sein, oder zumindest damit rechnen das was schiefgehen kann.
Doch man sollte sich im klaren sein das ein einmal auf testing gesetztes System nur sehr sehr schwer wieder auf stable zurückzubekommen ist, (glibc usw)

Ich würde dir eher dazu raten wieder auf openrc-3 zurückzugehen...

MfG

Ignatz

Schüler

  • »Ignatz« ist männlich
  • »Ignatz« ist der Autor dieses Themas

Beiträge: 134

  • Nachricht senden

14

22.12.2008, 06:19

"sysvinit" wurde als Abhängigkeit auch aktualisiert, daran wird es wohl nicht liegen.
Vorerst bleibe ich bei openrc-0.3.0. Das ist übrigens auch testing, eine stable-Version von openrc gibt es wohl noch nicht. Dei 0.4er Version muss ich extra maskieren.

Gruß,
Ignatz

bell

Erleuchteter

  • »bell« ist männlich

Beiträge: 3 128

  • Nachricht senden

15

27.12.2008, 11:42

Hallo,
ich habe mich heute wieder an die neue Version openrc-0.4.1 getraut. Anscheinend wurden jetzt alle "ungenauigkeiten" bereinigt. Läuft alles ohne Probleme: Bootsplach löuft. WLan wird zwar nicht mehr per Hotplug gestartet, läuft aber aus dem Default-Runlevel ohne Probleme, Reboot geht auch. Ich bleibe jetzt also bei 0.4.1 mit meinem Misch-System :)

PS: devfsd ist nicht der "alte" udev-Vorgänger, sondern allgemeine Mounts wie devpts. Also schön im "sysinit" Runlevel behalten, sonst funktionieren einige Dinge nicht mehr. 8)
Auch wenn Open-Source kostenlos ist, ist sie nicht umsonst. Dein Preis ist Dein Engagement und Mitarbeit an OS-Projekten.
Wenn Du keinen Preis bezahlen willst, bist Du die Ware. Und das ist nicht Open Source, geschweigedenn frei.

Ignatz

Schüler

  • »Ignatz« ist männlich
  • »Ignatz« ist der Autor dieses Themas

Beiträge: 134

  • Nachricht senden

16

27.12.2008, 13:56

Hallo bell,

bei mir kommt es nach Aktualisierung auf openrc-0.4.1 wieder zu den genannten Meldungen beim booten. Wie gesagt, das System läuft danach problemlos. Aber der Bootvorgang wird durch das Warten auf irgendwas?! ziemlich verlängert und das ist lästig.
Ich habe nacheinander "devfs", "sysfs", "udev" und "udev-mount" zum boot-runlevel hinzugefügt, nichts davon war hilfreich. Die Meldungen:

Quellcode

 
1

devfs: waiting for udev
kommen weiterhin, bis das Warten nach 60 Sekunden durch Timout abgebrochen wird.

Bisher konnte mir noch niemand dafür eine Lösung nennen. Deshalb bleibt ">=openrc-0.4.1" bei mir vorerst maskiert.

Gruß,
Ignatz

dyle

Erleuchteter

  • »dyle« ist männlich

Beiträge: 4 869

  • Nachricht senden

17

02.01.2009, 10:46

Zitat von »Ignatz«

Ich habe nacheinander "devfs", "sysfs", "udev" und "udev-mount" zum boot-runlevel hinzugefügt, nichts davon war hilfreich.

Hm, nein, nein ... seit openrc-0.4.0 gibt es einen neuen runlevel "sysinit". Dieser ist noch *vor* boot zu füttern.
Guck mal

Quellcode

 
1
2
3
4

# rc-update show sysinit
                dmesg | sysinit
                 udev | sysinit
                devfs | sysinit

im Gegensatz zu

Quellcode

 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

# rc-update show boot
        alsasound.new | boot
                 hald | boot
       udev-postmount | boot
                 fsck | boot
                 root | boot
                 swap | boot
               procfs | boot
              urandom | boot
          consolefont | boot
              keymaps | boot
              modules | boot
                 dbus | boot
           localmount | boot
              hwclock | boot
             bootmisc | boot
              hotplug | boot
               hdparm | boot
              numlock | boot
               sysctl | boot
        device-mapper | boot
               net.lo | boot
            syslog-ng | boot
         termencoding | boot
                 mtab | boot
             hostname | boot


Es ist IMHO sehr sehr sinnvoll, dass devfs und udev in sysinit sind. Das sind echte hard-core primär Systemdienste.
http://www.dyle.org
IM-Account (Jabber!) sind auf meiner HP ...
There is no place like /home

http://www.gentooforum.de
http://www.gentoofreunde.org

<div>how to annoy a web developer?</span>

Ignatz

Schüler

  • »Ignatz« ist männlich
  • »Ignatz« ist der Autor dieses Themas

Beiträge: 134

  • Nachricht senden

18

02.01.2009, 12:16

Hallo dyle,

meine Ausgabe von

Quellcode

 
1

# rc-update show sysinit
gleicht deiner exact. Daran sollte es also nicht liegen. Inzwischen bin ich schon etwas weiter gekommen. Siehe dieser Thread.
Vielleicht hast du da eine Idee?

Gruß,
Ignatz

Häufig verwendete Suchbegriffe:

www.my-echo.de mobile-parts-discount.net Andere Architekturen Lob & Kritik Gentoo Linux bka trojaner finden Emerge Probleme softwaregarage.de Drucker Linux Computer und Notebooks