TierHive General thread | Discuss, Updates, questions | LATEST: INSTALL FROM ISO available

btxx

@AnthonySmith said: Canada is back up.

Motherboard issues it has been replaced, and the server is back up, restoring services now.

Before I even had time to realize it was down, it's back up

Not_Oles

After working for several hours this morning on my Hillsboro NetBSD instance via both ssh and also via the web console, I took time off for lunch. Now, suddenly, the TierHive web Console, which worked fine all of yesterday and this morning, suddenly seems stuck at "Connecting to your VPS" and then eventually times out. Happily, ssh access continues to work as expected.

I tried rebooting the NetBSD instance both from within the VPS and via Shutdown followed by Boot from the TierHive Control Panel. I tried reloading the TierHive Control Panel. I tried completely logging out and logging back in to the TierHive Control Panel.

NetBSD dmesg output seems the same as previous boots where the web console worked.

Ideas on how to get the TierHive Control Panel Console to resume working, please? Thanks for any help!

• ssh is still working:

Last login: Wed Jun 24 21:03:45 2026 from xxx.xxx.xxx.xxx
NetBSD 11.0_RC5 (GENERIC) #0: Tue Jun 16 15:48:07 UTC 2026

Welcome to NetBSD!

This is a release candidate for NetBSD.

Bug reports: https://www.NetBSD.org/support/send-pr.html
Donations to the NetBSD Foundation: https://www.NetBSD.org/donations/
We recommend that you create a non-root account and use su(1) for root access.
hil# date
Wed Jun 24 21:17:43 UTC 2026
hil# uptime
 9:17PM  up 1 min, 1 user, load averages: 0.03, 0.01, 0.00
hil# 

*Output of grep wsdisplay /var/log/messages for most recent boot (noticed no difference from previous boots):

Jun 24 21:16:53 hil /netbsd: [   1.0148690] wsdisplay0 at genfb0 kbdmux 1: console (default, vt100 emulation), using wskbd0
Jun 24 21:16:53 hil /netbsd: [   1.0148690] wsmux1: connecting to wsdisplay0
Jun 24 21:16:53 hil /netbsd: [   9.4553710] wsdisplay0: screen 1 added (default, vt100 emulation)
Jun 24 21:16:53 hil /netbsd: [   9.4553710] wsdisplay0: screen 2 added (default, vt100 emulation)
Jun 24 21:16:53 hil /netbsd: [   9.4553710] wsdisplay0: screen 3 added (default, vt100 emulation)
Jun 24 21:16:53 hil /netbsd: [   9.4653812] wsdisplay0: screen 4 added (default, vt100 emulation)

• Web Console times out:

AnthonySmith

@Not_Oles try now please

Not_Oles

@AnthonySmith said:
@Not_Oles try now please

Thanks Ant! What did you do, please? What did I miss, please? May I please know how to diagnose this from my side if it happens again? Thanks!

Just now:

hil# echo "HELLO FROM SSH" > /dev/ttyE0
hil# 

AnthonySmith

@Not_Oles said:

@AnthonySmith said:
@Not_Oles try now please

Thanks Ant! What did you do, please? What did I miss, please?

Just now:

hil# echo "HELLO FROM SSH" > /dev/ttyE0
hil# 

You did nothing wrong I needed to reload a worker on the backend that was using and old version of something

Someone (feel free to name yourself) put in a bug report that virtual servers still show running when a node is down (Canada was down).

Obviously that's wrong we don't bill for compute while a hypervisor is down that's not fair, we patched that while we had the rare opportunity to do so in production (always fun) but I forgot to reload the VNC console worker that generates the session keys to tunnel your VNC session and it had the old cached file running and that caused the worker to silently fail.

Human error, this is a reminder of why we are still in Alpha

Not_Oles

@AnthonySmith said: I needed to reload a worker on the backend that was using and old version of something

Thanks for letting us know!

I am guessing that there is no way to diagnose this type of issue from the client side. If that's wrong, please tell me.

@AnthonySmith said: Human error, this is a reminder of why we are still in Alpha

Many people here at LES really appreciate that TierHive is run by a reliable, decent, honest person.

The best way we all can show enthusiasm is by trying everything on TierHive, generating problem reports, and thus helping to find and fix every issue. I heard that perfection does not admit of degree, but I nevertheless want TierHive ever more perfect than it already is!

Not_Oles

@cmeerw said:

@cmeerw said:
So installed NetBSD on a small VPS (128 MB RAM and 1 GB disk) by writing the disk image from a netboot.xyz booted Alpine.

Can't get IPv6 working with NetBSD. The web interface tells me to use something like "2001:0db8:1234:5678::1" as the gateway, but what seems strange is that the neighbor advertisement then comes from IP6 2001:0db8:1000::1 with the target address 2001:0db8:1234:5678::1 (which NetBSD then seems to ignore).

Ok, managed to get something working now by using the link-local address of the router (which I got by pinging ff02::2) - although even with that I can only reach a small subset of the outside IPv6 world. (btw, this is on the Roubaix, FR location)

Thanks for the tip about pinging ff02::2! If I understand right, TierHive IPv6 is tunnelled, which uses part of the available packet size, and packets which are too big get dropped. "mtu 1280" was added at the end of the IPv6 line in ifconfig.vioif0. In the boot messages, it could be seen that the packet size was reduced for both v4 and v6 even though the MTU size restriction was added only on the IPv6 line in ifconfig.vioif0. I hear that MTU 1280 is consistent with the RFCs, but that some people use larger packets which get dropped by some routers together with packet too large responses generated by those routers.

After adding the packet size restriction, NetBSD IPv6 seemed to work fine with the link local address of the router set as the gateway.

