<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
</head>
<body bgcolor="#ffffff" text="#000000">
<font size="+1"><tt>Hi CLUEbies,<br>
<br>
I'm working on some changes to rc.sysinit for an industrial computer
system based on CentOS 5.2 or 5.3. As shipped with CentOS the
rc.sysinit checks the filesystems at startup and fsck exits with return
code 1 (OK), 2 (fixed), 3 (fixed), and 4 (didn't fix).<br>
<br>
I've already made most of the filesystems read-only using the readonly
root stuff and /etc/rwtab. Almost all of the read/write stuff (all of
it is logfiles) is on a separate partition and not on the root
filesystem. I'm changing rc.sysinit around so that it will try more
aggressively to fix the filesystems if there is some sort of error.
Since the filesystems are mostly readonly I don't expect any errors on
those, but the logfile partition could be badly corrupted.<br>
<br>
In that case, the rc.sysinit is going to reformat the logfile partition
and then reboot. Hopefully on reboot the fsck will pass the logfile
partition with an exit code less than 4.<br>
<br>
I think I've got most of the logic figured out for how this needs to
work. But I need to induce moderate filesystem corruption so I can
test all of the cases. A google search made me think nobody has ever
wanted to intentionally corrupt a filesystem. Do any of you have any
suggestions for what I could do? Obviously I can dd garbage over the
superblocks, but I think that will just make fsck exit 4.<br>
<br>
Probably I will just wind up setting the variable in the script and not
actually corrupting the filesystem. :( But I was hoping to do
end-to-end testing under real conditions...<br>
<br>
Thanks,<br>
Jim<br>
</tt></font>
<pre class="moz-signature" cols="72">--
Jim Ockers, P.Eng. (<a class="moz-txt-link-abbreviated" href="mailto:ockers@ockers.net">ockers@ockers.net</a>)
Contact info: <a class="moz-txt-link-freetext" href="http://www.ockers.ca/pason.html">http://www.ockers.ca/pason.html</a>
</pre>
</body>
</html>