Debian Debian-France Debian-Facile Debian-fr.org Forum-Debian.fr Debian ? Communautés

Debian-facile

Bienvenue sur Debian-Facile, site d'aide pour les nouveaux utilisateurs de Debian.

Vous n'êtes pas identifié(e).

#1 19-05-2022 23:28:34

El_Gecko
Membre
Lieu : IDF
Inscription : 30-01-2022

VPS inaccessible (réparer grub?)

Hello,

Suite à une modif malheureuse d'une ligne du fichier /etc/default/grub, un VPS sous Debian 10 (cz Contabo) ne démarre plus.

Accès SSH impossible.
Ne répond pas à ping.
Accès VNC : un prompt "grub>" apparaît.
Restart en mode Live Debian 10: accès SSH OK

Comment réparer grub pour pouvoir à nouveau accéder à ce serveur ?

J'ai passé des heures à chercher sur le web comment réparer grub mais je n'ai rien trouvé de concluant pour ce VPS.
(le cas des VPS semble particulier)

En mode live, j'ai tenté en chroot de réinstaller grub, il n'y a pas d'erreur lors de l'installation mais ça ne change rien, accès toujours impossible après reboot.

Via VNC, il faut à un moment charger une image du noyau (vmlinuz...) que je n'ai pas sur le VPS.

Là, je commence vraiment à désespérer...

Pouvez-vous m'aider SVP ?

Je reste à votre entière disposition pour vous fournir toute info supplémentaire (logs...).

Merci par avance.

@+

El Gecko.

Dernière modification par El_Gecko (19-05-2022 23:29:09)


On commence à vieillir quand on finit d'apprendre (proverbe japonais)

Hors ligne

#2 20-05-2022 09:34:04

raleur
Membre
Inscription : 03-10-2014

Re : VPS inaccessible (réparer grub?)

El_Gecko a écrit :

une modif malheureuse d'une ligne du fichier /etc/default/grub


Quelle modification ?

El_Gecko a écrit :

j'ai tenté en chroot de réinstaller grub


Comment ?

Dernière modification par raleur (20-05-2022 09:37:54)


Il vaut mieux montrer que raconter.

Hors ligne

#3 20-05-2022 09:41:30

raleur
Membre
Inscription : 03-10-2014

Re : VPS inaccessible (réparer grub?)

El_Gecko a écrit :

Accès VNC : un prompt "grub>" apparaît.


Qu'affichent les commandes suivantes ?

ls
set # je ne veux que les valeurs de cmdpath, grub_platform, prefix, root
ls /


Il vaut mieux montrer que raconter.

Hors ligne

#4 20-05-2022 20:38:42

El_Gecko
Membre
Lieu : IDF
Inscription : 30-01-2022

Re : VPS inaccessible (réparer grub?)

Hello,

Merci de t'intéresser à mon cas presque désespéré.

Voici les infos grub:

LEur5ZmUfvI_VPS-grub-param.png

Reboot en Debian 10 Live : SSH connection port 22 timeout

De pire en pire !?!

VNC : echec de connexion !

Là je pige plus !


El Gecko.

On commence à vieillir quand on finit d'apprendre (proverbe japonais)

Hors ligne

#5 20-05-2022 21:12:03

El_Gecko
Membre
Lieu : IDF
Inscription : 30-01-2022

Re : VPS inaccessible (réparer grub?)

Ha, le mode rescue est OK, j'ai pu accéder au fichier /etc/default/grub certainement vérolé puisque l'accès SSH est impossible quand je boote en mode normal (à moins qu'un 2e problème se soit greffé, du genre réseau).
J'ai cru le remettre dans son état d'origine en commentant ou dé-commentant certaines lignes mais bon... on voit le résultat !:/

En gras , les lignes que je suis sûr suis d'avoir modifié
En gras italique, les lignes que je crois avoir modifié/ajouté

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

Dernière modification par El_Gecko (20-05-2022 22:39:19)


On commence à vieillir quand on finit d'apprendre (proverbe japonais)

Hors ligne

#6 20-05-2022 22:36:10

El_Gecko
Membre
Lieu : IDF
Inscription : 30-01-2022

Re : VPS inaccessible (réparer grub?)

En fait, une question m'obsède, y a-t-il moyen de réinitialiser ce fichier /etc/default/grub ou de le remplacer par une version standard pour un VPS sous Debian 10 ?

J'ai constaté que la réinstallation de grub ne modifie jamais ce fichier.
Si j'ai bien compris, ce fichier n'est pris en compte que si on fait update-grub  .
Un renommage de ce fichier (pour éviter sa prise en compte) suivi d'une réinstallation de grub devrait suffire à repartir sur une base saine.
Hélas, ce n'est pas le cas, ce fichier semble requis au démarrage de grub...
Un update-grub est peut-être fait automatiquement ???
Ce me paraît très étrange cette affaire.

Bref, "grub expert wanted !!!"   ;o)

