VPS unreachable (repair grub ?)

[El_Gecko]

Hello,

After an unfortunate change of one line of the /etc/default/grub file, a VPS with Debian 10 (at Contabo) no longer starts.
SSH access is impossible.
Do not answer to ping.
VNC access: a prompt "grub>" appears.
Restart in Debian 10 Live Mode: SSH Access OK

How do I fix grub to be able to access this server again?
I spent hours searching the web how to fix grub but I couldn't find anything conclusive for this VPS.
(the case of VPS seems particular)

In live mode, I tried in chroot to reinstall grub, there is no error during the installation but it does not change anything, access is still impossible after reboot.
Via VNC, you have to load at some point an image of the kernel (vmlinuz...) that I do not have on the VPS.

There, I really start to despair...

Can you please help me?
I remain at your disposal to provide you with any additional information (logs...).

Thank you in advance.

El Gecko.

 

[Condobloke]

G'day El_Gecko, Welcome to Linux.org

Others may come along with knowledge/advice......vps's are not my forte

However, the members name I will post below does have knowledge of VPS's

You dont need to do anything ....he will be alerted to the fact that I have posted his name here.

He is located in north western Europe, so please make allowance for differing time zones.

@f33dm3bits

 

[f33dm3bits]

However, the members name I will post below does have knowledge of VPS's

I'm not an expert when it comes to Grub but I can try and help, there are quite a few others here who are better with Grub than me.

After an unfortunate change of one line of the /etc/default/grub file, a VPS with Debian 10 (at Contabo) no longer starts.

What line did you change and what did you change it to and do you remember what it was before, have you tried changing it back?

 

[El_Gecko]

Hello,

grub infos:

In rescue mode, boot is OK, I was able to access /etc/default/grub file, which is certainly corrupt since SSH access is impossible when I boot in normal mode (unless a 2nd problem has arisen, such as a network issue).
I thought I put it back in its original state by commenting or uncommenting certain lines but hey... we see the result!
In bold, the lines that I'm sure I have changed
In bold italics, the lines that I believe I have modified/added

-----------------------------------------
# cat /etc/default/grub

# If you change this file, run 'update-grub' afterwards to update
# /boot/grub/grub.cfg.
# For full documentation of the options in this file, see:
# info -f grub -n 'Simple configuration'

GRUB_DEFAULT=0
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
# Test TeamV
# GRUB_CMDLINE_LINUX_DEFAULT="consoleblank=0"
GRUB_CMDLINE_LINUX_DEFAULT="quiet"
# ORI line
GRUB_CMDLINE_LINUX="rootdelay=10 net.ifnames=0 ixgbe.allow_unsupported_sfp=1"
# Restart KO si vide ?
#GRUB_CMDLINE_LINUX=""

# Uncomment to enable BadRAM filtering, modify to suit your needs
# This works with Linux (no patch required) and with any kernel that obtains
# the memory map information from GRUB (GNU Mach, kernel of FreeBSD ...)
#GRUB_BADRAM="0x01234567,0xfefefefe,0x89abcdef,0xefefefef"

# Uncomment to disable graphical terminal (grub-pc only)
#GRUB_TERMINAL=console

# The resolution used on graphical terminal
# note that you can use only modes which your graphic card supports via VBE
# you can see them in real GRUB with the command `vbeinfo'
GRUB_GFXMODE=1024x768
GRUB_GFXPAYLOAD_LINUX=1024x768

# Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to Linux
#GRUB_DISABLE_LINUX_UUID=true

# Uncomment to disable generation of recovery mode menu entries
#GRUB_DISABLE_RECOVERY="true"

# Uncomment to get a beep at grub start
#GRUB_INIT_TUNE="480 440 1"
---------------------------------------------------------------


In fact, one question obsesses me, is there a way to reset this /etc/default/grub file or to replace it with a standard version for a VPS under Debian 10 ???

I found that reinstalling grub never changes this file.
If I understand correctly, this file is only taken into account if we do update-grub .
A renaming of this file (to avoid it being taken into account) followed by a reinstallation of grub should be enough to start again on a healthy basis.
Alas, this is not the case, this file seems to be required when starting grub...
An update-grub is perhaps done automatically ???
This case seems very strange to me.
In short, "grub expert wanted!!!" ;o)

El Gecko

 

[Condobloke]

@wizardfromoz

@Lord Boltar

