[gelöst] Sehr langer Boot-Vorgang seit letztem du

[harley-peter]

Hallo,


seit dem letzten du dauert der Bootvorgang ca. 5 Minuten. Das Booten startet und nach ca. 10 s kommt die Meldung

Code: [Select]

/dev/sda3: Der Zeitpunkt des letzten Schreiben des Superblocks liegt in der Zukunft.
systemd-fsck [163] (weniger als 1 Tag wahrscheinlich auf Grund falsch gesetzter Hardware-Uhr) REPARIERT Danach steht die Kiste 3-4 Minuten bevor der Bootvorgang fortgesetzt und beendet wird. Das ist nicht kritisch aber lästig. Kann man das irgendwie beheben?


Mein System:

Code: [Select]

System:    Host: laptop Kernel: 3.16-3.towo-siduction-amd64 x86_64 (64 bit gcc: 4.9.1)
           Desktop: Xfce 4.10.2 (Gtk 2.24.18) Distro: sidux 2009-02 Αιθήρ - xfce - (200907141521)
Machine:   System: TOSHIBA product: Satellite A210 v: PSAFGE-06500RGR
           Mobo: ATI model: SB600 v: Rev 1 Bios: Phoenix v: 1.70 date: 02/22/2008
CPU:       Dual core AMD Athlon 64 X2 TK-57 (-MCP-) cache: 512 KB
           flags: (lm nx sse sse2 sse3 svm) bmips: 6386
           clock speeds: max: 1900 MHz 1: 1600 MHz 2: 1600 MHz
Graphics:  Card: Advanced Micro Devices [AMD/ATI] RS690M [Radeon Xpress 1200/1250/1270] bus-ID: 01:05.0
           Display Server: X.Org 1.16.1 driver: radeon Resolution: 1280x800@59.91hz
           GLX Renderer: Gallium 0.4 on ATI RS690 GLX Version: 2.1 Mesa 10.2.6 Direct Rendering: Yes
Network:   Card-1: Realtek RTL8101E/RTL8102E PCI Express Fast Ethernet controller
           driver: r8169 v: 2.3LK-NAPI port: a000 bus-ID: 08:00.0
           IF: eth0 state: down mac: 00:a0:d1:96:7a:05
           Card-2: Realtek RTL8187B Wireless Adapter driver: rtl8187 usb-ID: 001-003
           IF: wlan0 state: N/A mac: N/A
Drives:    HDD Total Size: 160.0GB (77.4% used) ID-1: model: TOSHIBA_MK1646GS
Info:      Processes: 154 Uptime: 48 min Memory: 679.8/1880.5MB Init: systemd runlevel: 5 Gcc sys: 4.9.1
           Client: Shell (bash 4.3.251) inxi: 2.2.12


[bluelupo]

Hi Peter,
ist die Uhr im BIOS richtig eingestellt?

[harley-peter]

Hi Michael,
gerade gecheckt, Datum und Uhrzeit sind o.k.

[bluelupo]

Hi Peter,
Zeitzone simmt? Evtl. hast du UTC eingestellt. Vielleicht hilft ein "Reconfigure":

Code: [Select]

# dpkg-reconfigure tzdata


[harley-peter]

Hi Michael,
ein "Reconfigure" hat leider auch nicht geholfen. Die Systemzeit im BIOS steht auf local time.

[spacepenguin]

Hast du noch ein weiteres System auf dem Rechner, in das du zwischenzeitlich gebootet hast?

[harley-peter]

Hhmm .... ja ... ein altes Windows Vista das ich letzte Woche mal benötigt habe.


Muss aber was mit dem aktuellen Kernel zu tun haben denn wenn ich in den 3.16-2 boote dann tritt das Problem nicht auf.

[jheaton5]

I have the same issue running a stock debian sid with 3.16-2-amd64 debian kernel.  It's got to be something with systemd.

[melmarker]

Hmm .. "it' got to be something with systemd" says absolutely nothing. So the post make no sense.

A simple hint as: Please run:

Code: [Select]

systemd-analyze blame and post the top 10 lines would be eventually helpful.

[jheaton5]

$ systemd-analyze blame
          2.335s mysql.service
           905ms kbd.service
           521ms NetworkManager.service
           489ms acpi-support.service
           413ms proftpd.service
           270ms exim4.service
           260ms ModemManager.service
           218ms binfmt-support.service
           212ms alsa-restore.service
           212ms console-kit-log-system-start.service
           205ms bluetooth.service
           155ms networking.service
 (END)

[melmarker]

So now your system look normal to me - in case of harley-peter the blame could show us the time consuming services - as i wrote, the top ten is enough, I don't think that we are interested in adding low amounts of milliseconds - but we are very interested in times in the range from ~1-n seconds.

[harley-peter]

hallo melmarker,
hier ist mein Auszug:

Code: [Select]

2min 57.499s systemd-fsck-root.service
         10.759s mysql.service
          6.201s nfs-common.service
          5.028s NetworkManager.service
          4.341s keyboard-setup.service
          4.140s clamav-freshclam.service
          2.645s sys-kernel-debug.mount
          2.486s dev-hugepages.mount
          2.483s dev-mqueue.mount
          2.117s alsa-restore.service
          2.116s pppd-dns.service


[melmarker]

ok - dann scheint es wirklich dieser doofe Filesystemcheck zu sein, der ewig dauert - das mit der Uhrzeit könnte ein Hinweis sein, den ich aber nicht wirklich deuten kann, selbiges gilt auch für:

Muss aber was mit dem aktuellen Kernel zu tun haben denn wenn ich in den 3.16-2 boote dann tritt das Problem nicht auf.

[hefee]

hast du ntp/ntpclient am laufen? Dann ist natürlich nachdem das system gebootet hat die uhrzeit korrekt. Wenn die Batterie auf dem Motherboard am Arsch ist, dann ist die Uhrzeit natürlich hin, wenn du den Rechner ausmachst. Am sicherersten bist du, wenn du den Rechner auschaltest und dann im BIOS die Uhrzeit überprüft. Auch ein spaßiges Problem kann sein, wenn ein anderes System auf dem Rechner ist , dass meint die BIOS Uhr in eine andere Zeitzone zu schuppsen...

[melmarker]

erm - ups sorry, wenn ich die lustige Fehlersuche so jäh unterbreche:

harley-peter: Alles Rumgestochere und Handauflegen wird wahrscheinlich nicht sonderlich viel bringen. Grund dürften die neuen initramfs-tools (0.117) sein - ein downgrade auf die Version aus testing wird ungewünschte Verhalten eventuell beheben. Wenn nicht von allein, ist noch ein update-initramfs -k all -u erforderlich.

Kurze Erläuterung: Wir haben bei unseren Isos seit 2 oder 3 Tagen auch ein unerklärliches Verhalten, dass ich jetzt per handauflegen wahrscheinlich auf die initramfs-tools runtergebrochen habe. Die Symptome ähneln denen von Dir zwar nicht 100%, aber doch deutlich. Mit meiner großen Klappe würde ich da von mindestens einer, wenn nicht noch mehr Regressionen reden wollen.