Nach SSD-Umzug: 32 Sekunden Untätigkeit beim Boot

[7Saturn]

Ich habe vor einigen Tagen mein System von einer 500 GB auf eine 1 TB SSD umgezogen. Mittel der Wahl war hier ein noch rum liegendes Acronis True Image 2015, die Boot-CD davon. Hat so weit auch gut geklappt, bis auf eine Macke, deren Ursache ich nicht eingekreist bekomme: Der Boot hat zwischen drin eine Verzögerung von über einer halben Minute, in der das System offenbar einfach gar nichts tut. Und zwar ziemlich weit am Anfang. Das bootchart dazu sieht so aus:

dmesg zeigt dazu parallel bei denselben Zeiten auch eine Lücke:

Code: Alles auswählen

[...]
[    3.211087] usb 1-1.6.4: new full-speed USB device number 7 using ehci-pci
[    3.342958] usb 1-1.6.4: New USB device found, idVendor=258a, idProduct=0016
[    3.342962] usb 1-1.6.4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[    3.342964] usb 1-1.6.4: Product: Usb Gaming Keyboard
[    3.342965] usb 1-1.6.4: Manufacturer: BY Tech
[    3.344897] input: BY Tech Usb Gaming Keyboard as /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.6/1-1.6.4/1-1.6.4:1.0/0003:258A:0016.0006/input/input7
[    3.403382] hid-generic 0003:258A:0016.0006: input,hidraw5: USB HID v1.11 Keyboard [BY Tech Usb Gaming Keyboard] on usb-0000:00:1a.0-1.6.4/input0
[    3.410290] input: BY Tech Usb Gaming Keyboard as /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.6/1-1.6.4/1-1.6.4:1.1/0003:258A:0016.0007/input/input8
[    3.467465] hid-generic 0003:258A:0016.0007: input,hiddev0,hidraw6: USB HID v1.11 Keyboard [BY Tech Usb Gaming Keyboard] on usb-0000:00:1a.0-1.6.4/input1
[   32.797773] EXT4-fs (sda5): mounted filesystem with writeback data mode. Opts: (null)
[   33.107403] bootchart continuing boot
[   33.154045] ip_tables: (C) 2000-2006 Netfilter Core Team
[   33.160066] systemd[1]: systemd 232 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN)
[   33.160332] systemd[1]: Detected architecture x86-64.
[...]

(Frage gleich hierzu: Der Zeitstempel von dmesg gibt an, wann der Schritt abgeschlossen, oder wann er gestartet wurde?) Was ich schon mal gecheckt habe ist, ob bei dem Umzug irgendwas mit dem Alignment daneben gegangen ist, aber da gibt parted mir keine Probleme aus. Alle Partitionen sind richtig alignt.

Was läuft da eigentlich (nicht) ab? Wo kann ich noch ansetzen? Von ca. 1 Minute Bootzeit die Hälfte nichts, die vorher auch nicht da war, stört mich schon ein wenig.

[willy4711]

Vielleicht mal deinstallieren ? Hab das nicht installiert. Aber vom Log und der Beschreibung scheint das zu passen.
systemd-bootchart

After collecting a certain amount of data (usually 15–30 seconds, default 20s)
the logging stops and a graph is generated from the logged information. This
graph contains vital clues as to which resources are being used, in which
order, and where possible problems exist in the startup sequence of the
system. It is essentially a more detailed version of the systemd-analyze plot
function.

Also entweder hübsche Grafik oder schnelles Booten?

Von ca. 1 Minute Bootzeit die Hälfte nichts, die vorher auch nicht da war, stört mich schon ein wenig.

Mein System (Samsung SSD 850 PRO) ist ab Grub in 12 s da.
Abgesehen von bootchart scheint sich da einiges andere noch zu viel Zeit zu lassen.

Code: Alles auswählen

systemd-analyze 
Startup finished in 4.287s (kernel) + 8.537s (userspace) = 12.824s 
graphical.target reached after 2.611s in userspace

