Harri Haataja wrote:
On Tue, Apr 01, 2003 at 06:48:33AM -0500, Michael Sinz wrote:
Jeremy Jackson wrote:
I'm wonder what's the official word about xfs_repair on a read-only
mounted fs. The utilities complain for me, so I have to boot from a
repair partition to fix XFS (a while back when the shutdown files in
use bug was still a problem). Ext2 has no problem with this. I'd
just to know for future reference, so I know if I have to have a
spare root fs or not.
While I too would like to have a way to repair XFS read-only mounts,
there are other reasons to have a special recovery partition for this.
What I have done is to make /boot its own partition at the start of
the disk. This is where the kernel lives, along with lilo stuff (or
grub if you use that)
Anyway, I have made a script that will build a mini-boot system in
that partition and that will then run as the init process to fix up
any other filesystems. To help reduce the chance that /boot is
corrupted, I mount it read-only and, since nothing normally runs from
it, if it ever needs fixing, I can just unmount it and fix it after a
regular boot.
You could have a /stand style thing that doesn't get mounted unless
doing recovery or a second initrd image (if all your tools fit on that)
that you can select in the boot loader.
I actually hate initrd images - for various support and maintainance
reasons and partially due to my personal preferences... Thus the
solution I have here. However, building an initrd that did the same
thing as this would not be that hard. The total extra space needed
on my systems tends to be in the 4 to 6 meg range (not counting the
kernel image) so an initrd image would be very simple. I do, however,
like the fact that I have it just living in /boot and make use of
that. (And there is less VM hit in doing it this way)
Come to think of it, I should start doing something like this as well. I
have machines I can't easily boot from a floppy or CD, but where I could
do single-user boots if they mess up.
Yes, this is critical for those systems. I have many systems that have
only hard drives and networking as their I/O. (And a serial port for
the console incase of major problems) I did this set of scripts to
deal with remotely repairing those without having to be at a console
or having to put in a disk image.
Since I keep /boot its own partition for security reasons (read-only
mount of the kernel and lilo stuff) it was easy enough to burn a few
extra meg of space to make it an alternate bootable root partition
that is always kept read-only during that process. (Yes, it is never
mounted read-write except during the install of a new kernel)
I have written up a bit more on this on a web page at:
<http://www.sinz.org/Michael.Sinz/Linux/>
--
Michael Sinz -- Director, Systems Engineering -- Worldgate Communications
A master's secrets are only as good as
the master's ability to explain them to others.
|