Abort Trap question

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Abort Trap question

Daniel Boyd-2
I've installed OpenBSD/macppc twice on my G4 Cube now and it seems to
be working fine until I go to untar src.tar.gz at which point it throws
some abort trap errors and crashes.  If I reboot, I get a bunch of
abort traps during the boot process followed by several:

init: can't exec getty '/usr/libexec/getty' for pot /dev/ttyC3: ...

What do you guys think this is...?  Hard drive failure...?

Reply | Threaded
Open this post in threaded view
|

Re: Abort Trap question

Mike Coddington
On Wed, Nov 15, 2017 at 10:01:09AM -0600, Daniel Boyd wrote:
> I've installed OpenBSD/macppc twice on my G4 Cube now and it seems to
> be working fine until I go to untar src.tar.gz at which point it throws
> some abort trap errors and crashes.  If I reboot, I get a bunch of
> abort traps during the boot process followed by several:
>
> init: can't exec getty '/usr/libexec/getty' for pot /dev/ttyC3: ...
>
> What do you guys think this is...?  Hard drive failure...?

Out of curiosity, does the same thing happen if you extract the tar with
the pax(1) program? That'll at least let you know if it's tar causing
the problem or not.

--
Put your Nose to the Grindstone!
                -- Amalgamated Plastic Surgeons and Toolmakers, Ltd.

Reply | Threaded
Open this post in threaded view
|

Re: Abort Trap question

Daniel Boyd-2
On Wed, 2017-11-15 at 13:08 -0600, Mike Coddington wrote:

> On Wed, Nov 15, 2017 at 10:01:09AM -0600, Daniel Boyd wrote:
> > I've installed OpenBSD/macppc twice on my G4 Cube now and it seems
> > to
> > be working fine until I go to untar src.tar.gz at which point it
> > throws
> > some abort trap errors and crashes.  If I reboot, I get a bunch of
> > abort traps during the boot process followed by several:
> >
> > init: can't exec getty '/usr/libexec/getty' for pot /dev/ttyC3: ...
> >
> > What do you guys think this is...?  Hard drive failure...?
>
> Out of curiosity, does the same thing happen if you extract the tar
> with
> the pax(1) program? That'll at least let you know if it's tar causing
> the problem or not.
>
>

Heh ... give me a couple days.  Need to find time to re-install the
system since it wno't boot anymore.  Have to set up a NFS server b/c
the CD-ROM drive is busted.

Reply | Threaded
Open this post in threaded view
|

Re: Abort Trap question

Philip Guenther-2
In reply to this post by Mike Coddington
On Wed, Nov 15, 2017 at 11:08 AM, Mike Coddington <[hidden email]>
wrote:

> On Wed, Nov 15, 2017 at 10:01:09AM -0600, Daniel Boyd wrote:
> > I've installed OpenBSD/macppc twice on my G4 Cube now and it seems to
> > be working fine until I go to untar src.tar.gz at which point it throws
> > some abort trap errors and crashes.  If I reboot, I get a bunch of
> > abort traps during the boot process followed by several:
> >
> > init: can't exec getty '/usr/libexec/getty' for pot /dev/ttyC3: ...
> >
> > What do you guys think this is...?  Hard drive failure...?
>
> Out of curiosity, does the same thing happen if you extract the tar with
> the pax(1) program? That'll at least let you know if it's tar causing
> the problem or not.
>

tar _is_ pax:
: corwin; ls -li /bin/tar /bin/pax
52015 -r-xr-xr-x  3 root  bin  433472 Nov  1 11:15 /bin/pax
52015 -r-xr-xr-x  3 root  bin  433472 Nov  1 11:15 /bin/tar
: corwin;

Fundamentally, unless a userspace process is poking at devices or similar,
it should be unable to panic the kernel.  An abort trap in the kernel is
either a kernel bug or a hardware bug.  IIRC there's some pmap bug on
macppc that no one has managed to track down which causes crashes on some
machines, but not others.  I've never hit it on the Macbook I use for
builds, but the ports build boxes, whatever model they are, seem to hit it
periodically...


Philip Guenther
Reply | Threaded
Open this post in threaded view
|

Re: Abort Trap question

Daniel Boyd-2
On Wed, 2017-11-15 at 13:35 -0800, Philip Guenther wrote:

