langer Bootvorgang nach grub vor LVM-PW-Eingabe

[pagro]

Hi Community,

habe endlich Debian kompatible Hardware (AMD Ryzen 5 1400, AMD Radeon RX 580) besorgt, nachdem das Gefrickel mit NVIDIA/Optimus kein Ergebnis gebracht hat. Ein klassischer Rechner, fühlt sich gut an! Nach Installation der entsprechenden non-free Treiber läuft es auch wunderbar, bis auf das im Betreff genannte Problem: Es dauert ca. eine Minute, bis ich nach grub ein Bild bekomme, genauer: Nachdem ich in grub den Start von Debian bestätigt habe, bekomme ich einen schwarzen Bildschirm, und nach ca. einer Minute erscheinen dann die Zeilen, in denen ich mein Passwort zur LVM-Entschlüsselung der Festplatte aufgefordert werde (ich vermute, die Zeilen stehen dort bereits einige Zeit, werden mir nur nicht dargestellt). Hier der Output von dmesg, der Menschen mit Ahnung sicherlich weiterhilft (in diesem Fall bin ich keiner davon):

dmesg

Vielen Dank im Voraus!

[pagro]

Oha, vielleicht hab ich was verballert bei den Treibern? HardInfo zeigt unter "Graphics":

Code: Alles auswählen

1920x1080
(Unknown)
The X.Org Foundation

Da sollte vermutlich die Radeon angezeigt werden!?

Edit: Bin hiernach vorgegangen.

[Livingston]

Bin mal durch den dmesg-Output durchgeklettert. Dort fiel mir folgendes auf:

Code: Alles auswählen

[    2.787012] [drm] Cannot find any crtc or sizes
[    2.790193] [drm] Initialized amdgpu 3.27.0 20150101 for 0000:09:00.0 on minor 0

Das sieht auf dem ersten Blick so aus, als würde die AMD-Karte richtig erkannt werden, aber der Monitor nicht.
Dann fallen die riesigen zeitlichen Lücken auf, die wahrscheinlich mit der Grafik zu tun haben.

Zur weiteren Untersuchung könnten wir hier noch die Ausgaben von lspci -v und den Inhalt von /var/log/Xorg.0.log gebrauchen. X ist immer sehr gesprächig, und da gibt's wohl am ehesten Hinweise, was los ist. lspci ist wichtig, um die Hardwarefeinheiten herauszukitzeln.

Ansonsten liefert journalctl -b noch allgemeine Logs seit dem letzten Boot. Am besten packste mal den ganzen Krempel nach nopaste.

[pagro]

Bin mal durch den dmesg-Output durchgeklettert.

Dafür schon mal ein herzliches Dankeschön!

Ich bin erst durch deine Antwort wieder daran erinnert worden, dass ja standardmäßig Wayland aktiviert ist (Randbemerkung/Frage am Rand: was zum heiligen Birnbaum bringt denn bitte Wayland? Gibt es da einen ehrlichen Mehrwert, oder ist das einfach nur cool und angesagt? Scheint mir, als müsste man das immer deaktivieren bzw. unter X starten, wenn man vernünftig arbeiten will. Muss mich mal belesen) und musste dementsprechend mich abmelden, neu anmelden (unter X, klar) und dann rebooten. Dieses Mal ein ganz normaler Bootvorgang. Ob die Maschine halt schon heiß war? Ob Wayland das Problem verursacht? Ich weiß es nicht. Aber hier trotzdem mal die erbetenen Outputs.

