Xubuntu: Nach Backup wiedereinspielen extrem langsamer Start

0815burner

Commander
Registriert
Nov. 2006
Beiträge
2.597
Hallo,

ich habe ein Tuxedo DC1506 laptop von 2016 und betreibe ein (Nicht-Tuxedo-)Xubuntu 20.04 auf einer 2.5" SSD und ein Win10 auf der m.2 SSD.
Die Tage habe ich mit Timeshift diverse Backup-Stände eingespielt, unter anderem um LibreOffice 7 und VLC 3.11 richtig zu installieren. Hatte das zuvor nicht sauber gemacht. Dabei ging wohl einiges schief. Zuerst war die Win SSD nicht mehr bootfähig. Da das Win nichts wichtiges enthält, habe ich also Win10 auf die m.2 SSD neu installiert, danach Xubuntu gebootet und Win wieder in grub integriert
Code:
sudo update-grub
.

Soweit so gut. Seitdem braucht mein Xubuntu aber ca. 2 Minuten zum Booten. Der dmesg-log zeigt folgende Auffälligkeit:
[ 6.443612] kernel: input: HDA Intel PCH Mic as /devices/pci0000:00/0000:00:1f.3/sound/card0/input33
[ 6.443653] kernel: input: HDA Intel PCH Front Headphone as /devices/pci0000:00/0000:00:1f.3/sound/card0/input34
[ 6.443690] kernel: input: HDA Intel PCH HDMI/DP,pcm=3 as /devices/pci0000:00/0000:00:1f.3/sound/card0/input35
[ 6.443725] kernel: input: HDA Intel PCH HDMI/DP,pcm=7 as /devices/pci0000:00/0000:00:1f.3/sound/card0/input36
[ 6.443762] kernel: input: HDA Intel PCH HDMI/DP,pcm=8 as /devices/pci0000:00/0000:00:1f.3/sound/card0/input37
[ 6.964230] kernel: Bluetooth: hci0: Waiting for firmware download to complete
[ 6.965270] kernel: Bluetooth: hci0: Firmware loaded in 1597635 usecs
[ 6.965304] kernel: Bluetooth: hci0: Waiting for device to boot
[ 6.976241] kernel: Bluetooth: hci0: Device booted in 10694 usecs
[ 6.976585] kernel: Bluetooth: hci0: Found Intel DDC parameters: intel/ibt-11-5.ddc
[ 6.980288] kernel: Bluetooth: hci0: Applying Intel DDC parameters completed
[ 93.691541] kernel: audit: type=1400 audit(1600015419.954:2): apparmor="STATUS" operation="profile_load" profile="unconfined" name="nvidia_modprobe" pid=1132 comm="apparmor_parser"
[ 93.691545] kernel: audit: type=1400 audit(1600015419.954:3): apparmor="STATUS" operation="profile_load" profile="unconfined" name="nvidia_modprobe//kmod" pid=1132 comm="apparmor_parser"
[ 93.691600] kernel: audit: type=1400 audit(1600015419.954:4): apparmor="STATUS" operation="profile_load" profile="unconfined" name="lsb_release" pid=1130 comm="apparmor_parser"
[ 93.691654] kernel: audit: type=1400 audit(1600015419.954:5): apparmor="STATUS" operation="profile_load" profile="unconfined" name="ippusbxd" pid=1127 comm="apparmor_parser"
[ 93.692030] kernel: audit: type=1400 audit(1600015419.954:6): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/lib/snapd/snap-confine" pid=1131 comm="apparmor_parser"
[ 93.692032] kernel: audit: type=1400 audit(1600015419.954:7): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/lib/snapd/snap-confine//mount-namespace-capture-helper" pid=1131 comm="apparmor_parser"
[ 93.692084] kernel: audit: type=1400 audit(1600015419.954:8): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/bin/man" pid=1125 comm="apparmor_parser"
[ 93.692086] kernel: audit: type=1400 audit(1600015419.954:9): apparmor="STATUS" operation="profile_load" profile="unconfined" name="man_filter" pid=1125 comm="apparmor_parser"
[ 93.692089] kernel: audit: type=1400 audit(1600015419.954:10): apparmor="STATUS" operation="profile_load" profile="unconfined" name="man_groff" pid=1125 comm="apparmor_parser"
[ 93.695199] kernel: audit: type=1400 audit(1600015419.958:11): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/sbin/cups-browsed" pid=1135 comm="apparmor_parser"
[ 94.021389] kernel: Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[ 94.021390] kernel: Bluetooth: BNEP filters: protocol multicast

Jemand eine Idee wie ich das Beheben kann? Kann ich den modprobe Treiber reparieren?
 
Da es sich um µs handelt und nicht um s, entspricht die angegebene Zeit im Log 1.5 Sekunden, ist also wahrscheinlich nicht für den langsamen Start verantwortlich.
Du könntest ja mal mit sudo systemd-analyze blame schauen ob da ein Übeltäter sichtbar wird
 
  • Gefällt mir