>
> tar _is_ pax:
> : corwin; ls -li /bin/tar /bin/pax
> 52015 -r-xr-xr-x  3 root  bin  433472 Nov  1 11:15 /bin/pax
> 52015 -r-xr-xr-x  3 root  bin  433472 Nov  1 11:15 /bin/tar
> : corwin;
>
> Fundamentally, unless a userspace process is poking at devices or
> similar,
> it should be unable to panic the kernel.  An abort trap in the kernel
> is
> either a kernel bug or a hardware bug.  IIRC there's some pmap bug on
> macppc that no one has managed to track down which causes crashes on
> some
> machines, but not others.  I've never hit it on the Macbook I use for
> builds, but the ports build boxes, whatever model they are, seem to
> hit it
> periodically...
>
>
> Philip Guenther
>

I'm happy to help track down the issue if someone will tell me what to
do.  I will reload the OS on the machine when I get a chance.  How will
we be able to determine whether we're dealing with a kernel bug or a
hardware failure?

Reply | Threaded
Open this post in threaded view
|

Re: Abort Trap question

patrick keshishian
In reply to this post by Philip Guenther-2
On 11/15/17, Philip Guenther <[hidden email]> wrote:

> On Wed, Nov 15, 2017 at 11:08 AM, Mike Coddington <[hidden email]>
> wrote:
>
>> On Wed, Nov 15, 2017 at 10:01:09AM -0600, Daniel Boyd wrote:
>> > I've installed OpenBSD/macppc twice on my G4 Cube now and it seems to
>> > be working fine until I go to untar src.tar.gz at which point it throws
>> > some abort trap errors and crashes.  If I reboot, I get a bunch of
>> > abort traps during the boot process followed by several:
>> >
>> > init: can't exec getty '/usr/libexec/getty' for pot /dev/ttyC3: ...
>> >
>> > What do you guys think this is...?  Hard drive failure...?
>>
>> Out of curiosity, does the same thing happen if you extract the tar with
>> the pax(1) program? That'll at least let you know if it's tar causing
>> the problem or not.
>>
>
> tar _is_ pax:
> : corwin; ls -li /bin/tar /bin/pax
> 52015 -r-xr-xr-x  3 root  bin  433472 Nov  1 11:15 /bin/pax
> 52015 -r-xr-xr-x  3 root  bin  433472 Nov  1 11:15 /bin/tar
> : corwin;
>
> Fundamentally, unless a userspace process is poking at devices or similar,
> it should be unable to panic the kernel.  An abort trap in the kernel is
> either a kernel bug or a hardware bug.  IIRC there's some pmap bug on
> macppc that no one has managed to track down which causes crashes on some
> machines, but not others.  I've never hit it on the Macbook I use for
> builds, but the ports build boxes, whatever model they are, seem to hit it
> periodically...

I read it as the tar process is the one aborting. which, if true,
sounds like user-land and kernel are out-of-sync.

Unfortunately, specific info is missing from the problem report.

--patrick

Reply | Threaded
Open this post in threaded view
|

Re: Abort Trap question

Ax0n
A quick thought... are you extracting src.tar.gz into /usr (like you to
with ports.tar.gz)? On a few occasions, I've done this (instead of making
sure I'm in /usr/src first as I should) and had system binaries get
clobbered. When I've accidentally done this in the past, I do get a bunch
of abort trap errors and a predictably un-bootable system.  Example: This
block of stuff from src.tar.gz, if extracted whilst in /usr, would
overwrite /usr/bin/cat with a directory full of the source code for cat(1)
and so on and so forth.