lspci -v
Xorg.0.log
journalctl -b (ich hoffe, 2.000 Zeilen reichen für's Erste )

[Livingston]

Moinmoin,

na dann mal der Reihe nach:
1. lspci ab Zeile 187:

Code: Alles auswählen

 09:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Ellesmere HDMI Audio [Radeon RX 470/480 / 570/580/590]
        Subsystem: Hewlett-Packard Company Ellesmere HDMI Audio [Radeon RX 470/480 / 570/580/590]

Sieht doch schon mal nett aus. Sollte in Buster voll unterstützt werden und keine Probleme machen. (Andere Meinungen?)

2. Xorg:

Code: Alles auswählen

[    58.230] (EE) Unable to find a valid framebuffer device
[    58.230] (WW) Falling back to old probe method for fbdev
...
[    58.231] (EE) Screen 0 deleted because of no matching config section.
[    58.231] (II) UnloadModule: "modesetting"
[    58.231] (EE) Screen 0 deleted because of no matching config section.
[    58.231] (II) UnloadModule: "fbdev"
[    58.231] (II) UnloadSubModule: "fbdevhw"
[    58.231] (EE)
Fatal server error:
[    58.231] (EE) Cannot run in framebuffer mode. Please specify busIDs        for all framebuffer devices
[    58.233] (EE) Server terminated with error (1). Closing log file.

Ein gezielter Blick auf Warnungen (WW) und Errors(EE) sagt, dass es Probleme mit dem Framebuffer und dem modesetting gibt.
Ab hier bin ich nicht mehr so richtig dabei, da ich mich selbst eher mit Intel- und Nvidia-Karten herumschlage. Zum Hintergrund kann ich noch ein bissel was beisteuern: modesetting beschreibt das Konfigurieren der Grafikkarte. Für AMD-/ATI-Geräte wird das üblicherweise auf eine genormte Art und Weise vom Linux-Kernel vorgenommen (KMS - Kernel Mode Setting). Eigentlich ganz cool. Mit NVIDIA geht das z.B. nicht und da kann manchmal ganz schön Handarbeit beim Parameter-Einstellen anstehen. ATI/AMD unterstützen aber KMS und sollten stressfrei sein.

Hier ist der Punkt, wo ich mal beim Rest der Community um Hilfe schreie, denn ab hier habe ich kaum Erfahrung, jedenfalls nicht mit Deiner Grafikkarte.

Zu Wayland: Wenn's endlich mal rund läuft, ist es ein gewaltiger Fortschritt zu X, das schon fast 40 Jahre auf dem Buckel hat, und das entstand, als Pixel noch punktweise mit dem Prozessor berechnet wurden. Leider hat Wayland immer noch ein paar Macken. Wie es mit GNOME3 zusammenspielt... ist leider auch nicht meine Baustelle. Ich mag's eher leichtgewichtig und arbeite mit Openbox. Aber da kann hier sicher im Forum wer anders noch was zu sagen.

[willy4711]

Für die Grafik wäre mal hilfreich die Ausgabe von

Code: Alles auswählen

lspci -nnk | grep VGA -A4

Hilfreich ist auch häufig die Installation von haveged

Edit: Bin hiernach vorgegangen.
Nach oben

Heißt das, du hast die Pakete gemäß Punkt 4 installiert ?
Sources.list um contrib non-free erweitert ?

Edit:
unter X11 Startet die Maschine normal ?

Mal die Ausgabe von

Code: Alles auswählen

dpkg -l *amd*|grep ii

[pagro]

Hier ist der Punkt, wo ich mal beim Rest der Community um Hilfe schreie, denn ab hier habe ich kaum Erfahrung, jedenfalls nicht mit Deiner Grafikkarte.

Ganz vielen Dank für deinen Einsatz!!

Code: Alles auswählen

lspci -nnk | grep VGA -A4
09:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Ellesmere [Radeon RX 470/480] [1002:67df] (rev c3)
	Subsystem: Hewlett-Packard Company Ellesmere [Radeon RX 470/480/570/570X/580/580X/590] [103c:83c2]
	Kernel driver in use: amdgpu
	Kernel modules: amdgpu
09:00.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] Ellesmere HDMI Audio [Radeon RX 470/480 / 570/580/590] [1002:aaf0]

Hilfreich ist auch häufig die Installation von haveged

Habe ich installiert, und nun?

Heißt das, du hast die Pakete gemäß Punkt 4 installiert ?

32-bit support habe ich nicht installiert, habe doch 64-bit!?!?

Sources.list um contrib non-free erweitert ?

Jau.

unter X11 Startet die Maschine normal ?

Es sieht so aus, auch heute morgen gab es einen ganz normalen Bootvorgang.

Code: Alles auswählen

