Hello,
I'm still having the same issue.
I made an update, and rebooted the machine which casued the error
appeared again.
I have a dual boot machine, but I have not run vista today yet.
And there's a 'screenshot' what happend after the restart right after
having updated all the packages:
Hello,
like I was afraid, having used older versions of e2fslibs and progs did
not change the situation, today (Sat 10.10.2009) I got the error again.
Next I updated all packages, and while rebooting I got the same error
again :(
Please have a look at the picture I took with my camera:
Let's try some simple and stupid debugging. Somebody who can reliably
reproduce the problem please add something like this to the *end* of
/lib/udev/rules.d/85-hwclock.rules :
KERNEL==rtc0, RUN+=/bin/touch /dev/rtc0-appeared
KERNEL==rtc0, RUN+=logger.agent
Hello,
I did try it and it was
[Marco d'Itri]
Petter determined that this works. I think that the real problem is
that the RUN rules in 85-hwclock.rules are only executed if
ENV{BADYEAR} exists.
Could be.
Importing /etc/default/rcS as if were a list of variables looks like
a bad idea to me anyway, so please replace the
On Mon, Oct 05, 2009 at 08:04:23AM +0200, Mader, Alexander (N-MSR) wrote:
Something additional: I am running a Debian kernel not a self built one,
and /lib/udev/rules.d/85-hwclock.rules was not there in the first place
so I had to create it.
That file is delivered by util-linux what
LaMont Jones schrieb:
On Mon, Oct 05, 2009 at 08:04:23AM +0200, Mader, Alexander (N-MSR) wrote:
Something additional: I am running a Debian kernel not a self built one,
and /lib/udev/rules.d/85-hwclock.rules was not there in the first place
so I had to create it.
That file is delivered by
Hi!
The two lines in /lib/udev/rules.d/85-hwclock.rules didn't change a thing for
me. Btw, I'm using the 2.6.30er kernel from here:
http://kernel-archive.buildserver.net/debian-kernel sid main
Since the last Debian update, however, the fsck problem doesn't
seem to appear anymore.
My guess is
Hello,
this is my first post here, and I'd like to report the bug is also affecting
me.
I have been using Debian unstable (AMD64) for about two years (with regular
updates every several days), and the issue started to occur around the
beginning of August (never had this problem before).
My first
On Sep 25, Marco d'Itri m...@linux.it wrote:
KERNEL==rtc0, RUN+=logger.agent
Petter determined that this works. I think that the real problem is
that the RUN rules in 85-hwclock.rules are only executed if
ENV{BADYEAR} exists.
Importing /etc/default/rcS as if were a list of variables looks like a
[LaMont Jones]
I completely agree on the severity, and would love to hear from the
people who convinced me this would work. again.
I guess that was me and Scott. :)
The idea was to allow the init.d scripts detect when udev would take
care of setting the system clock from the hardware clock
On Sep 25, Petter Reinholdtsen p...@hungry.com wrote:
I was told that udev would run the udev rule to set the system clock
if it was enabled, and thus believed it would be sufficient to look
for the existence of /dev/.udev to decode when to disable the init.d
scripts. Obviously this
severity 543375 serious
thanks
No response from the maintainers, no action, raising the priority.
that is happening again and again, although it never happened in all
the many years I am using Debian before. Now it
is getting a pain, esp when you are watching the system fs[u]ck-ing
away
On Thu, Sep 24, 2009 at 02:54:31PM +0200, Norbert Preining wrote:
No response from the maintainers, no action, raising the priority.
that is happening again and again, although it never happened in all
the many years I am using Debian before. Now it
is getting a pain, esp when you are
Dear maintainers of util-linux,
since it happened again, I dare to ask if there is any comment from your
side on that matter? It cannot be that normal booting forces me to
fsck the whole partition.
On Mo, 24 Aug 2009, Norbert Preining wrote:
Hi Petter,
sorry for my ignorance ...
On Mon,
Package: initscripts
Version: 2.87dsf-2
Severity: important
Dear maintainers,
I am not sure whom this bug belongs, please reassign accordingly.
Since some time (probably update of initscripts that pulled in insserv,
but hard to say) it happens sometimes that at booting time I see:
...
[Norbert Preining]
Dear maintainers,
I am not sure whom this bug belongs, please reassign accordingly.
I suspect a combination of things, and udev, util-linux, tzdata or
initscripts are probably the source of your problem.
Can you provide the output from these commands:
ls -ld
Hi Petter,
On Mon, 24 Aug 2009, Petter Reinholdtsen wrote:
Can you provide the output from these commands:
Sure:
ls -ld /etc/localtime /dev/.udev
drwxr-xr-x 6 root root 140 2009-08-24 19:53 /dev/.udev
-rw-r--r-- 1 root root 2211 2009-08-21 16:53 /etc/localtime
grep ^UTC /etc/default/rcS
[Norbert Preining]
The problem will happen when HW clock is not on UTC and /usr/ is a
separate partition from /.
No separate partition here.
No hardware clock on UTC either. One last thing to check. What is
the output from 'ls -l /dev/rtc; lsmod|grep rtc'?
I suspect your machine boot so
On Mon, 24 Aug 2009, Petter Reinholdtsen wrote:
No hardware clock on UTC either. One last thing to check. What is
the output from 'ls -l /dev/rtc; lsmod|grep rtc'?
lrwxrwxrwx 1 root root 4 2009-08-24 21:51 /dev/rtc - rtc0
$ ls -l /dev/rtc0
crw-rw 1 root root 254, 0 2009-08-24 21:51
reassign 543375 util-linux
thanks
[Norbert Preining]
no module, but self compiled kernel
Oh. No idea if the udev hooks are called when there is no kernel
module loading.
What should then happen?
Then the system clock should be set from the hardware clock in
hwclockfirst.sh which is called
Hi Petter,
sorry for my ignorance ...
On Mon, 24 Aug 2009, Petter Reinholdtsen wrote:
no module, but self compiled kernel
Oh. No idea if the udev hooks are called when there is no kernel
module loading.
Me neither, but I guess that a init script checks for *modules* would
be quite, well,
21 matches
Mail list logo