drwxrwxr-x  2 axon     axon             0 Oct  9 22:41 bin
drwxrwxr-x  2 axon     axon             0 Oct  9 22:41 bin/CVS
-rw-rw-r--  1 axon     axon             5 Oct  9 22:38 bin/CVS/Root
-rw-rw-r--  1 axon     axon             8 Oct  9 22:38 bin/CVS/Repository
-rw-rw-r--  1 axon     axon           439 Oct  9 22:41 bin/CVS/Entries
-rw-rw-r--  1 axon     axon            18 Oct  9 22:41 bin/CVS/Tag
-rw-rw-r--  1 axon     axon           241 Apr 25  2016 bin/Makefile
-rw-rw-r--  1 axon     axon           145 Jul 11  2014 bin/Makefile.inc
drwxrwxr-x  2 axon     axon             0 Oct  9 22:38 bin/cat
drwxrwxr-x  2 axon     axon             0 Oct  9 22:41 bin/cat/CVS
-rw-rw-r--  1 axon     axon             5 Oct  9 22:38 bin/cat/CVS/Root
-rw-rw-r--  1 axon     axon            12 Oct  9 22:38
bin/cat/CVS/Repository
-rw-rw-r--  1 axon     axon           172 Oct  9 22:41 bin/cat/CVS/Entries
-rw-rw-r--  1 axon     axon            18 Oct  9 22:41 bin/cat/CVS/Tag
-rw-rw-r--  1 axon     axon            93 Feb 18  2017 bin/cat/Makefile
-rw-rw-r--  1 axon     axon          4848 Jul  9  2016 bin/cat/cat.1
-rw-rw-r--  1 axon     axon          5567 Oct 19  2016 bin/cat/cat.c



On Wed, Nov 15, 2017 at 5:24 PM, patrick keshishian <[hidden email]>
wrote:

> On 11/15/17, Philip Guenther <[hidden email]> wrote:
> > On Wed, Nov 15, 2017 at 11:08 AM, Mike Coddington <[hidden email]>
> > wrote:
> >
> >> On Wed, Nov 15, 2017 at 10:01:09AM -0600, Daniel Boyd wrote:
> >> > I've installed OpenBSD/macppc twice on my G4 Cube now and it seems to
> >> > be working fine until I go to untar src.tar.gz at which point it
> throws
> >> > some abort trap errors and crashes.  If I reboot, I get a bunch of
> >> > abort traps during the boot process followed by several:
> >> >
> >> > init: can't exec getty '/usr/libexec/getty' for pot /dev/ttyC3: ...
> >> >
> >> > What do you guys think this is...?  Hard drive failure...?
> >>
> >> Out of curiosity, does the same thing happen if you extract the tar with
> >> the pax(1) program? That'll at least let you know if it's tar causing
> >> the problem or not.
> >>
> >
> > tar _is_ pax:
> > : corwin; ls -li /bin/tar /bin/pax
> > 52015 -r-xr-xr-x  3 root  bin  433472 Nov  1 11:15 /bin/pax
> > 52015 -r-xr-xr-x  3 root  bin  433472 Nov  1 11:15 /bin/tar
> > : corwin;
> >
> > Fundamentally, unless a userspace process is poking at devices or
> similar,
> > it should be unable to panic the kernel.  An abort trap in the kernel is
> > either a kernel bug or a hardware bug.  IIRC there's some pmap bug on
> > macppc that no one has managed to track down which causes crashes on some
> > machines, but not others.  I've never hit it on the Macbook I use for
> > builds, but the ports build boxes, whatever model they are, seem to hit
> it
> > periodically...
>
> I read it as the tar process is the one aborting. which, if true,
> sounds like user-land and kernel are out-of-sync.
>
> Unfortunately, specific info is missing from the problem report.
>
> --patrick
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Abort Trap question

Daniel Boyd-2
Haha crap.  I think this is what happened.   I haven’t bothered downloading src.tar.gz in awhile bc of syspatch, but since this is a PowerPC machine, i wanted to be ready for the first errata.  This is what I get for doing things from memory instead of reading the FAQ.

Right.  Let’s pretend that this didn’t happen, shall we?

Sent from my iPhone

