pfr So is the SIGKILL warning related to xauth and should I be concerned? If not then I'll move on.
It can not be caught because it shouldn't be caught, only the kernel should be able to do it, check https://stackoverflow.com/questions/35569659/the-signals-sigkill-and-sigstop-cannot-be-caught-blocked-or-orignored-why
I had implemented a similar solution for SSH X11 forwarding in this thread. As for executing X locally, the startx script takes care of that already . What I was referring to is the inability to overwrite .Xauthority by executing startx if the permissions of the file are messed up.
JuvenalUrbino I was referring to is the inability to overwrite .Xauthority by executing startx if the permissions of the file are messed up.
Just out of curiosity, why should they be messed up? In which case, why not just using chmod to correct those?
I'd expect even more trouble when .Xauthority doesn't exist or, am I just confused?
pin Just out of curiosity, why should they be messed up?
As I mentioned above, I faced similar issues with a NFS-shared home, as I was using the same hostname/username combination across the various client systems. Also if I remember correctly, changing the hostname will confuse xauth, since the X11 client library will no longer be able to find a matching cookie inside .Xauhority, resulting in a rejected connection1.
Finally, if you're working as root in your user's HOME and launch a X session or you run startx with sudo, you'll generate a root-owned Xauthority. This is the sort of mistake one may make as *nix beginner,; in my case, it happened several years ago.
1 and since @pfr had been changing the hostname associated with the loopback address inside /etc/hosts, I thought that to be the root of the X11 hanging problem.
pin I'd expect even more trouble when .Xauthority doesn't exist or, am I just confused?
Not quite; since the startx script already takes care of invoking xauth to generate a random authorization cookie and store it inside .Xauthority as a MIT-MAGIC-COOKIE-1 entry, using startx or xdm to lauch a local X11 session should always be enough to get credentials right. Things get trickier when launching a session remotely with Xnest or Xephyr over SSH or XMDPC, since you have to that manuallly.
rvp Post your /etc/hosts, /etc/resolv.conf and /etc/rc.conf
Note: I've commented out the parts that JU had suggested I put in my hosts file and my rc.conf file. Anything I change in my resolve.conf file gets overwritten by resolveconf. The suggested edit here was to put domain isp.dns.tld
/etc/hosts
# $NetBSD: hosts,v 1.9 2013/11/24 07:20:01 dholland Exp $
#
# Host name database.
#
# This file contains addresses and aliases for local hosts whose names
# need to be resolvable during system boot; typically this includes only
# the address and FQDN for this machine's hostname.
#
# By default this file is consulted before DNS, so adding additional
# material here that then becomes out of date can lead to confusion.
# See nsswitch.conf(5).
#
::1 localhost hackbox.local hackbox
127.0.0.1 localhost hackbox.local hackbox
#::1 localhost localhost.sdf.org localhost
#127.0.0.1 localhost localhost.sdf.org localhost
#
# RFC 1918 specifies that these networks are "internal":
# 10.0.0.0 - 10.255.255.255 (10/8 prefix)
# 172.16.0.0 - 172.31.255.255 (172.16/12 prefix)
# 192.168.0.0 - 192.168.255.255 (192.168/16 prefix)/etc/resolve.conf
# Generated by resolvconf
domain local
nameserver 192.168.1.1/etc/rc.conf
# $NetBSD: rc.conf,v 1.97 2014/07/14 12:29:48 mbalmer Exp $
#
# See rc.conf(5) for more information.
#
# Use program=YES to enable program, NO to disable it. program_flags are
# passed to the program on the command line.
#
# Load the defaults in from /etc/defaults/rc.conf (if it's readable).
# These can be overridden below.
#
if [ -r /etc/defaults/rc.conf ]; then
. /etc/defaults/rc.conf
fi
# If this is not set to YES, the system will drop into single-user mode.
#
rc_configured=YES
critical_filesystems_local="OPTIONAL:/var OPTIONAL:/usr"
# Add local overrides below.
#
#domainname=sdf.org
hostname=hackbox
random_file=/etc/entropy-file
#securelevel=1
microcode=YES
#rtclocaltime=YES
rpcbind=YES
dbus=YES
famd=YES
powerd=YES
wpa_supplicant=YES
wpa_supplicant_flags="-B -D bsd -i iwn0 -c /etc/wpa_supplicant.conf"
dhcpcd=YES
dhcpcd_flags="-qM iwn0 -b"
npf=YES
xdm=NO
raidframe=NO
wscons=YES
sshd=NO
postfix=NO
ipv6addrctl=YES
ipv6addrctl_policy=ipv4_prefer
envsys=YESpfr #::1 localhost localhost.sdf.org localhost
#127.0.0.1 localhost localhost.sdf.org localhost
Looks like I got confused by your /etc/hosts syntax while providing suggestions: why are there 3 names for each address? It should be:
address hostname aliasP.S. the loopack address should always be 'localhost'.
This is why is better to ask for technical advise publicly rather than on private message; the mistake would have been spotted immediately. Also, this thread could have turned much shorter.
pfr # Generated by resolvconf
domain local
Is that your real resolv.conf? Usually resolvconf will associate the domain entry to your ISP's DNS if using dhcp on a home network.
As JU said, in /etc/hosts just leave the localhost entries alone (get the original lines from the base tar files).
In /etc/rc.conf change hostname to the FQDN:
hostname="hackbox.local"As a test, after the system has come up, add a line like this to /etc/hosts:
192.168.68.151 hackbox.local hackboxChange 192.168.68.151 to whatever IP you got via DHCP, then see if you get the same error.
JuvenalUrbino This is why is better to ask for technical advise publicly rather than on private message
Agreed.
JuvenalUrbino Also, this thread could have turned much shorter.
Long threads are kinda my thing 
JuvenalUrbino Is that your real resolv.conf?
Sadly, yes.
JuvenalUrbino Usually resolvconf will associate the domain entry to your ISP's DNS if using dhcp on a home network.
Full disclosure: I have absolutely ZERO idea about network stuff. Once I had my system connected to the internet without issues I left it alone and forgot about it.
rvp As JU said, in /etc/hosts just leave the localhost entries alone (get the original lines from the base tar files).
Can you please point me to where the base tar files are kept?
All I changed from the standard entries was my hostname which was originally localhost
So the standard entry was probably: localhost localhost.local localhost
I think I'll give myself a new hostname this time around. I'm thinking ... cringebox 
rvp Change 192.168.68.151 to whatever IP you got via DHCP, then see if you get the same error.
Once again, network configuration talk is like Arabic to me (hint: I don't speak Arabic)
I know how to turn my internet on/off and thats about it. Can you explain this step in a little more datail please?
ie. How can I ask my computer nicely to tell me what IP address DHCP has given me? ... I'm guessing ifconfig ?
Wow, really showing my weak points here. Is now a good time to remind everyone that I'm a Social Worker and not a trained IT/Sysadmin professional? 
PS. I'm happy to receive reading material on the subject that will help me to understand this better
pfr point me to where the base tar files are kept?
The etc.tar.xz should have the original.
pfr Can you explain this step in a little more datail please?
The Guide explains some of this. Chapter 24
pfr I'm guessing
ifconfig?
Yes.
rvp The etc.tar.xz should have the original
I always keep a etc set for the running is version extracted at /usr/src or at /var/cache/sysupgrade, even though in the meantime, I've learned to backup original configs first. Few core things like rc.conf are always available at /etc/defaults. Then there's /usr/share/examples.
rvp
This did the trick. Thanks.
After reading through that wiki I feel a little more confident in what I'm doing now. Cheers 
rvp
You suggesting I set up a static IP? I'm game if you are!
Surely I could automate the manual part though with a script that is run at boot to edit my hosts file? Some awk/grep/sed magic ought to do it right? Even if I need to run the script manually after booting, it wouldn't be the end of the world.
pfr You suggesting I set up a static IP?
That's one way to do it: setup the router to hand out the same IP address based on a MAC address--but that you can handle on your own.
What I had in mind (if your dinky box is capable of it) is to have it assign your laptop any address it wants, but, associate the hostname we send it with that IP address. So you can change hackbox.X.Y to crackbox.X.Y and the router will answer DNS correctly. You can do this on standard Unix, but, I don't know if your router-box can.
In any case, this would mainly be router config. so better done off-board. This is United_BSD_, not Home-Router BBS. eh?
rvp In any case, this would mainly be router config. so better done off-board.
I'll email you