dpkg -l *amd*|grep ii
ii  amd64-microcode                      3.20181128.1                      amd64        Processor microcode firmware for AMD CPUs
ii  firmware-amd-graphics                20190114-2                        all          Binary firmware for AMD/ATI graphics chips
ii  fwupd-amd64-signed                   1.2.13+2                          amd64        Tools to manage UEFI firmware updates (signed)
ii  grub-efi-amd64                       2.02+dfsg1-20+deb10u2             amd64        GRand Unified Bootloader, version 2 (EFI-AMD64 version)
ii  grub-efi-amd64-bin                   2.02+dfsg1-20+deb10u2             amd64        GRand Unified Bootloader, version 2 (EFI-AMD64 modules)
ii  grub-efi-amd64-signed                1+2.02+dfsg1+20+deb10u2           amd64        GRand Unified Bootloader, version 2 (amd64 UEFI signed by Debian)
ii  libamd2:amd64                        1:5.4.0+dfsg-1                    amd64        approximate minimum degree ordering library for sparse matrices
ii  libcamd2:amd64                       1:5.4.0+dfsg-1                    amd64        symmetric approximate minimum degree library for sparse matrices
ii  libccolamd2:amd64                    1:5.4.0+dfsg-1                    amd64        constrained column approximate library for sparse matrices
ii  libcolamd2:amd64                     1:5.4.0+dfsg-1                    amd64        column approximate minimum degree ordering library for sparse matrices
ii  libdrm-amdgpu1:amd64                 2.4.97-1                          amd64        Userspace interface to amdgpu-specific kernel DRM services -- runtime
ii  libteamdctl0:amd64                   1.28-1                            amd64        library for communication with `teamd` process
ii  linux-image-4.19.0-10-amd64          4.19.132-1                        amd64        Linux 4.19 for 64-bit PCs (signed)
ii  linux-image-amd64                    4.19+105+deb10u5                  amd64        Linux for 64-bit PCs (meta-package)
ii  shim-helpers-amd64-signed            1+15+1533136590.3beb971+7+deb10u1 amd64        boot loader to chain-load signed boot loaders (signed by Debian)
ii  xserver-xorg-video-amdgpu            18.1.99+git20190207-1             amd64        X.Org X server -- AMDGPU display driver

[Tintom]

Ob Wayland das Problem verursacht?

Ein aktueller Kernel wirkt bei Wayland manchmal wahre Wunder. Allerdings sofern es unter Xorg läuft kannst du auch vorerst dabei belassen.

[KP97]

Mit

Code: Alles auswählen

systemd-analyze blame

kannst Du die einzelnen Startzeiten der Dienste ansehen.
Du solltest Dich generell mit systemd und journalctl beschäftigen. dmesg ist veraltet und stammt noch vom alten sysvinit System.

[pagro]

Ein aktueller Kernel wirkt bei Wayland manchmal wahre Wunder. Allerdings sofern es unter Xorg läuft kannst du auch vorerst dabei belassen.

Aktueller als Stable meinst du?

Code: Alles auswählen

systemd-analyze blame
         21.267s plymouth-quit-wait.service
          7.687s NetworkManager-wait-online.service
           613ms systemd-logind.service
           373ms dev-mapper-debaulian\x2d\x2dvg\x2droot.device
           277ms udisks2.service
           237ms fwupd.service
           195ms upower.service
           164ms systemd-timesyncd.service
           138ms systemd-journald.service
           109ms mnt-DATA.mount
            98ms systemd-fsck@dev-disk-by\x2duuid-D2E7\x2d6994.service
            92ms lvm2-pvscan@254:0.service
            87ms lvm2-monitor.service
            85ms systemd-fsck@dev-disk-by\x2duuid-6409ead5\x2dc7e0\x2d4575\x2d8c
            81ms user@1000.service
            78ms NetworkManager.service
            76ms ModemManager.service
            72ms colord.service
            69ms apparmor.service
            64ms systemd-cryptsetup@nvme0n1p3_crypt.service
            61ms accounts-daemon.service
            55ms systemd-udev-trigger.service
            51ms avahi-daemon.service

Na da haben wir doch den Schuldigen: Plymouth! Und ich habe noch nicht einmal den grafischen Bootloader installiert! Das mache ich nämlich eigentlich gerne, aber jetzt bin ich unsicher. Ich möchte den Bootvorgang beschleunigen (und ja, das passiert doch auch unter X, wie gerade festgestellt)! Ich denke, sowohl Plymouth als auch den NetworkManager muss ich da angreifen - aber wie? Vielen Dank auf jeden Fall für diesen Befehl!

Du solltest Dich generell mit systemd und journalctl beschäftigen. dmesg ist veraltet und stammt noch vom alten sysvinit System.

Hast du da spezielle Lektüre zu empfehlen, oder lese ich einfach die Wiki-Artikel? (Bei systemd schockiert mich der Artikel direkt; Googlecode drin!?)

[rhHeini]

Installier mal die firmware-amd-graphics aus Buster backports und den 5.6er oder 5.7er Kernel und schau ob das einen Unterschied macht.

Rolf

[KP97]

