Sie sind nicht angemeldet.

[gelöst] langsames Booten nach Upgrade auf Lubuntu 18.04.

cortlieb

User

  • »cortlieb« ist der Autor dieses Themas

Beiträge: 21

Registrierungsdatum: 21.08.2017

Derivat: Ubuntu

Architektur: 64-Bit PC

Desktop: unbekannt

Andere Betriebssysteme: Windows10

  • Nachricht senden

1

30.08.2018, 21:21

langsames Booten nach Upgrade auf Lubuntu 18.04.

Hallo liebe Experten,
nach dem Upgrade auf Lubuntu 18.04 (von 17.04) hat mein (immerhin 6 Jahre altes) Notebook leider eine Eigenschaft verloren, die mich beim Umstieg von Win10 auf Lubuntu begeistert hat: rasantes Starten!
Ich habe ein bisschen geforscht und denke ich habe in der dmesg-Ausgabe den Verursacher gefunden.

Quellcode

 
1
2
3
4
5
6
7

2.746773 <	0,000013>] usb 1-1.8: SerialNumber: Alaska Day 2006
[ 3.260332 <	0,513559>] clocksource: Switched to clocksource tsc
[ 32.934206 <   29,673874>] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null)
[ 33.238763 <	0,304557>] ip_tables: (C) 2000-2006 Netfilter Core Team
[ 33.259458 <	0,020695>] systemd[1]: systemd 237 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +X
Z +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN -PCRE2 default-hierarchy=hybrid)
[ 33.276183 <	0,016725>] systemd[1]: Detected architecture x86-64.

Das Mounten des file-systems dauert eine geschlagene halbe Minute, das scheint mir nicht normal.
Nun weiß ich aber nicht, wo ich ansetzten soll, um das Problem zu beheben?
Googlen brachte, dass die UUID für meine SSD mit der vom blkid-Befehl ausgegebenen UUID übereinstimmen muss.
Das ist der Fall.

Quellcode

 
1
2
3
4
5
6
7
8
9
10

# /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/sda1 during installation
UUID=d6ea39b1-4f44-48c9-87af-085d9de51c17 /           	ext4	errors=remount-ro 0   	1
/swapfile                             	none        	swap	sw          	0   	0

Kann mir jemand einen Tipp geben, wo ich ansetzten kann?
Vielen Dank.
Christian

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »cortlieb« (11.09.2018, 21:58)

chroot

Ubuntu-Forum-Team

  • »chroot« ist männlich

Beiträge: 2 321

Registrierungsdatum: 04.03.2008

Derivat: Kein Ubuntu-Derivat

Architektur: 64-Bit PC

Desktop: KDE4

Andere Betriebssysteme: Fedora 27

  • Nachricht senden

2

31.08.2018, 10:33

Hast du bzw. hattest du vorher ein verschlüsseltes system?
In dem beitrag hier geht es um eine verschlüsselte swap partition und das system wartet beim booten auf die partition bis ein time-out greift, daher die lange boot zeit.
"Do or do not. There is no try." (Yoda) || Thread auf gelöst/erledigt setzen

Klaus P

User

  • »Klaus P« ist männlich

Beiträge: 4 593

Registrierungsdatum: 25.10.2009

Derivat: anderes Ubuntu-Derivat

Architektur: 64-Bit PC

Desktop: anderer Desktop

Andere Betriebssysteme: 7/10

  • Nachricht senden

3

31.08.2018, 10:42

Zitat

nach dem Upgrade auf Lubuntu 18.04 (von 17.04)
Wirklich Upgrade oder Neuinstallation?
Falls ersteres, Daten sichern und neu installieren.

Gruß
Des modernen Menschen Computer ist sein Himmelreich! :rolleyes: Der Weg zur Hölle, ist allzu kurz auf dem falschen "EFI-Pfad" ;( : Kleiner Leitfaden zur UEFI-Installation

cortlieb

User

  • »cortlieb« ist der Autor dieses Themas

Beiträge: 21

Registrierungsdatum: 21.08.2017

Derivat: Ubuntu

Architektur: 64-Bit PC

Desktop: unbekannt

Andere Betriebssysteme: Windows10

  • Nachricht senden

4

31.08.2018, 11:57

@chroot
Nein, weder habe noch hatte ich ein verschlüsseltes System (es sei denn, das ist irgendwie Standard und ich habe es nicht bemerkt :S )

@Klaus P
Ernsthaft?
Durch Neuinstallation kann man das Problem wahrscheunlich beheben, aber das ist ja schon eine ziemliche Holzhammer-Methode!
Das muss doch auch eleganter gehen, oder?

Horsemanchip

User

Beiträge: 1 131

Registrierungsdatum: 08.11.2015

Derivat: unbekannt

Version: gar kein Ubuntu

Architektur: 64-Bit PC

Desktop: LXDE

Andere Betriebssysteme: Debian bullseye-testing / 5.10.0-10-amd64

  • Nachricht senden

5

31.08.2018, 13:59

Nimm doch mal quiet und slpash aus deiner /etc/default/grub heraus, mach ein grub-update und boote erneut.

Eventuell siehst Du dann, an welcher Stelle er hängen bleibt.

Vielleicht startet er damit allein auch schon schneller, weil ohne "splash" der Plymouth Bootkrams nicht läuft. Eh unnützer Schnickschnack. ^^
Heute ist keiner da! Komm morgen wieder. :-)

