Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

actually checking filesystems from fstab fails if the filesystem type is
reiser4
checkroot was the first I ran into - I had to change all my fstab entries with
reiser4 to be sure they are not fsck-ed to get a "normal" boot

the scripts output is the same as "fsck.reiser4 -p"
which in my case is
Default profile:
create:          "reg40"           (id:0x0 type:0x0)    [Regular file plugin
for creat(2)]
key:             "key_large"       (id:0x1 type:0xb)    [Key plugin]
compress:        "lzo1"            (id:0x0 type:0xc)    [Compression plugin]
compressMode:    "conv"            (id:0x4 type:0xd)    [Compression Mode
plugin]
cluster:         "64K"             (id:0x0 type:0x10)   [Cluster plugin]
hash:            "r5_hash"         (id:0x1 type:0x3)    [Directory entry hash
plugin]
fibration:       "ext_1_fibre"     (id:0x2 type:0x4)    [Key fibration plugin]
formatting:      "smart"           (id:0x2 type:0x5)    [File body formatting
plugin]


Reproducible: Always

Post the error message and attach your /etc/fstab please?

Created an attachment (id=133568) [details]
1st error - during checkroot

Created an attachment (id=133570) [details]
2nd error - during checking the remaining filesystems

Created an attachment (id=133571) [details]
my fstab file

if you need any more info, let me know, I wanna help

Attach the output of this command please.
fsck -T -C0 -p /; echo $?

g-zu g-zu # fsck -T -C0 -p /; echo $?
Default profile:
create:          "reg40"           (id:0x0 type:0x0)    [Regular file plugin
for creat(2)]
key:             "key_large"       (id:0x1 type:0xb)    [Key plugin]
compress:        "lzo1"            (id:0x0 type:0xc)    [Compression plugin]
compressMode:    "conv"            (id:0x4 type:0xd)    [Compression Mode
plugin]
cluster:         "64K"             (id:0x0 type:0x10)   [Cluster plugin]
hash:            "r5_hash"         (id:0x1 type:0x3)    [Directory entry hash
plugin]
fibration:       "ext_1_fibre"     (id:0x2 type:0x4)    [Key fibration plugin]
formatting:      "smart"           (id:0x2 type:0x5)    [File body formatting
plugin]

16

I think this should be useful:
as you can see the -p option causes that output
g-zu g-zu # fsck.reiser4 
Usage: fsck.reiser4 [ options ] FILE
Fsck options:
  --check                       checks the consistency (default)
  --fix                         fixes minor corruptions
  --build-sb                    rebuilds the super block
  --build-fs                    rebuilds the filesystem

  -L, --logfile file            complains into the file
  -n, --no-log                  makes fsck to not complain
  -a, --auto                    automatically checks the consistency
                                without any questions.
  -q, --quiet                   supresses gauges
  -r                            ignored
Plugins options:
  -p, --print-profile           prints the plugin profile.
  -l, --print-plugins           prints all known plugins.
  -o, --override TYPE=PLUGIN    overrides the default plugin of the type
                                "TYPE" by the plugin "PLUGIN" in the
                                profile.
Common options:
  -?, -h, --help                prints program usage.
  -V, --version                 prints current version.
  -y, --yes                     assumes an answer 'yes' to all questions.
  -f, --force                   makes fsck to use whole disk, not block
                                device or mounted partition.
  -c, --cache N                 number of nodes in tree buffer cache

Here - from man fsck - I believe you should use this option instead

       -a     Automatically  repair  the file system without any questions (use
this option with caution).  Note that e2fsck(8) supports -a for
              backwards compatibility only.  This option is mapped to e2fsck's
-p option which is safe to use, unlike the -a option  that  some
              file system checkers support.

Lets just say that resierfs (3 and 4) did a "preen" by default and used to
silently drop the -p option.

Patching reiser4progs to match reiserfs (and every other fsck helpers)
behaviour is the best solution.

Created an attachment (id=133596) [details]
Add the -p, --preen option

Try this patch for reiser4progs

I tried the patch... It has a problem, though, it asks for confirmation

g-zu reiser4progs-1.0.6 # fsck -T -C0 -p /subversion
*******************************************************************
This is an EXPERIMENTAL version of fsck.reiser4. Read README first.
*******************************************************************

Fscking the /subversion block device.                                           
Will check the consistency of the Reiser4 SuperBlock.                           
Will check the consistency of the Reiser4 FileSystem.                           
Continue?                                                                       
(Yes/No): 

I think it should be behaving the same as the -a flag as -a does only a
consistency check, without fixing stuff around - at least that's what I
understood from looking at the sources, please double-check it, just to be sure

Created an attachment (id=133618) [details]
Add the -p, --preen option

This one should fix that.

Created an attachment (id=133619) [details]
Add the -p, --preen option

Actually fix the disk.

What we're trying to do here is make reiser fsck helpers accept similar
arguments to ext2/3/4, jfs, xfs and freebsd's ufs helpers. We do this so we
don't have to write complicated init scripts just to check disks.

almost there, but it still doesn't comply with the other - it does a check even
if filesystem is clean

I think that the line from case 'a' is also needed
                        aal_set_bit(&data->options, FSCK_OPT_AUTO);

I'd like to know a solution to get a "dirty" filesystem without actually
reseting my computer, any suggestions? - just to check it out
fsck -T -C0 -p -a /subversion worked fine on the clean filesystem

output from fsck - I stopped it at 10%
I want to mention that the filesystem was clean, it shouldn't check if it's
clean

g-zu reiser4progs-1.0.6 # fsck -T -C0 -p /subversion
*******************************************************************
This is an EXPERIMENTAL version of fsck.reiser4. Read README first.
*******************************************************************

