Re: [9fans] suicide message on vmware

[Bakul Shah <bakul@bitblocks.com>]

On Fri, 06 Jun 2014 11:35:08 EDT erik quanstrom <quanstro@quanstro.net> wrote:
> On Fri Jun  6 11:26:13 EDT 2014, bakul@bitblocks.com wrote:
> >
> > > On Jun 5, 2014, at 8:15 PM, Ramakrishnan Muthukrishnan <vu3rdd@gmail.com>
>  wrote:
> > >
> > > Hi,
> > >
> > > I just saw a suicide message on 9atom running on plan9 while updating
> > > the system:
> > >
> > > % replica/pull -v /dist/replica/network
> >
> > I missed that you were running 9atom. Using old binaries to copy the new ke
> rnel to /n/9fat and rebooting means now you're running the bell labs kernel.
> I don't know how different the two kernels are but if you want to continue ru
> nning 9atom everything, you may have to undo nsec related changes in the user
> land.
> >
> > More generally, as this nsec change demonstrates, if you rely on sources ov
> er which you have no control & you also have local changes, you pretty much h
> ave to treat the external sources as a "vendor branch" and do a careful merge
>  to avoid such surprises.
>
> that's not how replica works.  replica respects local changes.  however,
> since in this case two different databases were mixed up, there is little
> chance that the user has a sane system.

What two databases?

Replica respects local changes at the file level.  You still
have to do a manual merge if the server version changed as
well.

The bigger issue is that the unit of update needs to be a
*set* of files that take a system from one consistent state to
another. If you update only a subset of files, you may be left
with an inconsistent system.

Another issue: your local changes may depend on the contents
of a file that you never changed so the update can overwrite
it with new and possibly incompatible contents. For all these
reasons external sources should go in a vendor branch.

And I never understood why binaries are pulled.  It is not
like on Linux/*BSD where building binaries takes a long time.

And replica (& related scripts) can't deal with changes like
syscall updates.

For a foolproof update in case of incompatible kernel changes
(and if you're running the same distribution as you pulled
from), you should

1. build all binaries and new kernels (but not install)
2. install the new kernel (& loader) on the boot partition
3. reboot
4. install new binaries
5. reboot

If you have local changes, you have to add

0. pull in a "vendor branch" and merge changes