Right, I've now disabled every grsecurity kernel config option, apart
from the overarching "Getrewted Kernel Security" one - indicating the
problem is in one of the non #ifdef parts of the patch. Could this be a
problem:
diff -ruN linux/fs/namei.c linux/fs/namei.c
--- linux/fs/namei.cSat May
On Tue, Jun 26, 2001 at 12:25:32AM +0200, Daniel Phillips wrote:
> > This is only true without the COMPAT_DIR_INDEX flag. Since e2fsck _needs_
> > to know about every filesystem feature, it will (correctly) refuse to touch
> > such a system for now. You could "tune2fs -O ^FEATURE_C4 /dev/hdX" to
I use debugfs to remove the flag before fsck'ing:
Start debugfs.
Type
open -f -w /dev/
features -FEATURE_C5
-tony
On 26 Jun 2001 00:25:32 +0200, Daniel Phillips wrote:
> On Monday 25 June 2001 21:51, Andreas Dilger wrote:
> > Daniel writes:
> > > Sure, if your root partition is expendable,
On Monday 25 June 2001 21:51, Andreas Dilger wrote:
> Daniel writes:
> > > > On Wednesday 20 June 2001 16:59, Tony Gale wrote:
> > > > > The main problem I have with this is that e2fsck doesn't know how
> > > > > to deal with it - at least I haven't found a version that will.
> > > > > This makes
Daniel writes:
> > > On Wednesday 20 June 2001 16:59, Tony Gale wrote:
> > > > The main problem I have with this is that e2fsck doesn't know how to
> > > > deal with it - at least I haven't found a version that will. This makes
> > > > it rather difficult to use, especially for your root fs.
>
>
On Monday 25 June 2001 11:46, Tony Gale wrote:
> After some testing, removing the grsecurity patch seems to have solved
> the disappearing-free-space problem. Now just need to find out why.
>
> On 20 Jun 2001 18:58:43 +0200, Daniel Phillips wrote:
> > On Wednesday 20 June 2001 16:59, Tony Gale wro
After some testing, removing the grsecurity patch seems to have solved
the disappearing-free-space problem. Now just need to find out why.
On 20 Jun 2001 18:58:43 +0200, Daniel Phillips wrote:
> On Wednesday 20 June 2001 16:59, Tony Gale wrote:
> > The main problem I have with this is that e2fs
On Wednesday 20 June 2001 18:02, Theodore Tso wrote:
> On Wed, Jun 20, 2001 at 03:59:58PM +0100, Tony Gale wrote:
> > The main problem I have with this is that e2fsck doesn't know how to
> > deal with it - at least I haven't found a version that will. This makes
> > it rather difficult to use, esp
On Wednesday 20 June 2001 16:59, Tony Gale wrote:
> The main problem I have with this is that e2fsck doesn't know how to
> deal with it - at least I haven't found a version that will. This makes
> it rather difficult to use, especially for your root fs.
Good, the file format isn't finalized, this
On Wed, Jun 20, 2001 at 03:59:58PM +0100, Tony Gale wrote:
>
> The main problem I have with this is that e2fsck doesn't know how to
> deal with it - at least I haven't found a version that will. This makes
> it rather difficult to use, especially for your root fs.
Getting e2fsck to deal with dir
The main problem I have with this is that e2fsck doesn't know how to
deal with it - at least I haven't found a version that will. This makes
it rather difficult to use, especially for your root fs.
And, since I used it, and have since stopped using it, I have a problem
in what all my disk free s
On Thursday 31 May 2001 21:44, Andreas Dilger wrote:
> I noticed something interesting when running "mongo" with debugging
> on. It is adding filenames which are only sequential numbers, and the
> hash code is basically adding to only two blocks until those blocks
> are full, at which point (I gue
Daniel writes:
> On Thursday 31 May 2001 21:44, Andreas Dilger wrote:
> > I think Al's idea of doing the validation once on the initial
> > read is a good one.
>
> I'm doing that in the current patch, for leaf blocks, look at
> ext2_bread. For index blocks, ext2_bread needs help to know that a
On Thursday 31 May 2001 21:44, Andreas Dilger wrote:
> Daniel, you write:
> > - Fall back to linear search in case of corrupted index
>
> OK, I have _some_ of the code needed to do this, but in one case I'm
> not sure of what your intention was - in dx_probe() you check for
> "unused_flags & 1"
Daniel, you write:
> - Fall back to linear search in case of corrupted index
OK, I have _some_ of the code needed to do this, but in one case I'm
not sure of what your intention was - in dx_probe() you check for
"unused_flags & 1" to signal a bad/unsupported index. Why only check
the low bit i
Changes:
- Freshen to 2.4.5
- EXT2_FEATURE_COMPAT_DIR_INDEX flag finalized
- Break up ext2_add_entry for aesthetic reasons (Al Viro)
- Handle more than 64K directories per directory (Andreas Dilger)
- Bug fix: new inode no longer inherits index flag (Andreas Dilger)
- Bug fix: correct
16 matches
Mail list logo
