On Jan 9, 2008 12:07 AM, Tuomo Valkonen <[EMAIL PROTECTED]> wrote:
> One should always indicate the version of software when complaining. Well,
>
> $ uname -a
> Linux noi 2.6.14 #1 PREEMPT Sun Oct 30 20:18:48 EET 2005 i686 GNU/Linux
>
> I've tried upgrading, and failed: the megatonne
On Jan 9, 2008 12:07 AM, Tuomo Valkonen [EMAIL PROTECTED] wrote:
One should always indicate the version of software when complaining. Well,
$ uname -a
Linux noi 2.6.14 #1 PREEMPT Sun Oct 30 20:18:48 EET 2005 i686 GNU/Linux
I've tried upgrading, and failed: the megatonne monolith with
On Tue, Jan 15, 2008 at 02:09:02AM +0100, Krzysztof Halasa wrote:
> Right, I remember some reports about that, probably IOAPIC or other
> HPET issues. Personally never seen that. Thus the suggestion of kernel
> upgrade.
I believe the ATI chipset managed to somehow get the timer interrupt to
arive
On Tue, Jan 15, 2008 at 12:13:51AM +0100, Alejandro Riveira Fern??ndez wrote:
> My experience too with a Uli 1697 based mb. Estrange clock behaviour with
> kernel around .15-20 but fixed now (suffering too with ext3 fsck now i use
> jfs)
>
> Back in the day i blamed the new mb but now that it
On Tue, Jan 15, 2008 at 02:09:02AM +0100, Krzysztof Halasa wrote:
Right, I remember some reports about that, probably IOAPIC or other
HPET issues. Personally never seen that. Thus the suggestion of kernel
upgrade.
I believe the ATI chipset managed to somehow get the timer interrupt to
arive
[EMAIL PROTECTED] (Lennart Sorensen) writes:
> I remember my nforce2 board having totally insane clock behaviour back
> around 2.6.14/2.6.15 or so. It has since been fixed in newer kernels.
> I seem to recall some ATI chipsets were even more insane than the nvidia
> at the time, with some
El Mon, 14 Jan 2008 11:18:28 -0500
[EMAIL PROTECTED] (Lennart Sorensen) escribió:
> On Mon, Jan 14, 2008 at 01:46:56PM +0100, Krzysztof Halasa wrote:
> > Nothing will make it work reliably if the system clock isn't stable.
>
> I remember my nforce2 board having totally insane clock behaviour
Tuomo Valkonen wrote:
On 2008-01-13 18:11 -0500, Theodore Tso wrote:
It's much more likely that this early in your boot cycle, your clock is
sometimes incorrect.
I doubt it. I get this nearly _always_ when the system crashes, which
accounts for the vast majority of the times I boot it. (I
On Mon, Jan 14, 2008 at 01:46:56PM +0100, Krzysztof Halasa wrote:
> Nothing will make it work reliably if the system clock isn't stable.
I remember my nforce2 board having totally insane clock behaviour back
around 2.6.14/2.6.15 or so. It has since been fixed in newer kernels.
I seem to recall
On 2008-01-14, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> It sounds like you have CONFIG_PM_TRACE turned on. From the Kconfig help:
It isn't listed in /proc/config.gz. No, I don't think I even have
swsusp stuff compiled in, if it's related to that.
--
Tuomo
--
To unsubscribe from this
On 1/14/08, Tuomo Valkonen <[EMAIL PROTECTED]> wrote:
> On 2008-01-13 18:11 -0500, Theodore Tso wrote:
> > It's much more likely that this early in your boot cycle, your clock is
> > sometimes incorrect.
>
> I doubt it. I get this nearly _always_ when the system crashes, which
> accounts for the
Tuomo Valkonen <[EMAIL PROTECTED]> writes:
>> So why don't you fix it first? Correct system time is essential.
>
> I've tried tuning it with adjtimex and everything, and sometimes it
> works for days, but then just suddenly the clock starts advancing.
Nothing will make it work reliably if the
On 2008-01-14, Bernd Petrovitsch <[EMAIL PROTECTED]> wrote:
> But for normal PCs, I don't know how much the quality of a PSU is
> relevant for the speed of the clock.
> Can you test with a different PSU?
I am testing right now. After all I had to get a new PSU, the old one
being as dead as a
On Mon, 2008-01-14 at 13:11 +0200, Tuomo Valkonen wrote:
> On 2008-01-14 10:57 +0100, Bernd Petrovitsch wrote:
> > That leads to the question why the clock starts to run like crazy at
> > some time so that `ntpd` can't cope with it.
>
> I do wonder whether the PSU could've been causing it. Now
On 2008-01-14 10:57 +0100, Bernd Petrovitsch wrote:
> That leads to the question why the clock starts to run like crazy at
> some time so that `ntpd` can't cope with it.
I do wonder whether the PSU could've been causing it. Now that think
about it, I got the PSU around two years ago, just like I
On 2008-01-14 11:06 +0100, Krzysztof Halasa wrote:
> So why don't you fix it first? Correct system time is essential.
I've tried tuning it with adjtimex and everything, and sometimes it
works for days, but then just suddenly the clock starts advancing.
> I guess I would upgrade to some newer
On Mon, 14 Jan 2008 10:57:09 +0100
Bernd Petrovitsch <[EMAIL PROTECTED]> wrote:
> On Mon, 2008-01-14 at 09:48 +, Tuomo Valkonen wrote:
> > On 2008-01-14, Bernd Petrovitsch <[EMAIL PROTECTED]> wrote:
> > > Yes, that is a usual bug/problem in common distributions[0] as
> > > there is no real
Tuomo Valkonen <[EMAIL PROTECTED]> writes:
> It isn't, right after boot. But while the system is on, it sometimes
> starts advancing very fast, 15min a day or so.
So why don't you fix it first? Correct system time is essential.
I guess I would upgrade to some newer version, perhaps one which
On Mon, 2008-01-14 at 09:48 +, Tuomo Valkonen wrote:
> On 2008-01-14, Bernd Petrovitsch <[EMAIL PROTECTED]> wrote:
> > Yes, that is a usual bug/problem in common distributions[0] as there is
> > no real guarantee that your clock is not far off.
>
> It isn't, right after boot. But while the
On 2008-01-14, Bernd Petrovitsch <[EMAIL PROTECTED]> wrote:
> Yes, that is a usual bug/problem in common distributions[0] as there is
> no real guarantee that your clock is not far off.
It isn't, right after boot. But while the system is on, it sometimes
starts advancing very fast, 15min a day or
On Mon, 2008-01-14 at 09:15 +0200, Tuomo Valkonen wrote:
[...]
> ntpdate isn't run by any of the init scripts. ntpd is, but like I
Yes, that is a usual bug/problem in common distributions[0] as there is
no real guarantee that your clock is not far off.
Add your timeservers in
On Mon, 2008-01-14 at 09:15 +0200, Tuomo Valkonen wrote:
[...]
ntpdate isn't run by any of the init scripts. ntpd is, but like I
Yes, that is a usual bug/problem in common distributions[0] as there is
no real guarantee that your clock is not far off.
Add your timeservers in
On 2008-01-14, Bernd Petrovitsch [EMAIL PROTECTED] wrote:
Yes, that is a usual bug/problem in common distributions[0] as there is
no real guarantee that your clock is not far off.
It isn't, right after boot. But while the system is on, it sometimes
starts advancing very fast, 15min a day or so.
On Mon, 2008-01-14 at 09:48 +, Tuomo Valkonen wrote:
On 2008-01-14, Bernd Petrovitsch [EMAIL PROTECTED] wrote:
Yes, that is a usual bug/problem in common distributions[0] as there is
no real guarantee that your clock is not far off.
It isn't, right after boot. But while the system is
Tuomo Valkonen [EMAIL PROTECTED] writes:
It isn't, right after boot. But while the system is on, it sometimes
starts advancing very fast, 15min a day or so.
So why don't you fix it first? Correct system time is essential.
I guess I would upgrade to some newer version, perhaps one which isn't
On Mon, 14 Jan 2008 10:57:09 +0100
Bernd Petrovitsch [EMAIL PROTECTED] wrote:
On Mon, 2008-01-14 at 09:48 +, Tuomo Valkonen wrote:
On 2008-01-14, Bernd Petrovitsch [EMAIL PROTECTED] wrote:
Yes, that is a usual bug/problem in common distributions[0] as
there is no real guarantee that
On Mon, 2008-01-14 at 13:11 +0200, Tuomo Valkonen wrote:
On 2008-01-14 10:57 +0100, Bernd Petrovitsch wrote:
That leads to the question why the clock starts to run like crazy at
some time so that `ntpd` can't cope with it.
I do wonder whether the PSU could've been causing it. Now that
On 2008-01-14, Bernd Petrovitsch [EMAIL PROTECTED] wrote:
But for normal PCs, I don't know how much the quality of a PSU is
relevant for the speed of the clock.
Can you test with a different PSU?
I am testing right now. After all I had to get a new PSU, the old one
being as dead as a rock. But
Tuomo Valkonen [EMAIL PROTECTED] writes:
So why don't you fix it first? Correct system time is essential.
I've tried tuning it with adjtimex and everything, and sometimes it
works for days, but then just suddenly the clock starts advancing.
Nothing will make it work reliably if the system
On 1/14/08, Tuomo Valkonen [EMAIL PROTECTED] wrote:
On 2008-01-13 18:11 -0500, Theodore Tso wrote:
It's much more likely that this early in your boot cycle, your clock is
sometimes incorrect.
I doubt it. I get this nearly _always_ when the system crashes, which
accounts for the vast
On Mon, Jan 14, 2008 at 01:46:56PM +0100, Krzysztof Halasa wrote:
Nothing will make it work reliably if the system clock isn't stable.
I remember my nforce2 board having totally insane clock behaviour back
around 2.6.14/2.6.15 or so. It has since been fixed in newer kernels.
I seem to recall
On 2008-01-14, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
It sounds like you have CONFIG_PM_TRACE turned on. From the Kconfig help:
It isn't listed in /proc/config.gz. No, I don't think I even have
swsusp stuff compiled in, if it's related to that.
--
Tuomo
--
To unsubscribe from this list:
Tuomo Valkonen wrote:
On 2008-01-13 18:11 -0500, Theodore Tso wrote:
It's much more likely that this early in your boot cycle, your clock is
sometimes incorrect.
I doubt it. I get this nearly _always_ when the system crashes, which
accounts for the vast majority of the times I boot it. (I
El Mon, 14 Jan 2008 11:18:28 -0500
[EMAIL PROTECTED] (Lennart Sorensen) escribió:
On Mon, Jan 14, 2008 at 01:46:56PM +0100, Krzysztof Halasa wrote:
Nothing will make it work reliably if the system clock isn't stable.
I remember my nforce2 board having totally insane clock behaviour back
[EMAIL PROTECTED] (Lennart Sorensen) writes:
I remember my nforce2 board having totally insane clock behaviour back
around 2.6.14/2.6.15 or so. It has since been fixed in newer kernels.
I seem to recall some ATI chipsets were even more insane than the nvidia
at the time, with some running
On 2008-01-13 18:11 -0500, Theodore Tso wrote:
> It's much more likely that this early in your boot cycle, your clock is
> sometimes incorrect.
I doubt it. I get this nearly _always_ when the system crashes, which
accounts for the vast majority of the times I boot it. (I wish swsusp
didn't suck
In article <[EMAIL PROTECTED]> you wrote:
> Just to clarify, I had about 60 days of uptime, and hence at least
> 60 days since the last FS check/mount/etc., when Linux crashed those
> few days ago, and wanted to start checking disks with "9192 days since
> last file system check".
This, however
On Mon, Jan 14, 2008 at 12:23:10AM +0200, Tuomo Valkonen wrote:
> On 2008-01-14 00:13 +0200, Tuomo Valkonen wrote:
> > Also, I must say that e2fsck is brain-damaged, if it can be confused
> > by/do the stupid then when the system clock has warped by just a few
> > hours, not the _days_ that a
On 2008-01-14 00:13 +0200, Tuomo Valkonen wrote:
> Also, I must say that e2fsck is brain-damaged, if it can be confused
> by/do the stupid then when the system clock has warped by just a few
> hours, not the _days_ that a file system check interval typically is,
> and users need to specifically
On 2008-01-12 10:06 -0500, Theodore Tso wrote:
> So running the "date" command after the boot sequence is completely
> finished. That doesn't mean that system clock was correct at the time
> when fsck is run.
Unless ntpd has managed to change it by that time, it was correct,
in the local time
On 2008-01-12 10:06 -0500, Theodore Tso wrote:
So running the date command after the boot sequence is completely
finished. That doesn't mean that system clock was correct at the time
when fsck is run.
Unless ntpd has managed to change it by that time, it was correct,
in the local time
On 2008-01-14 00:13 +0200, Tuomo Valkonen wrote:
Also, I must say that e2fsck is brain-damaged, if it can be confused
by/do the stupid then when the system clock has warped by just a few
hours, not the _days_ that a file system check interval typically is,
and users need to specifically
On Mon, Jan 14, 2008 at 12:23:10AM +0200, Tuomo Valkonen wrote:
On 2008-01-14 00:13 +0200, Tuomo Valkonen wrote:
Also, I must say that e2fsck is brain-damaged, if it can be confused
by/do the stupid then when the system clock has warped by just a few
hours, not the _days_ that a file
In article [EMAIL PROTECTED] you wrote:
Just to clarify, I had about 60 days of uptime, and hence at least
60 days since the last FS check/mount/etc., when Linux crashed those
few days ago, and wanted to start checking disks with 9192 days since
last file system check.
This, however sounds
On 2008-01-13 18:11 -0500, Theodore Tso wrote:
It's much more likely that this early in your boot cycle, your clock is
sometimes incorrect.
I doubt it. I get this nearly _always_ when the system crashes, which
accounts for the vast majority of the times I boot it. (I wish swsusp
didn't suck so
On Jan 12, 2008 10:06 AM, Theodore Tso <[EMAIL PROTECTED]> wrote:
[snip]
> Unfortunately Ubuntu users [snip] fit this demographic hugely, and
> Ubuntu refuses to fix this problem[1], so it's been personally very
> vexing, because the users complain to *me*, and I can't fix the problem,
> because
On Thu, Jan 10, 2008 at 03:41:11PM +0200, Tuomo Valkonen wrote:
> On 2008-01-10 08:16 -0500, Theodore Tso wrote:
> > > It displays just the right time. On boot anyway. (Linux has had some
> > > serious problems keeping the time after the switch from 2.6.7 to 2.6.14,
> > > advanding even 15 minutes
On 12.01.2008 18:10, TimC wrote:
> Bodo Eggert <[EMAIL PROTECTED]> said on Sat, 12 Jan 2008 02:41:17 +0100 (CET):
> > On Fri, 11 Jan 2008, Lennart Sorensen wrote:
> > > On Fri, Jan 11, 2008 at 05:22:45PM +0100, Bodo Eggert wrote:
> >
> > > > What can happen if someone does tune2fs -Lroot
On 12.01.2008 18:10, TimC wrote:
Bodo Eggert [EMAIL PROTECTED] said on Sat, 12 Jan 2008 02:41:17 +0100 (CET):
On Fri, 11 Jan 2008, Lennart Sorensen wrote:
On Fri, Jan 11, 2008 at 05:22:45PM +0100, Bodo Eggert wrote:
What can happen if someone does tune2fs -Lroot /dev/usbstick
and
On Thu, Jan 10, 2008 at 03:41:11PM +0200, Tuomo Valkonen wrote:
On 2008-01-10 08:16 -0500, Theodore Tso wrote:
It displays just the right time. On boot anyway. (Linux has had some
serious problems keeping the time after the switch from 2.6.7 to 2.6.14,
advanding even 15 minutes a day --
On Jan 12, 2008 10:06 AM, Theodore Tso [EMAIL PROTECTED] wrote:
[snip]
Unfortunately Ubuntu users [snip] fit this demographic hugely, and
Ubuntu refuses to fix this problem[1], so it's been personally very
vexing, because the users complain to *me*, and I can't fix the problem,
because it's a
Bodo Eggert <[EMAIL PROTECTED]> said on Sat, 12 Jan 2008 02:41:17 +0100 (CET):
> On Fri, 11 Jan 2008, Lennart Sorensen wrote:
> > On Fri, Jan 11, 2008 at 05:22:45PM +0100, Bodo Eggert wrote:
>
> > > What can happen if someone does tune2fs -Lroot /dev/usbstick
> > > and puts that stick into this
On Fri, 11 Jan 2008, Lennart Sorensen wrote:
> On Fri, Jan 11, 2008 at 05:22:45PM +0100, Bodo Eggert wrote:
> > What can happen if someone does tune2fs -Lroot /dev/usbstick
> > and puts that stick into this system?
>
> Don't know. I use UUIDs rather than LABELs. Having duplicated labels
> just
On Fri, Jan 11, 2008 at 05:22:45PM +0100, Bodo Eggert wrote:
> What can happen if someone does tune2fs -Lroot /dev/usbstick
> and puts that stick into this system?
Don't know. I use UUIDs rather than LABELs. Having duplicated labels
just means being careless. Having duplicate UUIDs should
Matthias Schniedermeyer <[EMAIL PROTECTED]> wrote:
>> > Don't use udev then. Good old static dev works fine if you have a fixed
>> > set of devices.
>>
>> It doesn't, with the unpredictable SCSI mapping insanity.
>
> That what LABEL und UUID-Support in mount is for.
>
> You label the
On Fri, Jan 11, 2008 at 05:22:45PM +0100, Bodo Eggert wrote:
What can happen if someone does tune2fs -Lroot /dev/usbstick
and puts that stick into this system?
Don't know. I use UUIDs rather than LABELs. Having duplicated labels
just means being careless. Having duplicate UUIDs should
Matthias Schniedermeyer [EMAIL PROTECTED] wrote:
Don't use udev then. Good old static dev works fine if you have a fixed
set of devices.
It doesn't, with the unpredictable SCSI mapping insanity.
That what LABEL und UUID-Support in mount is for.
You label the filesystems (e2label for
On Fri, 11 Jan 2008, Lennart Sorensen wrote:
On Fri, Jan 11, 2008 at 05:22:45PM +0100, Bodo Eggert wrote:
What can happen if someone does tune2fs -Lroot /dev/usbstick
and puts that stick into this system?
Don't know. I use UUIDs rather than LABELs. Having duplicated labels
just means
Bodo Eggert [EMAIL PROTECTED] said on Sat, 12 Jan 2008 02:41:17 +0100 (CET):
On Fri, 11 Jan 2008, Lennart Sorensen wrote:
On Fri, Jan 11, 2008 at 05:22:45PM +0100, Bodo Eggert wrote:
What can happen if someone does tune2fs -Lroot /dev/usbstick
and puts that stick into this system?
On 10.01.2008 12:30, Helge Hafting wrote:
> Matthias Schniedermeyer wrote:
Don't use udev then. Good old static dev works fine if you have a fixed
set of devices.
>>> It doesn't, with the unpredictable SCSI mapping insanity.
>>>
>>
>> That what LABEL und UUID-Support in
On Thu, Jan 10, 2008 at 12:30:31PM +0100, Helge Hafting wrote:
> >- fstab -
> >LABEL=root /xfs defaults,noatime0 1
> >LABEL=boot /bootext2defaults,noatime0 2
> >
> Would've been nice if they worked, but they don't.
>
> Disks should be so easy to identify
On 2008-01-10 08:16 -0500, Theodore Tso wrote:
> > It displays just the right time. On boot anyway. (Linux has had some
> > serious problems keeping the time after the switch from 2.6.7 to 2.6.14,
> > advanding even 15 minutes a day -- that ntpd doesn't seem to be able
> > to keep up with --
On Wed, Jan 09, 2008 at 02:16:52PM +, Tuomo Valkonen wrote:
> On 2008-01-09, Mathieu SEGAUD <[EMAIL PROTECTED]> wrote:
> > fix your hardware clock then
>
> It displays just the right time. On boot anyway. (Linux has had some
> serious problems keeping the time after the switch from 2.6.7 to
Matthias Schniedermeyer wrote:
Don't use udev then. Good old static dev works fine if you have a fixed
set of devices.
It doesn't, with the unpredictable SCSI mapping insanity.
That what LABEL und UUID-Support in mount is for.
You label the filesystems (e2label for ext2 and ext3)
Matthias Schniedermeyer wrote:
Don't use udev then. Good old static dev works fine if you have a fixed
set of devices.
It doesn't, with the unpredictable SCSI mapping insanity.
That what LABEL und UUID-Support in mount is for.
You label the filesystems (e2label for ext2 and ext3)
On Wed, Jan 09, 2008 at 02:16:52PM +, Tuomo Valkonen wrote:
On 2008-01-09, Mathieu SEGAUD [EMAIL PROTECTED] wrote:
fix your hardware clock then
It displays just the right time. On boot anyway. (Linux has had some
serious problems keeping the time after the switch from 2.6.7 to 2.6.14,
On 2008-01-10 08:16 -0500, Theodore Tso wrote:
It displays just the right time. On boot anyway. (Linux has had some
serious problems keeping the time after the switch from 2.6.7 to 2.6.14,
advanding even 15 minutes a day -- that ntpd doesn't seem to be able
to keep up with -- requiring
On Thu, Jan 10, 2008 at 12:30:31PM +0100, Helge Hafting wrote:
- fstab -
LABEL=root /xfs defaults,noatime0 1
LABEL=boot /bootext2defaults,noatime0 2
Would've been nice if they worked, but they don't.
Disks should be so easy to identify uniquely,
On 10.01.2008 12:30, Helge Hafting wrote:
Matthias Schniedermeyer wrote:
Don't use udev then. Good old static dev works fine if you have a fixed
set of devices.
It doesn't, with the unpredictable SCSI mapping insanity.
That what LABEL und UUID-Support in mount is for.
You
On Jan 9, 2008 2:53 PM, Martin Schwidefsky <[EMAIL PROTECTED]> wrote:
> On Jan 9, 2008 1:25 PM, Theodore Tso <[EMAIL PROTECTED]> wrote:
> > On Wed, Jan 09, 2008 at 10:54:11AM +0100, Martin Schwidefsky wrote:
> > > Actually you can force Windows to accept a hardware clock in UTC:
> > >
On 2008-01-09, Mathieu SEGAUD <[EMAIL PROTECTED]> wrote:
> fix your hardware clock then
It displays just the right time. On boot anyway. (Linux has had some
serious problems keeping the time after the switch from 2.6.7 to 2.6.14,
advanding even 15 minutes a day -- that ntpd doesn't seem to be
On Jan 9, 2008 1:25 PM, Theodore Tso <[EMAIL PROTECTED]> wrote:
> On Wed, Jan 09, 2008 at 10:54:11AM +0100, Martin Schwidefsky wrote:
> > Actually you can force Windows to accept a hardware clock in UTC:
> > HKEY_LOCAL_MACHINE/SYSTEMCurrentControlSetControl/TimeZoneInformation/RealTimeIsUniversal
Vous m'avez dit récemment :
> On 2008-01-08, John Stoffel <[EMAIL PROTECTED]> wrote:
>> Look at your filesystems, using 'tune2fs' and see if the ext3 journal
>> is actually turned on and used. If it's not, then I can see why
>> you're having problems on reboots.
>
> Journalling is on, but it's
On Wed, Jan 09, 2008 at 02:55:53AM -0500, [EMAIL PROTECTED] wrote:
>
> Does this create a snapshot of the *disk* at that moment, or does it
> capture "disk plus still-to-be-written blocks in the cache"?
> (Phrased differently, does it Do The Right Thing regarding "blocks
> queued before lvcreate"
On Wed, 9 Jan 2008 07:25:56 -0500
Theodore Tso <[EMAIL PROTECTED]> wrote:
> On Wed, Jan 09, 2008 at 10:54:11AM +0100, Martin Schwidefsky wrote:
> > On Jan 8, 2008 7:15 PM, Theodore Tso <[EMAIL PROTECTED]> wrote:
> > > That will fix the this issue. The problem you are facing is that
> > > you
On Wed, Jan 09, 2008 at 11:28:21AM +0100, Matthias Schniedermeyer wrote:
> On 09.01.2008 11:21, Matthias Schniedermeyer wrote:
> > On 09.01.2008 09:56, Tuomo Valkonen wrote:
> > > On 2008-01-09 00:06 +0100, Matthias Schniedermeyer wrote:
> > > > That what LABEL und UUID-Support in mount is for.
>
On Wed, Jan 09, 2008 at 10:54:11AM +0100, Martin Schwidefsky wrote:
> On Jan 8, 2008 7:15 PM, Theodore Tso <[EMAIL PROTECTED]> wrote:
> > That will fix the this issue. The problem you are facing is that you
> > have your hardware clock set to ticking localtime, instead of GMT.
> > Windows ticks
On 09.01.2008 11:21, Matthias Schniedermeyer wrote:
> On 09.01.2008 09:56, Tuomo Valkonen wrote:
> > On 2008-01-09 00:06 +0100, Matthias Schniedermeyer wrote:
> > > That what LABEL und UUID-Support in mount is for.
> >
> > That's udev shit. I don't want it.
>
> No.
To be more verbose.
The
On 09.01.2008 09:56, Tuomo Valkonen wrote:
> On 2008-01-09 00:06 +0100, Matthias Schniedermeyer wrote:
> > That what LABEL und UUID-Support in mount is for.
>
> That's udev shit. I don't want it.
No.
Bis denn
--
Real Programmers consider "what you see is what you get" to be just as
bad a
On Jan 8, 2008 7:15 PM, Theodore Tso <[EMAIL PROTECTED]> wrote:
> That will fix the this issue. The problem you are facing is that you
> have your hardware clock set to ticking localtime, instead of GMT.
> Windows ticks localtime, which is a mistake carried over from the
> 1970's and MS-DOS.
On 2008-01-09 00:06 +0100, Matthias Schniedermeyer wrote:
> That what LABEL und UUID-Support in mount is for.
That's udev shit. I don't want it.
--
Tuomo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info
On Wed, 09 Jan 2008 15:00:46 +0700, BuraphaLinux Server said:
> The help for CONFIG_DM_SNAPSHOT says it is EXPERIMENTAL (in
> 2.6.23.12). So this would mean that there is very high risk of
> software failure using snapshots. Would you want to do that for your
> fsck?
The overall current state
The help for CONFIG_DM_SNAPSHOT says it is EXPERIMENTAL (in
2.6.23.12). So this would mean that there is very high risk of
software failure using snapshots. Would you want to do that for your
fsck?
On 1/9/08, Kyle Moffett <[EMAIL PROTECTED]> wrote:
> On Jan 08, 2008, at 15:51:53, Andi Kleen
The help for CONFIG_DM_SNAPSHOT says it is EXPERIMENTAL (in
2.6.23.12). So this would mean that there is very high risk of
software failure using snapshots. Would you want to do that for your
fsck?
On 1/9/08, Kyle Moffett [EMAIL PROTECTED] wrote:
On Jan 08, 2008, at 15:51:53, Andi Kleen wrote:
On Wed, 09 Jan 2008 15:00:46 +0700, BuraphaLinux Server said:
The help for CONFIG_DM_SNAPSHOT says it is EXPERIMENTAL (in
2.6.23.12). So this would mean that there is very high risk of
software failure using snapshots. Would you want to do that for your
fsck?
The overall current state of
On 2008-01-09 00:06 +0100, Matthias Schniedermeyer wrote:
That what LABEL und UUID-Support in mount is for.
That's udev shit. I don't want it.
--
Tuomo
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On Jan 8, 2008 7:15 PM, Theodore Tso [EMAIL PROTECTED] wrote:
That will fix the this issue. The problem you are facing is that you
have your hardware clock set to ticking localtime, instead of GMT.
Windows ticks localtime, which is a mistake carried over from the
1970's and MS-DOS. Ticking
On 09.01.2008 09:56, Tuomo Valkonen wrote:
On 2008-01-09 00:06 +0100, Matthias Schniedermeyer wrote:
That what LABEL und UUID-Support in mount is for.
That's udev shit. I don't want it.
No.
Bis denn
--
Real Programmers consider what you see is what you get to be just as
bad a concept
On 09.01.2008 11:21, Matthias Schniedermeyer wrote:
On 09.01.2008 09:56, Tuomo Valkonen wrote:
On 2008-01-09 00:06 +0100, Matthias Schniedermeyer wrote:
That what LABEL und UUID-Support in mount is for.
That's udev shit. I don't want it.
No.
To be more verbose.
The 'LABEL=' is
On Wed, Jan 09, 2008 at 10:54:11AM +0100, Martin Schwidefsky wrote:
On Jan 8, 2008 7:15 PM, Theodore Tso [EMAIL PROTECTED] wrote:
That will fix the this issue. The problem you are facing is that you
have your hardware clock set to ticking localtime, instead of GMT.
Windows ticks localtime,
On Wed, Jan 09, 2008 at 11:28:21AM +0100, Matthias Schniedermeyer wrote:
On 09.01.2008 11:21, Matthias Schniedermeyer wrote:
On 09.01.2008 09:56, Tuomo Valkonen wrote:
On 2008-01-09 00:06 +0100, Matthias Schniedermeyer wrote:
That what LABEL und UUID-Support in mount is for.
On Wed, Jan 09, 2008 at 02:55:53AM -0500, [EMAIL PROTECTED] wrote:
Does this create a snapshot of the *disk* at that moment, or does it
capture disk plus still-to-be-written blocks in the cache?
(Phrased differently, does it Do The Right Thing regarding blocks
queued before lvcreate and
Vous m'avez dit récemment :
On 2008-01-08, John Stoffel [EMAIL PROTECTED] wrote:
Look at your filesystems, using 'tune2fs' and see if the ext3 journal
is actually turned on and used. If it's not, then I can see why
you're having problems on reboots.
Journalling is on, but it's no use
On Jan 9, 2008 1:25 PM, Theodore Tso [EMAIL PROTECTED] wrote:
On Wed, Jan 09, 2008 at 10:54:11AM +0100, Martin Schwidefsky wrote:
Actually you can force Windows to accept a hardware clock in UTC:
HKEY_LOCAL_MACHINE/SYSTEMCurrentControlSetControl/TimeZoneInformation/RealTimeIsUniversal
Oh,
On 2008-01-09, Mathieu SEGAUD [EMAIL PROTECTED] wrote:
fix your hardware clock then
It displays just the right time. On boot anyway. (Linux has had some
serious problems keeping the time after the switch from 2.6.7 to 2.6.14,
advanding even 15 minutes a day -- that ntpd doesn't seem to be able
On Jan 9, 2008 2:53 PM, Martin Schwidefsky [EMAIL PROTECTED] wrote:
On Jan 9, 2008 1:25 PM, Theodore Tso [EMAIL PROTECTED] wrote:
On Wed, Jan 09, 2008 at 10:54:11AM +0100, Martin Schwidefsky wrote:
Actually you can force Windows to accept a hardware clock in UTC:
On Tue, 08 Jan 2008 22:21:02 EST, Kyle Moffett said:
> lvcreate -s -n "${VOLUME}-snap" "${VG}/${VOLUME}"
> Basically you can fsck the offline snapshot in the background.
Something the lvcreate manpage is specifically not clear about is:
Does this create a snapshot of the *disk* at that
On Jan 08, 2008, at 15:51:53, Andi Kleen wrote:
Theodore Tso <[EMAIL PROTECTED]> writes:
Now, there are good reasons for doing periodic checks every N
mounts and after M months. And it has to do with PC class
hardware. (Ted's aphorism: "PC class hardware is cr*p").
If these reasons are
Sorry for feeding the troll:
On Die, 2008-01-08 at 17:52 +, Tuomo Valkonen wrote:
> On 2008-01-08, Andre Noll <[EMAIL PROTECTED]> wrote:
> > Use tune2fs to deactivate checking.
>
> So, a workaround is the answer to a clear bug. Typical FOSS.
At least you get a simple solution for your
> > Don't use udev then. Good old static dev works fine if you have a fixed
> > set of devices.
>
> It doesn't, with the unpredictable SCSI mapping insanity.
That what LABEL und UUID-Support in mount is for.
You label the filesystems (e2label for ext2 and ext3) and use that label to
mount them
1 - 100 of 161 matches
Mail list logo
