On Wed, Jun 02, 2010 at 02:42:53PM +0000, Uwe Dippel wrote: > Nick Holland <nick <at> holland-consulting.net> writes: > > > > There is one more machine (amd64) that needs to be upgraded. Before I do > > > this, I rather solicit suggestions on how to log the upgrade process, > > > debug it, or otherwise. > > > > serial console. > > Log everything from the first chars out the serial port to the reboot. > > In fact, log the reboot. > > Don't edit anything. > > Use a public mirror or an official CD for the install, make sure it is > > obvious which. > > > > Stick the resulting file on a webserver. > > Thanks, Nick. > > Based on the latest results, the problem seems to exist only for most of the > /sbin files. So, the upgrade runs through as programmed. > With a public mirror, it will take hours. I really hope SHA256 is good enough > to > confirm the integrity of the archives. Serial console seems a good idea; I > have > to use it in any case. > What I have in mind, is, before the reboot, to use the command prompt to check > the files in the /sbin-to-be. I have a hunch, that they'll be there, then. > Then > I'll do the same after the reboot, and once again, after the package upgrade. > Should the phenomenon show again, by now I can imagine that the changes are > happening some time later. We'll see ...
Just for clarity: is everything that fails to change on the same disk? I.e. can you post the output of 'mount' (within bsd.rd) as well? And I presume you shut down in a sensible fashion, right? Joachim