@+

El Gecko

Dernière modification par El_Gecko (20-05-2022 23:11:01)


On commence à vieillir quand on finit d'apprendre (proverbe japonais)

Hors ligne

#7 20-05-2022 22:43:31

El_Gecko
Membre
Lieu : IDF
Inscription : 30-01-2022

Re : VPS inaccessible (réparer grub?)

Concernant le "comment?", j'ai testé la solution chroot décrite dans le wiki debian, source a priori sérieuse et complète:

https://wiki.debian-fr.xyz/R%C3%A9insta … lus_simple

Dernière modification par El_Gecko (20-05-2022 22:44:14)


On commence à vieillir quand on finit d'apprendre (proverbe japonais)

Hors ligne

#8 21-05-2022 00:02:18

raleur
Membre
Inscription : 03-10-2014

Re : VPS inaccessible (réparer grub?)

El_Gecko a écrit :

Voici les infos grub:


Je serais curieux de savoir comment tu as réussi à avoir une valeur pareille pour $prefix. On dirait le résultat d'un chroot complètement raté.
Y a-t-il un fichier /boot/grub/grub.cfg ?

El_Gecko a écrit :

le mode rescue est OK


Quel mode rescue ?

El_Gecko a écrit :

En gras , les lignes que je suis sûr suis d'avoir modifié


Ces lignes sont commentées, elles sont donc sans effet.

El_Gecko a écrit :

En gras italique, les lignes que je crois avoir modifié/ajouté


Pourquoi forcer des options graphiques sur un VPS ?

El_Gecko a écrit :

y a-t-il moyen de réinitialiser ce fichier /etc/default/grub


Le modèle d'origine est dans /usr/share/grub/default/grub.

El_Gecko a écrit :

J'ai constaté que la réinstallation de grub ne modifie jamais ce fichier.


En effet, il est mis en place lors de l'installation du système.

El_Gecko a écrit :

Si j'ai bien compris, ce fichier n'est pris en compte que si on fait update-grub


Certaines options de ce fichier ont aussi un effet sur le résultat de grub-install. En tout cas il n'a pas d'effet direct sur le fonctionnement du chargeur GRUB au démarrage.


Il vaut mieux montrer que raconter.

Hors ligne

#9 21-05-2022 03:31:30

El_Gecko
Membre
Lieu : IDF
Inscription : 30-01-2022

Re : VPS inaccessible (réparer grub?)

Merci pour tes réponses.

Après restauration du fichier grub d'origine, reinstallation et update de grub, j'ai maintenant via VNC un joli grub en mode graphique... mais toujours pas d'accès SSH au VPS ! sad

LEvbgFZSCWI_grub-graph.png

Bon, je vais essayer de pioncer un peu, c'est pas gagné...

@+

El Gecko

On commence à vieillir quand on finit d'apprendre (proverbe japonais)

Hors ligne

#10 21-05-2022 09:10:09

raleur
Membre
Inscription : 03-10-2014

Re : VPS inaccessible (réparer grub?)

Une fois le système démarré, vérifie le nom et l'état de l'interface réseau.

ip addr
cat /etc/network/interfaces



Dans le fichier /etc/default/grub initial, GRUB_CMDLINE_LINUX contenait des paramètres affectant les interfaces réseau.
- net.ifnames=0 désactive le nommage "prévisible" (et la marmotte...) des interfaces réseau donc enX redevient ethX.
- ixgbe.allow_unsupported_sfp=1 est un paramètre pour le pilote Intel 10Gbit autorisant les modules d'interface (SFP) non supportés ou non testés.


Il vaut mieux montrer que raconter.

Hors ligne

#11 22-05-2022 03:56:07

El_Gecko
Membre
Lieu : IDF
Inscription : 30-01-2022

Re : VPS inaccessible (réparer grub?)

Hello,

Les infos demandées, anonymisées:

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

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


De plus, j'ai fait une découverte importante en regardant /var/log/syslog, OpenVPN ne démarre plus et par la même occasion SSH car, si j'ai bonne mémoire (j'ai configuré ce VPS en début de pandémie), ils partagent le même port 443 (ça a marché nickel durant des mois, VPS accessible de n'importe quel coin de France et de Navarre !).

C'est bizarre ce soucis car je n'ai rien bricolé de ce côté.
Je bricolais sur le fichier grub avant la perte d'accès SSH.
L'erreur OpenVPN semble très ancienne sur le web, après une recerche rapide.

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

