Hi, We've got some units in client's vehicles which are running Fedora core 1. We've can log into them over ssh remotely there is no console attached to them. I suspect one of them has some filesystem corruption, and I'd like to both force a fsck at next reboot (which I think I can do with shutdown -F) but I'd also like to make this fsck not require any human intervention. In particular, I am concerned about the case where fsck decides that it need manual intervention and requests you log in for maintainance. How can I ensure a non-user interaction fsck that will boot normally (and hence put the box back into a state where a gprs connection is re-established and I can log in again.) Thanks in advance, Tim Allen. (please CC me because I'm not on the list.)
On Wed, Mar 16, 2005 at 09:45:06AM +1100, Tim Allen wrote:> We've got some units in client's vehicles which are running Fedora core > 1. We've can log into them over ssh remotely there is no console > attached to them. I suspect one of them has some filesystem corruption, > and I'd like to both force a fsck at next reboot (which I think I can do > with shutdown -F) but I'd also like to make this fsck not require any > human intervention. > > In particular, I am concerned about the case where fsck decides that it > need manual intervention and requests you log in for maintainance. > > How can I ensure a non-user interaction fsck that will boot normally > (and hence put the box back into a state where a gprs connection is > re-established and I can log in again.)You can force the boot scripts to use the fsck -y option, but I'd also use the logsave program so you can see what fsck had to fix --- so if a system or appliction program/data file gets deleted, you can find out about it and fix it, for example: logsave -asv /var/log/fsck.log e2fsck -y /dev/hda1 (In fact, distributions should be encouraged to use logsave by default, since it means that any automatic fixes made by e2fsck during the boot process are saved in a log file for later analysis.) - Ted
On Tue, March 15, 2005 23:45, Tim Allen said:> with shutdown -F) but I'd also like to make this fsck not require any > human intervention.if it's not "/" what is to be checked, then simply unmount the partition, or mount it readonly and fsck it while you're logged in. if it is "/" you can only mount it readonly and try to fsck, but be careful letting fsck "fix" things to quickly. unmounting is really the better choice. perhaps you can do some nasty chroot tricks to unmount the "real /" on a running system, but i've never done that. another solution: setup a new partition (50M) where you populate a working "/" directory, reboot with "root=/dev/new_partition", then you can check the real "/". Christian. -- make bzImage, not war