neue C-Blues Installation bootet sehr langsam

jure · 2021/06/16, 16:00:17

Hallo zusammen,

ich habe das neue C-Blues KDE (danke dafür!) auf meinem "alten", also bisherigen PC ohne Probleme auf eine Toshiba 2,5" 500GB ((MQ01ABF050) installiert. (MBR/grub)
Das System bootet SEHR langsam, ca 50sec bis zum sddm login und ges ca 1:20min bis zum desktop.

Die sehr alte KDE Installation auf dem selben PC auf ner 250GB SSD braucht bis zum desktop ca 35sec...

Hat vielleicht jemand von euch eine Idee, einen Tipp, an was das liegen kann, bzw nach was ich schauen kann?

Wenn weitere Infos gebraucht werden - einfach nachfragen

Danke

Juergen

Code Auswählen

<file system>             <mount point>  <type>  <options>  <dump>  <pass>
UUID=8b9992d0-9b3f-4692-b644-20296199fcfb /              ext4    defaults,noatime 0 0
UUID=f5b4004b-3a04-4722-a6ba-498ae67057c8 /home          ext4    defaults,noatime 0 0
UUID=6d6eee07-ca0b-42d5-b0f2-497ef3d0c113 /opt/virtualbox ext4    defaults,noatime 0 0
UUID=c9a216b9-4474-41b1-b179-cee9b802aa92 /opt/daten_lokal ext4    defaults,noatime 0 0

#192.168.2.60:/volume1/music                     /media/musik-nas        nfs4     noauto,x-systemd.automount,x-systemd.device-timeout=10,timeo=14,x-systemd.idle-timeout=60min 0 0
....

die 6-te Stelle habe ich in der fstab nur mal zur Probe auf "0" gesetzt, stand vorher für / auf "1" und der Rest auf "2"
Die nfs mount habe ich zu Probe mal auskommentiert, alles ohne Erfolg bzgl der Bootzeit.

Code Auswählen

lsblk -f
NAME   FSTYPE FSVER LABEL          UUID                                 FSAVAIL FSUSE% MOUNTPOINT
sda
├─sda1 ext4   1.0                  8b9992d0-9b3f-4692-b644-20296199fcfb   77,7G    16% /
├─sda2 ext4   1.0                  f5b4004b-3a04-4722-a6ba-498ae67057c8   67,5G     9% /home
├─sda3 ext4   1.0                  6d6eee07-ca0b-42d5-b0f2-497ef3d0c113  162,6G    29% /opt/virtualbox
└─sda4 ext4   1.0                  c9a216b9-4474-41b1-b179-cee9b802aa92   32,9G     0% /opt/daten_lokal

die neue Installation

Code Auswählen

systemd-analyze blame 
7.737s udisks2.service
5.813s dev-sda1.device
5.724s cups.service
4.866s accounts-daemon.service
4.573s NetworkManager.service
4.484s avahi-daemon.service
4.482s polkit.service
3.976s wpa_supplicant.service
3.975s systemd-logind.service
3.262s smartmontools.service
3.174s ModemManager.service
2.942s systemd-journal-flush.service
2.256s nvidia-persistenced.service
2.104s packagekit.service
1.975s systemd-modules-load.service
1.672s systemd-udevd.service
1.668s gpm.service
1.154s systemd-tmpfiles-setup-dev.service
1.110s loadcpufreq.service
 958ms e2scrub_reap.service
 957ms preload.service
 945ms networking.service
 834ms virtualbox.service
 693ms colord.service
 681ms systemd-random-seed.service
 569ms dns-clean.service
 559ms alsa-restore.service
 446ms lvm2-monitor.service
 422ms systemd-sysusers.service
 386ms user@1000.service
 369ms systemd-udev-trigger.service
 357ms lm-sensors.service
 339ms keyboard-setup.service
 338ms systemd-journald.service
 317ms dev-hugepages.mount
 316ms dev-mqueue.mount
 316ms run-rpc_pipefs.mount
 315ms sys-kernel-debug.mount
 315ms sys-kernel-tracing.mount
 305ms hddtemp.service
 292ms systemd-user-sessions.service
 289ms modprobe@fuse.service
 288ms tmp.mount
 276ms kmod-static-nodes.service
 275ms modprobe@configfs.service
 274ms modprobe@drm.service
 263ms systemd-tmpfiles-setup.service
 254ms rpcbind.service
 234ms ifupdown-pre.service
 226ms upower.service
 224ms systemd-update-utmp.service
 199ms home.mount
 190ms opt-virtualbox.mount
 188ms systemd-remount-fs.service
 178ms opt-daten_lokal.mount
 164ms openvpn.service
 149ms cpufrequtils.service
 134ms systemd-sysctl.service
 108ms systemd-timesyncd.service
 106ms systemd-tmpfiles-clean.service
  95ms console-setup.service
  52ms nfs-config.service
  43ms sys-fs-fuse-connections.mount
  42ms sys-kernel-config.mount
  15ms systemd-update-utmp-runlevel.service
  10ms user-runtime-dir@1000.service
   3ms rtkit-daemon.service
  33us blk-availability.service