> On Nov 15, 2017, at 8:54 PM, Ax0n <[hidden email]> wrote:
>
> A quick thought... are you extracting src.tar.gz into /usr (like you to
> with ports.tar.gz)? On a few occasions, I've done this (instead of making
> sure I'm in /usr/src first as I should) and had system binaries get
> clobbered. When I've accidentally done this in the past, I do get a bunch
> of abort trap errors and a predictably un-bootable system.  Example: This
> block of stuff from src.tar.gz, if extracted whilst in /usr, would
> overwrite /usr/bin/cat with a directory full of the source code for cat(1)
> and so on and so forth.
>
> drwxrwxr-x  2 axon     axon             0 Oct  9 22:41 bin
> drwxrwxr-x  2 axon     axon             0 Oct  9 22:41 bin/CVS
> -rw-rw-r--  1 axon     axon             5 Oct  9 22:38 bin/CVS/Root
> -rw-rw-r--  1 axon     axon             8 Oct  9 22:38 bin/CVS/Repository
> -rw-rw-r--  1 axon     axon           439 Oct  9 22:41 bin/CVS/Entries
> -rw-rw-r--  1 axon     axon            18 Oct  9 22:41 bin/CVS/Tag
> -rw-rw-r--  1 axon     axon           241 Apr 25  2016 bin/Makefile
> -rw-rw-r--  1 axon     axon           145 Jul 11  2014 bin/Makefile.inc
> drwxrwxr-x  2 axon     axon             0 Oct  9 22:38 bin/cat
> drwxrwxr-x  2 axon     axon             0 Oct  9 22:41 bin/cat/CVS
> -rw-rw-r--  1 axon     axon             5 Oct  9 22:38 bin/cat/CVS/Root
> -rw-rw-r--  1 axon     axon            12 Oct  9 22:38
> bin/cat/CVS/Repository
> -rw-rw-r--  1 axon     axon           172 Oct  9 22:41 bin/cat/CVS/Entries
> -rw-rw-r--  1 axon     axon            18 Oct  9 22:41 bin/cat/CVS/Tag
> -rw-rw-r--  1 axon     axon            93 Feb 18  2017 bin/cat/Makefile
> -rw-rw-r--  1 axon     axon          4848 Jul  9  2016 bin/cat/cat.1
> -rw-rw-r--  1 axon     axon          5567 Oct 19  2016 bin/cat/cat.c
>
>
>
> On Wed, Nov 15, 2017 at 5:24 PM, patrick keshishian <[hidden email]>
> wrote:
>
>>> On 11/15/17, Philip Guenther <[hidden email]> wrote:
>>> On Wed, Nov 15, 2017 at 11:08 AM, Mike Coddington <[hidden email]>
>>> wrote:
>>>
>>>>> On Wed, Nov 15, 2017 at 10:01:09AM -0600, Daniel Boyd wrote:
>>>>> I've installed OpenBSD/macppc twice on my G4 Cube now and it seems to
>>>>> be working fine until I go to untar src.tar.gz at which point it
>> throws
>>>>> some abort trap errors and crashes.  If I reboot, I get a bunch of
>>>>> abort traps during the boot process followed by several:
>>>>>
>>>>> init: can't exec getty '/usr/libexec/getty' for pot /dev/ttyC3: ...
>>>>>
>>>>> What do you guys think this is...?  Hard drive failure...?
>>>>
>>>> Out of curiosity, does the same thing happen if you extract the tar with
>>>> the pax(1) program? That'll at least let you know if it's tar causing
>>>> the problem or not.
>>>>
>>>
>>> tar _is_ pax:
>>> : corwin; ls -li /bin/tar /bin/pax
>>> 52015 -r-xr-xr-x  3 root  bin  433472 Nov  1 11:15 /bin/pax
>>> 52015 -r-xr-xr-x  3 root  bin  433472 Nov  1 11:15 /bin/tar
>>> : corwin;
>>>
>>> Fundamentally, unless a userspace process is poking at devices or
>> similar,
>>> it should be unable to panic the kernel.  An abort trap in the kernel is
>>> either a kernel bug or a hardware bug.  IIRC there's some pmap bug on
>>> macppc that no one has managed to track down which causes crashes on some
>>> machines, but not others.  I've never hit it on the Macbook I use for
>>> builds, but the ports build boxes, whatever model they are, seem to hit
>> it
>>> periodically...
>>
>> I read it as the tar process is the one aborting. which, if true,
>> sounds like user-land and kernel are out-of-sync.
>>
>> Unfortunately, specific info is missing from the problem report.
>>
>> --patrick
>>
>>

Reply | Threaded
Open this post in threaded view
|

tar bombs (was: RE: Abort Trap question)

leo_tck
In reply to this post by Ax0n
Hi,

"Daniel Boyd" <[hidden email]> wrote:
> Haha crap. I think this is what happened. I haven't bothered downloading src.tar.gz in awhile bc of syspatch, but since this is a PowerPC machine, i wanted to be ready for the first errata. This is what I get for doing things from memory instead of reading the FAQ.

Mistakes happen, don't worry =)

Though I consider it good practice to at least do a 'pax -v | head'
before extracting anything. And in dubious cases, I create a '.x/' dir
first and do the extraction in there.

