From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <1706efdd3a7186cc1c2a54f2aba1c56e@brasstown.quanstro.net> References: <1706efdd3a7186cc1c2a54f2aba1c56e@brasstown.quanstro.net> From: Ramakrishnan Muthukrishnan Date: Fri, 6 Jun 2014 21:16:38 +0530 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] suicide message on vmware Topicbox-Message-UUID: f68ff818-ead8-11e9-9d60-3106f5b1d025 On Fri, Jun 6, 2014 at 9:05 PM, erik quanstrom wrot= e: > 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= kernel to /n/9fat and rebooting means now you're running the bell labs ker= nel. I don't know how different the two kernels are but if you want to cont= inue running 9atom everything, you may have to undo nsec related changes in= the userland. >> >> More generally, as this nsec change demonstrates, if you rely on sources= over which you have no control & you also have local changes, you pretty m= uch have to treat the external sources as a "vendor branch" and do a carefu= l 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 is the recommended way keep a 9atom system up to date? --=20 Ramakrishnan