die alte Installation

Code Auswählen

systemd-analyze blame
13.942s logrotate.service
11.839s networking.service
 6.882s systemd-networkd-wait-online.service
 4.044s ifupdown-wait-online.service
 3.229s ifupdown-pre.service
 2.398s udisks2.service
 1.647s smartmontools.service
 1.356s snapd.service
 1.229s systemd-journal-flush.service
 1.165s dev-sdb3.device
 1.060s systemd-modules-load.service
 1.051s man-db.service
 1.022s gpm.service
  876ms mariadb.service
  836ms nvidia-persistenced.service
  700ms postfix@-.service
  585ms systemd-random-seed.service
  534ms systemd-sysusers.service
  481ms snapd.seeded.service
  450ms dev-loop9.device
  450ms dev-loop10.device
  435ms media-daten\x2dnas.mount
  408ms dev-loop8.device
  407ms dev-loop11.device
  398ms dev-loop4.device
  397ms dev-loop7.device
  391ms dev-loop5.device
  385ms dev-loop6.device
  376ms dev-loop3.device
  376ms dev-loop13.device
  370ms dev-loop0.device
  367ms dev-loop1.device
  342ms dev-loop2.device
  306ms ModemManager.service
  304ms cups.service
  264ms accounts-daemon.service
  215ms avahi-daemon.service
  209ms NetworkManager.service
  191ms wpa_supplicant.service
  191ms systemd-logind.service
  183ms loadcpufreq.service
  177ms systemd-tmpfiles-setup-dev.service
  175ms user@1027.service
  154ms apparmor.service
  151ms upower.service
  139ms NetworkManager-wait-online.service
  126ms packagekit.service
  107ms systemd-udevd.service
  101ms virtualbox.service
  101ms systemd-networkd.service
   92ms ssh.service
   84ms systemd-tmpfiles-setup.service
   73ms systemd-journald.service
   72ms systemd-udev-trigger.service
   67ms lvm2-lvmpolld.service
   64ms lightdm.service
   59ms snap-snapd-12057.mount

unklarer · 2021/06/16, 19:22:07

Du hast wahrscheinlich die Befehlsausgaben neue <--> alte Installation verwechselt, wenn die Neue das Problem ist.

Nimm mal diese Befehle, sind übersichtlicher:

Code Auswählen

systemd-analyzeund

Code Auswählen

systemd-analyze critical-chain

Ich habe seit langer Zeit diese Erscheinung mit zwei "alten" Installationen. Keine Lösung bisher, alles Mögliche ausprobiert, nichts hilft.

Ignorieren. Ich weiß, hilft dir nicht wirklich.

hendrikL · 2021/06/16, 20:01:11

naja, die alte Installation hat einen gewaltigen Vorteil, sie liegt auf einer ssd!
Zu einer hdd sind das Welten, da können solche Differenzen möglich sein.

jure · 2021/06/16, 20:38:14

danke für die Antworten

@unklarer - nee die systemd-analyze blame Ausgabe habe ich nicht vertauscht ;-)

@hendrikL - ja, aber dass das soviel ausmacht ...
p.s. - ist aber im Betrieb auch spürbar träger, das stimmt schon.

hier die Ausgaben von "systemd-analyze" und "systemd-analyze critical-chain"

alte Installation

Code Auswählen

systemd-analyze
Startup finished in 3.084s (kernel) + 9.960s (userspace) = 13.044s 
graphical.target reached after 9.953s in userspace
[root@siductionbox juergen]$ systemd-analyze critical-chain
The time when unit became active or started is printed after the "@" character.
The time the unit took to start is printed after the "+" character.

graphical.target @9.953s
└─multi-user.target @9.953s
  └─postfix.service @9.947s +5ms
    └─postfix@-.service @9.428s +517ms
      └─network-online.target @9.420s
        └─network.target @9.420s
          └─networking.service @3.082s +6.337s
            └─ifupdown-pre.service @441ms +2.639s
              └─systemd-udev-trigger.service @364ms +76ms
                └─systemd-udevd-kernel.socket @344ms
                  └─system.slice @257ms
                    └─-.slice @257ms

neue Installation

Code Auswählen