HTH,

          --schaafuit.

Reply | Threaded
Open this post in threaded view
|

Re: Abort Trap question

Edgar Pettijohn III-2
In reply to this post by Daniel Boyd-2
 
 

 
 
 

 
 
 
 
 

>  
> On Nov 16, 2017 at 6:14 AM,  <Daniel Boyd>  wrote:
>  
>  
>  Haha crap. I think this is what happened. I haven’t bothered downloading src.tar.gz in awhile bc of syspatch, but since this is a PowerPC machine, i wanted to be ready for the first errata. This is what I get for doing things from memory instead of reading the FAQ.  
>    
>  
>  
>    
>  
>  The last I looked it had been removed from the FAQ. I didn't want to glob my system so I had to look through CVS to find the version with pre packing your src tree.  

 
>  
>  
>    
>  
>  Right. Let’s pretend that this didn’t happen, shall we  
>    
>  
>  Sent from my iPhone  >  On Nov 15, 2017, at 8:54 PM, Ax0n wrote:  >   >  A quick thought... are you extracting src.tar.gz into /usr (like you to  >  with ports.tar.gz)? On a few occasions, I've done this (instead of making  >  sure I'm in /usr/src first as I should) and had system binaries get  >  clobbered. When I've accidentally done this in the past, I do get a bunch  >  of abort trap errors and a predictably un-bootable system. Example: This  >  block of stuff from src.tar.gz, if extracted whilst in /usr, would  >  overwrite /usr/bin/cat with a directory full of the source code for cat(1)  >  and so on and so forth.  >   >  drwxrwxr-x 2 axon axon 0 Oct 9 22:41 bin  >  drwxrwxr-x 2 axon axon 0 Oct 9 22:41 bin/CVS  >  -rw-rw-r-- 1 axon axon 5 Oct 9 22:38 bin/CVS/Root  >  -rw-rw-r-- 1 axon axon 8 Oct 9 22:38 bin/CVS/Repository  >  -rw-rw-r-- 1 axon axon 439 Oct 9 22:41 bin/CVS/Entries  >  -rw-rw-r-- 1 axon axon 18 Oct 9 22:41 bin/CVS/Tag  >  -rw-rw-r-- 1 axon axon 241 Apr 25 2016 bin/Makefile  >  -rw-rw-r-- 1 axon axon 145 Jul 11 2014 bin/Makefile.inc  >  drwxrwxr-x 2 axon axon 0 Oct 9 22:38 bin/cat  >  drwxrwxr-x 2 axon axon 0 Oct 9 22:41 bin/cat/CVS  >  -rw-rw-r-- 1 axon axon 5 Oct 9 22:38 bin/cat/CVS/Root  >  -rw-rw-r-- 1 axon axon 12 Oct 9 22:38  >  bin/cat/CVS/Repository  >  -rw-rw-r-- 1 axon axon 172 Oct 9 22:41 bin/cat/CVS/Entries  >  -rw-rw-r-- 1 axon axon 18 Oct 9 22:41 bin/cat/CVS/Tag  >  -rw-rw-r-- 1 axon axon 93 Feb 18 2017 bin/cat/Makefile  >  -rw-rw-r-- 1 axon axon 4848 Jul 9 2016 bin/cat/cat.1  >  -rw-rw-r-- 1 axon axon 5567 Oct 19 2016 bin/cat/cat.c  >   >   >   >  On Wed, Nov 15, 2017 at 5:24 PM, patrick keshishian  >  wrote:  >   >>>  On 11/15/17, Philip Guenther wrote:  >>>  On Wed, Nov 15, 2017 at 11:08 AM, Mike Coddington  >>>  wrote:  >>>   >>>>>  On Wed, Nov 15, 2017 at 10:01:09AM -0600, Daniel Boyd wrote:  >>>>>  I've installed OpenBSD/macppc twice on my G4 Cube now and it seems to  >>>>>  be working fine until I go to untar src.tar.gz at which point it  >>  throws  >>>>>  some abort trap errors and crashes. If I reboot, I get a bunch of  >>>>>  abort traps during the boot process followed by several:  >>>>>   >>>>>  init: can't exec getty '/usr/libexec/getty' for pot /dev/ttyC3: ...  >>>>>   >>>>>  What do you guys think this is...? Hard drive failure...?  >>>>   >>>>  Out of curiosity, does the same thing happen if you extract the tar with  >>>>  the pax(1) program? That'll at least let you know if it's tar causing  >>>>  the problem or not.  >>>>   >>>   >>>  tar _is_ pax:  >>>  : corwin; ls -li /bin/tar /bin/pax  >>>  52015 -r-xr-xr-x 3 root bin 433472 Nov 1 11:15 /bin/pax  >>>  52015 -r-xr-xr-x 3 root bin 433472 Nov 1 11:15 /bin/tar  >>>  : corwin;  >>>   >>>  Fundamentally, unless a userspace process is poking at devices or  >>  similar,  >>>  it should be unable to panic the kernel. An abort trap in the kernel is  >>>  either a kernel bug or a hardware bug. IIRC there's some pmap bug on  >>>  macppc that no one has managed to track down which causes crashes on some  >>>  machines, but not others. I've never hit it on the Macbook I use for  >>>  builds, but the ports build boxes, whatever model they are, seem to hit  >>  it  >>>  periodically...  >>   >>  I read it as the tar process is the one aborting. which, if true,  >>  sounds like user-land and kernel are out-of-sync.  >>   >>  Unfortunately, specific info is missing from the problem report.  >>   >>  --patrick  >>   >>  
>  
     
Reply | Threaded
Open this post in threaded view
|

Re: Abort Trap question

Ax0n
In reply to this post by Daniel Boyd-2
For what it's worth, bricking my main workstation in this way a few times
over the past 20 years yes the only reason I thought about it. It also got
me into a (good) habit of examining the paths and contents of archive files
every single time before I extract them.

On Nov 16, 2017 06:14, "Daniel Boyd" <[hidden email]> wrote:

> Haha crap.  I think this is what happened.   I haven’t bothered
> downloading src.tar.gz in awhile bc of syspatch, but since this is a
> PowerPC machine, i wanted to be ready for the first errata.  This is what I
> get for doing things from memory instead of reading the FAQ.
>
> Right.  Let’s pretend that this didn’t happen, shall we?
>
> Sent from my iPhone
>
> > On Nov 15, 2017, at 8:54 PM, Ax0n <[hidden email]> wrote:
> >
> > A quick thought... are you extracting src.tar.gz into /usr (like you to
> > with ports.tar.gz)? On a few occasions, I've done this (instead of making
> > sure I'm in /usr/src first as I should) and had system binaries get
> > clobbered. When I've accidentally done this in the past, I do get a bunch
> > of abort trap errors and a predictably un-bootable system.  Example: This
> > block of stuff from src.tar.gz, if extracted whilst in /usr, would
> > overwrite /usr/bin/cat with a directory full of the source code for
> cat(1)
> > and so on and so forth.
> >
> > drwxrwxr-x  2 axon     axon             0 Oct  9 22:41 bin
> > drwxrwxr-x  2 axon     axon             0 Oct  9 22:41 bin/CVS
> > -rw-rw-r--  1 axon     axon             5 Oct  9 22:38 bin/CVS/Root
> > -rw-rw-r--  1 axon     axon             8 Oct  9 22:38 bin/CVS/Repository
> > -rw-rw-r--  1 axon     axon           439 Oct  9 22:41 bin/CVS/Entries
> > -rw-rw-r--  1 axon     axon            18 Oct  9 22:41 bin/CVS/Tag
> > -rw-rw-r--  1 axon     axon           241 Apr 25  2016 bin/Makefile
> > -rw-rw-r--  1 axon     axon           145 Jul 11  2014 bin/Makefile.inc
> > drwxrwxr-x  2 axon     axon             0 Oct  9 22:38 bin/cat
> > drwxrwxr-x  2 axon     axon             0 Oct  9 22:41 bin/cat/CVS
> > -rw-rw-r--  1 axon     axon             5 Oct  9 22:38 bin/cat/CVS/Root
> > -rw-rw-r--  1 axon     axon            12 Oct  9 22:38
> > bin/cat/CVS/Repository
> > -rw-rw-r--  1 axon     axon           172 Oct  9 22:41
> bin/cat/CVS/Entries
> > -rw-rw-r--  1 axon     axon            18 Oct  9 22:41 bin/cat/CVS/Tag
> > -rw-rw-r--  1 axon     axon            93 Feb 18  2017 bin/cat/Makefile
> > -rw-rw-r--  1 axon     axon          4848 Jul  9  2016 bin/cat/cat.1
> > -rw-rw-r--  1 axon     axon          5567 Oct 19  2016 bin/cat/cat.c
> >
> >
> >
> > On Wed, Nov 15, 2017 at 5:24 PM, patrick keshishian <[hidden email]>
> > wrote:
> >
> >>> On 11/15/17, Philip Guenther <[hidden email]> wrote:
> >>> On Wed, Nov 15, 2017 at 11:08 AM, Mike Coddington <[hidden email]>
> >>> wrote:
> >>>
> >>>>> On Wed, Nov 15, 2017 at 10:01:09AM -0600, Daniel Boyd wrote:
> >>>>> I've installed OpenBSD/macppc twice on my G4 Cube now and it seems to
> >>>>> be working fine until I go to untar src.tar.gz at which point it
> >> throws
> >>>>> some abort trap errors and crashes.  If I reboot, I get a bunch of
> >>>>> abort traps during the boot process followed by several:
> >>>>>
> >>>>> init: can't exec getty '/usr/libexec/getty' for pot /dev/ttyC3: ...
> >>>>>
> >>>>> What do you guys think this is...?  Hard drive failure...?
> >>>>
> >>>> Out of curiosity, does the same thing happen if you extract the tar
> with
> >>>> the pax(1) program? That'll at least let you know if it's tar causing
> >>>> the problem or not.
> >>>>
> >>>
> >>> tar _is_ pax:
> >>> : corwin; ls -li /bin/tar /bin/pax
> >>> 52015 -r-xr-xr-x  3 root  bin  433472 Nov  1 11:15 /bin/pax
> >>> 52015 -r-xr-xr-x  3 root  bin  433472 Nov  1 11:15 /bin/tar
> >>> : corwin;
> >>>
> >>> Fundamentally, unless a userspace process is poking at devices or
> >> similar,
> >>> it should be unable to panic the kernel.  An abort trap in the kernel
> is
> >>> either a kernel bug or a hardware bug.  IIRC there's some pmap bug on
> >>> macppc that no one has managed to track down which causes crashes on
> some
> >>> machines, but not others.  I've never hit it on the Macbook I use for
> >>> builds, but the ports build boxes, whatever model they are, seem to hit
> >> it
> >>> periodically...
> >>
> >> I read it as the tar process is the one aborting. which, if true,
> >> sounds like user-land and kernel are out-of-sync.
> >>
> >> Unfortunately, specific info is missing from the problem report.
> >>
> >> --patrick
> >>
> >>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Abort Trap question