Klaus P

User

  • »Klaus P« ist männlich

Beiträge: 4 593

Registrierungsdatum: 25.10.2009

Derivat: anderes Ubuntu-Derivat

Architektur: 64-Bit PC

Desktop: anderer Desktop

Andere Betriebssysteme: 7/10

  • Nachricht senden

6

31.08.2018, 17:46

Zitat von »cortlieb«

Ernsthaft?


Ja, an sich schon! Upgrades sind gerne Fehlerursache für alle Arten von Problemen unmittelbar danach. Mit einer Neuinstallation hat man ein frisches OS ohne Altlasten. Ich meide Upgrades, nutze aber auf einem Produktivsystem nur die LTS-Versionen. Alle 2 Jahre eine saubere Neuinstallation ist O.K.!

L.G.
Des modernen Menschen Computer ist sein Himmelreich! :rolleyes: Der Weg zur Hölle, ist allzu kurz auf dem falschen "EFI-Pfad" ;( : Kleiner Leitfaden zur UEFI-Installation

wowi

Ubuntu-Forum-Team

  • »wowi« ist männlich

Beiträge: 4 264

Registrierungsdatum: 03.05.2007

Derivat: Xubuntu

Architektur: 64-Bit PC

Desktop: XFCE

  • Nachricht senden

7

01.09.2018, 00:10

Hi cortlieb,

hast Du das langsame Booten eventuell nur, wenn Du keinen Netzwerkanschluss hast? Wenn ja, dann hilft vielleicht folgende Änderung:
Ändere in der Datei /etc/dhcp/dhclient.conf den timeout auf 15.

Greetz
wowi

cortlieb

User

  • »cortlieb« ist der Autor dieses Themas

Beiträge: 21

Registrierungsdatum: 21.08.2017

Derivat: Ubuntu

Architektur: 64-Bit PC

Desktop: unbekannt

Andere Betriebssysteme: Windows10

  • Nachricht senden

8

02.09.2018, 22:01

@Horsemanchip
Das habe ich mal gemacht und tatsächlich blieb das Ganze eine Weile an einer Zeile hängen:


Begin: Runing /scripts/local-premount ...


Alles davor und danach lief zu schnell ab, um es zu verfolgen, gibt es eine Möglichkeit, sich diese Ausgaben nochmal in Ruhe anzuschaun, also z.B. in eine Datei umzulenken? Vielleicht das ja sowieso irgendwo protokolliert.
Ich muss zugeben, die Zeile, an der es hakt, gibt mir eher Rätsel auf.
ich habe mehrere Ordner auf meinem System gefunden, die auf /<Pfad>/initramfs-tools/scripts/local-premount lauten. Einige sind leer, andere enthalten ein paar Skripte.
Aber bestimmt weiß einer von euch, wo ich da ansetzten kann ^^ .

@wowi
Das Notebook ist immer per WLAN ans Netz angeschlossen.
Das hat sich nicht verändert.
Daher vermute ich da nicht das Problem.

Ich probiere es trotzdem gleich mal.
Nein, wie erwartet, hat das keine Änderung gebracht.

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »cortlieb« (02.09.2018, 22:07)

Horsemanchip

User

Beiträge: 1 131

Registrierungsdatum: 08.11.2015

Derivat: unbekannt

Version: gar kein Ubuntu

Architektur: 64-Bit PC

Desktop: LXDE

Andere Betriebssysteme: Debian bullseye-testing / 5.10.0-10-amd64

  • Nachricht senden

9

03.09.2018, 08:17

@cortlieb:

Ok, danke!

Zeige mal die Ausgabe der beiden Kommandos:

Quellcode

 
1
2
3

cat /etc/initramfs-tools/conf.d/resume

sudo blkid | grep swap
Heute ist keiner da! Komm morgen wieder. :-)

cortlieb

User

  • »cortlieb« ist der Autor dieses Themas

Beiträge: 21

Registrierungsdatum: 21.08.2017

Derivat: Ubuntu

