Upgrade auf Stretch, längere Bootzeit, Firefox Optik

[rallygion]

Hallo,

ich hab gestern das Upgrade auf Stretch (GNOME 3) durchgeführt, lief im Großen und Ganzen auch problemlos.
Nur seit dem hängt der Laptop beim Booten für ein paar Sekunden und dabei erscheint folgende Meldung beim Booten:

Code: Alles auswählen

Loading, please wait...
"disk/by-uuid/[UUID-der-SSD]": Invalid path for Logical Volume.
/dev/sda1: clean, 500728/15630336 files, 38782190/62514432 blocks
[1.606304] iwlwifi 0000:04:00.0: api_index larger than supported by driver

Die SSD taucht aber unter /dev/disk/by-uuid mit der richtigen UUID auf und ist auch bei /etc/fstab mit der richtigen UUID angegeben.
Sie ist mit ext4 formatiert.

Oder ist das Problem die Firmware des Intelchipsatz? WLAN-Chip ist der 7260AC von Intel

Code: Alles auswählen

dpkg -l | grep  iwlwifi
ii  firmware-iwlwifi                      20161130-3                           all          Binary firmware for Intel Wireless cards

Code: Alles auswählen

dmesg | grep iwlwifi
[    1.606293] iwlwifi 0000:04:00.0: firmware: direct-loading firmware iwlwifi-7260-17.ucode
[    1.606304] iwlwifi 0000:04:00.0: api_index larger than supported by driver
[    1.606664] iwlwifi 0000:04:00.0: loaded firmware version 17.352738.0 op_mode iwlmvm
[    1.648472] iwlwifi 0000:04:00.0: Detected Intel(R) Dual Band Wireless AC 7260, REV=0x144
[    1.648550] iwlwifi 0000:04:00.0: L1 Enabled - LTR Enabled
[    1.648845] iwlwifi 0000:04:00.0: L1 Enabled - LTR Enabled
[    3.219006] iwlwifi 0000:04:00.0: L1 Enabled - LTR Enabled
[    3.219250] iwlwifi 0000:04:00.0: L1 Enabled - LTR Enabled
[    3.425852] iwlwifi 0000:04:00.0: L1 Enabled - LTR Enabled
[    3.426091] iwlwifi 0000:04:00.0: L1 Enabled - LTR Enabled
[    3.442317] iwlwifi 0000:04:00.0: L1 Enabled - LTR Enabled
[    3.442575] iwlwifi 0000:04:00.0: L1 Enabled - LTR Enabled
[    3.637525] iwlwifi 0000:04:00.0: L1 Enabled - LTR Enabled
[    3.637769] iwlwifi 0000:04:00.0: L1 Enabled - LTR Enabled

Der Networkmanager braucht auch immer wieder etwas bis der Rückmeldung gibt, aber das nur hin und wieder.
Die Meldung davon hab ich leider nicht parat. Reiche Sie aber nach, sollte sie mal wieder erscheinen.

Zu dem nächsten Problem:
Der Firefox integriert sich nicht mehr so gut in die Gnome3-Umgebung. Hab das Adwaita-Theme aktiv.
Oben die Titelleiste sieht normal wie immer aus und der Rest von Firefox sieht nach der Standardoptik unter Windows aus


Bis jetzt hab ich leider über das Internet oder die Forensuche darüber nichts gefunden.
Ich weiß auch ehrlich gesagt nicht so recht, wo ich ansetzen soll.
Wenn jemand Tipps hat, wär ich dafür sehr dankbar!

Grüße

PS: Anscheinend braucht er etwas beim Laden der grafischen Oberfläche. Der Mauszeiger erscheint schon und ich kann die Maus auch bedienen. Bis aber dann der Desktop gestartet wird, dauerts ein paar Sekunden.

[rendegast]

Ein erster Überblick für das erste Problem

Code: Alles auswählen

systemd-analyze blame > sa-blame.txt
systemd-analyze critical-chain > sa-critical-chain.txt
systemd-analyze plot > sa-plot.svg

... for Logical Volume.

Bei mir ging es um darunterliegende pv, jedoch echte timeout von x*30s,
viewtopic.php?f=32&t=165401.
Insoweit handelt es sich bei Dir wohl eher nur um ein Optimierungsproblem.

Dazu hier ein Ansatz
viewtopic.php?f=27&t=165577
Jedoch sind die von die erwähnten potentiellen Hänger
(disk + Netzwerkvoraussetzung)
eher nicht dafür geeignet, aus der Bootphase herausgezogen zu werden.

[rallygion]

Vielen Dank für die Antwort.
Ich muss mich dafür entschuldigen, dass ich erst jetzt antworte. Bin derzeit am Haus bauen und hab ein kleines Kind, dementsprechend wenig Zeit hab ich derzeit
Hier mal die Ausgaben von:

systemd-analyze blame
pastebin/?mode=view&s=39915

Code: Alles auswählen

systemd-analyze critical-chain
graphical.target @15.002s
└─multi-user.target @15.002s
  └─smbd.service @14.872s +130ms
    └─winbind.service @14.788s +82ms
      └─nmbd.service @14.633s +151ms
        └─network-online.target @14.632s
          └─NetworkManager-wait-online.service @2.030s +12.602s
            └─NetworkManager.service @1.867s +161ms
              └─network-pre.target @1.866s
                └─ebtables.service @1.729s +128ms
                  └─local-fs.target @1.726s
                    └─run-user-1000.mount @14.779s
                      └─local-fs-pre.target @1.724s
                        └─keyboard-setup.service @136ms +1.587s
                          └─systemd-journald.socket @135ms
                            └─-.mount @117ms
                              └─system.slice @134ms
                                └─-.slice @117ms
                                

