[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Why root fs "read-only" on shutdown?

On Thu, Nov 09, 2006 at 09:11:16AM +0100, Daniel Haude wrote:
> Hello,
> every day I turn my computer off when I leave work. Consequently, I have  
> to turn I back on when I get back. About twice a week, of course, one of my
> 6 harddisk partitions is ready for its routine check on startup which  
> costs me precious worktime. In an attempt to gain maybe 2 hours cumulative  
> over my entire work life, I came up with the following brilliant idea: To  
> my custom shutdown script (which backs up my day's work and does some  
> cleanup) I added the line:
>     touch /forcefsck
> and placed this symbolic link in rc0.d:
>     S41checkfs.sh -> ../init.d/checkfs.sh
> (right after S40umountfs -> ../init.d/umountfs). The idea being that I  
> don't care how long the machine works before powerdown as by that time I'm  
> well on my way home.
> It didn't take me long to discover that init.d/umountfs remounts /  
> read-only, preventing checkfs.sh to wipeout the /forcefsck flag, but as  
> the remount line was commented as "superfluous" in init.d/umountfs I took  
> the liberty to comment it out.
> Anyway, checkfs.sh still can't delete the flag because rm still says that  
> the root fs is read-only. This of course results in *every* partition  
> being force-checked on *every* startup, which is the exact opposite of  
> what I had been trying to accomplish. A grep on "remount" in init.d,  
> however, revealed that there are no other scripts that remount / as  
> read-only.
> So how come that / is read-only by the time I get to my ingenious  
> rc0.d/S41 hack?
> Needless to say that the quest for the answer has by now cost me much more  
> time than I had hoped to save. But my curiosity is tickled.

I would suggest changing your "ingenious rc0.d/S41 hack" to just go
ahead and force check (and automatically say 'yes'?) the filesystems and
not worry about /forcecheck.  

Before power off, the filesystem has to be unmounted or it risks
corruption.  Since its being used (is busy) by the very scripts trying
to unmount, it can't.  The answer is for it to be remounted ro.  This
way, the write cache is purged and no further writes occur, yet open
files can remain open.


Reply to: