[9fans] suicide message on vmware

[9fans] suicide message on vmware

[Ramakrishnan Muthukrishnan]

Hi,

I just saw a suicide message on 9atom running on plan9 while updating
the system:

% replica/pull -v /dist/replica/network

After a while, I saw this printed, but the replica/pull is proceeding
without any problem.

(not completely readable because stats window overwrote the screen)
... bad sys call number 53 pc 101c6
timesync 57: suicide: sys: bad syscall pc=0x101c6

I am sorry, if this is a stupid question, I am updating this system
for the first time since I installed it a few weeks(2 months?) ago:
What is the exact procedure to update? Is the above replica/pull
command enough? Will it update the kernel as well?

Thanks
--
  Ramakrishnan

Re: [9fans] suicide message on vmware

[erik quanstrom]

On Thu Jun  5 23:17:37 EDT 2014, 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
>
> After a while, I saw this printed, but the replica/pull is proceeding
> without any problem.
>
> (not completely readable because stats window overwrote the screen)
> ... bad sys call number 53 pc 101c6
> timesync 57: suicide: sys: bad syscall pc=0x101c6

nsec!  arrrrrgh!

- erik

Re: [9fans] suicide message on vmware

[Ramakrishnan Muthukrishnan]

On Fri, Jun 6, 2014 at 8:51 AM, erik quanstrom <quanstro@quanstro.net> wrote:
> On Thu Jun  5 23:17:37 EDT 2014, 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
>>
>> After a while, I saw this printed, but the replica/pull is proceeding
>> without any problem.
>>
>> (not completely readable because stats window overwrote the screen)
>> ... bad sys call number 53 pc 101c6
>> timesync 57: suicide: sys: bad syscall pc=0x101c6
>
> nsec!  arrrrrgh!

Ah, I should have remembered.

So, I guess, I got the updating sequence wrong? First upgrade kernel,
then upgrade the rest?

--
  Ramakrishnan

Re: [9fans] suicide message on vmware

[Ramakrishnan Muthukrishnan]

Well, looks like I cannot run any binaries anymore and getting the
suicide message! I don't have anything critical on this vm image and
can re-install it. But I want to see if I can recover it and how. I
will re-read the "syscall 53" thread to look for any solutions.

Ramakrishnan


On Fri, Jun 6, 2014 at 9:35 AM, Ramakrishnan Muthukrishnan
<vu3rdd@gmail.com> wrote:
> On Fri, Jun 6, 2014 at 8:51 AM, erik quanstrom <quanstro@quanstro.net> wrote:
>> On Thu Jun  5 23:17:37 EDT 2014, 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
>>>
>>> After a while, I saw this printed, but the replica/pull is proceeding
>>> without any problem.
>>>
>>> (not completely readable because stats window overwrote the screen)
>>> ... bad sys call number 53 pc 101c6
>>> timesync 57: suicide: sys: bad syscall pc=0x101c6
>>
>> nsec!  arrrrrgh!
>
> Ah, I should have remembered.
>
> So, I guess, I got the updating sequence wrong? First upgrade kernel,
> then upgrade the rest?
>
> --
>   Ramakrishnan



--
  Ramakrishnan

Re: [9fans] suicide message on vmware

[Bakul Shah]

On Fri, 06 Jun 2014 10:48:21 +0530 Ramakrishnan Muthukrishnan <vu3rdd@gmail.com> wrote:
> Well, looks like I cannot run any binaries anymore and getting the
> suicide message! I don't have anything critical on this vm image and
> can re-install it. But I want to see if I can recover it and how. I
> will re-read the "syscall 53" thread to look for any solutions.

Aren't the old binaries saved under the same name  but
prefixed with _?  If you haven't rebooted yet, you can use
those to copy the new kernel to the FAT partition.

