TierHive General thread | Discuss, Updates, questions | LATEST: New Location - PARIS

1111213141517»

Comments

  • @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 :tongue:

    Thanked by (1)AnthonySmith
  • Not_OlesNot_Oles Hosting ProviderContent Writer
    edited June 24

    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:

  • AnthonySmithAnthonySmith AdministratorHosting ProviderOGSenpai

    @Not_Oles try now please

    Thanked by (1)Not_Oles

    TierHive - Hourly VPS - NAT Native - /24 per customer - DE, UK, SG, CA, USA x3, FR, AU, PL, NL
    FREE tokens on sign up, try before you buy. | Static Hosting Free for life: https://tierhive.com/static-hosting/

  • Not_OlesNot_Oles Hosting ProviderContent Writer
    edited June 24

    @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# 
    

  • AnthonySmithAnthonySmith AdministratorHosting ProviderOGSenpai
    edited June 24

    @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 :)

    Thanked by (1)Not_Oles

    TierHive - Hourly VPS - NAT Native - /24 per customer - DE, UK, SG, CA, USA x3, FR, AU, PL, NL
    FREE tokens on sign up, try before you buy. | Static Hosting Free for life: https://tierhive.com/static-hosting/

  • Not_OlesNot_Oles Hosting ProviderContent Writer

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

    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! :star:

  • Not_OlesNot_Oles Hosting ProviderContent Writer
    edited June 25

    @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! <3

    Thanked by (2)xms cmeerw
Sign In or Register to comment.