On Sun, Feb 12, 2006 at 09:43:54PM -0500, Martin Stolle wrote:
> On Sun, Feb 12, 2006 at 06:08:51PM +0100, Bastian Blank wrote:
> > On Sun, Feb 12, 2006 at 12:30:58AM -0500, Martin Stolle wrote:
> > > Get random "permission denied" as root.  It seems like all the extended
> > > attributes on reiserfs are badly/poorly initialized?  Did they get
> > > changed?  Or maybe they were ignored before and are suddenly used now?
> > 
> > Yes, the one stable reiserfs patch enables usage of attributes if
> > supported by the filesystem.
> > 
> > What happens if you do a "mount -o remount,noattr /"?
> > 
> > Anyway, you forgot to show which filesystem version you use.
> > 
> 
> So mount -o remount,noattr /  gives an error:
> 
> [EMAIL PROTECTED]:~$ sudo mount -o remount,noattr /
> mount: / not mounted already, or bad option
> 
> 

ok, so I did a remount with noattrs instead of noattr (picked that up on
the kernel mailing list... is there any documentation for this mount
options?  man mount  definitely doesn't talk about this!)

all the system partitions are now mounted noattrs:

[EMAIL PROTECTED]:/usr$ mount | grep reiserfs
/dev/hda5 on / type reiserfs (rw,noattrs)
/dev/hda6 on /tmp type reiserfs (rw,noattrs)
/dev/hda7 on /var type reiserfs (rw,noattrs)
/dev/hda8 on /usr type reiserfs (rw,noattrs)
/dev/hda10 on /home type reiserfs (rw,noattrs)
/dev/sda1 on /var/external type reiserfs (rw)

Now things seem to be more or less back to normal.  Still having
problems with symlinks, though... I can't delete them?

[EMAIL PROTECTED]:/usr/share/doc$ ls -ld gfortran-4.0* gcc-4.0-base/
drwxr-xr-x 5 root root 432 2006-02-13 11:04 gcc-4.0-base/
lrwxrwxrwx 1 root root  12 2006-02-01 15:21 gfortran-4.0 -> gcc-4.0-base
lrwxrwxrwx 1 root root  12 2006-02-13 11:15 gfortran-4.0.dpkg-new ->
gcc-4.0-base
lrwxrwxrwx 1 root root  12 2006-02-13 11:15 gfortran-4.0.dpkg-tmp ->
gcc-4.0-base

[EMAIL PROTECTED]:/usr/share/doc$ sudo mv gfortran-4.0 /tmp
mv: cannot remove `gfortran-4.0': Operation not permitted
[EMAIL PROTECTED]:/usr/share/doc$ sudo rm gfortran-4.0 
rm: cannot remove `gfortran-4.0': Operation not permitted


But now lsattr returns "Inappropriate ioctl for device".... oh well:

[EMAIL PROTECTED]:/usr/share/doc$ lsattr -d gfortran-4.0 gcc-4.0-base/
lsattr: Inappropriate ioctl for device While reading flags on
gfortran-4.0
lsattr: Inappropriate ioctl for device While reading flags on
gcc-4.0-base/


I guess that remounting the filesystem doesn't clear the special
treament that symlinks get?  I guess a bug in the kernel/mount ?

Anyways, I'll try rebooting, having changed the fstab settings to
noattrs, to see if it works better then.


BTW: I also tried just clearing all the attributes before.  That seemed to work
for many things, but not for special devices in /dev ... It looks like
even though special devices aren't supposed to have inode attributes (at
least they can't be read or set), if they exist because they were random
from old reiserfs version, then they are still used!  This is probably a
separate bug, but should be addressed/forwarded to reiserfs developers


Martin

PS: File system version:

[EMAIL PROTECTED]:~$  sudo /sbin/debugreiserfs /dev/hda5
debugreiserfs 3.6.19 (2003 www.namesys.com)


Filesystem state: consistency is not checked after last mounting

Reiserfs super block in block 16 on 0x305 of format 3.6 with standard journal
Count of blocks on the device: 72272
Number of bitmaps: 3
Blocksize: 4096
Free blocks (count of blocks - used [journal, bitmaps, data, reserved] blocks): 
38666
Root block: 8220
Filesystem is NOT clean
Tree height: 4
Hash function used to sort names: "r5"
Objectid map size 968, max 972
Journal parameters:
        Device [0x0]
        Magic [0x0]
        Size 8193 blocks (including 1 for journal header) (first block 18)
        Max transaction length 1024 blocks
        Max batch size 900 blocks
        Max commit age 30
Blocks reserved by journal: 0
Fs state field: 0x0:
sb_version: 2
inode generation number: 601453
UUID: 40797b86-360b-4f49-91d9-5049e7b1eb1e
LABEL: 
Set flags in SB:
        ATTRIBUTES CLEAN




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Reply via email to