>
> Ramakrishnan
>
>
> On Fri, Jun 6, 2014 at 9:35 AM, Ramakrishnan Muthukrishnan
> <vu3rdd@gmail.com> wrote:
> > On Fri, Jun 6, 2014 at 8:51 AM, erik quanstrom <quanstro@quanstro.net> wrot
> e:
> >> On Thu Jun  5 23:17:37 EDT 2014, 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
> >>>
> >>> After a while, I saw this printed, but the replica/pull is proceeding
> >>> without any problem.
> >>>
> >>> (not completely readable because stats window overwrote the screen)
> >>> ... bad sys call number 53 pc 101c6
> >>> timesync 57: suicide: sys: bad syscall pc=0x101c6
> >>
> >> nsec!  arrrrrgh!
> >
> > Ah, I should have remembered.
> >
> > So, I guess, I got the updating sequence wrong? First upgrade kernel,
> > then upgrade the rest?
> >
> > --
> >   Ramakrishnan
>
>
>
> --
>   Ramakrishnan
>

Re: [9fans] suicide message on vmware

[Ramakrishnan Muthukrishnan]

On Fri, Jun 6, 2014 at 11:30 AM, Bakul Shah <bakul@bitblocks.com> wrote:
> On Fri, 06 Jun 2014 10:48:21 +0530 Ramakrishnan Muthukrishnan <vu3rdd@gmail.com> wrote:
>> Well, looks like I cannot run any binaries anymore and getting the
>> suicide message! I don't have anything critical on this vm image and
>> can re-install it. But I want to see if I can recover it and how. I
>> will re-read the "syscall 53" thread to look for any solutions.
>
> Aren't the old binaries saved under the same name  but
> prefixed with _?  If you haven't rebooted yet, you can use
> those to copy the new kernel to the FAT partition.

Thanks, I didn't know that old binaries are kept prefixed with _. Very nice!

I copied the kernels from David (9legacy.org/download/kernel.tar.bz2),
untar'ed it. This copied into /386/9pcf. Then I do:

9fat:
_cp /386/9pcf /n/9fat/9pcf

But I get an error message: '/n/9fat/9pcf clone failed'.

Re: [9fans] suicide message on vmware

[Bakul Shah]

On Fri, 06 Jun 2014 13:02:14 +0530 Ramakrishnan Muthukrishnan <vu3rdd@gmail.com> wrote:
> On Fri, Jun 6, 2014 at 11:30 AM, Bakul Shah <bakul@bitblocks.com> wrote:
> > On Fri, 06 Jun 2014 10:48:21 +0530 Ramakrishnan Muthukrishnan <vu3rdd@gmail
> .com> wrote:
> >> Well, looks like I cannot run any binaries anymore and getting the
> >> suicide message! I don't have anything critical on this vm image and
> >> can re-install it. But I want to see if I can recover it and how. I
> >> will re-read the "syscall 53" thread to look for any solutions.
> >
> > Aren't the old binaries saved under the same name  but
> > prefixed with _?  If you haven't rebooted yet, you can use
> > those to copy the new kernel to the FAT partition.
>
> Thanks, I didn't know that old binaries are kept prefixed with _. Very nice!
>
> I copied the kernels from David (9legacy.org/download/kernel.tar.bz2),
> untar'ed it. This copied into /386/9pcf. Then I do:

I don't know what's on 9legacy.org. Copy the labs kernel from
/386/9pcf since after reboot it will support the updated labs
binaries that use nsec() syscall.

My assumption is you are running an old kernel with new
binaries.

> 9fat:
> _cp /386/9pcf /n/9fat/9pcf
>
> But I get an error message: '/n/9fat/9pcf clone failed'.

9fat: will use the new binaries! Look at /rc/bin/9fat: and
follow the steps using the old binaries. The following may
be enough.


_dossrv
_mount -c /srv/dos /n/9fat /dev/sdC0/9fat

Unless dossrv is already running (use _ps) and /n/9fat is
already mounted, in which case you will have to _unmount it
and kill dossrv.

Re: [9fans] suicide message on vmware

[Ramakrishnan Muthukrishnan]

Hi,