@dos2unix

 

[Deleted member 108694]

I would put # in front of the following 3 lines
GRUB_CMDLINE_LINUX="rootdelay=10 net.ifnames=0 ixgbe.allow_unsupported_sfp=1"
GRUB_GFXMODE=1024x768
GRUB_GFXPAYLOAD_LINUX=1024x768
So it should look like
#GRUB_CMDLINE_LINUX="rootdelay=10 net.ifnames=0 ixgbe.allow_unsupported_sfp=1"
#GRUB_GFXMODE=1024x768
#GRUB_GFXPAYLOAD_LINUX=1024x76
Next
#GRUB_CMDLINE_LINUX="" you need to remove the #
GRUB_CMDLINE_LINUX=""
save the file then run

sudo update-grub

afterwards
reboot and see what happens

 

[El_Gecko]

Hi,
The suggested modifications bring me back to the original grub config file that is here : /usr/share/grub/default/grub (just discovered!).
With such settings, in VNC, I get a nice grub in graphical mode
but alas impossible to access this VPS via SSH.

It's crazy !
Perhaps there is another problem (network?).

El Gecko.

 

[El_Gecko]

@Condobloke thanks to try to recruit the most skilled people for this issue ! ​

 

[Deleted member 108694]

Have you tried connecting through PuTTY where the red block is just put root@ then real IP Address make sure port is 22 and SSH is checked

Also does your ssh have secure key pairs?
Also is the user added to SSH list:

echo "AllowUsers USERNAME" >> /etc/ssh/sshd_config

 

[f33dm3bits]

With such settings, in VNC, I get a nice grub in graphical mode
but alas impossible to access this VPS via SSH.

It's crazy !
Perhaps there is another problem (network?).

As long as you are getting that Grub screen the system isn't booting into the os so the network won't be up and neither will sshd. When you are in rescue mode and chrooted into your system what does /boot look like and what your partition setup looks like?

ls -l /boot /boot/grub
lsblk

It also might be worth looking at Rescatux or another boot repair tool.

Rescatux

Rescatux 0.73 desktop Rescatux is a Debian-based live distribution featuring a graphical wizard for rescuing broken GNU/Linux and Windows installations and boot loaders. Rescatux 0.73 hands on video https://www.youtube.com/watch?v=cusq-ZI3-2E Rescatux 0.32b3 Tutorial video...

www.supergrubdisk.org

GRUB options:

• Easy GNU/Linux Boot Fix
• Restore GRUB and GRUB2
• Update any GRUB2 menues
• Update Debian/Ubuntu grub menues

SystemRescue - System tools

Boot loader and UEFI

• The Grub bootloader programs can be used if you need to repair the boot loader of your Linux distribution.
• You will need efibootmgr if you want to change the definitions or the order of the UEFI boot entries on your computer.

 

[dos2unix]