• Different packet sizes, different results

hil# ping6 -c 2 -s 1452 ipv6.google.com
PING6(1500=40+8+1452 bytes) $Address6 --> 2607:f8b0:4023:1002::66

--- ipv6.l.google.com ping6 statistics ---
2 packets transmitted, 0 packets received, 100.0% packet loss
hil# ping6 -c 2 -s 1432 ipv6.google.com
PING6(1480=40+8+1432 bytes) #Address6 --> 2607:f8b0:4023:1002::66

--- ipv6.l.google.com ping6 statistics ---
2 packets transmitted, 0 packets received, 100.0% packet loss
hil# ping6 -c 2 -s 1402 ipv6.google.com
PING6(1450=40+8+1402 bytes) $Address6 --> 2607:f8b0:4023:1002::66

--- ipv6.l.google.com ping6 statistics ---
2 packets transmitted, 0 packets received, 100.0% packet loss
hil# ping6 -c 2 -s 1232 ipv6.google.com
PING6(1280=40+8+1232 bytes) $Address6 --> 2607:f8b0:4023:1009::8a
1240 bytes from 2607:f8b0:4023:1009::8a, icmp_seq=0 hlim=103 time=58.495 ms
1240 bytes from 2607:f8b0:4023:1009::8a, icmp_seq=1 hlim=103 time=58.457 ms

--- ipv6.l.google.com ping6 statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 58.457/58.476/58.495/0.027 ms
hil# 

• After mtu 1280 added to end of ifconfig.vioif0 IPv6 address line with link local address of the router, plus network restart:

hil# ping6 -c 2 ipv6.google.com
PING6(56=40+8+8 bytes) $Address6 --> 2607:f8b0:400a:80c::200e
16 bytes from 2607:f8b0:400a:80c::200e, icmp_seq=0 hlim=114 time=42.456 ms
16 bytes from 2607:f8b0:400a:80c::200e, icmp_seq=1 hlim=114 time=42.459 ms

--- ipv6.l.google.com ping6 statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 42.456/42.458/42.459/0.002 ms
hil# 

For Hillsboro, the fastest DNS resolver seemed to be Hurricane Electric for IPv6 and 1.1.1.1 for IPv5.

Hope this is helpful!

WSS

Lost my IPv6 again.

AnthonySmith

@WSS said:
Lost my IPv6 again.

fixed.

AnthonySmith

@WSS said:
Lost my IPv6 again.

Actually, unless I am going crazy... its been down for 4 days in Vint Hill, and no one reported it.

Not_Oles

@AnthonySmith I noticed Vint Hill IPv6 seemed to be down a couple of days ago. However, I seemed to be able to fix it by removing and reassigning the IPv6 address to my Vint Hill VPS, so I didn't report anything.

In my limited experience, with low priority settings and with the VPSes sometimes turned off at TierHive, IPv6 sometimes seems faster than IPv4, so I am really glad to have IPv6.

If it's helpful to you, we can check our logs and probably figure out when it was that I noticed the IPv6 issue.

I appreciate TierHive! Thank you!

WSS

@AnthonySmith said:

@WSS said:
Lost my IPv6 again.

Actually, unless I am going crazy... its been down for 4 days in Vint Hill, and no one reported it.

I've been moving my parents. So, logging into my backup NAT VPS wasn't all that high on my priorities list.

david3

@Not_Oles said:
@AnthonySmith I noticed Vint Hill IPv6 seemed to be down a couple of days ago. However, I seemed to be able to fix it by removing and reassigning the IPv6 address to my Vint Hill VPS, so I didn't report anything.

In my limited experience, with low priority settings and with the VPSes sometimes turned off at TierHive, IPv6 sometimes seems faster than IPv4, so I am really glad to have IPv6.

If it's helpful to you, we can check our logs and probably figure out when it was that I noticed the IPv6 issue.

I appreciate TierHive! Thank you!

Same for me, IPv6 was down in Vint Hill several days ago, and I was able to fix it by removing IPv6 and adding it back. I've got a cron job that checks IPv4 and IPv6 connectivity from a remote system every 10 minutes, so I'll notice if it's down.

AnthonySmith

@david3 said:

@Not_Oles said:
@AnthonySmith I noticed Vint Hill IPv6 seemed to be down a couple of days ago. However, I seemed to be able to fix it by removing and reassigning the IPv6 address to my Vint Hill VPS, so I didn't report anything.

In my limited experience, with low priority settings and with the VPSes sometimes turned off at TierHive, IPv6 sometimes seems faster than IPv4, so I am really glad to have IPv6.

If it's helpful to you, we can check our logs and probably figure out when it was that I noticed the IPv6 issue.

I appreciate TierHive! Thank you!

Same for me, IPv6 was down in Vint Hill several days ago, and I was able to fix it by removing IPv6 and adding it back. I've got a cron job that checks IPv4 and IPv6 connectivity from a remote system every 10 minutes, so I'll notice if it's down.

Every time this happens I do try and get to the root cause and fix it.

But I think in truth, this time, it was just human error I brought things back online in the wrong order after one of the vinthill nodes rebooted so the routes were never added, the router was fine but removing and reading from your side would fix the routes.

Anyway, I added a cron that checks what routes should exist Vs what does exist and adds anything missing every 5 minutes now so you should never need to do that again.

AnthonySmith

Friendly names for virtual servers now support spaces , . - and more favicons added so they show up on all devices and browsers.

Scioner

Minor things in FAQ.

"Can I have more than 3 TCP ports per VPS?". Should be 5.
"IPv6 Australia". But selector missing Paris and Poland as well.