Ubuntu Linux startet nach Hardwarewechsel langsamer

Hallo zusammen!

Ich nutze jetzt schon seit einiger Zeit Ubuntu Linux 18.04 LTS. Dies hatte ich bisher mit einem

  • ASRock Z77 Pro4 Mainboard
  • einer Intel Core i5-3570 CPU
  • 16-GB Kingston HyperX Genesis DDR3-1600 RAM
  • einer MSI N770 TwinFrozr (Geforce GTX770 2GB)
  • sowie zwei Samsung SSD 850 Evo und
  • einer Samsung SSD 830 Evo

betrieben. Die SSD 830 habe ich als Swap-SSD eingerichtet. Hier startete das System noch wunderbar flott und sogar schneller als mein altes, aufgeräumtes Windows 10.

Nun habe ich aber fast komplett meine Hardware gewechselt die nun wie folgt aussieht:

  • ASRock Z390 Phantom Gaming 4 Mainboard
  • Intel Core i5-9600KF CPU
  • 16-GB Kingston HyperX Fury Black DDR4-2666 RAM
  • ASUS GeForce RTX 2070 DUAL EVO-V2 8GB Grafikkarte

Der Rest, wie die SSDs, die Creative SoundBlaster X-Fi Titanium Fatal1ty und der LG BluRay-Brenner sind gleich geblieben.

Folgende Nachricht erhalte ich immer beim Booten von Linux:

Gave up waiting for suspend/resume device
/dev/sdb2: clean […]

Die zweite Zeile hatte ich vorher auch immer bekommen, was ja durch den TRIM-Cronjob normal ist. Die erste jedoch ist neu, womit ich überhaupt nichts anfangen kann, da ich das System eigentlich immer komplett runterfahre (rechts oben in der Leiste).

Ich habe schon etwas im Netz recherchiert, aber jetzt nichts wirklich hilfreiches gefunden. GeTRIMt wird bei den SSD nach wie vor und die Swap-SSD ist auch wieder eingerichtet. Allerdings habe ich u.a. zwei Befehle kennengelernt, die die Bootabfolge zeigen.

Hier hat sich mittels systemd-analyze blame kam folgendes heute raus:

 16.261s apt-daily-upgrade.service
  5.020s bolt.service
  4.923s NetworkManager-wait-online.service
  1.625s dev-sdb2.device
   954ms snapd.service
   738ms plymouth-quit-wait.service
   524ms systemd-journal-flush.service
   503ms dev-loop3.device
   500ms dev-loop4.device
   479ms dev-loop0.device
   471ms dev-loop2.device
   470ms dev-loop1.device
   464ms snap-core-8935.mount
   422ms dev-loop8.device
   422ms dev-loop7.device
   407ms dev-loop10.device
   406ms dev-loop6.device
   387ms snap-indicator\x2dsensors-261.mount
   383ms winbind.service
   380ms dev-loop11.device
   362ms dev-loop9.device
   351ms dev-loop13.device
   346ms motd-news.service

Der Befehl systemd-analyze critical-chain gibt mir folgendes aus:

The time after the unit is active or started is printed after the "@" character.
The time the unit takes to start is printed after the "+" character.

graphical.target @7.054s
└─multi-user.target @7.054s
  └─teamviewerd.service @7.015s +38ms
    └─network-online.target @7.015s
      └─NetworkManager-wait-online.service @2.091s +4.923s
        └─NetworkManager.service @1.996s +94ms
          └─dbus.service @1.969s
            └─basic.target @1.966s
              └─sockets.target @1.966s
                └─snapd.socket @1.962s +3ms
                  └─sysinit.target @1.962s
                    └─apparmor.service @1.841s +119ms
                      └─local-fs.target @1.841s
                        └─run-user-121.mount @6.894s
                          └─swap.target @1.682s
                            └─dev-disk-by\x2duuid-786a7283\x2d9f51\x2d4961\x2dbbb8\x2d3329adf77912.swap @1.639s +42
                              └─dev-disk-by\x2duuid-786a7283\x2d9f51\x2d4961\x2dbbb8\x2d3329adf77912.device @1.639s

Anbei auch noch meine fstab:

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/sda2 during installation
UUID=454b3874-3032-4cb6-9e5c-92a00ed53afb /               ext4    errors=remount-ro 0       1
# /boot/efi was on /dev/sda1 during installation
UUID=3CA5-DD5E  /boot/efi       vfat    umask=0077      0       1
#/swapfile                                 none            swap    sw              0       0
UUID=786a7283-9f51-4961-bbb8-3329adf77912 none swap sw 0 0
#second SSD
/dev/disk/by-uuid/d57e6c12-cfa3-4e89-986d-f1d20bae0b91 /mnt/d57e6c12-cfa3-4e89-986d-f1d20bae0b91 auto nosuid,nodev,nofail,x-gvfs-show 0 0

Ich würde ja gerne noch einen boot.log anhängen, leider weiß ich nicht ab wo in der Datei der aktuelle beginnt.

Treiber und Updates sind auch alle installiert. Im UEFI sind auch alle unnötigen Funktionen wie z.B. Thunderbolt deaktiviert.

Wäre super, wenn mir jemand helfen könnte.

1 Like

Ich hänge den Link zur boot.log noch mit hier an. :slight_smile:

Okay, habe das Problem doch selber gefunden. :smiley:

Und zwar war in der resume-Datei /etc/initramfs-tools/conf.d/resume noch die alte UUID der SWAP-Partition des alten Systems eingetragen. Hier muss man nur die UUID durch die neue aus der fstab ersetzen und den Befehl sudo update-initramfs -u ausführen und dann passt wieder alles. :slight_smile:

1 Like

Vermutlich hat dich das „gave up“ dann doch irgendwann drauf gebracht, dass da irgendwas versucht wurde, was nicht geklappt hat?

Ja, nämlich

Und da hat er offenbar versucht ein Resume zu machen aus einem (Swap-)Device, was nicht existierte. Und nach einer Zeit hat er den versuch halt abgebrochen.

Sebastian

Ich weiß. Nur der UP hat seltsamerweise vermutet, dass sich das „gave up“ auf das bezog, was danach kam. Und deshalb die eigentliche Fehlermeldung weder bemerkt noch hier zitiert.

Mag sein.

Auf der anderen Seite habe ich lange nicht so eine gute Fehlerbeschreibung gelesen, bei der der Autor vorher so gut nachgedacht, Informationen gesammelt hat, die neben einer guten Fehlerbeschreibung in eine äußerst gut lesbare Form gebracht hat.

So macht es doch Spaß zu helfen.

Großes Lob an @JoghurtBuddha!

2 Like

Da hake ich jetzt doch noch mal ein, um sicher zu sein, dass ich nichts falsch verstanden habe. Der UP schrieb:

Ich habe das so interpretiert:

/dev/sdb2: clean […]

Das kam schon immer, d.h. auch schon vor dem HW-Tausch und bevor der Rechner langsam gebootet hat. Ist auch normal, das ist die Ausgabe von fsck, das bei jedem Startvorgang ausgeführt wird.

Gave up waiting for suspend/resume device

Diese Meldung ist neu, d.h. kommt erst seit dem HW-.Austausch, und der UP vermutet, dass sie etwas mit dem Problem zu tun hat., Inzwischen ist auch klar, dass das tatsächlich so ist.

Da lag der UP doch völlig richtig mit seiner Vermutung?

Dieses Thema wurde automatisch 36 Stunden nach der letzten Antwort geschlossen. Es sind keine neuen Nachrichten mehr erlaubt.