Reaktionen: 0815burner
Danke dir, ich habe das in der Tat in Sekunden interpretiert. sudo systemd-analyze blame zeeigt auch nichts auffallendes:
6.358s NetworkManager-wait-online.service >
5.882s fstrim.service >
2.178s systemd-backlight@backlight:intel_backlight.service >
2.150s man-db.service >
1.544s snapd.service >
1.493s gpu-manager.service >
1.460s plymouth-quit-wait.service >
1.263s dev-sda5.device >
714ms udisks2.service >
610ms blueman-mechanism.service >
472ms snap-snapd-7777.mount >
420ms snap-vlc-1700.mount >
405ms dev-loop0.device >
405ms networkd-dispatcher.service >
395ms dev-loop1.device >
390ms logrotate.service >
389ms snap-gnome\x2d3\x2d34\x2d1804-36.mount >
356ms dev-loop2.device >
352ms systemd-logind.service >
336ms accounts-daemon.service >
330ms snap-snapd-8790.mount >
319ms dev-loop3.device >
284ms dev-loop5.device >
281ms dev-loop4.device >
262ms snap-snap\x2dstore-454.mount >
lines 3-25
2.178s systemd-backlight@backlight:intel_backlight.service
2.150s man-db.service
1.544s snapd.service
1.493s gpu-manager.service
1.460s plymouth-quit-wait.service
1.263s dev-sda5.device
714ms udisks2.service
610ms blueman-mechanism.service
472ms snap-snapd-7777.mount
420ms snap-vlc-1700.mount
405ms dev-loop0.device
405ms networkd-dispatcher.service
395ms dev-loop1.device
390ms logrotate.service
389ms snap-gnome\x2d3\x2d34\x2d1804-36.mount
356ms dev-loop2.device
352ms systemd-logind.service
336ms accounts-daemon.service
330ms snap-snapd-8790.mount
319ms dev-loop3.device
284ms dev-loop5.device
281ms dev-loop4.device
262ms snap-snap\x2dstore-454.mount
249ms dev-loop6.device
238ms snap-gnome\x2d3\x2d34\x2d1804-33.mount
233ms avahi-daemon.service
227ms snap-gtk\x2dcommon\x2dthemes-1506.mount
224ms snap-snap\x2dstore-467.mount
223ms bluetooth.service
223ms NetworkManager.service
215ms polkit.service
212ms dev-loop8.device
211ms ModemManager.service
210ms lightdm.service
208ms upower.service
186ms snap-core18-1885.mount
183ms systemd-resolved.service
173ms thermald.service
169ms wpa_supplicant.service
167ms dev-loop7.device
156ms snap-core18-1754.mount
149ms systemd-journal-flush.service
142ms tlp.service
140ms dev-loop9.device
138ms apport.service
120ms e2scrub_reap.service
118ms grub-common.service
111ms systemd-udevd.service
105ms user@1000.service
105ms systemd-journald.service
101ms systemd-udev-trigger.service
95ms systemd-timesyncd.service
84ms keyboard-setup.service
84ms alsa-restore.service
71ms grub-initrd-fallback.service
71ms teamviewerd.service
66ms systemd-fsck@dev-disk-by\x2duuid-D754\x2d0425.service
66ms colord.service
64ms apparmor.service
58ms rsyslog.service
57ms systemd-fsck@dev-disk-by\x2duuid-6683357e\x2d6c96\x2d4ab2\x2d839d\x2d629673108f4c.service
55ms boot-efi.mount
54ms lm-sensors.service
54ms dev-disk-by\x2duuid-e736b1b4\x2d1902\x2d48f0\x2dad99\x2dded1f74f9b93.swap
48ms systemd-modules-load.service
45ms mnt-27141B503B8ACCB9.mount
40ms snapd.seeded.service
39ms kerneloops.service
39ms hddtemp.service
34ms pppd-dns.service
31ms snapd.apparmor.service
29ms systemd-sysusers.service
27ms systemd-random-seed.service
23ms plymouth-start.service
21ms systemd-tmpfiles-setup.service
16ms systemd-remount-fs.service
16ms systemd-sysctl.service
13ms modprobe@drm.service
13ms home.mount
13ms user-runtime-dir@1000.service
13ms dev-hugepages.mount
12ms setvtrgb.service
12ms systemd-tmpfiles-setup-dev.service
12ms dev-mqueue.mount
12ms plymouth-read-write.service
11ms systemd-user-sessions.service
11ms sys-kernel-debug.mount
11ms sys-kernel-tracing.mount
10ms systemd-update-utmp.service
9ms rtkit-daemon.service
9ms console-setup.service
8ms kmod-static-nodes.service
8ms systemd-update-utmp-runlevel.service
4ms sys-fs-fuse-connections.mount
3ms sys-kernel-config.mount
3ms ufw.service
1ms snapd.socket
198us clean-mount-point@media-ubuntuer-Seagate\x204TB.service
Noch eine Info:
Wöhrend der Bootvorgang hängt steht unter dem Xubuntu Logo: Strg+C drücken um laufende Dateisystem-Prüfungen abzubrechen. Passieren tut aber auch mit Strg+C nichts.
 
Ah ok, dann hat das System also erkannt, dass irgendwas mit der Partition passiert ist (sie wurde ja geklont) und versucht dann das zu überprüfen, du könntest testweise im gestarteten System mit GParted eine Überprüfung starten und somit die Partition zu "reparieren" und um den "möglicherweise beschädigt" Status zu entfernen.
Wenn du beim Starten das Logo siehst kannst du übrigens Esc drücken um Plymouth auszublenden und um zu sehen was systemd beim Starten macht, da müsste man auch erkennen können ob das System noch bei einem anderen Schritt hängen bleibt
 
Der Tipp mit ESC war hilfreich. Es läuft ein 90s start job für die UUID. Ist bestimmt die Win-Partition, die nicht mehr zum Ubuntu Backup passt. Schaue ich mir mal an.

Edit: Genau so war es. "Falsche" Partition in der etc/fstab auskommentiert. Schon geht es. Eigentlich ein Klassiker. Dachte aber fälschlicherweise, das Grub-Update würde das schnakeln.

Danke für deine Hilfe.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: or2k
Zurück
Oben