[Madlug] nfs, ext3, ande2fsck

[John G. Heim]

From: "Mark Tinberg" <mtinberg at raven667.org>
To: "John G. Heim" <jheim at math.wisc.edu>
Cc: "madlug" <madlug at madisonlinux.org>
Sent: Thursday, December 17, 2009 11:38 AM
Subject: Re: [Madlug] nfs, ext3, ande2fsck


> Comments in-line
>
> --  Mark Tinberg
>
> On Dec 16, 2009, at 16:43, "John G. Heim" <jheim at math.wisc.edu> wrote:
>
>>
>> vm. I would think vmware hides that from the virtual machine. Is  there 
>> any
>> point in running smartmond on a virtual disk?
>>
>
>
> You are right, there is no point in doing any hardware monitoring  inside 
> the guest VM.
>
>> Also, I can't access the console of the machine because vmware  doesn't 
>> work
>> well enough with my screen reader for me to do that. I have to do  all 
>> this remotely.
>>
>
> I thought there was a way to enable serial console for the VM but you  had 
> to edit the VMX file, the settings for it weren't exposed in the  ui. If I 
> recall correctly you could make the virtual serial port show  up as a file 
> on the vmware host.
>
>>  Nothing. Yet, the umount command kept
>> saying the file system was busy.
>>
>
> You probably already checked for this but are there any other  filesystems 
> mounted under the path you are trying to umount. I've ran  into that 
> problem before.
>


Just a followup to my fsck troubles on a virtual machine.  The original 
problem was that my virtual machine would not reboot cleanly because it came 
up asking to go into maintenance mode due to file systems errors. I had to 
get sighted assistance to bring the machine up. So then at some later time, 
I brought the system down, fixed the file systems errors, and rebooted. But 
then the next day, 'fsck -n' indicated more errors on the same file system. 
So last Wednesday I brought the machine down again. But this time, after 
umounting the file system, e2fsck said the file system was clean. So trying 
to run fsck in readonly mode on a mounted ext3 file system must not work. 
It gave error messages on a file system that was actually clean.

I guess it is good news that there were no new errors on the file system but 
now I am at something of a loss as to how to keep the original  problem from 
happening again.  I don't want to find out about file systems errors upon 
reboot because the console is inaccessible. Well, maybe this is a vmware 
question. I guess I'll have to see if I can figure out a way to make the 
console accessible.