First thoughts...
is a firewall running? is ssh allowed?
Is the the sshd server running?
Are you trying to ssh as a user or root (some distro's block root by default).

 

[Deleted member 108694]

For Rescatux I would also add here - https://sourceforge.net/projects/rescatux/

 

[El_Gecko]

Hello,

More infos...

-----------------
21/5 15:00

root@debian-live:~# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 00:50:56:40:c2:a2 brd ff:ff:ff:ff:ff:ff
inet 93.xxx.xxx.xxx/24 brd 93.xxx.xxx.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::250:xxxx:xxxx:xxxx/64 scope link
valid_lft forever preferred_lft forever

root@debian-live:~# cat /etc/network/interfaces
auto lo
iface lo inet loopback

allow-hotplug 93.xxx.xxx.xxx
iface 93.xxx.xxx.xxx inet static
address
netmask 93.xxx.xxx.1
gateway 255.255.255.0

--------------------


In addition, I made an important discovery by looking at /var/log/syslog,

OpenVPN no longer starts and SSH too because, if I have good memory (I configured this VPS at the beginning of the pandemic), they share the same port 443 (it had been working very well for months, VPS accessible from any corner of the country !).

This problem is weird, because I didn't tinker with anything on this side. I was tinkering on the grub config file before the loss of SSH access.
The OpenVPN error looks very old on the web, after a quick recerche.

----------------------
root@debian-live:~# tail -n100 /var/log/syslog

May 17 23:21:41 vmi458278 systemd[1]: [email protected]: Service RestartSec=5s expired, scheduling restart.
May 17 23:21:41 vmi458278 systemd[1]: [email protected]: Scheduled restart job, restart counter is at 55.
May 17 23:21:41 vmi458278 systemd[1]: Stopped OpenVPN service for server.
May 17 23:21:41 vmi458278 systemd[1]: Starting OpenVPN service for server...
May 17 23:21:41 vmi458278 openvpn[2292]: OpenVPN 2.4.7 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Apr 28 2021
May 17 23:21:41 vmi458278 openvpn[2292]: library versions: OpenSSL 1.1.1n 15 Mar 2022, LZO 2.10
May 17 23:21:41 vmi458278 systemd[1]: Started OpenVPN service for server.
May 17 23:21:41 vmi458278 openvpn[2292]: Diffie-Hellman initialized with 2048 bit key
May 17 23:21:41 vmi458278 openvpn[2292]: Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
May 17 23:21:41 vmi458278 openvpn[2292]: Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
May 17 23:21:41 vmi458278 openvpn[2292]: Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
May 17 23:21:41 vmi458278 openvpn[2292]: Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
May 17 23:21:41 vmi458278 openvpn[2292]: TUN/TAP device tun0 opened
May 17 23:21:41 vmi458278 openvpn[2292]: TUN/TAP TX queue length set to 100
May 17 23:21:41 vmi458278 systemd-udevd[2293]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable.
May 17 23:21:41 vmi458278 openvpn[2292]: /sbin/ip link set dev tun0 up mtu 1500
May 17 23:21:41 vmi458278 openvpn[2292]: /sbin/ip addr add dev tun0 10.8.0.1/24 broadcast 10.8.0.255
May 17 23:21:41 vmi458278 openvpn[2292]: Could not determine IPv4/IPv6 protocol. Using AF_INET
May 17 23:21:41 vmi458278 openvpn[2292]: Socket Buffers: R=[131072->131072] S=[16384->16384]
May 17 23:21:41 vmi458278 openvpn[2292]: TCP/UDP: Socket bind failed on local address [AF_INET]93.xxx.xxx.xxx:443: Cannot assign requested address (errno=99)
May 17 23:21:41 vmi458278 openvpn[2292]: Exiting due to fatal error
May 17 23:21:41 vmi458278 openvpn[2292]: Closing TUN/TAP interface
May 17 23:21:41 vmi458278 openvpn[2292]: /sbin/ip addr del dev tun0 10.8.0.1/24
May 17 23:21:41 vmi458278 systemd[1]: [email protected]: Main process exited, code=exited, status=1/FAILURE
May 17 23:21:41 vmi458278 systemd[1]: [email protected]: Failed with result 'exit-code'.
May 17 23:21:46 vmi458278 systemd[1]: [email protected]: Service RestartSec=5s expired, scheduling restart.
May 17 23:21:46 vmi458278 systemd[1]: [email protected]: Scheduled restart job, restart counter is at 56.
May 17 23:21:46 vmi458278 systemd[1]: Stopped OpenVPN service for server.
May 17 23:21:46 vmi458278 systemd[1]: Starting OpenVPN service for server...
May 17 23:21:46 vmi458278 openvpn[2315]: OpenVPN 2.4.7 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Apr 28 2021
May 17 23:21:46 vmi458278 openvpn[2315]: library versions: OpenSSL 1.1.1n 15 Mar 2022, LZO 2.10
May 17 23:21:46 vmi458278 openvpn[2315]: Diffie-Hellman initialized with 2048 bit key
May 17 23:21:46 vmi458278 openvpn[2315]: Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
May 17 23:21:46 vmi458278 openvpn[2315]: Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
May 17 23:21:46 vmi458278 openvpn[2315]: Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
May 17 23:21:46 vmi458278 openvpn[2315]: Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
May 17 23:21:46 vmi458278 openvpn[2315]: TUN/TAP device tun0 opened
May 17 23:21:46 vmi458278 openvpn[2315]: TUN/TAP TX queue length set to 100
May 17 23:21:46 vmi458278 openvpn[2315]: /sbin/ip link set dev tun0 up mtu 1500
May 17 23:21:46 vmi458278 systemd[1]: Started OpenVPN service for server.
May 17 23:21:46 vmi458278 openvpn[2315]: /sbin/ip addr add dev tun0 10.8.0.1/24 broadcast 10.8.0.255
May 17 23:21:46 vmi458278 openvpn[2315]: Could not determine IPv4/IPv6 protocol. Using AF_INET
May 17 23:21:46 vmi458278 openvpn[2315]: Socket Buffers: R=[131072->131072] S=[16384->16384]
May 17 23:21:46 vmi458278 openvpn[2315]: TCP/UDP: Socket bind failed on local address [AF_INET]93.xxx.xxx.xxx:443: Cannot assign requested address (errno=99)
May 17 23:21:46 vmi458278 openvpn[2315]: Exiting due to fatal error
May 17 23:21:46 vmi458278 openvpn[2315]: Closing TUN/TAP interface
May 17 23:21:46 vmi458278 openvpn[2315]: /sbin/ip addr del dev tun0 10.8.0.1/24
May 17 23:21:46 vmi458278 systemd-udevd[2316]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable.
May 17 23:21:46 vmi458278 systemd[1]: [email protected]: Main process exited, code=exited, status=1/FAILURE
May 17 23:21:46 vmi458278 systemd[1]: [email protected]: Failed with result 'exit-code'.
May 17 23:21:51 vmi458278 systemd[1]: [email protected]: Service RestartSec=5s expired, scheduling restart.
May 17 23:21:51 vmi458278 systemd[1]: [email protected]: Scheduled restart job, restart counter is at 57.
May 17 23:21:51 vmi458278 systemd[1]: Stopped OpenVPN service for server.
May 17 23:21:51 vmi458278 systemd[1]: Starting OpenVPN service for server...
May 17 23:21:51 vmi458278 openvpn[2341]: OpenVPN 2.4.7 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Apr 28 2021
May 17 23:21:51 vmi458278 openvpn[2341]: library versions: OpenSSL 1.1.1n 15 Mar 2022, LZO 2.10
May 17 23:21:51 vmi458278 systemd[1]: Started OpenVPN service for server.
May 17 23:21:51 vmi458278 openvpn[2341]: Diffie-Hellman initialized with 2048 bit key
May 17 23:21:51 vmi458278 openvpn[2341]: Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
May 17 23:21:51 vmi458278 openvpn[2341]: Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
May 17 23:21:51 vmi458278 openvpn[2341]: Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
May 17 23:21:51 vmi458278 openvpn[2341]: Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
May 17 23:21:51 vmi458278 openvpn[2341]: TUN/TAP device tun0 opened
May 17 23:21:51 vmi458278 openvpn[2341]: TUN/TAP TX queue length set to 100
May 17 23:21:51 vmi458278 openvpn[2341]: /sbin/ip link set dev tun0 up mtu 1500
May 17 23:21:51 vmi458278 systemd-udevd[2342]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable.
May 17 23:21:51 vmi458278 openvpn[2341]: /sbin/ip addr add dev tun0 10.8.0.1/24 broadcast 10.8.0.255
May 17 23:21:51 vmi458278 openvpn[2341]: Could not determine IPv4/IPv6 protocol. Using AF_INET
May 17 23:21:51 vmi458278 openvpn[2341]: Socket Buffers: R=[131072->131072] S=[16384->16384]
May 17 23:21:51 vmi458278 openvpn[2341]: TCP/UDP: Socket bind failed on local address [AF_INET]93.xxx.xxx.xxx:443: Cannot assign requested address (errno=99)
May 17 23:21:51 vmi458278 openvpn[2341]: Exiting due to fatal error
May 17 23:21:51 vmi458278 openvpn[2341]: Closing TUN/TAP interface
May 17 23:21:51 vmi458278 openvpn[2341]: /sbin/ip addr del dev tun0 10.8.0.1/24
May 17 23:21:51 vmi458278 systemd[1]: [email protected]: Main process exited, code=exited, status=1/FAILURE
May 17 23:21:51 vmi458278 systemd[1]: [email protected]: Failed with result 'exit-code'.
May 17 23:21:57 vmi458278 systemd[1]: [email protected]: Service RestartSec=5s expired, scheduling restart.
May 17 23:21:57 vmi458278 systemd[1]: [email protected]: Scheduled restart job, restart counter is at 58.
May 17 23:21:57 vmi458278 systemd[1]: Stopped OpenVPN service for server.
May 17 23:21:57 vmi458278 systemd[1]: Starting OpenVPN service for server...
May 17 23:21:57 vmi458278 openvpn[2363]: OpenVPN 2.4.7 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Apr 28 2021
May 17 23:21:57 vmi458278 openvpn[2363]: library versions: OpenSSL 1.1.1n 15 Mar 2022, LZO 2.10
May 17 23:21:57 vmi458278 systemd[1]: Started OpenVPN service for server.
May 17 23:21:57 vmi458278 openvpn[2363]: Diffie-Hellman initialized with 2048 bit key
May 17 23:21:57 vmi458278 openvpn[2363]: Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
May 17 23:21:57 vmi458278 openvpn[2363]: Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
May 17 23:21:57 vmi458278 openvpn[2363]: Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
May 17 23:21:57 vmi458278 openvpn[2363]: Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
May 17 23:21:57 vmi458278 openvpn[2363]: TUN/TAP device tun0 opened
May 17 23:21:57 vmi458278 openvpn[2363]: TUN/TAP TX queue length set to 100
May 17 23:21:57 vmi458278 systemd-udevd[2364]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable.
May 17 23:21:57 vmi458278 openvpn[2363]: /sbin/ip link set dev tun0 up mtu 1500
May 17 23:21:57 vmi458278 openvpn[2363]: /sbin/ip addr add dev tun0 10.8.0.1/24 broadcast 10.8.0.255
May 17 23:21:57 vmi458278 openvpn[2363]: Could not determine IPv4/IPv6 protocol. Using AF_INET
May 17 23:21:57 vmi458278 openvpn[2363]: Socket Buffers: R=[131072->131072] S=[16384->16384]
May 17 23:21:57 vmi458278 openvpn[2363]: TCP/UDP: Socket bind failed on local address [AF_INET]93.xxx.xxx.xxx:443: Cannot assign requested address (errno=99)
May 17 23:21:57 vmi458278 openvpn[2363]: Exiting due to fatal error
May 17 23:21:57 vmi458278 openvpn[2363]: Closing TUN/TAP interface
May 17 23:21:57 vmi458278 openvpn[2363]: /sbin/ip addr del dev tun0 10.8.0.1/24
May 17 23:21:57 vmi458278 systemd[1]: [email protected]: Main process exited, code=exited, status=1/FAILURE
May 17 23:21:57 vmi458278 systemd[1]: [email protected]: Failed with result 'exit-code'.
-------------------

Must I reinstall OpenVPN ?

@+


El_Gecko

 

[f33dm3bits]

As mentioned before as long as you are getting that Grub cli on boot the rest of the services will never start and if you are in a rescue chroot normal services won't start either, networking will but not ssh. So what steps did you take to boot in into rescue mode and to the chroot into your system? Normally it would be something like this.
1. Boot from Debian cd
2. In boot menu select "Advance options"
3. Select "Graphical Rescue mode"
4. Select the following options
- language
- location
- Configure locales
- Configure keyboard
- Configure the network: hostname
- Configure the network: domain name(You can just press enter/continue here)
5. Enter rescue mode: Select your root filesystem here and continue.
6. Enter rescue mode: Select yes to mount /boot
7. Rescue operations: Select execute in a a shell (Then your root partition)
8. Select Continue
9. Now you are in a rescue shell, from here you you edit your Grub configurate and generate your /boot/grub/grub.cfg file. And from here you can run the following and share that with us.

ls -l /boot /boot/grub
lsblk

As for guessing, usually when you get a Grub cli on boot Grub can't find your root filesystem or something in that direction. So I would think maybe So maybe your mbr record is corrupt and or or the files in /boot/grub have gotten corrupt since Grub can't find the root fileystem to boot from. That may be worth looking into? So clearing /boot/grub(and maybe the rest of /boot as well), reinstalling Grub and then reinstalling the kernel, doing this from rescue mode as I have described above is what I would do if it were my vps.

In addition, I made an important discovery by looking at /var/log/syslog,

OpenVPN no longer starts and SSH too because, if I have good memory (I configured this VPS at the beginning of the pandemic), they share the same port 443 (it had been working very well for months, VPS accessible from any corner of the country !).

This problem is weird, because I didn't tinker with anything on this side. I was tinkering on the grub config file before the loss of SSH access.
The OpenVPN error looks very old on the web, after a quick recerche.

I would find that to not be possible because only one program can be running on a port at once, if you try for example start a webserver with ssl/443 configured and then configure ssh to also run on 443. When you then try to start sshd you will get an error that it can't start because something already being bound or running on that port.

 

[El_Gecko]

Hello,

If I think well, the 1st thing I should do is to prevent OpenVPN from starting at boot time and go back to SSH standard port 22.

Alas, I didn't manage to do that...

root@debian-live:~# fdisk -l Disk /dev/sda: 300 GiB, 322122547200 bytes, 629145600 sectors Disk model: QEMU HARDDISK Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x72c158aa Device Boot Start End Sectors Size Id Type /dev/sda1 * 2048 1953791 1951744 953M 83 Linux /dev/sda2 1953792 629143551 627189760 299.1G 83 Linux root@debian-live:/# mount /dev/sda2 /mnt && mount -o bind /dev /mnt/dev && mount -o bind /dev/pts /mnt/dev/pts && mount -o bind /proc /mnt/proc && mount -o bind /run /mnt/run && mount -o bind /sys /mnt/sys && mount -o bind /etc /mnt/etc && chroot /mnt /bin/bash root@debian-live:/# more /etc/default/openvpn more: stat of /etc/default/openvpn failed: No such file or directory root@debian-live:/# find / -name openvpn.conf /usr/lib/tmpfiles.d/openvpn.conf

I can't reach openvpn config files.

What am I doing wrong ?


EL Gecko.

 

[El_Gecko]

Ok, I stop for today !

I think I have all set at a minimum level:

- openvpn : OFF
- firewall : OFF
- SSH port 22 standard

=> after reboot, I still can't ping the VPS !

So we are back to a pure grub problem ?!?

Actions done in "Debian 10 live mode"

# lsblk
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
loop0    7:0    0 526.5M  1 loop /usr/lib/live/mount/rootfs/filesystem.squashfs
sda      8:0    0   300G  0 disk
├─sda1   8:1    0   953M  0 part
└─sda2   8:2    0 299.1G  0 part

# fsck -f /dev/sda2
fsck from util-linux 2.33.1
e2fsck 1.44.5 (15-Dec-2018)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/sda2: 215126/19603456 files (0.3% non-contiguous), 6056812/78398720 blocks

# mkdir /mnt/sos
# mount /dev/sda2 /mnt/sos
# cd /mnt/sos
# chroot /mnt/sos


# nano /etc/default/openvpn
 uncomment autostart="none" to stop it

# nano /etc/ssh/sshd_config
port 22

# systemctl reload sshd
Error : I guess, due to chroot but well, it's reloaded when rebooting, no ?

Test:
# ssh -p 22 root@localhost
System has not been booted with systemd as init system (PID 1). Can't operate.
Failed to connect to bus: Host is down


# ufw status
Status: inactive


Autostart ON/OFF
# nano /etc/ufw/ufw.conf
 
# /etc/ufw/ufw.conf

# Set to yes to start on boot. If setting this remotely, be sure to add a rule
# to allow your remote connection before starting ufw. Eg: 'ufw allow 22/tcp'
#ENABLED=yes


# ufw disable
Firewall stopped and disabled on system startup

# ufw status verbose
Status: inactive


# exit

# ssh -p 22 root@localhost
The authenticity of host 'localhost (::1)' can't be established.
ECDSA key fingerprint is SHA256:/Iaaz54NtvkGFrIBV1HawjRbHMC0oFs6S487TR3dHb0.
Are you sure you want to continue connecting (yes/no)? no

# reboot

 

[Deleted member 108694]

Has the kernel on Debian VPS machine been upgraded? generally you cannot upgrade the kernel or initramdisk yourself, the VPS provider must do that - like the kernel and initramdisk for the VPS are usually stored on the host domain. You can choose a Xen-based VPS provider that allows users to provide their own kernel. I know that Linode allows this via pv-grub, and I'm sure there are others that allow this as well but I cannot recall them at the moment.

 

[Condobloke]

This may be a completely no-knowledge statement...but......is there some benefit to be had by installing (etc) a NEW vps?....rather than trying to repair the old?

 

[f33dm3bits]

In your last post(#7) which I replied to first you were still getting a Grub rescue but it seems you have fixed that but not mentioned it, since you decided not to do anything with my second reply(and neither with my third) and it isn't clear how far along you have gotten than you were before. So I am just leaving this topic since it's waste of my time for all the effort I put into it while being pinged into it.