Per Jessen said the following on 12/29/2008 07:41 AM:
Graham Anderson wrote:
My /var partition failed to mount this morning with the error "resize inode not valid". I have had no soft or hard crashes that I am aware of and have made no recent changes to the structure and layout of my volumes.
I known nothing about ext3, but googling 'resize inode not valid' returns quite a few hits from the last 2-3 years. Maybe one those will give you a hint.
What I have done so far is basically fsck.ext3 -f on all my volumes from a recovery console, all volumes are reported as clean. I can actually manually mount /var but the system will not boot with /var in fstab.
I believe the only different between those two is that the latter does an fsck before mounting it. The mount command should be the same, and therefore should produce the same result (unless something else changes the state of the filesystem).
I don't think that it. I've been getting this with /var ever since I moved to 11.1 and thought it was a mistake I'd made until I saw this posting. I too run LVM and in my case /var is reiserFS. My investigation involved eliminating concurrency of the parallel fsck and setting thee 6th field of /etc/fstab. As far as I can make out fsck is returning exit code 2 on /var even after finding that it is perfectly good. This happens if I place the line for /var right after root or much later in thee list of filesystem. The real problem is that when when /var doesn't pass I get strings of errors from other processes in /etc/init.d, for example, unable to create PID files. The strange thing is that the error message says that it can't write to a read-only FS. If /var errored and can't be mounted then why those errors? Surely it defaults back to the root FS, the /var on root that the mount would overlay? I'm forced to conclude that the /dev/vgmain/var mounts in read-only mode. WHY? And more to the point, why is this intermittent? And why "/var"? And why with 11.1 when 11.0 worked fine? I HATE marginal, intermittent problems! -- "Quality is not a sprint; it is a long-distance event." Daniel Hunt. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org