From mboxrd@z Thu Jan 1 00:00:00 1970 To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> In-reply-to: Your message of "Fri, 06 Jun 2014 11:35:08 EDT." <1706efdd3a7186cc1c2a54f2aba1c56e@brasstown.quanstro.net> References: <1706efdd3a7186cc1c2a54f2aba1c56e@brasstown.quanstro.net> Date: Fri, 6 Jun 2014 09:49:45 -0700 From: Bakul Shah Message-Id: <20140606164945.70A57B827@mail.bitblocks.com> Subject: Re: [9fans] suicide message on vmware Topicbox-Message-UUID: f6cdf92e-ead8-11e9-9d60-3106f5b1d025 On Fri, 06 Jun 2014 11:35:08 EDT erik quanstrom wrote: > On Fri Jun 6 11:26:13 EDT 2014, bakul@bitblocks.com wrote: > > > > > On Jun 5, 2014, at 8:15 PM, Ramakrishnan Muthukrishnan > 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