systemd-analyze
Startup finished in 4.077s (kernel) + 21.928s (userspace) = 26.006s
graphical.target reached after 21.884s in userspace
[root@siductionbox juergen]$ systemd-analyze critical-chain
The time when unit became active or started is printed after the "@" character.
The time the unit took to start is printed after the "+" character.

graphical.target @21.884s
└─multi-user.target @21.871s
  └─cups-browsed.service @21.858s
    └─cups.service @16.361s +5.483s
      └─network.target @16.336s
        └─NetworkManager.service @11.710s +4.613s
          └─dbus.service @11.696s
            └─basic.target @11.645s
              └─sockets.target @11.633s
                └─pcscd.socket @11.620s
                  └─sysinit.target @11.389s
                    └─systemd-timesyncd.service @11.191s +184ms
                      └─systemd-tmpfiles-setup.service @10.893s +179ms
                        └─local-fs.target @10.799s
                          └─opt-daten_lokal.mount @10.719s +67ms
                            └─dev-sdb4.device @10.695s

hendrikL · 2021/06/16, 21:13:56

[...] ja, aber dass das soviel ausmacht [...]
Ja, kann schon sein,

ps. Habe zwei alte x61s TP, eines mit ssd das andere mit hdd, je 6Gig RAM, ähnliche kde Installation, jenes mit der ssd bootet gut 10x so schnell, ein d-u/full-upgrade geht gefühlte 100x schneller, die Programme starten geschmeidiger und so weiter, nimm ne ssd, sind nicht mehr so teuer und die hdd als Datengrab!

jure · 2021/06/16, 22:19:04

ok, dann scheint das der Grund zu sein.

Ich könnte auch die "alte" SSD Installationen auf-/umräumen.

Funktioniert das, wenn ich die sdb1 (boot) und sdb2 lösche und dann die sdb3 (/ root) in den frei gewordenen Bereich vergrößere. Habe das noch nie gemacht. Dann müsste der MBR "neu geschrieben" werden,
Oder ich behalte die sdb1 (boot), verkleinere die deutlich und lösche nur die sdb2. Dann die sdb3 vergrößern..

In der Dokumentation von geparted liest sich das so, als würde das gehen. Das ganze aus nem livesystem, betr. Partitionen natürlich ausgehangen.

Zitat von: gepartedUm die Größe und den Ort der Partition festzulegen, verwenden Sie eine oder mehrere der folgenden Optionen:

Klicken Sie auf einen der Pfeile an den Enden des grafischen Bereichs und halten Sie die Maustaste gedrückt. Ziehen Sie den Pfeil innerhalb des Anzeigebereichs nach links oder rechts.

Klicken Sie auf die Mitte der Partition im grafischen Bereich und halten Sie die Maustaste gedrückt. Ziehen Sie den Pfeil innerhalb des Anzeigebereichs nach links oder rechts.

Klicken Sie auf die Pfeilknöpfe oder geben Sie Zahlenwerte in die Felder ein, um die folgenden Werte einzustellen:

Vorhergehender freier Speicherplatz

Neue Größe

Anschließender freier Speicherplatz

vinzv · 2021/06/16, 23:12:37

Zitat von: jure in 2021/06/16, 22:19:04
Funktioniert das, wenn ich die sdb1 (boot) und sdb2 lösche und dann die sdb3 (/ root) in den frei gewordenen Bereich vergrößere. Habe das noch nie gemacht. Dann müsste der MBR "neu geschrieben" werden,
Oder ich behalte die sdb1 (boot), verkleinere die deutlich und lösche nur die sdb2. Dann die sdb3 vergrößern..

Ich persönlich würde letzteres machen. Einfach, weil du ja eh wieder eine /boot Partition brauchst. Gib der 1GB, lösch sdb2 und guck dann zur Sicherheit in /etc/default/grub ob du ggf. Pfade anpassen musst.

jure · 2021/06/17, 20:10:33

Hallo

ich habe jetzt mal die sdb2 gelöscht & die sdb1 verkleinert und dann die root Partition sdb3 vergrößert.
Das lief in gparted auch fehlerfrei und recht zügig durch.

Obwohl sdb1 weiterhin mit "boot" markiert ist und an deren Anfang ja eigentlich nichts geändert wurde,
und root ja weiterhin auf sdb3 liegt, startet das System nicht.
Man sieht kurz "welcome to grub" dann bleibt der Bildschirm dunkel.
In der "/etc/default/grub" sehe ich nix was anzupassen wäre. Es fehlt jetzt halt die sdb2...

Was kann man/ich in diesen Fall tun...? Muss der MBR aufgrund der fehlenden sdb2 (wie) angepasst werden ?

Thx
Juergen

unklarer · 2021/06/17, 20:53:39

Ähm, ich sehe gerade, bei dir läuft da etwas falsch...

