On Wed, Jun 02, 2010 at 02:42:53PM +0000, Uwe Dippel wrote:
quoted text > 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
