Hello
After converting a Phy → HVM → PV of a SLES11 SP1 (x86_64) note that every time I start the domU runs fsck.reiserfs.
The dom0 is a SLES11 SP2.
Not sure if SLES error or something wrong set of domU and domU is apage doing incorrectly.
does the fsck run mention why it was started? Maybe your DomU wasn’t shut down properly, leaving the FS in an unclean state.
What happens if you create loop devices in Dom0 for your disk image and run fsck on the second (root) partition manually? Does it complain? (Of course, you should only do this if the DomU is stopped!)
Hello jmozdzen
Whenever I start the domU running the fsck, the domU is shutdown correctly with the command ‘halt’
When you start the fsck command does not indicate that, but I find it strange that you run the fsck
Mount the disk with qemu-nbd and check the disk, fsck indicates no errors.
When you start the domU is the log:
mount: devpts already mounted or /dev/pts busy
mount: according to mtab, devpts is already mounted on /dev/pts
Boot logging started on /dev/xvc0(/dev/console) at Wed Sep 4 08:06:07 2013
Waiting for device /dev/xvda2 to appear: ok
fsck from util-linux-ng 2.16
[/sbin/fsck.reiserfs (1) -- /] fsck.reiserfs -a /dev/xvda2
Reiserfs super block in block 16 on 0xca02 of format 3.6 with standard journal
Blocks (total/free): 3931904/3056254 by 4096 bytes
Filesystem is clean
fsck succeeded. Mounting root device read-write.
Mounting root /dev/xvda2
mount -o rw,acl,user_xattr -t reiserfs /dev/xvda2 /root
[ 1.691817] REISERFS (device xvda2): found reiserfs format "3.6" with standard journal
[ 1.691837] REISERFS (device xvda2): using ordered data mode
[ 1.691842] reiserfs: using flush barriers
[ 1.692038] REISERFS (device xvda2): journal params: device xvda2, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
[ 1.692460] REISERFS (device xvda2): checking transaction log (xvda2)
[ 1.693368] REISERFS (device xvda2): Using r5 hash to sort names
INIT: version 2.86 booting
The line ‘[/sbin/fsck.reiserfs (1) - /] fsck.reiserfs-a /dev/xvda2’ normal? I see it as a mistake … 'll be confused?
the messages you quoted don’t match what I see in /etc/init.d/boot.d/S02boot.rootfsck, so they might come from code in the initrd… but while looking at the mentioned script, I noticed the check for /forcefsck - you might want to check that you don’t have that file lingering in your root directory by chance.
Something else to look at are the tuning bits of the ReiserFS - it might be that the max mount count (see man tunefs.reiserfs, “-m” option) is set too low.
jmozdzen:
No such file /forcefsck, if I disable the script boot.rootfsck (which implements the /forcefsck) reflect ‘fsck.reiserfs-a /dev/xvda2’
Below I put the info of reiserfstune (apparently this good)
When you indicate ‘so They Might eat from code in the initrd’ this is that you can tell the initrd to perform an fsck?
This Marece no damage, but makes me curious …
reiserfstune[CODE]virt-server:~ # reiserfstune /dev/nbd0p2
reiserfstune: Journal device has not been specified. Assuming journal is on the main device (/dev/nbd0p2).
Current parameters:
Filesystem state: consistent
Reiserfs super block in block 16 on 0x2b02 of format 3.6 with standard journal
Count of blocks on the device: 3931904
Number of bitmaps: 120
Blocksize: 4096
Free blocks (count of blocks - used [journal, bitmaps, data, reserved] blocks): 3054977
Root block: 32941
Filesystem is clean
Tree height: 4
Hash function used to sort names: “r5”
Objectid map size 940, max 972
Journal parameters:
Device [0x0]
Magic [0x789964b7]
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: 73779
UUID: fb5c6b0b-3688-43cd-8b20-d8fa3a0ba993
LABEL:
Set flags in SB:
ATTRIBUTES CLEAN
Mount count: 2
Maximum mount count: 30
Last fsck run: Thu Sep 5 15:26:15 2013
Check interval in days: 180[/CODE]
[QUOTE=Flako000;15758]jmozdzen:
No such file /forcefsck, if I disable the script boot.rootfsck (which implements the /forcefsck) reflect ‘fsck.reiserfs-a /dev/xvda2’[/QUOTE]
Sorry, I don’t understand what the result of disabling boot.rootfsck is - does it still run the fsck?
Yes, looks good indeed - neither a low max mount count nor a short check interval there, that may have caused fsck to run.
[QUOTE=Flako000;15758]When you indicate ‘so They Might eat from code in the initrd’ this is that you can tell the initrd to perform an fsck?
This Marece no damage, but makes me curious …[/QUOTE]
Initrd is basically a collection of scripts and binaries, run to do the initial mount and kick off the “init” process - close to anything could be in there (but usually there’s only very basic stuff there, needed to access the root partition).
I’m running out of ideas, so in your position, I’d check all startup scripts for fsck invocations and add “echo statements” to assist in locating the exact place where the fsck is invoked - then it should be easier to find out why it is run.
Hello jmozdzen
About the boot.rootfsck script, if I insert ‘exit 0’ at the beginning of the script also runs the fsck (confirms that the script is not responsible)
I’ll try it to find all occurrences fsck and insert a ‘echo’ to see where it happens.
thank you very much for all the ideas :), I test it's done and you commented.