Nach deinem Bild von gParted zu Urteilen, hast du keine /boot-Partition. Man sieht es nicht, aber sdb1 hat sehr wahrscheinlich das "Bootflag" .

Ich hätte ja die erste Variante genommen und alles sdb3 (/) zugeschlagen.

Du mußt den Bootloader neu installieren. Sowas mache ich von der siduction-live gleich anschließend nach gparted, also chroot:

Code Auswählen

 mount /dev/sdb3 /mnt
 mount --bind /proc/ /mnt/proc
 mount --bind /run/ /mnt/run
 mount --bind /sys/ /mnt/sys
 mount --bind /dev/ /mnt/dev
 mount --bind /dev/pts /mnt/dev/pts
 chroot /mnt /bin/bash

Code Auswählen

grub-install /dev/sdb [oder:grub-install --force --root-directory=/mnt /dev/sdb3 > in den PBR!]

Überprüfe aber bitte nochmal, ob das nach dem mißlungenen Neustart noch sdb3 ist. Kann mir vorstellen, gparted hat da
jetzt sdb2 daraus gemacht.

Und, gibt es auch eine sda mit Haupt-Grub für dein System? Dann muß die Installation natürlich nach /dev/sda erfolgen!

jure · 2021/06/17, 21:29:07

Hi danke für die Infos,

ja die sdb1 hat & hatte das Bootflag.

Die heißen nur sdbx weil zu dem Zeitpunkt die neue HDD angeschlossen war, jetzt von ner live Version ohne die HDD ist es sdax etc.
Nee es ist weiterhin sda3 (bzw sdb3 wenn die HDD angeschlossen ist).

ps. es gibt in gparted sda1, sda3, dann 1MB nicht zugeteilt (blieb wohl über) und sda4 mit den extended Partitionen 5,6,7

Somit sollte Grub auch auf der sda sein, war es ja vorher auch, da gab es keine weitere HDD.
chroot muss ich jetzt mal "probieren", habe das noch nie gemacht, aber wenn sich das auf das von dir geschriebene beschränkt, ist das ja machbar

kann ich ja jetzt auf der Konsole von der C-Blues live machen ....

Bitte alles unmissverständlich schreiben ;-)

Kommt der loader an den Anfang der ersten Partition (sda1) oder von der root Partition, weil du schreibst

"[oder:grub-install --force --root-directory=/mnt /dev/sdb3 > in den PBR!]"

und was meinst du mit "PBR" ?

sorry ich habe da bisher keine Erfahrungen mit ..

jure · 2021/06/17, 21:43:51

ok soweit bin ich jetzt

Code Auswählen

siducer@siduction:~$ sudo mount /dev/sda3 /mnt
siducer@siduction:~$ sudo mount --bind /proc/ /mnt/proc
siducer@siduction:~$ sudo mount --bind /run/ /mnt/run
siducer@siduction:~$ sudo mount --bind /sys/ /mnt/sys
siducer@siduction:~$ sudo mount --bind /dev/ /mnt/dev
siducer@siduction:~$ sudo mount --bind /dev/pts/ /mnt/dev/pts
siducer@siduction:~$ sudo chroot /mnt/ /bin/bash

[root@siduction /]$ ~

Code Auswählen

fdisk -l

Device     Boot     Start       End   Sectors   Size Id Type
/dev/sda1  *         2048  46245887  46243840  22,1G 83 Linux
/dev/sda3        46245888 194559999 148314112  70,7G 83 Linux
/dev/sda4       194562048 500117503 305555456 145,7G  5 Extended
/dev/sda5       194564096 256004095  61440000  29,3G 83 Linux
/dev/sda6       256006144 337926143  81920000  39,1G 83 Linux
/dev/sda7       337928192 500117503 162189312  77,3G 83 Linux

Code Auswählen

 grub-install /dev/sda
i386-pc wird für Ihre Plattform installiert.
installation beendet. Keine Fehler aufgetreten.
[root@siduction /]$

mal sehen ob`es läuft ...

p.s. danke für deine Unterstützung das System läuft nach der hier oben aufgeführten Aktion wieder !

Gruß
Juergen

unklarer · 2021/06/18, 09:03:16

Dann Glückwunsch!

PBR = ist der PartitionsBootRecord der betreffenden Partition, im Unterschied zu MBR = MasterBootRecord, der sich am Anfang von sda, sdb usw. befindet.

Code Auswählen

grub-install --force --root-directory=/mnt /dev/sdb3
installiert Grub am Anfang von sdb3. Dabei ist 'force' nötig, weil er es sonst nicht macht, dort zuwenig Platz für ihn ist und er das in Blocklisten machen muß (diese seien unzuverlässig). Ist mir in meinem Linuxleben noch nicht passiert.