May 17 23:21:41 vmi458278 systemd[1]: openvpn-server@server.service: Service RestartSec=5s expired, scheduling restart.
May 17 23:21:41 vmi458278 systemd[1]: openvpn-server@server.service: 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]: openvpn-server@server.service: Main process exited, code=exited, status=1/FAILURE
May 17 23:21:41 vmi458278 systemd[1]: openvpn-server@server.service: Failed with result 'exit-code'.
May 17 23:21:46 vmi458278 systemd[1]: openvpn-server@server.service: Service RestartSec=5s expired, scheduling restart.
May 17 23:21:46 vmi458278 systemd[1]: openvpn-server@server.service: 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]: openvpn-server@server.service: Main process exited, code=exited, status=1/FAILURE
May 17 23:21:46 vmi458278 systemd[1]: openvpn-server@server.service: Failed with result 'exit-code'.
May 17 23:21:51 vmi458278 systemd[1]: openvpn-server@server.service: Service RestartSec=5s expired, scheduling restart.
May 17 23:21:51 vmi458278 systemd[1]: openvpn-server@server.service: 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]: openvpn-server@server.service: Main process exited, code=exited, status=1/FAILURE
May 17 23:21:51 vmi458278 systemd[1]: openvpn-server@server.service: Failed with result 'exit-code'.
May 17 23:21:57 vmi458278 systemd[1]: openvpn-server@server.service: Service RestartSec=5s expired, scheduling restart.
May 17 23:21:57 vmi458278 systemd[1]: openvpn-server@server.service: 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]: openvpn-server@server.service: Main process exited, code=exited, status=1/FAILURE
May 17 23:21:57 vmi458278 systemd[1]: openvpn-server@server.service: Failed with result 'exit-code'.
-------------------

Suis-je condamné à réinstaller OpenVPN ?

@+


El_Gecko.

Dernière modification par El_Gecko (22-05-2022 04:06:27)


On commence à vieillir quand on finit d'apprendre (proverbe japonais)

Hors ligne

#12 22-05-2022 07:58:24

Croutons
Membre
Distrib. : Debian10 Buster
Noyau : Linux 4.19.0-18-amd64
(G)UI : Mate
Inscription : 16-12-2016

Re : VPS inaccessible (réparer grub?)

Hello
     Ce serait cool si tu pouvais éditer ton message pour faire ressortir les commandes, leurs sorties, etc. en utilisant le BBCode du forum (Les gros boutons au-dessus du post d'édition).
    Voir le tuto : Le code, ça pique moins les yeux en couleur

-->les cahiers du debutant<--      WikiDF-->Découvrir les principales commandes Linux<--
L' expérience, c'est le nom que chacun donne à ses erreurs. Oscar Wilde

Hors ligne

#13 22-05-2022 10:57:08

raleur
Membre
Inscription : 03-10-2014

Re : VPS inaccessible (réparer grub?)

ip addr montre que l'interface ethernet s'appelle eth0 et a une adresse IPv4 publique en 93.*, et pas d'adresse IPv6 globale. Je suppose que c'est la bonne adresse IP. Par précaution vérifier que "ip route" liste une route par défaut avec la bonne adresse de routeur (anciennement "passerelle").

Par contre le contenu de /etc/network/interfaces est incorrect : il contient l'adresse IP à la place du nom de l'interface, l'option address qui est censée contenir l'adresse est vide et les options netmask et gateway sont manifestement interverties. Ce n'est visiblement pas ce fichier qui sert à configurer l'interface. Mais peu importe si l'interface est correctement configurée.

El_Gecko a écrit :

OpenVPN ne démarre plus et par la même occasion SSH car, si j'ai bonne mémoire, ils partagent le même port 443


Deux services ne peuvent pas partager le même port TCP sur la même adresse IP. SSH écoute en TCP et OpenVPN peut écouter en UDP (préféré) ou en TCP. Si OpenVPN est configuré en UDP, alors ce n'est pas vraiment le même port puisque c'est un port UDP alors que SSH écoute sur un port TCP.

Ils peuvent être accessibles via le même port TCP et la même adresse grâce à un démultiplexeur comme sslh qui écoute sur le port et aiguille les connexions en fonction du protocole détecté. Mais dans ce cas les deux services doivent écouter sur des ports et/ou adresses distincts. Or d'après les logs OpenVPN cherche à écouter sur l'adresse publique et le port 443, et échoue peut-être parce que quelque chose l'utilise déjà ou bien ce n'est pas la bonne adresse IP.
Vérifie les fichiers de configuration de sshd et OpenVPN, et si quelque chose utilise le port 443.

ss -tnlp | grep 443

Dernière modification par raleur (22-05-2022 10:58:45)


Il vaut mieux montrer que raconter.

Hors ligne

#14 23-05-2022 20:24:49

El_Gecko
Membre
Lieu : IDF
Inscription : 30-01-2022

Re : VPS inaccessible (réparer grub?)

Hello,

Bon, procédons par étapes...
1 - Empêcher le démarrage auto d'openVPN.

Bon bein, ça commence pas fort. sad

J'ai rebooté le VPS en mode "Debian 10 Live".


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



Je vois pas les fichiers de config d'openvpn !?!

Où c'est que j'ai merdu ?

Bon, je vais manger un morceau, mes neurones manquent de sucre ! yikes)

