>   
> 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 via email to