Architektur: 64-Bit PC

Desktop: unbekannt

Andere Betriebssysteme: Windows10

  • Nachricht senden

10

03.09.2018, 14:01

... und hier sind die Ausgaben:

Quellcode

 
1
2

cat /etc/initramfs-tools/conf.d/resume
RESUME=UUID=158de763-7c03-4cad-b48a-a9b242895335


Quellcode

 
1
2
3
4
5
6

sudo blkid
/dev/sda1: UUID="d6ea39b1-4f44-48c9-87af-085d9de51c17" TYPE="ext4" PARTUUID="aa2556b7-01"
/dev/loop0: TYPE="squashfs"
/dev/loop1: TYPE="squashfs"
/dev/loop2: TYPE="squashfs"
/dev/loop3: TYPE="squashfs"



Quellcode

 
1

sudo blkid | grep swap
ergibt eine leere Ausgabe

Horsemanchip

User

Beiträge: 1 131

Registrierungsdatum: 08.11.2015

Derivat: unbekannt

Version: gar kein Ubuntu

Architektur: 64-Bit PC

Desktop: LXDE

Andere Betriebssysteme: Debian bullseye-testing / 5.10.0-10-amd64

  • Nachricht senden

11

03.09.2018, 14:06

Ok! In der resume Datei steht noch deine Swap Partition von deinem alten System drin. Ubuntu 18.04 arbeitet aber neuerdings mit einem swapfile, statt einer Partition, wie Du auch in der /etc/fstab weiter oben sehen kannst.

Mach also folgendes:

1) Datei öffnen mit Editor und Root Rechten:

Quellcode

 
1

sudo leafpad /etc/initramfs-tools/conf.d/resume


dort änderst Du die Zeile in:

Quellcode

 
1

RESUME=none


nun die Datei abspeichern und folgendes ausführen:

Quellcode

 
1

sudo update-initramfs -u


danach "reboot" und schauen. ^^

Dein System sucht halt beim booten nach deiner Swap Partition, aber die ist ja niciht mehr da. So gehts erst nach dem timeout weiter mit booten.
Heute ist keiner da! Komm morgen wieder. :-)

cortlieb

User

  • »cortlieb« ist der Autor dieses Themas

Beiträge: 21

Registrierungsdatum: 21.08.2017

Derivat: Ubuntu

Architektur: 64-Bit PC

Desktop: unbekannt

Andere Betriebssysteme: Windows10

  • Nachricht senden

12

03.09.2018, 22:13

Hmmm, das hat so noch nicht geholfen.
Der Bootvorgang hängt an der selben Stelle.
Beim Ausführen von sudo update-initramfs -u gab es folgende Meldung:

Quellcode

 
1
2
3
4
5

~$ sudo update-initramfs -u

update-initramfs: Generating /boot/initrd.img-4.15.0-33-generic
W: initramfs-tools configuration sets RESUME=UUID=158de763-7c03-4cad-b48a-a9b242895335
W: but no matching swap device is available.

In /etc/initramfs-tools/conf.d/resume steht aber der gewünschte Eintrag (RESUME=none).
Es scheint noch woanders einen Hinweis auf die swap-Partition zu geben?

babalawo

User

  • »babalawo« ist männlich

Beiträge: 1

Registrierungsdatum: 02.08.2015

Derivat: Ubuntu

Version: Ubuntu 18.04 LTS - Bionic Beaver

Architektur: 64-Bit PC

Desktop: GNOME 3.0

  • Nachricht senden

13

03.09.2018, 23:51

... selbes Problem aber nach Neuinstallation!

Hallo zusammen, ich habe komplett neu installiert und habe die selben Symptome! 30s Wartezeit.

Zitat von »cortlieb«

Begin: Runing /scripts/local-premount ...

In meiner FSTAB steht folgendes:
/dev/mapper/ubuntu--vg-root / ext4 errors=remount-ro 0 1
/dev/mapper/ubuntu--vg-swap_1 none swap sw 0 0
Also wie wird man die Sache nun los!?
LG

Horsemanchip

User

Beiträge: 1 131

Registrierungsdatum: 08.11.2015

Derivat: unbekannt

Version: gar kein Ubuntu

Architektur: 64-Bit PC

Desktop: LXDE

Andere Betriebssysteme: Debian bullseye-testing / 5.10.0-10-amd64

  • Nachricht senden

14

04.09.2018, 06:20

@cortlieb: Schau auch mal in dieser Datei, nach einem "RESUME= ..." Eintrag. -> /etc/initramfs-tools/initramfs.conf

Und folgende Ausgabe würde ich gern nochmal sehen:

Quellcode

 
1

cat /etc/initramfs-tools/conf.d/resume