Die Plotdatei kann ich gerade leider nicht hochladen, da kommt bei mir nur eine Fehlermeldung.

Jedoch sind die von die erwähnten potentiellen Hänger
(disk + Netzwerkvoraussetzung)
eher nicht dafür geeignet, aus der Bootphase herausgezogen zu werden.

Was meinst du mit "nicht dafür geeignet aus der Bootphase herausgezogen zu werden? Dass die Bootreihenfolge nicht geändert werden sollte?

Die von dir verlinkten Beiträge seh ich mir an, ob ich damit weiterkomme.

Grüße

[rendegast]

Was meinst du mit "nicht dafür geeignet aus der Bootphase herausgezogen zu werden? Dass die Bootreihenfolge nicht geändert werden sollte?

Das bezieht sich auf die oben angesprochene Methode zur beschleunigten Anzeige des grafischen Login.
Hier mache ich das mit für den Benutzer eher unwichtigen Diensten wie
nginx
fhem
fail2ban
xrdp
samba
Spielerei, Schnickschnack.
Und die Remote-Benutzer müssen länger auf ihre Dienste warten.




Die 'blame' / 'critical-chain' scheinen mir unverdächtig / nicht weiterführend.

Nach dem Bootprozeß übrigbleibende Prozesse 'lvm scan'?
Benutzt du lvm + Verschlüsselung?

Code: Alles auswählen

blkid | sort -V

[scientific]

Wenn du keine Dienste hast, die unbedingt eine Netzwerkverbindung benötigen, könnte auch

Code: Alles auswählen

 
systemctl disable NetworkManager-wait-online.service 

Eine Beschleunigung bringen.

Aber Gnome muss 300MB laden. Gdm lädt eine volle Gnome Sitzung... Und bei einer langsamen Platte dauert das. Hab das mal beobachtet, wie der Speicherverlauf ist, während gdm gestartet ist und tatsächlich sichtbar wird.

Lg scientific

[rallygion]

Nach dem Bootprozeß übrigbleibende Prozesse 'lvm scan'?
Benutzt du lvm + Verschlüsselung?

lvm scan gibt bei mir nichts aus, außer dass es diesen Befehl nicht gibt.
Ich benutze weder lvm noch Verschlüsselung, ich hab nur eine Ext4-Partition

Code: Alles auswählen

blkid | sort -V
/dev/sda1: UUID="7be46bd3-550d-4193-bffb-e7fc67f246a7" TYPE="ext4" PARTUUID="000e1bd9-01"

Code: Alles auswählen

systemctl disable NetworkManager-wait-online.service 

Der Befehl hat das ganze schon mal um einiges beschleunigt.

Da ich nur einen lokal genutzen Laptop habe, brauch ich eigentlich kaum irgendwelche Dienste.

[scientific]

Nochmal nachgefragt...

Braucht das Anzeigen von gdm so lange, oder des Desktops, nachdem du dich in Gdm eingelogt hast?

Oder wirst du automatisch angemeldet, und benõtigt dann Gnome3 so lange?

Du hast dein System ja auf einer SSD. Damit sollte der Desktop ja ratzfatz geladen sein (bei mir in ca. 1 Sekunde).

Was hier noch blockieren kann sind Services des user-systemd.

Finde einmal heraus, welche UID Debian-gdm hat. Und dann poste die Ausgabe von (als root ausgeführt)

Code: Alles auswählen

 journalctl -b -u user@117.service -u user@1000.service

Wobei 117 durch die UID von Debian-gdm und 1000 durch die UID deines Users zu ersetzen ist.

Du findest die UID mit dem Befehl (als User ausgeführt)

Code: Alles auswählen

 id 

für deinen User, bzw

Code: Alles auswählen

 id Debian-gdm

heraus.

Hier könnte sich zeigen, ob auf ein User-Service gewartet wird, oder ob eines fehlschlägt.

[rallygion]

Bis GDM gestartet wird, dauert es etwas.
Die Obefläche nach der Anmeldung ist relativ schnell gestartet.

Ausgabe von journalctl -b -u user@114.service -u user@1000.service
pastebin/?mode=view&s=39925&highlight=text

Evtl. liegt das Problem an der Erkennung der Hardware.
Seit ich NetworkManager-wait-online.service deaktiviert habe, erscheint eine Meldung bezüglich eth0 (oder es liegt an dem letzten apt upgrade)

Ausgabe von dmesg
pastebin/?mode=view&s=39926

Auszug davon, die in der Ausgabe rot markiert sind:
[ 1.741294] iwlwifi 0000:04:00.0: api_index larger than supported by driver

[ 3.370787] r8169 0000:03:00.0 eth0: rtl_counters_cond == 1 (loop: 1000, delay: 10).
[ 3.421468] r8169 0000:03:00.0 eth0: rtl_counters_cond == 1 (loop: 1000, delay: 10).

Die Meldung bezüglich iwlwifi wird mir schon seit dem Upgrade angezeigt, allerdings hab ich bis jetzt nicht wirklich eine Lösung dafür gefunden.