@+

El_Gecko

Dernière modification par El_Gecko (23-05-2022 20:25:19)


On commence à vieillir quand on finit d'apprendre (proverbe japonais)

Hors ligne

#15 24-05-2022 01:18:36

El_Gecko
Membre
Lieu : IDF
Inscription : 30-01-2022

Re : VPS inaccessible (réparer grub?)

kernal_panic.gifscratchhead.gifcrash.gif

Bon, là j'abandonne pour ce soir.

Je pense avoir tout réglé au minimum côté serveur:

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

=> après reboot, je n'arrive toujours pas à pinguer le serveur !

On en revient à un pb de grub pur et dur ?!?

Actions faites en "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 : il me semble, dûe au chroot mais bon, reload  lors reboot, non ?

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
 

Dernière modification par El_Gecko (24-05-2022 01:24:03)


On commence à vieillir quand on finit d'apprendre (proverbe japonais)

Hors ligne

#16 24-05-2022 23:35:34

raleur
Membre
Inscription : 03-10-2014

Re : VPS inaccessible (réparer grub?)

J'ai tendance à décrocher devant les difficultés de communication.

Il vaut mieux montrer que raconter.

Hors ligne

#17 26-05-2022 16:53:42

El_Gecko
Membre
Lieu : IDF
Inscription : 30-01-2022

Re : VPS inaccessible (réparer grub?)

Hello me revoilo,

Mouais, ce fil part un peu dans tous les sens, désolé. sad
Bon j'ai encore passé la nuit dessus donc là, j'ai une forte envie de réinstaller ce VPS Debian 10 ex-nihilo mais j'ai aussi envie de comprendre le problème et d'avoir une solution au cas où il se reproduirait.

A ce jour, en VNC, j'ai ça :

LEAocd6UsCI_grub-graph2.png

J'ai potassé un peu la doc Grub et si j'ai bien compris, vu ma config , les valeurs de prefix et root sont archi fausses.