[DeletedUserReAsG]

Das bootchart dazu sieht so aus:

Leider kann man darauf so gar nix lesen. Wird das nicht (wahlweise) als SVG ausgegeben? Damit könnte man es so skalieren, dass man damit sogar was anfangen kann.

[smutbert]

[…]
(Frage gleich hierzu: Der Zeitstempel von dmesg gibt an, wann der Schritt abgeschlossen, oder wann er gestartet wurde?) Was ich schon mal gecheckt habe ist, ob bei dem Umzug irgendwas mit dem Alignment daneben gegangen ist, aber da gibt parted mir keine Probleme aus. Alle Partitionen sind richtig alignt.
[…]

Der Zeitstempel gibt an wann die Meldungen vom Kernel und seinen Modulen ausgegeben worden sind. Nachdem das meistens Meldungen von Erfolg oder Fehlschlag sind, würde ich meinen die meisten der Meldungen werden nachdem irgendetwas passiert ist ausgegeben, aber auf das was im Userspace passiert kannst du aus dmesg nur unzureichend schließen.

Ich würde einmal mit

Code: Alles auswählen

# systemd-analyze blame
# systemd-analyze critical-chain

anfangen, um nachzusehen was im Userspace (möglicherweise unnötig) lange dauert. Mit dem Alignment können solche Verzögerungen meiner Meinung aber normalerweise nichts zu tun haben.

[jph]

Was läuft da eigentlich (nicht) ab? Wo kann ich noch ansetzen? Von ca. 1 Minute Bootzeit die Hälfte nichts, die vorher auch nicht da war, stört mich schon ein wenig.

Ins Blaue geraten: du identifizierst die Swap-Partition anhand ihrer UUID und die hat sich beim Umzug geändert. Musst du in /etc/fstab und /etc/initramfs-tools/conf.d/resume ändern und anschließend mit update-initramfs -u -k all das initramfs neu bauen. Die Änderung für das initramfs wird gerne vergessen.

Siehe auch hier: https://wiki.debianforum.de/Grub_repari ... uert_lange

[7Saturn]

@willy4711 und @smutbert: Das mit systemd-analyze hatte ich auch schon gemacht, was ähnliche Werte wie bei willy4711 raus schmiss. Weshalb ich mich eben gewundert habe, warum niemand was damit zu tun zu haben scheint. Die Wartezeit geht ja schon vor bootchart los. Systemd hat da auch nichts nützliches ergeben, in der Kette tauchten die 30 Sek. nicht mal auf. Trotzdem danke für den Hinweis.

@niemand: Shit, du hast recht. Der Witz ist: Ich dachte, baust ein 72 dpi PNG, das sieht hier auch gut lesbar aus und braucht nicht 5 MB. Aber anscheinend fummelt die Forensoftware vorher nochmal dran rum, weshalb das dann jetzt hier so verwaschen aussieht. Muss ich mir merken, dass meine Grafiken hier ggf. noch »nachretuschiert« werden. Ist aber auch egal, das Problem ist gelöst:

Ins Blaue geraten: du identifizierst die Swap-Partition anhand ihrer UUID und die hat sich beim Umzug geändert. Musst du in /etc/fstab und /etc/initramfs-tools/conf.d/resume ändern und anschließend mit update-initramfs -u -k all das initramfs neu bauen. Die Änderung für das initramfs wird gerne vergessen.

Volltreffer! Danke, das hat geholfen. In der fstab war's schon drin. In resume nicht. Jetzt will ich's aber genauer wissen...

Beim stupiden Klonen scheint die UUID ja unverändert zu bleiben. Ich hätte jetzt in meiner Naivität erwartet, dass Acronis nicht an den UUIDs rum fummelt. Konkreter gefragt, hängt die UUID bei swap von etwas anderem ab? Bei EXT4-Partitionen kann ich sie mit geeigneten Mitteln ja sogar selbst festlegen, wenn ich das möchte. Passiert bei swap noch was anderes? Und wenn ja, warum?