Diese Services brauchst Du nicht:

NetworkManager-wait-online.service
ModemManager.service

Wenn Du Plymouth deinstallieren kannst, mach das. Dann ist auch der Service weg.
Ich habe kein Plymouth installiert, daher kann ich das nicht genau sagen.
Falls ein Deinstallieren zuviel Abhängigkeiten hat, versuche den Service zu disablen
mit folgendem Befehl als root:

Code: Alles auswählen

systemctl disable plymouth-quit-wait.service

Das gilt auch für die anderen Services.

man systemd
man journalctl

Links zu systemd:
https://wiki.archlinux.de/title/Systemd
https://wiki.ubuntuusers.de/systemd/
https://www.freedesktop.org/wiki/Software/systemd/

[pagro]

Installier mal die firmware-amd-graphics aus Buster backports und un den 5.6er oder 5.7er Kernel und schau ob das einen Unterschied macht.

Ehm. Das möchte ich erst mal nicht machen und bei Stable bleiben. Stecke nicht genug in der Materie, um da jetzt solche Sprünge zu machen. Aber danke für den Hinweis!

Falls ein Deinstallieren zuviel Abhängigkeiten hat

Woran erkenne ich "zu viele" Abhängigkeiten?

Das gilt auch für die anderen Services.

Plural? Außer dem NetworkManager noch was?

Edit: Hab den ModemManager übersehen.

[pagro]

Und ich kann die Services sicher deinstallieren? Habe in diesem Link gelesen, dass er besser aktiviert sein sollte, weil es sonst kein Netzwerk für systemd gibt und dass er außerdem nicht zwangsläufig die Bootzeit verlängert. Ist das bei Debian anders?

Und das mit Plymouth finde ich merkwürdig. Das ist doch dazu da, um einen grafischen Bootvorgang zu haben, was ich sowieso einrichten sollte. Aber bisher musste ich das immer installieren und nach dieser Anleitung konfigurieren, wollte das eigentlich wieder tun. Was ist denn dann bereits installiert? Nach wie vor sind die Bootvorgänge scheinbar willkürlich kurz oder lang.

[willy4711]

Ich bin der Meinung, wenn das eine noch nicht modifizierte Standard Installation ist (???) , sollte das ohne die Deinstallation von
normalerweise vorhanden Diensten funktionieren. Das Problem müsste dann woanders liegen.

Habe mir nochmal deine dmesg Ausgabe angesehen: Da gibt es eine Pause nach 5 Sek, und wenn ich den Timestamp
richtig verstehe (?) , ist dann erstmal 4 Minuten Pause, was ja nach deinen Aussagen nicht sein kann (ca. 1 Minute)

Code: Alles auswählen

    4.809423] usbcore: registered new interface driver uas
[    4.810103] ums-realtek 1-9:1.0: USB Mass Storage device detected
[    4.816204] scsi host12: usb-storage 1-9:1.0
[    4.816299] usbcore: registered new interface driver ums-realtek
[    5.829738] scsi 12:0:0:0: Direct-Access     Generic- SD/MMC/MS PRO    1.00 PQ: 0 ANSI: 4
[    5.836253] sd 12:0:0:0: [sdb] Attached SCSI removable disk
[  262.393242] NET: Registered protocol family 38
[  384.861543] [drm] fb mappable at 0xE0828000
[  384.861545] [drm] vram apper at 0xE0000000
[  384.861545] [drm] size 8294400
[  384.861546] [drm] fb depth is 24
[  384.861546] [drm]    pitch is 7680
[  384.861659] fbcon: amdgpudrmfb (fb0) is primary device
[  384.900173] Console: switching to colour frame buffer device 240x67
[  384.920243] amdgpu 0000:09:00.0: fb0: amdgpudrmfb frame buffer device
[  401.556320] PM: Image not found (code -22)
[  401.676721] EXT4-fs (dm-1): mounted filesystem with ordered data mode. Opts: (null)
[  401.798795] systemd[1]: Inserted module 'autofs4'
[  402.005283] systemd[1]: systemd 241 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN -PCRE2 default-hierarchy=hybrid)
[  402.024420] systemd[1]: Detected architecture x86-64.
[  402.031243] systemd[1]: Set hostname to <debaulian>.
[  402.105920] systemd[1]: Listening on initctl Compatibility Named Pipe.
[  402.105974] systemd[1]: Reached target Remote File Systems.
[  402.106321] systemd[1]: Set up automount Arbitrary Executable File Formats File System Automount Point.
[  402.108171] systemd[1]: Created slice system-getty.slice.
[  402.108232] systemd[1]: Listening on fsck to fsckd communication Socket.
[  402.108244] systemd[1]: Reached target User and Group Name Lookups.
[  402.108276] systemd[1]: Started Forward Password Requests to Wall Directory Watch.
[  402.121807] EXT4-fs (dm-1): re-mounted. Opts: errors=remount-ro

