martin12
Anmeldungsdatum: 15. August 2009
Beiträge: 150
|
Hallo, mein Rechner braucht recht lange beim booten, deutlich länger als früher. Seit nun 3 Monaten habe ich ihn von 14.04 auf 16.04 hochgerüstet. Bei der Recherche habe ich die Einträge in der /etc/fstab untersucht. Nun meine Frage: Wie muss die UUID in /etc/fstab eingetragen sein. Bei mir finde ich bei der swap die UUID in "Tüddelchen". Ist das richtig? Im Wiki der fstab habe ich solche "Tüddelchen" nicht gefunden. Meine fstab:
# /etc/fstab: static file system information.
#
...
#
# <file system> <mount point> <type> <options> <dump> <pass>
# / was on /dev/sda4 during installation
UUID=5585f473-0c6d-4555-90a8-f2bdd821ce16 / ext4 errors=remount-ro 0 1
UUID="2e978581-6f2b-4a77-9792-195db0d4b4c3" none swap sw 0 0
UUID=F65CBA445CB9FF83 /home/martin/Daten-2 ntfs-3g defaults,users,uid=1000,gid=1000 0 0
Und dann wundert mich auch, dass der Eintrag der swap mit einem Leerzeichen beginnt. Ist das ein Problem? martin12
|
Doc_Symbiosis
Anmeldungsdatum: 11. Oktober 2006
Beiträge: 4390
Wohnort: Göttingen
|
Hm, ich kenne die Einträge auch nur ohne Double Quotes (Tüdelchen, wie Du sie nennst). Das Leerzeichen am Anfang der Zeile macht nichts weiter aus. Aber wenn an der fstab etwas falsch wäre, dann dürfte das Einhängen gar nicht klappen und nicht den Bootprozess so extrem verlangsamen. Probier es vielleicht mal mit systemd-analyze blame , um die Prozesse zu finden, die das Booten so lange verzögern.
|
frostschutz
Anmeldungsdatum: 18. November 2010
Beiträge: 7657
|
Leerzeichen und " sind zwar nicht verboten aber ich würds trotzdem wegmachen. Beides unnötig. Ansonsten checken daß die UUID auch tatsächlich existiert und richtig ist (blkid, lsblk)
|
tomtomtom
Supporter
Anmeldungsdatum: 22. August 2008
Beiträge: 53593
Wohnort: Berlin
|
Und da es um die Swap-Partition geht kannst du z.B. mit free überprüfen ob sie genutzt wird.
|
frostschutz
Anmeldungsdatum: 18. November 2010
Beiträge: 7657
|
lsblk zeigt auch Swap an, sofern dieser benutzt wird, ist [SWAP] als Mountpoint angegeben. swapon (ohne weitere Parameter) listet auch die verwendeten Swaps auf. free zeigt dagegen die Größe des insgesamt verfügbaren Swapbereichs (ohne dies einzeln aufzuschlüsseln falls mehrere Swap-Partitionen im Einsatz sind). Vorhandene jedoch ungenutzte Swap sieht man in blkid.
|
tomtomtom
Supporter
Anmeldungsdatum: 22. August 2008
Beiträge: 53593
Wohnort: Berlin
|
frostschutz schrieb: lsblk zeigt auch Swap an, sofern dieser benutzt wird, ist [SWAP] als Mountpoint angegeben.
Gerade was gelernt, hab ich noch nie ohne Ausgabeoptionen benutzt.
free zeigt dagegen die Größe des insgesamt verfügbaren Swapbereichs (ohne dies einzeln aufzuschlüsseln falls mehrere Swap-Partitionen im Einsatz sind).
Anhand des Inhalt der fstab wissen wir aber, dass das da nur eine ist.
|
Xeno
Ehemalige
Anmeldungsdatum: 6. April 2005
Beiträge: 2572
Wohnort: Schweiz
|
Doc_Symbiosis schrieb:
Aber wenn an der fstab etwas falsch wäre, dann dürfte das Einhängen gar nicht klappen und nicht den Bootprozess so extrem verlangsamen.
Doch, eine falsche etc/fstab mit falschen UUIDs kann ganz problemlos den Bootvorgang extrem verlangsamen, so von 15 Sekunden auf 2 Minuten. Ist reproduzierbar. Lg X.
|
tomtomtom
Supporter
Anmeldungsdatum: 22. August 2008
Beiträge: 53593
Wohnort: Berlin
|
Xeno schrieb: Doch, eine falsche etc/fstab mit falschen UUIDs kann ganz problemlos den Bootvorgang extrem verlangsamen
und eine falsche /etc/fstab erstmal. 😈
|
Doc_Symbiosis
Anmeldungsdatum: 11. Oktober 2006
Beiträge: 4390
Wohnort: Göttingen
|
Natürlich, wenn die UUIDs falsch sind, aber wenn nach dem Boot alles richtig eingehängt ist, können die UUIDs ja nicht falsch sein.
Swap hatte ich allerdings vergessen, wo man vielliecht wirklich nicht merkt, dass sie gar nicht eingehängt ist...
|
tomtomtom
Supporter
Anmeldungsdatum: 22. August 2008
Beiträge: 53593
Wohnort: Berlin
|
Doc_Symbiosis schrieb: Natürlich, wenn die UUIDs falsch sind, aber wenn nach dem Boot alles richtig eingehängt ist, können die UUIDs ja nicht falsch sein.
Deshalb war ja die Frage, ob das alles einhängt ist.
|
martin12
(Themenstarter)
Anmeldungsdatum: 15. August 2009
Beiträge: 150
|
Habe die "Tüddelchen" (Doppelquotes) in der fstab weggenommen, auch das Leerzeichen vor der swap. Die Zeit beim Hochfahren blieb fast unverändert. Also: Im Sinne der Frage „Ist die UUID in der fstab richtig eingetragen?“ ist das Problem gelöst - obwohl der Hintergrund der Frage (längere Zeit zum Hochfahren) weiter besteht.
|
Xeno
Ehemalige
Anmeldungsdatum: 6. April 2005
Beiträge: 2572
Wohnort: Schweiz
|
tomtomtom schrieb: Xeno schrieb: Doch, eine falsche etc/fstab mit falschen UUIDs kann ganz problemlos den Bootvorgang extrem verlangsamen
und eine falsche /etc/fstab erstmal. 😈
Sei nicht so streng! Hast natürlich Recht! Beachte auch die Uhrzeit meines Postings... Lg X.
|
Xeno
Ehemalige
Anmeldungsdatum: 6. April 2005
Beiträge: 2572
Wohnort: Schweiz
|
martin12 schrieb: Habe die "Tüddelchen" (Doppelquotes) in der fstab weggenommen, auch das Leerzeichen vor der swap. Die Zeit beim Hochfahren blieb fast unverändert. Also: Im Sinne der Frage „Ist die UUID in der fstab richtig eingetragen?“ ist das Problem gelöst - obwohl der Hintergrund der Frage (längere Zeit zum Hochfahren) weiter besteht.
Dan liefere jetzt die im zweiten Posting von Doc_Symbiosis angeforderte Terminalausgabe, bitte vollständig im Codeblock. Lg X.
|
martin12
(Themenstarter)
Anmeldungsdatum: 15. August 2009
Beiträge: 150
|
gut, also hier die Terminalausgabe zu den Eintragungen > 0,5 s nach Eingabe von systemd-analyze blame :
14.472s NetworkManager-wait-online.service
2.285s networking.service
2.238s apport.service
1.877s timidity.service
1.783s grub-common.service
1.678s irqbalance.service
1.656s speech-dispatcher.service
1.655s ondemand.service
1.595s lightdm.service
1.425s dev-sda4.device
1.151s ModemManager.service
1.021s systemd-rfkill.service
874ms apparmor.service
783ms snapd.firstboot.service
759ms NetworkManager.service
625ms accounts-daemon.service
624ms systemd-logind.service
619ms console-kit-log-system-start.service
586ms vboxdrv.service
581ms gpu-manager.service
|
Xeno
Ehemalige
Anmeldungsdatum: 6. April 2005
Beiträge: 2572
Wohnort: Schweiz
|
Da sieht alles normal aus. Schwer zu sagen, was das bedeutet; möglicherweise tritt das Problem erst später auf? Mache jetzt im Terminal systemd-analyze plot > boot.svg und poste die Grafik boot.svg hier als Dateianhang. Lg X.
|