Siduction Forum
Siduction Forum => Installation - Support => Topic started by: jure on 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
<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.
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
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
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
-
Du hast wahrscheinlich die Befehlsausgaben neue <--> alte Installation verwechselt, wenn die Neue das Problem ist. ;)
Nimm mal diese Befehle, sind übersichtlicher:
systemd-analyze
und systemd-analyze critical-chain
Ich habe seit langer Zeit diese Erscheinung mit zwei "alten" Installationen (https://forum.siduction.site/index.php?topic=7707.msg62790#msg62790). Keine Lösung bisher, alles Mögliche ausprobiert, nichts hilft.
Ignorieren. Ich weiß, hilft dir nicht wirklich. ;D
-
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.
-
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
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
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
-
[...] 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!
-
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.
Um 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
(https://up.picr.de/41438598ao.png)
-
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.
-
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
-
Ähm, ich sehe gerade, bei dir läuft da etwas falsch... ;D
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:
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
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!
-
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 :P 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 ..
-
ok soweit bin ich jetzt
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 /]$ ~
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
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
-
:D Dann Glückwunsch!
PBR = ist der PartitionsBootRecord der betreffenden Partition, im Unterschied zu MBR = MasterBootRecord, der sich am Anfang von sda, sdb usw. befindet.
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. ;D