Dein Journalausdruck gibt das auch nicht her. der geht von 20:05:16 bis 20:05:22 also 8 Sekunden.

Es wäre also mal sinnvoll, nochmal direkt nach einem Bootvorgang das Journal mit

Code: Alles auswählen

journalctl -b >irgendeinen Datei

auszugeben und dann gezielt in einem Editor nach der Zeitlücke zu suchen.
Umleitung deswegen, da bei so ellenlangen Ausgaben das Journal recht unübersichtlich wird und auch Lücken und Doppeltes
in der Ausgabe erscheinen. Jedenfalls bei mir.

[pagro]

Bitte ein Beispiel für eine Datei!

[willy4711]

Falls du damit plymouth meinst:

Code: Alles auswählen

apt purge plymouth

Abhängigkeiten werden dann angezeigt, wenn du den Befehl eingibst. Apt zeigt dir dann an, was (in Abhängigkeit) noch so alles deinstalliert werden soll.
Kannst du dann bestätigen oder auch nicht. Und falls du unsicher bist hier die Ausgabe erstmal einstellen.

[pagro]

Code: Alles auswählen

journalctl -b >irgendeinen Datei

Ich meinte hier bitte ein Beispiel für eine Datei nennen. Oder soll ich willkürlich eine aussuchen? Wenn ja, aus welchem Verzeichnis.

Naja und Plymouth...mich wundert, dass da was installiert ist, obwohl ich ja ganz offensichtlich keinen grafischen Bootbildschirm habe - aber ich möchte einen und hatte vorher nie Probleme mit Plymouth, bin mir jetzt aber unsicher, ob ich einfach nach der genannten Anleitung das Installieren soll oder inwiefern es dann zu Problemen mit bereits installiertem Kram kommt bzw. ob Plymouth der Grund ist für die lange Wartezeit.

wenn ich den Timestamp richtig verstehe (?) , ist dann erstmal 4 Minuten Pause, was ja nach deinen Aussagen nicht sein kann (ca. 1 Minute)

Wie gesagt: Die Länge des Bootens ist so willkürlich dass ich auch 4 Min nicht ausschließen kann.

[MSfree]

Vielleicht hilft ja auch die Ausgabe von

Code: Alles auswählen

systemd-analyze plot > output.svg

weiter.

output.svg kannst du dann auch hier nach NoPaste laden.

[pagro]

SVG wird von NoPaste nicht akzeptiert, aber hier ist es trotzdem zum DL:

https://upload.disroot.org/r/5cHt9ZvP#r ... UbuQbpVm4=

[willy4711]

Wie gesagt: Die Länge des Bootens ist so willkürlich dass ich auch 4 Min nicht ausschließen kann.

Ich kann mir an sich nicht vorstellen, dass bei gleichbleibenden Bedingungen (USB- Laufwerke angesteckt? usw) dermaßen
unterschiedliche Bootzeiten zustande kommen.

[pagro]

Und ich kann es nicht erklären!
Aber nein, nix ab- oder dran geklemmt.

[willy4711]

Naja und Plymouth...mich wundert, dass da was installiert ist, obwohl ich ja ganz offensichtlich keinen grafischen Bootbildschirm habe - aber ich möchte einen und hatte vorher nie Probleme mit Plymouth, bin mir jetzt aber unsicher, ob ich einfach nach der genannten Anleitung das Installieren soll oder inwiefern es dann zu Problemen mit bereits installiertem Kram kommt bzw. ob Plymouth der Grund ist für die lange Wartezeit.

Ich habe Plymouth nicht installiert, weiss auch gar nicht wozu man das braucht.
Für Grub habe ich ein schönes Theme installiert.
Für Lightdm (Displaymanager wie GDM) ein eigenes Hintergrundbild
Nach dem Login-Schirm von Lightdm dauert es genau 2 Sekunden bis meine Oberfläche vorhanden ist.
Der gesamte Bootvorgang dauert ab Grub 8 Sekunden.
Ich würde erstmal wie vorgeschlagen vorgehen, und ein vernünftig startendes System herstellen.
Dazu bräuchten wir aber erstmal noch einmal die Ausgabe vom Journal (wie oben beschrieben)
mit vielleicht erstmal 10 Zeilen vor und nach dem Zeitsprung, den man im Journal gut sehen kann.

