Alexander, please see my workaround posted with Bug #432070:
WORKAROUND:
Adding the following to "[options]" in /etc/e2fsck.conf, running
update-initramfs and rebooting fixed it for me:
buggy_init_scripts = 1
--
superblock last write time is in the future
https://bugs.launchpad.net/bugs/26
I found this bug report through bug #432070, and after reading this –
http://swiss.ubuntuforums.org/showthread.php?t=1330844 – topic on the
Ubuntu forums.
It seems many people are still affected by this bug, including me, and
it does not seem to be fixed in Ubuntu 9.10 as this bug report claims. I
I believe that the ubiquity task is Invalid now that there is a fix in
e2fsprogs.
** Changed in: ubiquity (Ubuntu Karmic)
Status: New => Invalid
--
superblock last write time is in the future
https://bugs.launchpad.net/bugs/268808
You received this bug notification because you are a membe
all of my kernels load now
after I did the
gedit /usr/share/initscripts/default.rcS
changed UTC line to UTC=no
it ran fsck once and loaded system then all kernels seem fine
does not do it anymore
--
superblock last write time is in the future
https://bugs.launchpad.net/bugs/268808
You received
This bug was fixed in the package e2fsprogs - 1.41.9-1ubuntu2
---
e2fsprogs (1.41.9-1ubuntu2) karmic; urgency=low
* Applied patch (sent upstream) to ignore a future last mount, write or
check time by up to 24 hrs when fsck called with -p ("preen", ie.
fix minor problems w
On Sat, 2009-10-10 at 20:19 +, Rob Speer wrote:
> Scott, that's a good explanation for how I can fix the situation in my
> case.
>
> Still, I don't think it's desirable to bail out to a root prompt just
> because the hardware clock is wrong, no matter how that came to be.
>
I agree.
Scott
-
I did this
gedit /usr/share/initscripts/default.rcS
changed UTC line to UTC=no
and no time issue that I see
it goes straight into fsck with me having to give the command
also no mention of mountall not loading so no double log in
--
superblock last write time is in the future
https://bugs.launc
Scott, that's a good explanation for how I can fix the situation in my
case.
Still, I don't think it's desirable to bail out to a root prompt just
because the hardware clock is wrong, no matter how that came to be.
--
superblock last write time is in the future
https://bugs.launchpad.net/bugs/26
I am on a desktop and this is a real pain I thought that it was an issue
with a partition and it completely keeps me from loading kernel 28.12 or
28.13 I can work with in the 28.11 but that means that I have to catch
it on load also I notice that this affects how x is loading my desktop
the polkit
On Thu, 2009-10-08 at 16:48 +, Rob Speer wrote:
> I interact with other computers that are on UTC. That strikes me as an
> undesirable workaround, when the bug is that dumping to a root shell and
> forcing a fsck is an inappropriate response to the clock being off by a
> few hours.
>
You misu
I second that, I can understand the behaviour on servers or other
mission critical systems, but there seems to be no point forcing an fsck
for such an issue on either desktops or mobile systems. Would be cool to
be able to enable/disable this feature with a mount option (eg.
mount=ignore_superbock_
I interact with other computers that are on UTC. That strikes me as an
undesirable workaround, when the bug is that dumping to a root shell and
forcing a fsck is an inappropriate response to the clock being off by a
few hours.
--
superblock last write time is in the future
https://bugs.launchpad.
On Wed, 2009-10-07 at 09:14 +, Rob Speer wrote:
> This happens to me because I dual boot, and Windows and Linux disagree
> about what time zone to set the system clock to. If Windows decides to
> change the time (which it sees as local EDT) to what the Internet says
> it is, and Linux is expec
This happens to me because I dual boot, and Windows and Linux disagree
about what time zone to set the system clock to. If Windows decides to
change the time (which it sees as local EDT) to what the Internet says
it is, and Linux is expecting to see UTC, then if I reboot into Linux
after less than
I'm having this issue eventough independent of the time zone. I'm
running on a laptop with a faulty battery (to be delivered soon).
Therefore the system time is always reset to some date in 2008. Under
Jaunty this caused a slightly annoying, yet automatic skipable fsck.
Under Karmic, I need to se
Of course, but partly it is because Ubiquity has set without asking UTC
to yes. After changing it to no the problem seems to be gone. This might
also a sysvinit bug because of the initializing.
--
superblock last write time is in the future
https://bugs.launchpad.net/bugs/268808
You received this
I also received a similar error after installing Ubuntu 9.10 on Sun
Virtual Box 3.0.6 r52128. I never had this problem with Ubuntu 9.04 on
VirtualBox. A screenshot of the error on my system is attached.
** Attachment added: "Superblock last mount time is in the future on Sun
VirtualBox"
http
Issues that happen after installing a new kernel are, of course, not
installer bugs.
--
superblock last write time is in the future
https://bugs.launchpad.net/bugs/268808
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs ma
Regarding Stefans comment: please also look at Bug #440281 which was
marked as a duplicate of this bug, but I believe it isn't.
--
superblock last write time is in the future
https://bugs.launchpad.net/bugs/268808
You received this bug notification because you are a member of Ubuntu
Bugs, which i
This is still an issue. It often happens after installing a new kernel.
--
superblock last write time is in the future
https://bugs.launchpad.net/bugs/268808
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ub
I'd have to take a look, but from memory it was from 2 or 3 days ago. I
guess just out of habit I just downloaded the daily spin, will the beta
be different? (I can try it later this day if you like)
--
superblock last write time is in the future
https://bugs.launchpad.net/bugs/268808
You receive
Most bizarre, as I was pretty confident that I'd already quite recently
made ubiquity change the clock before doing filesystem operations.
Please confirm the datestamp of the daily build you were using (and why
a daily build rather than the beta?).
Please note that we don't use the upstream ubiqui
I can confirm this, it is, in my opinion, a pretty nasty user experience
actually!
My user experience:
1. Switch new PC to linux (note, the system clock was set to local (Amsterdam)
time, which is 1 hour ahead of GMT)
2. Drop my shiny new daily build Karmic Netbook Remix cd in the drive,
install
** Also affects: ubiquity
Importance: Undecided
Status: New
--
superblock last write time is in the future
https://bugs.launchpad.net/bugs/268808
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubun
Thank you for taking the time to report this bug and helping to make Ubuntu
better. This bug did not have a package associated with it, which is important
for ensuring that it gets looked at by the proper developers. You can learn
more about finding the right package at
https://wiki.ubuntu.com/
25 matches
Mail list logo
