hallo
ich habe mein system neu aufgesetzt mit debian.
wenn ich von der rettungscd boote und dann von dev/sda2 ein image auf dev/sda4 erstelle kommt beim anschliessenden neustart folgende meldung: last mount was in the future check forced
last check was 49000 days ago
aber nur bei sda4
hat jemand eine idee???
hängt das mit der uhrzeit von der rettungscd und dem normalen debian zusammen=´?
ext3 check forced
hi,
wenn du gelegentlich wegen leerer CMOS-Batterien oder
sonstwie kaputter PC-Uhren eine völlig falsche Uhrzeit hast,
ist dieser Effekt normal.
Im normalen Betrieb wird das evt. vertuscht, wenn du die Uhr
des Betriebssystems aus dem Internet stellst. Ein Live-System
macht das eher nicht, und schon hast du einen Fehler von z.B.
knapp 2 Jahren, was den 49000 Tagen entsprechen würde.
Waren das wirklich genau 49000? Wenn du die exakte Zahl in
Sekunden umrechnest und von 4294967296 abziehst, kommt
dann ein Zeitdifferenz raus, die dir bekannt vorkommt?
Gib mal ein bis drei dieser Befehle ein:
dabei werden u.a. alle interessanten Zeitpunkte angezeigt.
Evt. ist was aufälliges dabei, wenn man die mit der Anzeige
von "date" vergleicht.
wenn du gelegentlich wegen leerer CMOS-Batterien oder
sonstwie kaputter PC-Uhren eine völlig falsche Uhrzeit hast,
ist dieser Effekt normal.
Im normalen Betrieb wird das evt. vertuscht, wenn du die Uhr
des Betriebssystems aus dem Internet stellst. Ein Live-System
macht das eher nicht, und schon hast du einen Fehler von z.B.
knapp 2 Jahren, was den 49000 Tagen entsprechen würde.
Waren das wirklich genau 49000? Wenn du die exakte Zahl in
Sekunden umrechnest und von 4294967296 abziehst, kommt
dann ein Zeitdifferenz raus, die dir bekannt vorkommt?
Gib mal ein bis drei dieser Befehle ein:
Code: Alles auswählen
# tune2fs -l /pfad/zum/image
# tune2fs -l /dev/sda2
# tune2fs -l /dev/sda4Evt. ist was aufälliges dabei, wenn man die mit der Anzeige
von "date" vergleicht.
Beware of programmers who carry screwdrivers.
hallo,
vielen dank für die antwort. hm
also ein live system nutze ich nicht, die uhr stell ich nicht nach einem zeitserver und die cmos batterie ist nicht leer.
meine vermutung... kann mich aber irren
ich hab von einer live cd gebootet , dev/sda4 eingehängt und mit partimage ein image von sda2 auf sda4 gezogen.
durch das mounten wurde ein zeitstempel in das dateisystem geschrieben.
dann hab ich das laufwerk ausgehängt und neu gestartet.
debian wird vermutlich eine andere uhrzeit (sommer/winterzeit) haben und so war eine stunde zeitdifferenz.
das letzte mounten war also knapp eine stunde in der zukunft.
könnte das sein???
vielen dank für die antwort. hm
also ein live system nutze ich nicht, die uhr stell ich nicht nach einem zeitserver und die cmos batterie ist nicht leer.
meine vermutung... kann mich aber irren
ich hab von einer live cd gebootet , dev/sda4 eingehängt und mit partimage ein image von sda2 auf sda4 gezogen.
durch das mounten wurde ein zeitstempel in das dateisystem geschrieben.
dann hab ich das laufwerk ausgehängt und neu gestartet.
debian wird vermutlich eine andere uhrzeit (sommer/winterzeit) haben und so war eine stunde zeitdifferenz.
das letzte mounten war also knapp eine stunde in der zukunft.
könnte das sein???
-
habakug
- Moderator
- Beiträge: 4314
- Registriert: 23.10.2004 13:08:41
- Lizenz eigener Beiträge: MIT Lizenz
Hallo!
Das ist ein Bug in fsck der sich schon über Jahre hinzieht. Es kann bis zur Endlos-Schleife gehen.
Die Reihenfolge der Startskripte hat wohl damit zu tun.
Gruß, habakug
[1] https://bugs.launchpad.net/debian/+sour ... +bug/43239
[2] https://launchpad.net/ubuntu/+source/e2 ... +bug/63175
[3] https://bugs.launchpad.net/ubuntu/+sour ... +bug/89069
[4] https://bugs.launchpad.net/ubuntu/+sour ... +bug/43239
Noch nicht mal ein Jahr alt und so viel Ahnungcosmac hat geschrieben:...[...]und schon hast du einen Fehler von z.B.
knapp 2 Jahren, was den 49000 Tagen entsprechen würde.
Das ist ein Bug in fsck der sich schon über Jahre hinzieht. Es kann bis zur Endlos-Schleife gehen.
Die Reihenfolge der Startskripte hat wohl damit zu tun.
Gruß, habakug
[1] https://bugs.launchpad.net/debian/+sour ... +bug/43239
[2] https://launchpad.net/ubuntu/+source/e2 ... +bug/63175
[3] https://bugs.launchpad.net/ubuntu/+sour ... +bug/89069
[4] https://bugs.launchpad.net/ubuntu/+sour ... +bug/43239
Ok. anscheinend gibt es nen
Bug. Aber bei mir taucht der Fehler
nur ein einziges mal auf. Nach
dem fsck von der Rettungscd.
Vermutlich liegt es dann dcoh an
einer verstellten Uhrzeit mit der
Sommer Winterzeit. Debian wird wohl
beim Booten irgendwann auf
Winterzeit wechseln, w„hrend die
Rettungscd sich keine Gedanken macht
und dann eine Uhrzeit aus der
Zukunft eintr„gt.
W„hre so ein heftiger Bug nicht grad
bei Debian gefunden und behoben???
Bug. Aber bei mir taucht der Fehler
nur ein einziges mal auf. Nach
dem fsck von der Rettungscd.
Vermutlich liegt es dann dcoh an
einer verstellten Uhrzeit mit der
Sommer Winterzeit. Debian wird wohl
beim Booten irgendwann auf
Winterzeit wechseln, w„hrend die
Rettungscd sich keine Gedanken macht
und dann eine Uhrzeit aus der
Zukunft eintr„gt.
W„hre so ein heftiger Bug nicht grad
bei Debian gefunden und behoben???
Auf Dateisystem-Ebene gibt es bei Unix keine Sommer- oder
Winterzeit. Damit kann es höchstens dann zusammenhängen,
wenn die BIOS-Uhr von Hand (oder Windows) verstellt wurde.
Solange die auf UTC eingestellt ist, gibt es das Problem nicht.
Winterzeit. Damit kann es höchstens dann zusammenhängen,
wenn die BIOS-Uhr von Hand (oder Windows) verstellt wurde.
Solange die auf UTC eingestellt ist, gibt es das Problem nicht.
du sprichst in Rätseln, klär mich bitte auf.habakug hat geschrieben:Noch nicht mal ein Jahr alt und so viel Ahnung
Beware of programmers who carry screwdrivers.
Wenn die Zeitdifferenz z.B. genau eine Stunde gewesen wäre,
hätte ich auch erstmal auf ein Sommerzeit-Problem getippt,
zum Beispiel.
Da die Zeitstempel im ext2 unsigned 32 Bit sind, hab' ich die
49000 Tage als negativ interpretiert:
2^32 - (49000 * 24 * 60 * 60) = 61367296 Sekunden
oder knapp 2 Jahre.
Auf jeden Fall danke für den Tipp mit dem fsck-Bug!
hätte ich auch erstmal auf ein Sommerzeit-Problem getippt,
zum Beispiel.
Da die Zeitstempel im ext2 unsigned 32 Bit sind, hab' ich die
49000 Tage als negativ interpretiert:
2^32 - (49000 * 24 * 60 * 60) = 61367296 Sekunden
oder knapp 2 Jahre.
Auf jeden Fall danke für den Tipp mit dem fsck-Bug!
Beware of programmers who carry screwdrivers.
hallo cosmac
hmm nicht windows sondern ich glaub die rettungscd hat die uhr verstellt.
vieleicht arbeitet debian mit der sommer/winterzeit
während die rettungscd einfach die bios uhrzeit übernimmt.
und schon haben wir das dilemma das der letzte fs-mount in der zukunft liegt.
denn nach einem neustart trat es nicht mehr auf...
hmm nicht windows sondern ich glaub die rettungscd hat die uhr verstellt.
vieleicht arbeitet debian mit der sommer/winterzeit
während die rettungscd einfach die bios uhrzeit übernimmt.
und schon haben wir das dilemma das der letzte fs-mount in der zukunft liegt.
denn nach einem neustart trat es nicht mehr auf...
-
habakug
- Moderator
- Beiträge: 4314
- Registriert: 23.10.2004 13:08:41
- Lizenz eigener Beiträge: MIT Lizenz
Hallo!
So ähnlich heisst es auch in der Bug-Description [1]:
Man kann im Übrigen in den Bug-Descriptions Hinweise auf Dualboot-Systeme (Windows und Linux) und, wie schon erwähnt, die Reihenfolge der Start-Skripts (udev, hwclock und checkroot) finden.
Gruß, habakug
[1] https://bugs.launchpad.net/debian/+sour ... +bug/43239
So ähnlich heisst es auch in der Bug-Description [1]:
Ich schätze mal der Initiator dieses Threads hat die "49000" nur aus der Erinnerung eingesetzt.A quick google of "fsck 49710" gives out numerous examples, revealing inter alia that 49710 days is close to 2^32 seconds, and gives a clear indication that fsck simply isn't equipped to deal with a misconfigured system clock.
Man kann im Übrigen in den Bug-Descriptions Hinweise auf Dualboot-Systeme (Windows und Linux) und, wie schon erwähnt, die Reihenfolge der Start-Skripts (udev, hwclock und checkroot) finden.
Gruß, habakug
[1] https://bugs.launchpad.net/debian/+sour ... +bug/43239
ok
jetzt wird es interessant.
also:
die uhr ist nicht kaputt sondern funktioniert.
ich hab erst gedacht, das sommer winterzeit dran schuld ist. aber ist sie es???
linux speichert die uhrzeit doch als sekundenwert nach dem 1.1.1970
demnach ist es dann nicht egal, ob winter oder sommerzeit?
ich habe die platte gemountet
daten drauf geschrieben
dann hab ich unmount aufgerufen. die platte ist zu diesem zeitpunkt sauber ausgehängt.
als nächstes hab ich noch fsck /dev/sda4 -f laufen lassen.
es wurden keine fehler angezeigt.
dann ein reboot.
direkt beim ersten booten kam der fehler, bei weiteren bootvorgängen nicht mehr.
laut fsck war die platte sauber und da sie nicht eingehängt war kann sich eine zeit auch nicht merh verstellen.
es kann also nur was mit der uhrzeit zu tun haben...... oder???
jetzt wird es interessant.
also:
die uhr ist nicht kaputt sondern funktioniert.
ich hab erst gedacht, das sommer winterzeit dran schuld ist. aber ist sie es???
linux speichert die uhrzeit doch als sekundenwert nach dem 1.1.1970
demnach ist es dann nicht egal, ob winter oder sommerzeit?
ich habe die platte gemountet
daten drauf geschrieben
dann hab ich unmount aufgerufen. die platte ist zu diesem zeitpunkt sauber ausgehängt.
als nächstes hab ich noch fsck /dev/sda4 -f laufen lassen.
es wurden keine fehler angezeigt.
dann ein reboot.
direkt beim ersten booten kam der fehler, bei weiteren bootvorgängen nicht mehr.
laut fsck war die platte sauber und da sie nicht eingehängt war kann sich eine zeit auch nicht merh verstellen.
es kann also nur was mit der uhrzeit zu tun haben...... oder???