Fscking the /subversion block device.
Will fix minor corruptions of the Reiser4 SuperBlock.
Will fix minor corruptions of the Reiser4 FileSystem.
***** fsck.reiser4 started at Tue Oct 16 15:56:30 2007
Reiser4 fs was detected on /subversion.
Master super block (16):
magic:          ReIsEr4
blksize:        4096
format:         0x0 (format40)
uuid:           d09ad7db-b4ce-4a1c-afe1-541fad32d18b
label:          <none>

Format super block (17):
plugin:         format40
description:    Disk-format plugin.
version:        0
magic:          ReIsEr40FoRmAt
mkfs id:        0x248e6e4b
flushes:        0
blocks:         524288
free blocks:    270400
root block:     254398
tail policy:    0x2 (smart)
next oid:       0x6de9a
file count:     227060
tree height:    4
key policy:     LARGE


CHECKING THE STORAGE TREE
[=====\                                             ] 10%

*** Bug 199091 has been marked as a duplicate of this bug. ***

Created an attachment (id=141232) [details]
reiser4progs-add_preen-to-fsck.patch

this should solve the problem with baselayout-2/openrc and reiser4, being
forced to boot root partition with rw

(see http://thread.gmane.org/gmane.comp.file-systems.reiserfs.general/21324 for
more info)

Created an attachment (id=141233) [details]
updated ebuild with reference to reiser4progs-add_preen-to-fsck.patch

To use reiser4 and baselayout-2 put "CONSOLE=/dev/tty1 rw" in grub.conf (kernel
options)

this won't fix any problems found by fsck.reiser4, 
that way you will need to boot from a livecd and do a full check ...

(In reply to comment #21)
> this won't fix any problems found by fsck.reiser4, 
> that way you will need to boot from a livecd and do a full check ...
> 

I need to append rw, new ebuild with patch is not enough for me, it hangs while
remounting rw

issue with remounting reiser4 partition read/write is resolved in baselayout
from openrc overlay.

so, if everything is fixed why:

do I get a list of r4 plugins, before the fsck script from baselayout2/openrc
bails out and terminates boot?

Same thing here. It started right after I upgraded to baselayout-2 and OpenRC.
My system is an ~AMD64 running Reiser4 in the root partition. 

The workaround for now is to add the /fastboot file, so /etc/init.d/fsck won't
do any checking.

Hi,

could you please replace the -p with an -a?

-a is supported by fsck.ext3, so there is no downside. And the patches are
'stupid' - don't change the behaviour of a critical package if you don't have
to.

The fix is easy, just replace ONE (!) letter with another one.

What is so hard about it?

-a is supported by fsck.extX for compatibility - and compatibility is needed
NOW.

Really guys, after 6 month this starts to look ridiculous.

that statement is incorrect.  there was a reason we changed from -a to -p.

and what was that reason?

ext2&3 support -a for compatibility.
reiserfs does too
reiser4 needs -a
'standard' fsck knows -a but not -p
fsck.msdos knows -a and -p
fsck.jfs knows -a and -p

so what was the reason that it was changed to -p?

(In reply to comment #29)
> so what was the reason that it was changed to -p?

-a is not the same as -p in ext2/3.
Infact, the use of -a is discouraged by the ext devs.

The BSD's (which we now support) don't now the -a option at all, whereas they
support -p.

Every fs aside from resier4 works fine with -p.
The only thing looking ridiculous are the reiser4 devs who give the finger to
everyone else about command line compat. 

should be fixed with 1.0.6-r1

>-a is not the same as -p in ext2/3.

the manpages disagrees, from man fsck.ext3:
 -a     This option does the same thing as the -p option.

btw, since the namesys side is very dead, the 'correct' homepage is:

http://www.kernel.org/pub/linux/utils/fs/reiser4
and
http://www.kernel.org/pub/linux/utils/fs/reiserfs

taking a sample of -a and -p is pointless.  there are known issues with using
-a for all checkers whereas the known issues with -p is largely non existent.

which issues?

from all the manpages -a is the supported option. So which fsck has a problem
with -a?

xfs? Well, xfs has a problem with all options. And which one is left?

But hey, breaking reiser4progs compatibility with upstream is more important
than putting -a in /etc/init.d/fsck. Fine. And I always thought gentoo had a
'close to upstream policy'.

(In reply to comment #34)
> And I always thought gentoo had a 'close to upstream policy'.

Is this the policy of all supported fs's on the kernels Gentoo supports?
Or do you mean upstream being the maintainers of unaccepted large kernel
patches which is a close description of where reiser4 is now.

Luckily for you, you can put fsck_args="-a" in /etc/conf.d/net so you work
around this limition reiser4 enforces.

How about testing patches before forcing them onto users?

You know what happens with that -preen patch&default fsck on boot?

Yes?

No.

All reiser4 filesystems do a COMPLETE fsck. And that takes ages. 20min boot is
a great argument against that patch&openrc.

Of course, with -a&'vanilla' progs everything is fine.

btw
Will be xfs patched to to support --preen and -p?

upstream xfs changed to -p a while ago

instead of being sarcastic, file a new bug, or no one will look at it

(In reply to comment #33)
> taking a sample of -a and -p is pointless.  there are known issues with using
> -a for all checkers whereas the known issues with -p is largely non existent.
> 

So it's this "largely nonexistant" problem which has turned a working system
into one which is completely useless and will not get through boot?

You say open another bug or it won't get looked at. Why not? You know what this
issue is. It's now nearly 8 mths you've known about it.

What new information do you need to fix it?

The only thing preventing this being fixed is the fact that this bug is
incorrectly marked as resolved.

Please fix this in portage .

http://bugs.gentoo.org/show_bug.cgi?id=237393