Siduction Forum
Siduction Forum => Upgrade Warnings => Topic started by: harley-peter on 2014/09/29, 08:35:48
-
Hallo,
seit dem letzten du dauert der Bootvorgang ca. 5 Minuten. Das Booten startet und nach ca. 10 s kommt die Meldung
/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:
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
-
Hi Peter,
ist die Uhr im BIOS richtig eingestellt?
-
Hi Michael,
gerade gecheckt, Datum und Uhrzeit sind o.k.
-
Hi Peter,
Zeitzone simmt? Evtl. hast du UTC eingestellt. Vielleicht hilft ein "Reconfigure":
# dpkg-reconfigure tzdata
-
Hi Michael,
ein "Reconfigure" hat leider auch nicht geholfen. Die Systemzeit im BIOS steht auf local time.
-
Hast du noch ein weiteres System auf dem Rechner, in das du zwischenzeitlich gebootet hast?
-
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.
-
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.
-
Hmm .. "it' got to be something with systemd" says absolutely nothing. So the post make no sense.
A simple hint as: Please run:
systemd-analyze blame and post the top 10 lines would be eventually helpful.
-
$ 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)
-
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.
-
hallo melmarker,
hier ist mein Auszug:
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
-
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.
-
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...
-
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.
-
Update: einfach noch mal einen d-u nachschieben - ich habe die initramfs-tools 0.117.2~really~0.116 hochgeladen. Ich hab damit ein paar ISOs gebaut - funktioniert gut, soweit ich es beurteilen kann. Eventuell ist noch ein update-initramfs -k all -u nachschieben und gut ists gewesen
-
Hi melmarker,
danke! Hat geklappt. Nach einem du ist wieder alles normal. Vielen Dank an alle für die Unterstützung.
Gruß
Peter
-
Hi,
seit einem der letzten du das gleiche Problem wieder. Ein systemd-analyze blame liefert:
2min 16.952s systemd-fsck-root.service
12.932s apache2.service
10.645s NetworkManager.service
9.259s mysql.service
8.752s systemd-logind.service
8.661s console-kit-log-system-start.service
8.657s alsa-restore.service
8.648s pppd-dns.service
8.600s lm-sensors.service
8.536s rc-local.service
8.532s ifplugd.service
8.531s systemd-user-sessions.service
8.531s ntp.service
8.530s loadcpufreq.service
8.522s rsyslog.service
8.518s virtualbox-guest-utils.service
8.517s wicd.service
8.516s lirc.service
8.504s sysstat.service
8.502s virtualbox.service
-
nö - gleich ist das problem nicht - das sind jetzt immerhin initramfs-tools 0.119 8)
3 mögliche Lösungsansätze:
* downgrade wie gehabt auf unsere gefixten Sachen, da kein unmittelbares Release ansteht, sehe ich also eigentlich nicht ein, ein neues Really-Paket zu bauen, das ist nur der wirklich letzte Ausweg. - Wenn dieser Ansatz gewählt wird, antackern des Pakets mit apt-mark hold nicht vergessen
* ein wenig Recherche, ob man das Verhalten vom filecheck eventuell konfigurieren könnte
* systemd aus experimental testen
Ich fall als Testperson aus, da ich auf meinen Installationen dieses Problem bisher nicht hatte oder hervorrufen konnten - und ich werde nicht deswegen auf Sid downgraden :)
-
Hi,
seit einem der letzten du das gleiche Problem wieder. Ein systemd-analyze blame liefert:
2min 16.952s systemd-fsck-root.service
In der Grub die cmdline editieren und hinzu fügen:
systemd.unit=emergency.target
Emergency bootet im readonly /-root Modus: Da kannst du mal fsck.ext4 drüber laufen lassen.
Anders rescue.target: Da kann man auch was in die /etc Einstellungen schreiben.
-
@ralul - was soll das bringen? Ok - vielleicht ist Deine Glaskugel moderer als meine, aber eine "Lösung" ohne ein echtes Problem ist und bleibt Mumpitz.
@peter: eventuell ist es die Zeit wert, mal zu erforschen, was den check auslöst - ich vermute mal, der wird im initramfs gestartet - und a gehört er nu wirklich nicht hin. Könnte auch durchaus auf das Alter der betroffenen Installation ankommen. Da wäre die Lösung einfach, einfach den hook für die Sachen löschen, wo auch immer er sich befindet. Das wäre kein Systemd-Problem. Das Auftreten nach der Erneuerung der Initramfs-Tools lässt mich das einfach mal irgendwie vermuten - ansonsten könnte ein erneuter Downgrade helfen.
-
Do all UUID match in fstab ?
If so
You can "TRY" and add noauto,x-systemd.automount to all partitions except / (of course). That "MAY" speed up your boot time.
You can always undo if it don't do nothing, doesn't hurt to try :)
-
Hi,
here is an other way to stop systemd-fsck@sirvice to check "/" at every boot,
take a look to the /etc/fstab
and change
UUID=foo-bar-n / ext4 defaults,relatime,errors=remount-ro 0 1
to
UUID=foo-bar-n / ext4 defaults,relatime,errors=remount-ro 0 0
cange the sixed row, where / (root) is, from 1 to 0 (zero)
and run
tune2fs -c 30 -i 30 /dev/sdxN
/dev/sdxN is the device with the root filesystem "/" like /dev/sda1 or /dev/sdb3 ...
You should find it out with: "df -hT".
greetz hendrikL
-
@ralul - was soll das bringen? Ok - vielleicht ist Deine Glaskugel moderer als meine, aber eine "Lösung" ohne ein echtes Problem ist und bleibt Mumpitz.
To not loose any data in case there is something wrong with the filesystem of root and the fsck service of systemd at the same time: I would recommend to fsck by hand using emergency.target at first!
... And then afterwards search the bug.