Nick Holland


On 11/16/17 08:40, Ax0n wrote:

> For what it's worth, bricking my main workstation in this way a few times
> over the past 20 years yes the only reason I thought about it. It also got
> me into a (good) habit of examining the paths and contents of archive files
> every single time before I extract them.
>
> On Nov 16, 2017 06:14, "Daniel Boyd" <[hidden email]> wrote:
>
>> Haha crap.  I think this is what happened.   I haven’t bothered
>> downloading src.tar.gz in awhile bc of syspatch, but since this is a
>> PowerPC machine, i wanted to be ready for the first errata.  This is what I
>> get for doing things from memory instead of reading the FAQ.
>>
>> Right.  Let’s pretend that this didn’t happen, shall we?
>>
>> Sent from my iPhone

good news: that means your recovery is probably pretty easy -- just boot
from bsd.rd (which should be unharmed) and do a re-install.

Nick.

>>
>> > On Nov 15, 2017, at 8:54 PM, Ax0n <[hidden email]> wrote:
>> >
>> > A quick thought... are you extracting src.tar.gz into /usr (like you to
>> > with ports.tar.gz)? On a few occasions, I've done this (instead of making
>> > sure I'm in /usr/src first as I should) and had system binaries get
>> > clobbered. When I've accidentally done this in the past, I do get a bunch
>> > of abort trap errors and a predictably un-bootable system.  Example: This
>> > block of stuff from src.tar.gz, if extracted whilst in /usr, would
>> > overwrite /usr/bin/cat with a directory full of the source code for
>> cat(1)
>> > and so on and so forth.
>> >
>> > drwxrwxr-x  2 axon     axon             0 Oct  9 22:41 bin
>> > drwxrwxr-x  2 axon     axon             0 Oct  9 22:41 bin/CVS
>> > -rw-rw-r--  1 axon     axon             5 Oct  9 22:38 bin/CVS/Root
>> > -rw-rw-r--  1 axon     axon             8 Oct  9 22:38 bin/CVS/Repository
>> > -rw-rw-r--  1 axon     axon           439 Oct  9 22:41 bin/CVS/Entries
>> > -rw-rw-r--  1 axon     axon            18 Oct  9 22:41 bin/CVS/Tag
>> > -rw-rw-r--  1 axon     axon           241 Apr 25  2016 bin/Makefile
>> > -rw-rw-r--  1 axon     axon           145 Jul 11  2014 bin/Makefile.inc
>> > drwxrwxr-x  2 axon     axon             0 Oct  9 22:38 bin/cat
>> > drwxrwxr-x  2 axon     axon             0 Oct  9 22:41 bin/cat/CVS
>> > -rw-rw-r--  1 axon     axon             5 Oct  9 22:38 bin/cat/CVS/Root
>> > -rw-rw-r--  1 axon     axon            12 Oct  9 22:38
>> > bin/cat/CVS/Repository
>> > -rw-rw-r--  1 axon     axon           172 Oct  9 22:41
>> bin/cat/CVS/Entries
>> > -rw-rw-r--  1 axon     axon            18 Oct  9 22:41 bin/cat/CVS/Tag
>> > -rw-rw-r--  1 axon     axon            93 Feb 18  2017 bin/cat/Makefile
>> > -rw-rw-r--  1 axon     axon          4848 Jul  9  2016 bin/cat/cat.1
>> > -rw-rw-r--  1 axon     axon          5567 Oct 19  2016 bin/cat/cat.c
>> >
>> >
>> >
>> > On Wed, Nov 15, 2017 at 5:24 PM, patrick keshishian <[hidden email]>
>> > wrote:
>> >
>> >>> On 11/15/17, Philip Guenther <[hidden email]> wrote:
>> >>> On Wed, Nov 15, 2017 at 11:08 AM, Mike Coddington <[hidden email]>
>> >>> wrote:
>> >>>
>> >>>>> On Wed, Nov 15, 2017 at 10:01:09AM -0600, Daniel Boyd wrote:
>> >>>>> I've installed OpenBSD/macppc twice on my G4 Cube now and it seems to
>> >>>>> be working fine until I go to untar src.tar.gz at which point it
>> >> throws
>> >>>>> some abort trap errors and crashes.  If I reboot, I get a bunch of
>> >>>>> abort traps during the boot process followed by several:
>> >>>>>
>> >>>>> init: can't exec getty '/usr/libexec/getty' for pot /dev/ttyC3: ...
>> >>>>>
>> >>>>> What do you guys think this is...?  Hard drive failure...?
>> >>>>
>> >>>> Out of curiosity, does the same thing happen if you extract the tar
>> with
>> >>>> the pax(1) program? That'll at least let you know if it's tar causing
>> >>>> the problem or not.
>> >>>>
>> >>>
>> >>> tar _is_ pax:
>> >>> : corwin; ls -li /bin/tar /bin/pax
>> >>> 52015 -r-xr-xr-x  3 root  bin  433472 Nov  1 11:15 /bin/pax
>> >>> 52015 -r-xr-xr-x  3 root  bin  433472 Nov  1 11:15 /bin/tar
>> >>> : corwin;
>> >>>
>> >>> Fundamentally, unless a userspace process is poking at devices or
>> >> similar,
>> >>> it should be unable to panic the kernel.  An abort trap in the kernel
>> is
>> >>> either a kernel bug or a hardware bug.  IIRC there's some pmap bug on
>> >>> macppc that no one has managed to track down which causes crashes on
>> some
>> >>> machines, but not others.  I've never hit it on the Macbook I use for
>> >>> builds, but the ports build boxes, whatever model they are, seem to hit
>> >> it
>> >>> periodically...
>> >>
>> >> I read it as the tar process is the one aborting. which, if true,
>> >> sounds like user-land and kernel are out-of-sync.
>> >>
>> >> Unfortunately, specific info is missing from the problem report.
>> >>
>> >> --patrick
>> >>
>> >>
>>
>>
>