Questions[hetzner](server)

I have a Hetzner W2012 R2 Cloud VM, and I updated the VirtIO vioscsi driver on it. Now it only boots into recovery mode and I cannot access the C-drive even from command prompt.

Is there any way to save this VM or is it a goner?
I have no (recent) snapshot of it :(

I can mount the old previous VirtIO ISO, but how can I reinstall the old driver when I have no access to the C-drive?

Update 1:
Am able to get access to the C-drive with drvload vioscsci.inf.
Still trying to figure out how to reinstall the old drivers.

Update 2
I used dism /image:e:\ /add-driver /driver:vioscsi.inf to add the driver but it still won't boot.

Update 3
Startup repair gives error 0x490.

No clue what to do next or how to even troubleshoot why it is not booting.

Update 4

It appears all my system drivers have become unsigned. Disabling driver signature enforcement allowed the system to finally boot.

Do not know why this happened. It appears I will have to do a full reinstall, but at least I got back access to the VM now.

I've setup a clean new VPS running Ubuntu 20.04 LTS with Hetzner and would like to access it via ssh.

Here is what I've tried to do:

1. I have added my public ssh key (passphrase-less) in Hetzner's online GUI. That looked something like this:

ssh-rsa blahblahblah= [email protected]

2. But when I attempt to ssh-copy-id this key to the server, I run into issues. Since I haven't logged into the server to create users, I don't know what to put for the user in this command:

ssh-copy-id -i .ssh/id_rsa_pub [user]@serveraddress

I've tried adding the key to root user like so:

ssh-copy-id -i .ssh/id_rsa_pub [user]@serveraddress

But then I'm prompted for a password I don't know.

This leads me to the following questions I've had a hard time finding answers to:

1. How can I use ssh-copy-id to copy my public key to the server if I haven't setup a user yet?

2. What is the default root password on the server? How Would I find this out? I've tried ubuntu, root, the basics.

3. What does adding a public key via GUI on the server host's website normally do with regards to server users? Does it add the key to the known_hosts file?

4. What is the technical significance of the final comment line in my public ssh key, currently [email protected]?

I have couple of Hetzner 'root servers' (as they call it - dedicated co-located linux machines) and all of them experience the same problem (which i simply do not fully understand).

The domain www.dnsblchile.org does not want to resolve to an IP (servers are installed from Hetzner own Debian Jessie images). All other domains of course resolve properly (i did not experience any problems before with any other domains resolving - or i did not spot it before).

When i test nslookup -type=A www.dnsblchile.org i get:

;; Got SERVFAIL reply from 213.133.98.98, trying next server
;; Got SERVFAIL reply from 213.133.99.99, trying next server
Server:         213.133.100.100
Address:        213.133.100.100#53

** server can't find www.dnsblchile.org: SERVFAIL

so NO proper answer here, but when i try using 8.8.8.8 (google) as nameserver like nslookup -type=A www.dnsblchile.org 8.8.8.8 i get:

Server:         8.8.8.8
Address:        8.8.8.8#53

Non-authoritative answer:
Name:   www.dnsblchile.org
Address: 66.23.231.212

so everything is OK here and i get proper IP.

The contents of `/etc/resolv.conf' (default after installation) is:

### Hetzner Online GmbH installimage
# nameserver config
nameserver 213.133.98.98
nameserver 213.133.99.99
nameserver 213.133.100.100

If i add the 8.8.8.8 as a new entry to /etc/resolv.conf all is working just fine as well.

Now - is it something wrong on Hetzner nameservers configuration side or shall i just use 8.8.8.8 nameserver instead (as a good practice)?
I'm talking to Hetzner support for two days already but have no common ground here - hearing that their nameservers are all perfectly fine.
Shall their own nameservers as well properly resolve the www.dnsblchile.org domain?

update from support:

..but as the domain are using nameservers which are not allowing requests from our resolvers the domain can not be resolved. If you want to resolve the domain you have to use other resolvers or maybe own resolvers, which are allowed to request the nameservers of the domain

Now - may their nameservers be 'blocked' like they say (i'm not an expert here)?

As well - is it a common practice (as the answer below suggests) to use e.g. google name server and just skip Hetzner nameservers setup?
Would i just add the google name server to the list (at top or bottom of /etc/resolv.conf file) and shall i remove the Hetzner nameservers (or leave them)?

Assume we have two servers A and B with 'real' and external IPs and we can switch the so called 'failover ip' (W.X.Y.Z) to point to a specific external IP of A or B. This works from the 'outside' and was easily done. As a background: the failover ip is configured as a new entry in /etc/network/interfaces :

auto eth0:0  
iface eth0:0 inet static
  address W.X.Y.Z
  netmask 255.255.255.224 

Now let us assume W.X.Y.Z is configured dynamically to use hardware A. Now I call 'curl domain.com' from B and it uses the correct failover ip W.X.Y.Z but then resolves somehow to the wrong external IP B (or localhost?) instead of using the configured one A:

Trying W.X.Y.Z ...
* connect to W.X.Y.Z port 443 failed: Connection refused
* Failed to connect to domain.com port 443: Connection refused
* Closing connection 0
curl: (7) Failed to connect to domain.com port 443: Connection refused

When I start the local nginx it can successfully curl domain.com

Do I need to configure DNS locally somehow? How can I find out more about the DNS chain?

Using mtr just prints domain.com if trying this from server B

Is this related to this question?

The failover IP is W.X.Y.Z and is also the A record of domain.com

The /etc/hosts file for both nodes serverA and serverB looks like:

    127.0.0.1       localhost
    127.0.1.1       luminarhost            
    xxx    serverA
    xxx    serverB        

The /etc/network/interfaces of serverA

    ### Hetzner Online AG - installimage
    # Loopback device:
    auto lo
    iface lo inet loopback

    # device: eth0
    auto  eth0
    iface eth0 inet static
      address   xxx
      broadcast xxx
      netmask   xxx
      gateway   xxx
      # default route to access subnet
      up route add -net xxx netmask 255.255.255.224 gw xxx eth0

    iface eth0 inet6 static
      address xxx
      netmask xxx
      gateway xxx

    # failover ip
    auto eth0:0
    iface eth0:0 inet static
      address W.X.Y.Z
      netmask 255.255.255.224

and of serverB it is:

    ### Hetzner Online AG - installimage
    # Loopback device:
    auto lo
    iface lo inet loopback

    # device: eth0
    auto  eth0
    iface eth0 inet static
      address   xxx
      broadcast xxx
      netmask   xxx
      gateway   xxx
      # default route to access subnet
      up route add -net xxx netmask 255.255.255.192 gw xxx eth0

    iface eth0 inet6 static
      address xxx
      netmask xxx
      gateway xxx

    # failover ip
    auto eth0:0
    iface eth0:0 inet static
      address W.X.Y.Z
      netmask 255.255.255.224

Please note: The answers and comments to this question contains content from another, similar question that has received a lot of attention from outside media but turned out to be hoax question in some kind of viral marketing scheme. As we don't allow ServerFault to be abused in such a way, the original question has been deleted and the answers merged with this question.

Here's a an entertaining tragedy. This morning I was doing a bit of maintenance on my production server, when I mistakenly executed the following command:

sudo rm -rf --no-preserve-root /mnt/hetznerbackup /

I didn't spot the last space before / and a few seconds later, when warnings was flooding my command line, I realised that I had just hit the self-destruct button. Here's a bit of what burned into my eyes:

rm: cannot remove `/mnt/hetznerbackup': Is a directory
rm: cannot remove `/sys/fs/ecryptfs/version': Operation not permitted
rm: cannot remove `/sys/fs/ext4/md2/inode_readahead_blks': Operation not permitted
rm: cannot remove `/sys/fs/ext4/md2/mb_max_to_scan': Operation not permitted
rm: cannot remove `/sys/fs/ext4/md2/delayed_allocation_blocks': Operation not permitted
rm: cannot remove `/sys/fs/ext4/md2/max_writeback_mb_bump': Operation not permitted
rm: cannot remove `/sys/fs/ext4/md2/mb_stream_req': Operation not permitted
rm: cannot remove `/sys/fs/ext4/md2/mb_min_to_scan': Operation not permitted
rm: cannot remove `/sys/fs/ext4/md2/mb_stats': Operation not permitted
rm: cannot remove `/sys/fs/ext4/md2/trigger_fs_error': Operation not permitted
rm: cannot remove `/sys/fs/ext4/md2/session_write_kbytes': Operation not permitted
rm: cannot remove `/sys/fs/ext4/md2/lifetime_write_kbytes': Operation not permitted
# and so on..

I stopped the task and was relieved when I discovered that the production service was still running. Sadly, the server no longer accept my public key or password for any user via SSH.

How would you move forward from here? I'll swim an ocean of barbed wire to get that SSH-access back.

The server is running Ubuntu-12.04 and hosted at Hetzner.