On Fri, Jun 6, 2014 at 1:30 PM, Bakul Shah <bakul@bitblocks.com> wrote:
> On Fri, 06 Jun 2014 13:02:14 +0530 Ramakrishnan Muthukrishnan <vu3rdd@gmail.com> wrote:
>> On Fri, Jun 6, 2014 at 11:30 AM, Bakul Shah <bakul@bitblocks.com> wrote:
>> > On Fri, 06 Jun 2014 10:48:21 +0530 Ramakrishnan Muthukrishnan <vu3rdd@gmail
>> .com> wrote:
>> >> Well, looks like I cannot run any binaries anymore and getting the
>> >> suicide message! I don't have anything critical on this vm image and
>> >> can re-install it. But I want to see if I can recover it and how. I
>> >> will re-read the "syscall 53" thread to look for any solutions.
>> >
>> > Aren't the old binaries saved under the same name  but
>> > prefixed with _?  If you haven't rebooted yet, you can use
>> > those to copy the new kernel to the FAT partition.
>>
>> Thanks, I didn't know that old binaries are kept prefixed with _. Very nice!
>>
>> I copied the kernels from David (9legacy.org/download/kernel.tar.bz2),
>> untar'ed it. This copied into /386/9pcf. Then I do:
>
> I don't know what's on 9legacy.org. Copy the labs kernel from
> /386/9pcf since after reboot it will support the updated labs
> binaries that use nsec() syscall.
>
> My assumption is you are running an old kernel with new
> binaries.

Yes.

>> 9fat:
>> _cp /386/9pcf /n/9fat/9pcf
>>
>> But I get an error message: '/n/9fat/9pcf clone failed'.
>
> 9fat: will use the new binaries! Look at /rc/bin/9fat: and

Ah, that's right. Thanks.

> follow the steps using the old binaries. The following may
> be enough.
>
> _dossrv
> _mount -c /srv/dos /n/9fat /dev/sdC0/9fat

Worked perfectly! Thanks.

--
  Ramakrishnan

Re: [9fans] suicide message on vmware

[Bakul Shah]

> 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 kernel 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 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 much have to treat the external sources as a "vendor branch" and do a careful merge to avoid such surprises.

Re: [9fans] suicide message on vmware

[erik quanstrom]

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 kernel 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 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 much have 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.

- erik

Re: [9fans] suicide message on vmware

[Ramakrishnan Muthukrishnan]

On Fri, Jun 6, 2014 at 9:05 PM, 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 kernel 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 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 much have 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 is the recommended way keep a 9atom system up to date?

-- 
  Ramakrishnan

Re: [9fans] suicide message on vmware

[erik quanstrom]

> > 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?

running pull as user glenda, same as the standard distribution.
there are options to update just parts of the system at a time.

- erik

Re: [9fans] suicide message on vmware

[Ramakrishnan Muthukrishnan]

On Fri, Jun 6, 2014 at 8:54 PM, Bakul Shah <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 kernel 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 running 9atom everything, you may have to undo nsec related changes in the userland.

I thought that replica/pull on a 9atom would pull 9atom binaries and
not the labs version. Looks like that assumption is wrong?

-- 
  Ramakrishnan

Re: [9fans] suicide message on vmware

[erik quanstrom]

> I thought that replica/pull on a 9atom would pull 9atom binaries and
> not the labs version. Looks like that assumption is wrong?

only on .iso versions of 9atom several years old.  to correct this issue,
you'd have to sync /usr/glenda/bin/rc/pull first.

- erik

Re: [9fans] suicide message on vmware

[Ramakrishnan Muthukrishnan]

On Fri, Jun 6, 2014 at 9:25 PM, erik quanstrom <quanstro@quanstro.net> wrote:
>> I thought that replica/pull on a 9atom would pull 9atom binaries and
>> not the labs version. Looks like that assumption is wrong?
>
> only on .iso versions of 9atom several years old.  to correct this issue,
> you'd have to sync /usr/glenda/bin/rc/pull first.

Thanks. I just discovered the existence of /dist/replica/atom which is
used by /usr/glenda/bin/rc/pull script.

--
  Ramakrishnan

Re: [9fans] suicide message on vmware

[erik quanstrom]

On Fri Jun  6 12:08:28 EDT 2014, vu3rdd@gmail.com wrote:
> On Fri, Jun 6, 2014 at 9:25 PM, erik quanstrom <quanstro@quanstro.net> wrote:
> >> I thought that replica/pull on a 9atom would pull 9atom binaries and
> >> not the labs version. Looks like that assumption is wrong?
> >
> > only on .iso versions of 9atom several years old.  to correct this issue,
> > you'd have to sync /usr/glenda/bin/rc/pull first.
>
> Thanks. I just discovered the existence of /dist/replica/atom which is
> used by /usr/glenda/bin/rc/pull script.

