On Thu, 8 Mar 2001, God wrote:
> > *users* have no business changing the system configuration. End of story.
> > Again, if somebody doesn't read manpages before doing stuff under root -
> > no point trying to protect him. He will find a way to fsck up, no matter
> > how many "safety" checks
Hi,
On Thu, 8 Mar 2001, God wrote:
> Look at some of the confirmation requests in windows, some ask you twice
> if you whish to perform an action. Even Red Hat (that I know of, others
> may as well), has an alias for "rm" that by
> default turns on confirmation. Why? Because not ALL users
On Wed, 7 Mar 2001, Ben Greear wrote:
> For the power/insane user, there could be a --really-do-stupid-thing-i-told-you-to
> option, and it should be that hard to type!!
There is, though historically it's undocumented. It's called "root
password".
Pause. Reflect.
--
"Love the dolphins," she
[22 new messages! Most recent from God]
You know how much this bothers me to turn around and see these in my
mailbox? I am not ready to answer for all of the things
past/present/future, so please change your name because you are not "god"!
Andre Hedrick
Linux ATA Development
On Thu, 8 Mar 2001, Alexander Viro wrote:
> Date: Thu, 8 Mar 2001 01:21:31 -0500 (EST)
> From: Alexander Viro <[EMAIL PROTECTED]>
> To: Ben Greear <[EMAIL PROTECTED]>
> Cc: Alan Cox <[EMAIL PROTECTED]>,
> Linux Kernel <[EMAIL PROTECTED]>
> Sub
On Wed, 7 Mar 2001, Ben Greear wrote:
> Date: Wed, 07 Mar 2001 23:32:11 -0700
> From: Ben Greear <[EMAIL PROTECTED]>
> To: Alexander Viro <[EMAIL PROTECTED]>
> Cc: Alan Cox <[EMAIL PROTECTED]>,
> Linux Kernel <[EMAIL PROTECTED]>
> Subject: Re: 2.4
On Wed, 7 Mar 2001, Ben Greear wrote:
Date: Wed, 07 Mar 2001 23:32:11 -0700
From: Ben Greear [EMAIL PROTECTED]
To: Alexander Viro [EMAIL PROTECTED]
Cc: Alan Cox [EMAIL PROTECTED],
Linux Kernel [EMAIL PROTECTED]
Subject: Re: 2.4.2 ext2 filesystem corruption ? (was 2.4.2: What happened
On Thu, 8 Mar 2001, Alexander Viro wrote:
Date: Thu, 8 Mar 2001 01:21:31 -0500 (EST)
From: Alexander Viro [EMAIL PROTECTED]
To: Ben Greear [EMAIL PROTECTED]
Cc: Alan Cox [EMAIL PROTECTED],
Linux Kernel [EMAIL PROTECTED]
Subject: Re: 2.4.2 ext2 filesystem corruption ? (was 2.4.2: What
[22 new messages! Most recent from God]
You know how much this bothers me to turn around and see these in my
mailbox? I am not ready to answer for all of the things
past/present/future, so please change your name because you are not "god"!
Andre Hedrick
Linux ATA Development
Hi,
On Thu, 8 Mar 2001, God wrote:
Look at some of the confirmation requests in windows, some ask you twice
if you whish to perform an action. Even Red Hat (that I know of, others
may as well), has an alias for "rm" that by
default turns on confirmation. Why? Because not ALL users will
On Thu, 8 Mar 2001, God wrote:
*users* have no business changing the system configuration. End of story.
Again, if somebody doesn't read manpages before doing stuff under root -
no point trying to protect him. He will find a way to fsck up, no matter
how many "safety" checks you put
On Wed, 7 Mar 2001, Ben Greear wrote:
> I see it differently: If it's possible for the driver to protect the
> user, and it does not, then it strikes me as irresponsible programming. If
> there is a reason other than 'only elite users are cool enough to tune
> their system, and they never
Alexander Viro wrote:
>
> On Wed, 7 Mar 2001, Ben Greear wrote:
>
> > However, messing with the hdparms options can do random things, at
> > least from my perspective as a user: It may bring exciting new performance
> > to your system, and it may subtly, or not so, corrupt your file system.
>
On Wed, 7 Mar 2001, Ben Greear wrote:
> However, messing with the hdparms options can do random things, at
> least from my perspective as a user: It may bring exciting new performance
> to your system, and it may subtly, or not so, corrupt your file system.
It's root-only. If you run
Alan Cox wrote:
>
> > I'm not arguing it was a smart thing to do, but I would think that the
> > fs/kernel/driver writers could keep really nasty and un-expected things
> > from happenning. For instance, the driver could dis-allow any new (non-hdparm)
>
> Like stopping root from using rm -r ?
At 03:54 07/03/01, Ben Greear wrote:
>Alan Cox wrote:
> > Its not a bug. As the system administrator you reconfigured a hard disk on
> > the fly and shit happened. The hdparm man page warnings do exist for a
> reason.
>
>I'm not arguing it was a smart thing to do, but I would think that the
> I'm not arguing it was a smart thing to do, but I would think that the
> fs/kernel/driver writers could keep really nasty and un-expected things
> from happenning. For instance, the driver could dis-allow any new (non-hdparm)
Like stopping root from using rm -r ? Where is the line drawn
-
To
I'm not arguing it was a smart thing to do, but I would think that the
fs/kernel/driver writers could keep really nasty and un-expected things
from happenning. For instance, the driver could dis-allow any new (non-hdparm)
Like stopping root from using rm -r ? Where is the line drawn
-
To
At 03:54 07/03/01, Ben Greear wrote:
Alan Cox wrote:
Its not a bug. As the system administrator you reconfigured a hard disk on
the fly and shit happened. The hdparm man page warnings do exist for a
reason.
I'm not arguing it was a smart thing to do, but I would think that the
On Wed, 7 Mar 2001, Ben Greear wrote:
However, messing with the hdparms options can do random things, at
least from my perspective as a user: It may bring exciting new performance
to your system, and it may subtly, or not so, corrupt your file system.
It's root-only. If you run unfamiliar
Alexander Viro wrote:
On Wed, 7 Mar 2001, Ben Greear wrote:
However, messing with the hdparms options can do random things, at
least from my perspective as a user: It may bring exciting new performance
to your system, and it may subtly, or not so, corrupt your file system.
It's
Alan Cox wrote:
>
> > running a bad hdparm command while running a full GNOME desktop:
> > (This was not a good idea...and I know, and knew that...but)
> >
> > hdparm -X34 -d1 -u1 /dev/hda
> > (As found here: http://www.oreillynet.com/pub/a/linux/2000/06/29/hdparm.html?page=2
> >
> > Sorry
> running a bad hdparm command while running a full GNOME desktop:
> (This was not a good idea...and I know, and knew that...but)
>
> hdparm -X34 -d1 -u1 /dev/hda
> (As found here: http://www.oreillynet.com/pub/a/linux/2000/06/29/hdparm.html?page=2
>
> Sorry for the lame bug report, but I'm
On Mon, 5 Mar 2001, [iso-8859-1] Frédéric L. W. Meunier wrote:
> Hi. After a reboot I had to manually run fsck (sulogin from
> sysinit script) since there were failures.
's what I had, also after something like 8 hours idle.
lost+found looks a bit bigger with 43 files... no problems just using
On Mon, 5 Mar 2001, [iso-8859-1] Frédéric L. W. Meunier wrote:
Hi. After a reboot I had to manually run fsck (sulogin from
sysinit script) since there were failures.
's what I had, also after something like 8 hours idle.
lost+found looks a bit bigger with 43 files... no problems just using
running a bad hdparm command while running a full GNOME desktop:
(This was not a good idea...and I know, and knew that...but)
hdparm -X34 -d1 -u1 /dev/hda
(As found here: http://www.oreillynet.com/pub/a/linux/2000/06/29/hdparm.html?page=2
Sorry for the lame bug report, but I'm scared
Alan Cox wrote:
running a bad hdparm command while running a full GNOME desktop:
(This was not a good idea...and I know, and knew that...but)
hdparm -X34 -d1 -u1 /dev/hda
(As found here: http://www.oreillynet.com/pub/a/linux/2000/06/29/hdparm.html?page=2
Sorry for the lame bug
Maybe I should give details about my hardware. The system was
installed 5 months ago, and this is the first problem.
I used 2.2.16 stock Kernel from Slackware 7.1
2.2.17
2.2.18
2.4.0
2.4.1
And the only problem was with 2.4.2.
FYI, I'm not using hdparm or changing the BIOS to use UDMA 66.
It'd
For what it's worth, I was able to completely screw up my root FS
using redhat's Fisher beta kernel (2.2.18 + stuff). I did this by
running a bad hdparm command while running a full GNOME desktop:
(This was not a good idea...and I know, and knew that...but)
hdparm -X34 -d1 -u1 /dev/hda
(As
Hi. After a reboot I had to manually run fsck (sulogin from
sysinit script) since there were failures.
In my second (and problematic) boot with 2.4.2 I used the
option mount --bind in my sysinit script to mount the old /dev
in /dev-old before devfs was mounted, so I could get rid of all
entries
Hi. After a reboot I had to manually run fsck (sulogin from
sysinit script) since there were failures.
In my second (and problematic) boot with 2.4.2 I used the
option mount --bind in my sysinit script to mount the old /dev
in /dev-old before devfs was mounted, so I could get rid of all
entries
For what it's worth, I was able to completely screw up my root FS
using redhat's Fisher beta kernel (2.2.18 + stuff). I did this by
running a bad hdparm command while running a full GNOME desktop:
(This was not a good idea...and I know, and knew that...but)
hdparm -X34 -d1 -u1 /dev/hda
(As
Maybe I should give details about my hardware. The system was
installed 5 months ago, and this is the first problem.
I used 2.2.16 stock Kernel from Slackware 7.1
2.2.17
2.2.18
2.4.0
2.4.1
And the only problem was with 2.4.2.
FYI, I'm not using hdparm or changing the BIOS to use UDMA 66.
It'd
33 matches
Mail list logo