Ma config. : (obtenue en mode "Debian rescue" proposé par l'hébergeur Contabo et offrant un accès SSH)

# fdisk -l
...
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

# mount /dev/sda2 /mnt
# mount /dev/sda1 /mnt/boot/

# mount --bind /dev /mnt/dev
# mount --bind /dev/pts /mnt/dev/pts
# mount --bind /sys /mnt/sys
# mount -t proc /proc /mnt/proc

# chroot /mnt /bin/bash

# ls /boot/grub
fonts  grubenv  grub.cfg i386-pc  locale  unicode.pf2




On devrait avoir:

prefix=(hd0/msdos1)/boot/grub
root=hd0/msdos1



(hd0/msdos1) correspond à /dev/sda1 , partition de boot, Non ?

Pourquoi le grub-install s'emmêle les pinceaux sur une config aussi simple (2 partitions) ?
Comment corriger le problème ?
Le fait que ce soit un VPS complique les choses ?

grub_platform=pc , c'est bon pour un VPS ? Pas d'histoire d'EFI, même émulé ?
(j'ai vu que la version du kernel est "signed" donc grub EFI requis ?

# dpkg -l linux* | grep -E '^ii.*-(headers|image)'
ii  linux-image-4.19.0-11-amd64          4.19.146-1        amd64        Linux 4.19 for 64-bit PCs (signed)
ii  linux-image-4.19.0-20-amd64          4.19.235-1        amd64        Linux 4.19 for 64-bit PCs (signed)
ii  linux-image-amd64                    4.19+105+deb10u15 amd64        Linux for 64-bit PCs (meta-package)


)

grub_cpu=i386 ???
Pourquoi pas amd64 puisque

# uname -r
5.10.0-10-amd64



Pourtant j'ai désinstallé (purge) et réinstallé grub, on voit bien amd64. oldstable c'est curieux, non ?

apt search grub | grep installed

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

grub-common/oldstable,oldstable,now 2.02+dfsg1-20+deb10u4 amd64 [installed,automatic]
grub-pc/oldstable,oldstable,now 2.02+dfsg1-20+deb10u4 amd64 [installed,automatic]
grub-pc-bin/oldstable,oldstable,now 2.02+dfsg1-20+deb10u4 amd64 [installed,automatic]
grub2/oldstable,oldstable,now 2.02+dfsg1-20+deb10u4 amd64 [installed]
grub2-common/oldstable,oldstable,now 2.02+dfsg1-20+deb10u4 amd64 [installed,automatic]

# ls /lib/modules
4.19.0-11-amd64  4.19.0-20-amd64

 


On notera au passage une différence de version entre la valeur retournée par uname -a (5.10) et les modules sous /lib/modules (4.19)...

Bon, je m'arrête là car je vais finir par poster les 500 lignes de capture de cette nuit ! smile


Par avance merci d'apporter vos avis toujours éclairés... et promis, je me concentre sur vos suggestions !

@+

El Gecko.

Dernière modification par El_Gecko (26-05-2022 17:20:05)


On commence à vieillir quand on finit d'apprendre (proverbe japonais)

Hors ligne

#18 26-05-2022 19:22:04

El_Gecko
Membre
Lieu : IDF
Inscription : 30-01-2022

Re : VPS inaccessible (réparer grub?)

Quel bazar ! kernal_panic.gif
Grub est installé sur les 2 partitions.
Comment c'est possible ? Il n'est pas capable de repérer la partition de boot ?

LEArrQQZAQI_grub-x2.png

Comment nettoyer tout ça proprement ? sos.gif

Merci.

@+

El Gecko

On commence à vieillir quand on finit d'apprendre (proverbe japonais)

Hors ligne

#19 27-05-2022 19:14:41

El_Gecko
Membre
Lieu : IDF
Inscription : 30-01-2022

Re : VPS inaccessible (réparer grub?)

Hello,

Super, ça marche, j'ai réussi !
J'ai résumé les étapes dans un petit tuto que je suis heureux de partager avec la communauté ! big_smile
Un système Linux, c'est toujours réparable, non ?

... roll neutral sad mad ...

...c'est ce que j'aimerais bien vous annoncer mais là, quand ça veut pas, ça veut pas, même après avoir lu des 10aines de pages sur le sujet, je ne tombe jamais dans le même cas de figure, pourtant simple (VPS à 2 partitions) !


LEBqQoBYEiI_grub-2x2.png

Je dois m'y prendre comme un manche mais j'arrive jamais à obtenir ça :

prefix=(hd0/msdos1)/boot/grub
root=hd0/msdos1



et si j'ai bien compris, c'est le but à atteindre puisque mon boot est sur sda1.

Bon, je vous donne toutes les étapes suivies, si un expert voit où j'ai merdu, qu'il ne se gène pas pour me filer un petit coup de main et transformer ces essais ratés en tutorial génial. wink
help.gif merci.gif

En mode "Debian Rescue" proposé par l'hébergeur Contabo et offrant le prompt SSH.

# mount /dev/sda2 /mnt/

# cat /mnt/etc/fstab

---
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/sda2 during installation
UUID=f03937c0-2759-4fb8-a27e-fac4c817d283 /               ext4    errors=remount-ro 0       0
# /boot was on /dev/sda1 during installation
UUID=772b7fda-3d9e-40fd-a1ed-9e9af210c548 /boot           ext4    defaults,noatime        0       0
---

# mount /dev/sda1 /mnt/boot


# mount --bind /dev /mnt/dev
# mount --bind /dev/pts /mnt/dev/pts
# mount --bind /sys /mnt/sys
# mount -t proc /proc /mnt/proc

# chroot /mnt/

copie des  images kernel sous /root (sauvegardées précédemment sous /grub_bak.tar.gz)

# update-grub2
Generating grub configuration file ...
... les images kernel ...
Found background image: /usr/share/images/desktop-base/desktop-grub.png
done

# grub-mkconfig
Affiche le fichier de conf grub

# exit

# reboot

 



Voilà, merci.gif par avance.

A votre dispo pour fournir toute info complémentaire.

@+

El Gecko,
un peu déprimé. sad

Dernière modification par El_Gecko (28-05-2022 04:10:04)


On commence à vieillir quand on finit d'apprendre (proverbe japonais)

Hors ligne

#20 27-05-2022 20:36:28

raleur
Membre
Inscription : 03-10-2014

Re : VPS inaccessible (réparer grub?)

Pas compris, au final ça marche ou ça ne marche pas ?

Il vaut mieux montrer que raconter.

Hors ligne

#21 28-05-2022 04:07:22

El_Gecko
Membre
Lieu : IDF
Inscription : 30-01-2022

Re : VPS inaccessible (réparer grub?)

Hélas, non, le tuto génial, pour l'instant il est dans mes rêves les plus fous.
Quand je reboot en mode normal (après un exit pour quitter chmod en mode rescue), je n'arrive pas à accéder au VPS en SSH.
Via VNC, j'ai un grub graphique avec les variables données dans mon post précédent.

Si j'ai bien compris, le grub doit s'installer sur ma partition msdos1 (selon fdisk qui indique /dev/sda1 en boot) et pas moyen, il se retrouve toujours sur msdos2 !

Après avoir lu des 10aines de pages web, je pense avoir cerné la démarche mais ça m3rde qq part.
Les commandes lancées et leur ordre te semblent ils OK (cf. mon poste précédent)?

Merci d'y apporter un oeil d'expert.

@+

El Gecko,
en totale insomnie.

On commence à vieillir quand on finit d'apprendre (proverbe japonais)

Hors ligne

#22 28-05-2022 09:26:51

raleur
Membre
Inscription : 03-10-2014

Re : VPS inaccessible (réparer grub?)

El_Gecko a écrit :

Ma config. : (obtenue en mode "Debian rescue" proposé par l'hébergeur Contabo et offrant un accès SSH)


Il y a une ambiguïté dans cette appellation "Debian rescue". S'agit-il d'une entrée de menu de GRUB (mode recovery ou dépannage) du système normal installé ou d'une option de l"hébergeur qui démarre un système (live ?) totalement indépendant ?

El_Gecko a écrit :

On devrait avoir:

prefix=(hd0/msdos1)/boot/grub
root=hd0/msdos1


Non, car d'une part la syntaxe est (hdX,msdosY) et non (hdX/msdosY).
D'autre part la partition n° 1 est montée sur /boot donc le chemin relatif à la racine de cette partition est /grub et non /boot/grub puisque /boot ne fait pas partie de la partition.
Pour finir, il ne faut pas trop se focaliser sur la variable $root. Sa valeur initiale est le périphérique contenu dans $prefix, mais elle peut être modifiée par les diverses commandes "search" présentes dans grub.cfg.

El_Gecko a écrit :

grub_platform=pc , c'est bon pour un VPS ? Pas d'histoire d'EFI, même émulé ?


"pc" ça veut dire "PC avec BIOS". GRUB démarre, donc c'est bon. Le VPN est peut-être capable de démarrer en mode UEFI mais c'est plus compliqué et fragile et ça n'a aucun intérêt.

El_Gecko a écrit :

(j'ai vu que la version du kernel est "signed" donc grub EFI requis ?


Non, c'est seulement dans l'autre sens : un noyau signé est requis pour démarrer avec le secure boot EFI. Mais il fonctionne aussi sans secure boot ou sans EFI.

El_Gecko a écrit :

grub_cpu=i386 ???
Pourquoi pas amd64


Parce que le BIOS ne tourne pas en mode 64 bits.

El_Gecko a écrit :

On notera au passage une différence de version entre la valeur retournée par uname -a (5.10) et les modules sous /lib/modules (4.19)


Si le système rescue actif est indépendant du système installé, ce n'est pas anormal.

El_Gecko a écrit :

Grub est installé sur les 2 partitions.
Comment c'est possible ?


C'est possible si tu as exécuté grub-install tantôt avec /dev/sda1 monté sur /boot et tantôt sans.
Ce qui est plus ennuyeux, c'est qu'aucun des deux emplacements ne contient d'image de noyau. Comment est-ce possible ? En tout cas impossible de démarrer le système installé dans ces conditions.

El_Gecko a écrit :

Je dois m'y prendre comme un manche mais j'arrive jamais à obtenir ça :

prefix=(hd0/msdos1)/boot/grub


Tant mieux car ce n'est pas la bonne valeur qui est plutôt

prefix=(hd0,msdos1)/grub


ce qui était le cas dans ton message #17.

El_Gecko a écrit :

copie des  images kernel sous /root (sauvegardées précédemment sous /grub_bak.tar.gz)


Une idée de pourquoi elles n'étaient plus là ? Tu as aussi restauré les initrd, ou les as reconstruites avec update-initramfs -u ?

Je pense qu'il manque

grub-install /dev/sda


pour réinstaller GRUB avec /dev/sda1 montée sur /boot.

El_Gecko a écrit :

Via VNC, j'ai un grub graphique


Avec quelles entrées de menu ? Normalement aucun si c'est le GRUB installé sans sda1 et qui utilise un grub.cfg dans sda2/boot/grub généré sans image de noyau.

Dernière modification par raleur (29-05-2022 00:40:12)


Il vaut mieux montrer que raconter.

Hors ligne

#23 28-05-2022 23:25:54

El_Gecko
Membre
Lieu : IDF
Inscription : 30-01-2022

Re : VPS inaccessible (réparer grub?)

Hello,

Merci de t'intéresser à mon cas presque désespéré. wink

Mode "Debian Rescue" = une solution de l'hébergeur parmi 4 proposées (boot d'une Debian 11 à partir de leur réseau, ça explique la différence de version constatée  puisque mon VPS est en Debian 10).
J'ai aussi testé "Debian 10 -Live" qui correspond à un live CD.

Cela permet d'accéder directement à un prompt SSH.

LECvHcQLIFI_CTB-rescue.png


Donc OK, le but à atteindre est dans l'environnement grub est :

prefix=(hd0,msdos1)/grub



raleur a écrit :

Une idée de pourquoi les images du kernel n'étaient plus là ? Tu as aussi restauré les initrd, ou les as reconstruites avec update-initramfs -u ?


A un moment j'ai décidé de supprimer totalement le dossier grub et j'ai fait un backup complet avant.
Les initrd ont aussi été restaurés il me semble, je vais vérifier.
Sinon je ferai un update-initramfs -u .

raleur a écrit :

Il manque grub-install /dev/sda
pour réinstaller GRUB avec /dev/sda1 montée sur /boot

.

OK, je vais remplacer

update-grub2


par

grub-install /dev/sda


suivi je suppose d'un

update-grub




Via VNC, j'ai un grub graphique
Avec quelles entrées de menu ?


Je nai toujours eu qu'un simple prompt grub>, sans menu .
NB: quand le VPS marchait je n'avais jamais de menu mais un accès direct à un prompt SSH.

Bon, merci, je vais refaire un test, et tracer pas à pas mes actions.

@+

El Gecko.

Dernière modification par El_Gecko (28-05-2022 23:36:40)


On commence à vieillir quand on finit d'apprendre (proverbe japonais)

Hors ligne

#24 29-05-2022 00:43:14

raleur
Membre
Inscription : 03-10-2014

Re : VPS inaccessible (réparer grub?)

El_Gecko a écrit :

Je nai toujours eu qu'un simple prompt grub>, sans menu


Peut-être à cause de l'absence d'image de noyau.

El_Gecko a écrit :

quand le VPS marchait je n'avais jamais de menu mais un accès direct à un prompt SSH.


Pardon ? SSH fournit un shell via le réseau, rien à voir avec la console où s'affiche GRUB.

Dernière modification par raleur (29-05-2022 00:44:31)


Il vaut mieux montrer que raconter.

Hors ligne

#25 29-05-2022 02:29:43

El_Gecko
Membre
Lieu : IDF
Inscription : 30-01-2022

Re : VPS inaccessible (réparer grub?)

J'ai découvert en tapant 'help' en mode 'Debian rescue' un script sympa qui fait tous les mount et le chroot correctement ! smile

chroot-in.sh <ROOT> <BOOT>

chroot-in.sh /dev/sda2 /dev/sda1



Tout ce qu'il faut est là ! smile

# ls -al /mnt/boot
total 87216
drwxr-xr-x  3 root root     4096 May 27 15:05 .
drwxr-xr-x 20 root root     4096 May 27 15:09 ..
-rw-r--r--  1 root root   206143 May 27 15:05 config-4.19.0-11-amd64
-rw-r--r--  1 root root   206331 May 27 15:05 config-4.19.0-20-amd64
drwxr-xr-x  5 root root     4096 May 27 14:56 grub
-rw-r--r--  1 root root 35598073 May 27 15:05 initrd.img-4.19.0-11-amd64
-rw-r--r--  1 root root 35859275 May 27 15:05 initrd.img-4.19.0-20-amd64
-rw-r--r--  1 root root  3414871 May 27 15:05 System.map-4.19.0-11-amd64
-rw-r--r--  1 root root  3425737 May 27 15:05 System.map-4.19.0-20-amd64
-rw-r--r--  1 root root  5274864 May 27 15:05 vmlinuz-4.19.0-11-amd64
-rw-r--r--  1 root root  5299456 May 27 15:05 vmlinuz-4.19.0-20-amd64



Un grub est déjà présent:

# ls -al /mnt/boot/grub
total 2384
drwxr-xr-x 5 root root    4096 May 27 14:56 .
drwxr-xr-x 3 root root    4096 May 27 15:05 ..
drwxr-xr-x 2 root root    4096 May 26 11:13 fonts
-r--r--r-- 1 root root    3581 May 27 14:56 grub.cfg
-rw-r--r-- 1 root root    1024 May 26 11:13 grubenv
drwxr-xr-x 2 root root   20480 May 27 14:52 i386-pc
drwxr-xr-x 2 root root    4096 May 27 14:52 locale
-rw-r--r-- 1 root root 2396122 May 26 11:08 unicode.pf2



J'installe grub par dessus et génère le fichier de config.:

# grub-install /dev/sda
Installing for i386-pc platform.
Installation finished. No error reported.

# update-grub
Generating grub configuration file ...
Found background image: /usr/share/images/desktop-base/desktop-grub.png
Found linux image: /boot/vmlinuz-4.19.0-20-amd64
Found initrd image: /boot/initrd.img-4.19.0-20-amd64
Found linux image: /boot/vmlinuz-4.19.0-11-amd64
Found initrd image: /boot/initrd.img-4.19.0-11-amd64
done



Certaines dates ont bien changé:

# ls -al /boot/grub
total 2388
drwxr-xr-x 5 root root    4096 May 29 00:05 .
drwxr-xr-x 3 root root    4096 May 27 17:05 ..
drwxr-xr-x 2 root root    4096 May 26 13:13 fonts
-r--r--r-- 1 root root    8058 May 29 00:05 grub.cfg
-rw-r--r-- 1 root root    1024 May 26 13:13 grubenv
drwxr-xr-x 2 root root   20480 May 29 00:04 i386-pc
drwxr-xr-x 2 root root    4096 May 29 00:04 locale
-rw-r--r-- 1 root root 2396122 May 26 13:08 unicode.pf2



Sortie du chroot et reboot:

# exit
exit
Cleanup chroot environment.
Unmounted /mnt/dev/pts/
Unmounted /mnt/dev
Unmounted /mnt/sys
Unmounted /mnt/proc
Unmounted /mnt/boot
Unmounted /mnt

reboot



Résultat : toujours pas d'accès SSH sad
ping KO

Par contre en VNC, j'ai la popup d'authentification pour accès à l'interface graphique.
(j'ai pas réussi à me conecter root car le password est très complexe et le clavier de PC portable très mal géré! tongue)

Retour en mode rescue + chroot-in.sh, on voit openvpn qui tente de démarrer alors que j'ai mis OFF l'autostart.

tail /var/log/syslog

May 29 01:04:10 vmi458278 systemd[1]: Started OpenVPN service for server.
May 29 01:04:10 vmi458278 openvpn[3273]: TUN/TAP device tun0 opened
May 29 01:04:10 vmi458278 openvpn[3273]: TUN/TAP TX queue length set to 100
May 29 01:04:10 vmi458278 openvpn[3273]: /sbin/ip link set dev tun0 up mtu 1500
May 29 01:04:10 vmi458278 openvpn[3273]: /sbin/ip addr add dev tun0 10.8.0.1/24                           broadcast 10.8.0.255
May 29 01:04:10 vmi458278 systemd-udevd[3274]: link_config: autonegotiation is u                          nset or enabled, the speed and duplex are not writable.
May 29 01:04:10 vmi458278 openvpn[3273]: Could not determine IPv4/IPv6 protocol.                           Using AF_INET
May 29 01:04:10 vmi458278 openvpn[3273]: Socket Buffers: R=[131072->131072] S=[1                          6384->16384]
May 29 01:04:10 vmi458278 openvpn[3273]: TCP/UDP: Socket bind failed on local ad                          dress [AF_INET]93.xx.xx.xx:443: Cannot assign requested address (errno=99)
May 29 01:04:10 vmi458278 openvpn[3273]: Exiting due to fatal error
May 29 01:04:10 vmi458278 openvpn[3273]: Closing TUN/TAP interface
May 29 01:04:10 vmi458278 openvpn[3273]: /sbin/ip addr del dev tun0 10.8.0.1/24
May 29 01:04:10 vmi458278 systemd[1]: openvpn-server@server.service: Main proces                          s exited, code=exited, status=1/FAILURE
May 29 01:04:10 vmi458278 systemd[1]: openvpn-server@server.service: Failed with    



/# nano /etc/default/openvpn

AUTOSTART="none"

# update-rc.d openvpn disable
update-rc.d: error: cannot find a LSB script for openvpn ???




Vérif dans /etc/services présence "22 ssh"

Firewall OFF:

# ufw status
Status: inactive
 




Bon là, je sèche et il se fait tard...

@demain

El Gecko.

Dernière modification par El_Gecko (29-05-2022 03:10:26)


On commence à vieillir quand on finit d'apprendre (proverbe japonais)

Hors ligne

Pied de page des forums