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 attachment 133568 [details] 1st error - during checkroot
Created attachment 133570 [details] 2nd error - during checking the remaining filesystems
Created attachment 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 attachment 133596 [details, diff] 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 attachment 133618 [details, diff] Add the -p, --preen option This one should fix that.
Created attachment 133619 [details, diff] 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 attachment 141232 [details, diff] 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 attachment 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
