Return to BSD News archive
Newsgroups: comp.os.386bsd.questions Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!elroy.jpl.nasa.gov!swrinde!cs.utexas.edu!uunet!news.univie.ac.at!email!mbirgmei From: mbirgmei@email.tuwien.ac.at (Martin BIRGMEIER) Subject: Re: fsck summary info bad after every shutdown Message-ID: <1993May19.095416.21213@email.tuwien.ac.at> Organization: Technical University of Vienna References: <root.737640955@gimli> Date: Wed, 19 May 1993 09:54:16 GMT Lines: 39 In article <root.737640955@gimli> root@gimli.cs.uct.ac.za (Sandi Donno) writes: >Has anyone had the following problem, or can anyone point me at the >likely cause: > >I have installed 386bsd on 4 identical 486's with 120MB IDE hard drives, and >patchkit 0.2.3. Whether I use /sbin/shutdown, /usr/distbin/shutdown or reboot, >fsck always finds the summary information bad after rebooting; the system >is rebooted and the next time fsck finds no errors. [...] This happens if you set the clock (via rdate, for example) from a remote machine after multiuser bootup, and the local (i.e. system board) clock is late (this is what happened to me). What happens is this: 1) shutdown et al write the current time to the disk's superblock. 2) system reboots, time is initialized from the RTC on the system board. 3) fsck tries to make sure that the time stored in the disk's superblock is earlier than the one it gets from the system. Since presumably your network clock shows a later time, this is not the case, since a later time was recorded on the disk at step 1). 4) fsck failing causes another reboot - this time from single user mode, where the time could not yet be set from the network time server. 5) Now the time on the disk is earlier than the RTC (unless the RTC runs backwards :-)). Thus fsck is happy. 6) Multiuser comes up, you set the system time forward from the network time server. 7) Ad infinitum... Solution: Set your CMOS clock ahead, or use some other means to keep it within a few seconds (the time to run the reboot sequence, to be precise) within the network time. Cheers, Martin