.cinch
Anmeldungsdatum: 8. Oktober 2013
Beiträge: 29
|
Servus, nachdem update auf 18.04 vergeht gefühlt eine Ewigkeit bis mein System bootet. Habe davor meine Partitionierung verändern müssen, da /root zu klein war. Ubuntu ist auf auf dem Lenovo X1 Carbon (4th) das einzige OS. systemd-analyze time
Startup finished in 35.071s (kernel) + 3min 1.572s (userspace) = 3min 36.644s
graphical.target reached after 1min 41.846s in userspace
systemd-analyze blame
8.224s NetworkManager-wait-online.service
2.966s plymouth-quit-wait.service
2.015s postfix@-.service
1.062s dev-sda1.device
864ms fwupd.service
764ms snapd.service
557ms tlp.service
540ms sysfsutils.service
377ms dev-loop9.device
350ms plymouth-start.service
339ms dev-loop11.device
330ms dev-loop8.device
310ms dev-loop10.device
302ms dev-loop1.device
296ms dev-loop0.device
290ms dev-loop13.device
285ms dev-loop12.device
277ms dev-loop7.device
275ms dev-loop3.device
273ms dev-loop2.device
272ms dev-loop4.device
251ms systemd-logind.service
245ms dev-loop5.device
sudo parted -l
Modell: ATA SAMSUNG MZNLN256 (scsi)
Festplatte /dev/sda: 256GB
Sektorgröße (logisch/physisch): 512B/512B
Partitionstabelle: msdos
Disk-Flags:
Nummer Anfang Ende Größe Typ Dateisystem Flags
1 1049kB 21,0GB 21,0GB primary ext4 boot
2 21,0GB 256GB 235GB extended
5 21,0GB 247GB 226GB logical ext4
6 247GB 256GB 8678MB logical linux-swap(v1)
sudo lsblk -o NAME,UUID,FSTYPE,LABEL,MOUNTPOINT
NAME UUID FSTYPE LABEL MOUNTPOINT
loop0 squashf /snap/core/4917
loop1 squashf /snap/core/5328
loop2 squashf /snap/vlc/365
loop3 squashf /snap/gnome-calculator
loop4 squashf /snap/gnome-logs/43
loop5 squashf /snap/gnome-3-26-1604/
loop6 squashf /snap/core/5145
loop7 squashf /snap/inkscape/4274
loop8 squashf /snap/gnome-characters
loop9 squashf /snap/communitheme/120
loop10 squashf /snap/gtk-common-theme
loop11 squashf /snap/gnome-system-mon
loop12 squashf /snap/vlc/555
loop13 squashf /snap/vlc/190
sda
├─sda1 4c1c2f95-e705-49bb-9a1a-941f854205c7 ext4 /
├─sda5 c6a641df-d80d-4e2a-b59d-c47c7ba05871 ext4 /home
└─sda6 5e80cce0-43ec-4afd-9e3b-d0dc080d0eaf swap Habe den Verdacht, dass ich bei der Partitionierung etwas vergeigt habe.
Ich hoffe Ihr könnt mir helfen.
Besten Dank! Moderiert von Taomom: Entspamt.
|
cosinus
Anmeldungsdatum: 11. Mai 2010
Beiträge: 1374
Wohnort: HB
|
Mal beim Bootvorgang mit ESC den bootenden Kernel anzeigen und notieren an welcher Stelle er länger steckenbleibt. Ich hatte bei Ubuntu auf meinem Testnotebook auch einen Hänger, es lag am resume device.
|
hakel
Anmeldungsdatum: 13. August 2009
Beiträge: 23336
|
Du findest sehr viele fertige Threads zu diesem Thema. Vergleiche fstab mit blkid, meist sind es UUIDs von vergessenen oder geänderten Laufwerken. blame ist nicht sehr aussagekräftig. 😈 Plymouth deaktivieren (nicht deinstallieren), plot ... P.S. in den seltensten Fällen ist das mal flott erkannt!
|
Berlin_1946
Supporter, Wikiteam
Anmeldungsdatum: 18. September 2009
Beiträge: 8686
|
Hallo .cinch, Sry hakel vllt für einen User mit 6 Post etwas zu konzentriert. Ich versuche mal etwas ausführlicher. 😇
Vergleiche fstab mit blkid
Mit diesen nachfolgenden Befehlen kannst du das vergleichen, ob die UUID übereinstimmen. lenovo@lenovo-ThinkPad-T400:~$ cat /etc/fstab | grep -i uuid
# device; this may be used with UUID= as a more robust way to name devices
UUID=43e82f8b-e5c7-4f27-b7bb-xxxxxxxxxxxx / ext4 errors=remount-ro 0 1
UUID=c993b866-6bf0-41bf-aa35-yyyyyyyyyyyy none swap sw 0 0
lenovo@lenovo-ThinkPad-T400:~$
Werte mit xxx.., bzw yyy.. habe ich überschrieben. (meine Daten anonymisiert)
lenovo@lenovo-ThinkPad-T400:~$ sudo blkid | grep -i uuid
[sudo] Passwort für lenovo:
/dev/sda1: LABEL="System" UUID="CCC41FA2C41F8DB8" TYPE="ntfs" PARTUUID="ae293828-01"
/dev/sda2: LABEL="Windows" UUID="6C3221463221169C" TYPE="ntfs" PARTUUID="ae293828-02"
/dev/sda5: UUID="43e82f8b-e5c7-4f27-b7bb-xxxxxxxxxxxx" TYPE="ext4" PARTUUID="ae293828-05"
/dev/sda6: UUID="c993b866-6bf0-41bf-aa35-yyyyyyyyyyyy" TYPE="swap" PARTUUID="ae293828-06"
lenovo@lenovo-ThinkPad-T400:~$ Bei Post immer bitte Terminalausgaben im Codeblock von Prompt bis Promt posten. Wichtige Informationen zu den Befehlen finders du in den Wikis fstab , blkid und grep Solltest du ein Delta haben, musst du die fstab bearbeite, steht auch im dazugehörenden Wiki.
|
.cinch
(Themenstarter)
Anmeldungsdatum: 8. Oktober 2013
Beiträge: 29
|
Vielen Dank für die schnellen Antworten.
Sry hakel vllt für einen User mit 6 Post etwas zu konzentriert. Ich versuche mal etwas ausführlicher. 😇
Mit etwas Lesen im Wiki hat's auch so geklappt - trotzdem danke. Die UIID der swap stimmten nicht überein. Hab die fstab editiert und Plymouth deaktiviert: oc@oc:~$ cat /etc/fstab | grep -i uuid
# device; this may be used with UUID= as a more robust way to name devices
UUID=4c1c2f95-e705-49bb-9a1a-aaaaaaaaaaaa / ext4 errors=remount-ro 0 1
UUID=c6a641df-d80d-4e2a-b59d-bbbbbbbbbbbb /home ext4 defaults 0 2
UUID=5e80cce0-43ec-4afd-9e3b-cccccccccccc none swap sw 0 0
oc@oc:~$ sudo blkid | grep -i uuid
/dev/sda1: UUID="4c1c2f95-e705-49bb-9a1a-aaaaaaaaaaaa" TYPE="ext4" PARTUUID="eaea93d5-01"
/dev/sda5: UUID="c6a641df-d80d-4e2a-b59d-bbbbbbbbbbbb" TYPE="ext4" PARTUUID="eaea93d5-05"
/dev/sda6: UUID="5e80cce0-43ec-4afd-9e3b-cccccccccccc" TYPE="swap" PARTUUID="eaea93d5-06"
oc@oc:~$ systemd-analyze plot > plot_2.svg
oc@oc:~$ systemd-analyze time
Startup finished in 37.140s (kernel) + 11.775s (userspace) = 48.916s
graphical.target reached after 11.208s in userspace
oc@oc:~$ Anbei die plots vor und nach der Bearbeitung.
- plot_2.svg (150.6 KiB)
- Download plot_2.svg
- plot.svg (284.2 KiB)
- Download plot.svg
|
hakel
Anmeldungsdatum: 13. August 2009
Beiträge: 23336
|
Prima, deinen groben Fehler hast du also beseitigt. 👍 Jetzt wird es kompliziert. Das Plot zeigt ja wunderbar, daß dein Rechner 35s in der Nase bohrt. Das ist nicht deine Schuld. Da sehe ich jetzt 3 Möglichkeiten, inkompatibles Luxusbord, Ubuntu Gnome Kiste (?) Entropie/haveged, snap (?). Als "armer" Xubuntu Nutzer fehlt mir an dieser Stelle die Erfahrung. Da müßten sich die Berliner melden.
|
cosinus
Anmeldungsdatum: 11. Mai 2010
Beiträge: 1374
Wohnort: HB
|
Das mit fehlender Entropie hatte ich auch, aber da war die Wartezeit erst direkt nach dem Login (GUI). haveged hat das behoben.Einfach nachinstallieren. Was issen jetzt mit meinem Vorschlag sich einfach mal die Ausgaben des bootenden Kernel anzuschauen mit ESX während das Ding bootet und dann notiert man die Zeile bei der System die 30 Sekunden hängt? Ich vermute mal wieder ganz stark das resume device.
|
hakel
Anmeldungsdatum: 13. August 2009
Beiträge: 23336
|
Das mit fehlender Entropie hatte ich auch, aber da war die Wartezeit erst direkt nach dem Login (GUI).
Es handelt sich doch um einen Kernelbug unter 18.04. 😲
Jetzt wird es kompliziert.
😈 Egal - Keine Erfahrung, keine Meinung!
|
hollerbrätling
Anmeldungsdatum: 24. April 2016
Beiträge: 130
|
|
.cinch
(Themenstarter)
Anmeldungsdatum: 8. Oktober 2013
Beiträge: 29
|
Prima, deinen groben Fehler hast du also beseitigt. 👍
Ein Traum.
Jetzt wird es kompliziert.
Ich bin ja lernwillig. Führt ja nur dazu, dass ich Ubuntu besser verstehe.
Installiere mal haveged
Done. Die meiste Zeit beim booten vergeht anfangs im blackscreen. Genauso viel Zeit vergeht bei dieser Zeile: Beginn: Running /scripts/local-premount
|
alterpinguin
Anmeldungsdatum: 24. Mai 2014
Beiträge: 786
|
.cinch schrieb: Prima, deinen groben Fehler hast du also beseitigt. 👍
Ein Traum.
Jetzt wird es kompliziert.
Ich bin ja lernwillig. Führt ja nur dazu, dass ich Ubuntu besser verstehe.
Installiere mal haveged
Done. Die meiste Zeit beim booten vergeht anfangs im blackscreen. Genauso viel Zeit vergeht bei dieser Zeile: Beginn: Running /scripts/local-premount
Schau in /etc/initramfs-tools/... meist die conf.d/resume (wenn es da eine gibt) nach, es können aber auch Einträge in den anderen Verzeichnissen dort sein und korrigiere die veralteten Einstellungen. Dann müssen noch die initrd-Dateien neu erstellt werden (sudo update-initramfs -ukall) und kontrolliere das auch, d.h. schau vorher nach wie die Dateien in /boot aussehen und danach ob sich da was geändert hat (ändert sich da nichts, dann sollte immer noch die Verzögerung auf der Suche nach nicht vorhandenen Partitionen passieren). Übrigens, wie Du ganz am Anfang schreibst hattest Du Deine Partitionierung verändert - also dabei wahrscheinlich auch vorhandene UUIDs verändert, gelöscht, neu erstellt und da diese IDs genutzt werden um die richtige Partition zu identifizieren, stimmt das jetzt nicht mehr.
|
.cinch
(Themenstarter)
Anmeldungsdatum: 8. Oktober 2013
Beiträge: 29
|
Schau in /etc/initramfs-tools/... meist die conf.d/resume (wenn es da eine gibt) nach, es können aber auch Einträge in den anderen Verzeichnissen dort sein und korrigiere die veralteten Einstellungen.
Hab jetzt die richtige ID der Swap genommen, richtig?
Dann müssen noch die initrd-Dateien neu erstellt werden (sudo update-initramfs -ukall) und kontrolliere das auch, d.h. schau vorher nach wie die Dateien in /boot aussehen und danach ob sich da was geändert hat (ändert sich da nichts, dann sollte immer noch die Verzögerung auf der Suche nach nicht vorhandenen Partitionen passieren).
Done.
Übrigens, wie Du ganz am Anfang schreibst hattest Du Deine Partitionierung verändert - also dabei wahrscheinlich auch vorhandene UUIDs verändert, gelöscht, neu erstellt und da diese IDs genutzt werden um die richtige Partition zu identifizieren, stimmt das jetzt nicht mehr.
Wie hätte man die Partitionierung denn ideal vollzogen, ohne die anschließende manuelle Änderung der IDs? Anbei der aktuelle boot-plot. Sieht schon sehr viel besser aus - geht da noch was? Nach dem Lenovo-splashscreen hängt's noch bisschen im blackscreen.
- plot_3.svg (125.7 KiB)
- Download plot_3.svg
|
cosinus
Anmeldungsdatum: 11. Mai 2010
Beiträge: 1374
Wohnort: HB
|
alterpinguin schrieb: Schau in /etc/initramfs-tools/... meist die conf.d/resume (wenn es da eine gibt) nach, es können aber auch Einträge in den anderen Verzeichnissen dort sein und korrigiere die veralteten Einstellungen.
Ja genau resume, das ist der Fehler den ich angesprochen habe, ich hab resume=none eingetragen: | # cat /etc/initramfs-tools/conf.d/resume
RESUME=none
|
Danch muss ein update.iniramfs -u her.
|
.cinch
(Themenstarter)
Anmeldungsdatum: 8. Oktober 2013
Beiträge: 29
|
Ja genau resume, das ist der Fehler den ich angesprochen habe, ich hab resume=none eingetragen:
Hab ich gemacht. Ändert aber nichts am boot-Vorgang.
|
Taomon
Supporter
Anmeldungsdatum: 30. Januar 2011
Beiträge: 8431
Wohnort: Digiworld
|
sudo update-initramfs -u -k all nach der Änderung in der /etc/initramfs-tools/conf.d/resume ausgeführt? Blöd nachfrag, windows wird immer komplett runtergefahren? Spiele auf Schnell-Start/Fast-Boot an. Was ist für eine Windows-Version drauf? In einem Dualboot mit windows kann es auch zu Problemen mit der Systemzeit kommen. alex@beelzemon:~$ lsinitramfs /boot/initrd.img-4.15.0-34-generic | grep local-premount
scripts/local-premount
scripts/local-premount/fixrtc
scripts/local-premount/ntfs_3g
scripts/local-premount/resume
scripts/local-premount/ORDER
alex@beelzemon:~$ Gruß Taomon
|