@babalawo: Machst Du bitte dein eigenes Thema auf, im passenden Unterforum. Siehe Forenregeln dazu!
Heute ist keiner da! Komm morgen wieder. :-)

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »Horsemanchip« (04.09.2018, 06:39)

cortlieb

User

  • »cortlieb« ist der Autor dieses Themas

Beiträge: 21

Registrierungsdatum: 21.08.2017

Derivat: Ubuntu

Architektur: 64-Bit PC

Desktop: unbekannt

Andere Betriebssysteme: Windows10

  • Nachricht senden

15

05.09.2018, 22:54

Hello again,
hier der Inhalt von resume.

Quellcode

 
1
2

~$ cat /etc/initramfs-tools/conf.d/resume
RESUME=none

In /etc/initramfs-tools/initramfs.conf steht nichts von RESUME ;(
Äh - und übrigens vielen Dank für die Hilfe! :thumbsup:

Horsemanchip

User

Beiträge: 1 131

Registrierungsdatum: 08.11.2015

Derivat: unbekannt

Version: gar kein Ubuntu

Architektur: 64-Bit PC

Desktop: LXDE

Andere Betriebssysteme: Debian bullseye-testing / 5.10.0-10-amd64

  • Nachricht senden

16

06.09.2018, 10:56

Das resume File passt. Versuch es mal so:

Quellcode

 
1

sudo apt-get install --reinstall initramfs-tools


Ansonsten weiß ich nicht, woher der Eintrag genommen wird. Unter Debian läuft das alles über das resume File. Deine fstab zeigt ja auch auf das neues Swap File.

Nachtrag:

BEVOR Du das machst, setz mal folgendes Kommando ab, dann durchsuchen wir /etc nach der UUID deiner alten swap:

Quellcode

 
1

sudo grep -r "158de763-7c03-4cad-b48a-a9b242895335" /etc/


Kommt da was bei raus?
Heute ist keiner da! Komm morgen wieder. :-)

Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von »Horsemanchip« (06.09.2018, 12:25)

cortlieb

User

  • »cortlieb« ist der Autor dieses Themas

Beiträge: 21

Registrierungsdatum: 21.08.2017

Derivat: Ubuntu

Architektur: 64-Bit PC

Desktop: unbekannt

Andere Betriebssysteme: Windows10

  • Nachricht senden

17

09.09.2018, 15:24

Hallo,
die Suche nach der UUID war nicht sonderlich ergiebig:

Quellcode

 
1
2
3

~$cortlieb@Linux-Notebook:~$ sudo grep -r "158de763-7c03-4cad-b48a-a9b242895335" /etc/
[sudo] Passwort für cortlieb: 
cortlieb@Linux-Notebook:~$

Aber das Reinstallieren der initramfs-tools hat es gebracht!
Danach bootet das Notebook tatsächlich wieder wie vorher, das Hängen an der vorherigen Stelle gibt es nicht mehr!
Super, vielen Dank! :thumbsup:

Wenn du jetzt noch ein paar erklärende Worte dazu sagst, was ich da eigentlich gemacht habe, bin ich rundum glücklich :D und schließe diesen Thread.

Gruß Christian

Horsemanchip

User

Beiträge: 1 131

Registrierungsdatum: 08.11.2015

Derivat: unbekannt

Version: gar kein Ubuntu

Architektur: 64-Bit PC

Desktop: LXDE

Andere Betriebssysteme: Debian bullseye-testing / 5.10.0-10-amd64

  • Nachricht senden

18

09.09.2018, 21:50

Naja, dein altes Ubuntu 17.04 hat noch eine eigene Partition für Swap und die stand im resume file und deswegen wurde sie beim booten versucht zu nutzen.
Da sie aber nicht gefunden wurde, denn nach deinem Upgrade auf 18.04 nutzt Ubuntu ein Swap-File und keine Partition mehr, dauerte dein Boot länger bis zum timeout.

Jetzt haben wir nur die Partition aus dem resume File entfernt und initramfs-tools neu drüber gebügelt.

Warum unsere erste Konfiguration nicht geklappt hat, kann ich Dir nicht sagen.
Heute ist keiner da! Komm morgen wieder. :-)

cortlieb

User

  • »cortlieb« ist der Autor dieses Themas

Beiträge: 21

Registrierungsdatum: 21.08.2017

Derivat: Ubuntu

Architektur: 64-Bit PC

Desktop: unbekannt

Andere Betriebssysteme: Windows10

  • Nachricht senden

19

11.09.2018, 21:53

OK, soweit halbwegs klar.
Dann Danke ich dir nochmal und betrachte den Fall als gelöst! ^^

Ähnliche Themen

Verwendete Tags

Booten