I am also getting this on my karmic upgrade from jaunty. I am running
with UTC=yes in my rcS. The problem in my case seems to arise from the
fact that the init scripts do not restore the system clock from the
hardware clock before launching into fsck.
I had to put the following into my
When the hardware clock is stored in UTC, the issue is of particular
visibility to those living in GMT-hh timezones and whose system clocks
go back in time on every boot until they're re-adjusted from the
hardware clock.
--
fsck halts bootup when checked file has timestamp in the future from
This issue has definitely been fixed.
If you are still seeing issues with the hardware or system clock, you do
not have *this* bug. You should file a new bug, so we can triage your
problems independently
Thanks
** Changed in: clock-setup (Ubuntu)
Status: Triaged = Fix Released
--
fsck
Right, this looks like a karmic installer bug ;)
I guess so: I've made a fresh install from karmic alpha 5 amd64 on a computer,
and almost each time I boot I get the timestamp in the future error. I'm not
dual booting with anything.
--
fsck halts bootup when checked file has timestamp in the
I suspect Colin already fixed this and will mark this as a dup of
another bug
--
fsck halts bootup when checked file has timestamp in the future from other
Ubuntu installation
https://bugs.launchpad.net/bugs/422869
You received this bug notification because you are a member of Ubuntu
Bugs,
Right, this looks like a karmic installer bug ;)
** Package changed: e2fsprogs (Ubuntu) = clock-setup (Ubuntu)
** Changed in: clock-setup (Ubuntu)
Status: Won't Fix = Triaged
--
fsck halts bootup when checked file has timestamp in the future from other
Ubuntu installation
I received my laptop with a windows installation on its first hard disk.
I installed Jaunty on the second disk and never booted into Windows on
the first, so I guess it was dual boot of sorts (albeit entirely
different disks/filesystems)
When I later installed Karmic I wiped the Windows disk to
status incomplete
On Tue, 2009-09-01 at 22:07 +, Theodore Ts'o wrote:
At a guess, your Jaunty and Karmic installations disagree about whether
the hardware clock should be to tick localtime or UTC time, and one of
the things the shutdown scripts do is to set the hardware clock from the
Jaunty: $ grep UTC /etc/default/rcS
UTC=no
--
fsck halts bootup when checked file has timestamp in the future from other
Ubuntu installation
https://bugs.launchpad.net/bugs/422869
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
Karmic: $ grep UTC etc/default/rcS
UTC=yes
--
fsck halts bootup when checked file has timestamp in the future from other
Ubuntu installation
https://bugs.launchpad.net/bugs/422869
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
Thanks.
That's a clear configuration issue.
You're dual-booting between two systems that are storing different
values in the hardware clock, and expecting to find different values
there.
It's no different to having UTC=yes and dual booting between Linux and
Windows, the hardware clock will go
Should it worry us that I don't remember ever actually set this manually
myself?
--
fsck halts bootup when checked file has timestamp in the future from other
Ubuntu installation
https://bugs.launchpad.net/bugs/422869
You received this bug notification because you are a member of Ubuntu
Bugs,
On Wed, 2009-09-02 at 15:48 +, Scott Ritchie wrote:
Should it worry us that I don't remember ever actually set this manually
myself?
Did you originally dual-boot with Windows?
Scott
--
Scott James Remnant
sc...@canonical.com
--
fsck halts bootup when checked file has timestamp in the
** Attachment added: Dependencies.txt
http://launchpadlibrarian.net/31182673/Dependencies.txt
--
fsck halts bootup when checked file has timestamp in the future from other
Ubuntu installation
https://bugs.launchpad.net/bugs/422869
You received this bug notification because you are a member
At a guess, your Jaunty and Karmic installations disagree about whether
the hardware clock should be to tick localtime or UTC time, and one of
the things the shutdown scripts do is to set the hardware clock from the
system clock. This causes the time at boot up to be incorrect until
NTP has a
I acknowledge that, however I don't think it's a reasonable assumption
for e2fsprogs to assume the system booting has the correct time in that
way -- failing to bootup and dumping the user to a recovery terminal
from the automatic check is probably the worst thing to do here.
--
fsck halts
There's an easy fix
Put the following in /etc/e2fsck.conf
[options]
buggy_init_scripts = 1
This used to be the default for Ubuntu systems, partially because
Ubuntu's init scripts *were* buggy, way back when, but partially also
because Ubuntu users don't seem to care about making
17 matches
Mail list logo