yup!  did you do it some other way?  that is, did i leave something
dangerous lying about?

- erik

Re: [9fans] suicide message on vmware

[Ramakrishnan Muthukrishnan]

On Fri, Jun 6, 2014 at 9:56 PM, erik quanstrom <quanstro@quanstro.net> wrote:
> On Fri Jun  6 12:08:28 EDT 2014, vu3rdd@gmail.com wrote:
>> On Fri, Jun 6, 2014 at 9:25 PM, erik quanstrom <quanstro@quanstro.net> wrote:
>> >> I thought that replica/pull on a 9atom would pull 9atom binaries and
>> >> not the labs version. Looks like that assumption is wrong?
>> >
>> > only on .iso versions of 9atom several years old.  to correct this issue,
>> > you'd have to sync /usr/glenda/bin/rc/pull first.
>>
>> Thanks. I just discovered the existence of /dist/replica/atom which is
>> used by /usr/glenda/bin/rc/pull script.
>
> yup!  did you do it some other way?  that is, did i leave something
> dangerous lying about?

Well, this morning when I tried to update, I did this:

replica/pull -v /dist/replica/network  # instead of /dist/replica/atom

instead of invoking the /usr/glenda/bin/rc/pull (which pulls from
/dist/replica/atom).

Sorry for the confusion. Entirely my fault and ignorance.
--
  Ramakrishnan

Re: [9fans] suicide message on vmware

[Bakul Shah]

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

Re: [9fans] suicide message on vmware

[erik quanstrom]

> What two databases?

the divergent versions of /sys/lib/dist/replica/plan9.db and its log
on the sources and 9atom.

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

that's what i said, but this is remove vs remote, and replica is
unable to deal with this sort of issue.

> 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.

 it would be a great feature, but it's unrelated to this failure.

i'm part of the way there with the patch system in atom.  in theory
a few scripts could allow one to add changes as required.  unfortunately,
it's pretty easy for this to go wrong, even with tools like hg.

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

if one recalls back to the beginning of the 4th edition, the
install cd would upgrade things as well as to initial installs.

- erik

Re: [9fans] suicide message on vmware

[Ramakrishnan Muthukrishnan]

My vm installation does not boot anymore with the new kernel (I forgot
to note down the error, but probably it is not worth reporting because
I messed up the system beyond repair).

I downloaded a fresh 9atom iso and installed under virtual box again.
After the installation (I got an error while the copydist was ~80%,
which again I forgot to note down) when I booted up the new
installation, it hangs after printing:
...
init: starting /bin/rc

But I am able to install the Labs edition just fine (downloaded this morning).

Just wanted to report it here.

Re: [9fans] suicide message on vmware

[Aram Hăvărneanu]

On Sat, Jun 7, 2014 at 1:24 PM, Ramakrishnan Muthukrishnan
<vu3rdd@gmail.com> wrote:
> it hangs after printing:
> ...
> init: starting /bin/rc

Probably a problem with timesync(8), disable it in your cpurc/termrc.

-- 
Aram Hăvărneanu

Re: [9fans] suicide message on vmware

[erik quanstrom]

> I downloaded a fresh 9atom iso and installed under virtual box again.
> After the installation (I got an error while the copydist was ~80%,
> which again I forgot to note down) when I booted up the new
> installation, it hangs after printing:

posting this error might be helpful.

- erik

Re: [9fans] suicide message on vmware

[Ramakrishnan Muthukrishnan]

[-- Attachment #1: Type: text/plain, Size: 459 bytes --]

On Sat, Jun 7, 2014 at 8:12 PM, erik quanstrom <quanstro@quanstro.net> wrote:
>> I downloaded a fresh 9atom iso and installed under virtual box again.
>> After the installation (I got an error while the copydist was ~80%,
>> which again I forgot to note down) when I booted up the new
>> installation, it hangs after printing:
>
> posting this error might be helpful.

Attaching the two screenshots of the warning and error messages during copydist.

[-- Attachment #2: Screen Shot 2014-06-07 at 10.39.14 pm.png --]
[-- Type: image/png, Size: 57441 bytes --]

[-- Attachment #3: Screen Shot 2014-06-07 at 10.39.45 pm.png --]
[-- Type: image/png, Size: 49659 bytes --]