Spielen kann man immer noch.

[pagro]

Plymouth zu deinstallieren scheint konfliktfrei zu sein, aber ich bin jetzt ganz vorsichtig, hier die Ausgabe:

Code: Alles auswählen

apt purge plymouth
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.       
Statusinformationen werden eingelesen.... Fertig
Das folgende Paket wurde automatisch installiert und wird nicht mehr benötigt:
  libplymouth4
Verwenden Sie »apt autoremove«, um es zu entfernen.
Die folgenden Pakete werden ENTFERNT:
  plymouth* plymouth-label*
0 aktualisiert, 0 neu installiert, 2 zu entfernen und 0 nicht aktualisiert.
Nach dieser Operation werden 534 kB Plattenplatz freigegeben.
Möchten Sie fortfahren? [J/n] 

Das journal möchte ich sehr gerne bereitstellen, aber ich verstehe noch nicht ganz, was ich anstatt ">irgendeinen Datei" eingeben soll.

Und nochmal zu Plymouth: Also grub selbst customizen (ohje was für ein herrlichhässliches Anglizismus) und du empfiehlst lightdm statt GDM? Das ersetzt Plymouth wunderbar und man hat weniger Code, versteh ich das richtig?

[MSfree]

Ich habe Plymouth nicht installiert, weiss auch gar nicht wozu man das braucht.

Installiert ist das bei mir zwar, schlägt bei mir aber nur mit ein paar Milisekunden ins Gewicht:

Code: Alles auswählen

systemd-analyze blame | grep plymout
            48ms plymouth-quit-wait.service
            41ms plymouth-start.service
            24ms plymouth-read-write.service

Plymouth wird wohl bei der Standardinstallation, wenn man die nicht absolut frugal durchführt, mit installiert.

Nach dem Login-Schirm von Lightdm dauert es genau 2 Sekunden bis meine Oberfläche vorhanden ist.
Der gesamte Bootvorgang dauert ab Grub 8 Sekunden.

Naja, du hast ja auch einen superschnellen Rechner. Mein Q9300-Oldtimer hier liegt bei:

Code: Alles auswählen

systemd-analyze 
Startup finished in 4.738s (kernel) + 8.478s (userspace) = 13.216s 
graphical.target reached after 8.462s in userspace

Und hier mal was zum Vergleich. Mein alter EeePC mit seiner 630MHz Einkern-CPU bringt:

Code: Alles auswählen

systemd-analyze
Startup finished in 12.315s (kernel) + 40.664s (userspace) = 52.980s 
graphical.target reached after 15.288s in userspace

systemd-analyze blame
         18.994s apt-daily.service
         13.997s logrotate.service
          8.027s apt-daily-upgrade.service
          7.541s dev-sda1.device
          5.083s systemd-journald.service
          3.643s keyboard-setup.service
          2.371s apparmor.service
          2.134s wicd.service
          2.080s systemd-udev-trigger.service
          1.595s ssh.service
          1.423s systemd-rfkill.service
          1.283s networking.service
          1.071s rsyslog.service
          1.013s systemd-logind.service
           994ms systemd-journal-flush.service
           870ms wpa_supplicant.service
           517ms polkit.service
           516ms systemd-udevd.service
           504ms user@1000.service
           458ms systemd-modules-load.service
           422ms sys-kernel-debug.mount
           409ms systemd-remount-fs.service
           386ms systemd-tmpfiles-setup.service
           385ms dev-mqueue.mount
           355ms systemd-backlight@backlight:eeepc.service
           307ms systemd-timesyncd.service
           306ms systemd-update-utmp-runlevel.service
           298ms systemd-sysusers.service
           295ms console-setup.service
           283ms systemd-sysctl.service
           238ms systemd-user-sessions.service
           237ms systemd-backlight@backlight:intel_backlight.service
           236ms kmod-static-nodes.service
           234ms systemd-tmpfiles-setup-dev.service
           225ms dev-hugepages.mount
           220ms systemd-random-seed.service
           143ms user-runtime-dir@1000.service
           130ms systemd-update-utmp.service
            93ms ifupdown-pre.service

länger sollte es also wirklich nicht dauern.