Bonjour,
hier soir j'étais en train de faire des modifications sur mon serveur dédié Kimsufi (à jour en Debian 12.7) quand celui-ci a redémarré et depuis j'ai complètement perdu la main, il ne démarre plus qu'en mode rescue.
Ce que je faisais : tester du "docker rootless" et tester des règles nftables pour faire de la redirection de port pour mes containers
Ce que j'ai fait sur mon serveur depuis le mode rescue
- des fsck sur les partitions / et /home, pas de problème.
- j'ai aussi une partition sda1 indiquée "BIOS boot" et je ne sais pas à quoi elle correspond ni quel FS est dessus. Elle n'est pas listée dans mon fstab
- en chroot : désactiver voire désinstaller le firewall (iptables/nftables), docker, nginx, php-fpm
- désactiver le service "docker rootless" de mon utilisateur
- modifier la config de grub pour démarrer sur un ancien kernel, même installer un autre kernel. Le plus récent installé est 6.1.0-25, j'ai testé le -21 et le -11
Le truc c'est que les logs kern.log et syslog n'ont pas été modifiés depuis hier soir, ce qui me laisse penser que mon système ne boote pas. Mais j'avoue ne pas avoir d'idée sur comment débugger le boot sans accès type KVM sur IP (console distante sur IP).
Idéalement il faudrait que je puisse booter sur un kernel minimal me donnant du réseau mais je ne suis pas certain que ça existe… ni que ça fonctionne.
J'ai bien évidemment contacté le support qui me dit que c'est un problème de configuration, donc de mon côté, et ne peuvent rien faire.
Je suis donc preneur de toute idée, ou solution 
sans accès type KVM
Bonjour,
Il y a moyen de louer un KVM physique, voir si le prix est acceptable lors du processus de commande avant de valider.
Le support m'a répondu que sur la gamme Eco il n'y a pas de KVM. Je vais quand même regarder un peu
Bonjour,
Cela dépend du type de serveur, certains KS peuvent avoir un KVM payant (c'est visible dans l'espace client).
Cordialement, janus57
D'accord
Malheureusement je ne vois rien de tel. J'ai l'impression que je suis bien coincé.
J'ai l'impression que je suis bien coincé.
J'ai un ks2g depuis une dizaine d'années à rbx5 . Je suis certain qu'à une certaine époque c'était suggéré dans l'espace client à un prix en centaines d'euros la journée ou la semaine (pour un serveur à 5€)
Mais aujourd'hui pour ce même serveur j'obtiens un laconique
Le truc c'est que les logs kern.log et syslog
Bonjour, il est vrai que cela est étonnant. Tout en sachant que, "normalement", sur une debian 12 d'origine, les fichiers syslog et kern.log n'existent plus, tout est journalisé par systemd (journalctl pour consulter).
Si ces fichiers sont bien présents et étaient encore récemment remplis, alors il doit y avoir rsyslog.
Bref, quoi qu'il en soit, il pourrait être intéressant de vérifier, en mode rescue :
1. Monter les partitions et chrooter dans le système (monter également /boot si c'est une partition séparée)
2. Consulter le journal système via journalctl
3. Vérifier le contenu du fstab
4. Réinstaller grub (plutôt que juste cibler un ancien kernel)
5. Régénérer l'initramfs
6. Vérifier qu'il y a bien tout ce qu'il faut côté noyau (dans /boot)
7. Vérifier la configuration de GRUB
8. Penser à mettre à jour GRUB (update-grub)
Y a t'il plusieurs disques ? Si oui, sont ils en RAID ? Si oui :
9. Vérifier l'état du RAID
Si j'ai d'autres idées qui me viennent je n'hésiterai pas à les communiquer. Mais faute de mieux c'est comme cela que j'irai diagnostiquer la panne de mon côté.
j'ai aussi une partition sda1 indiquée "BIOS boot"
Si c'est bien une machine utilisant GPT avec BIOS (non UEFI), c'est quelque chose de normal. Il me semble que GRUB y stocke des infos. Il ne doit pas y avoir de FS dessus donc pas nécessité d'apparaitre dans le fstab.
@popallo j'ai déjà fait tout ça. Il n'y a que journalctl auquel je n'avais pas pensé mais je viens de le faire et je pense que je vois celui du système "rescue-customer-eu" non pas celui de mon serveur.
Pour reinstaller grub : grub-install /dev/sda
Pour regen les initramfs : update-initramfs -u -k all
Après modif de /etc/default/grub pour changer l'ordre du kernel à monter, j'ai fait le update-grub
Pas de RAID
Dans /boot j'ai pour chaque noyau :
- config-VERSION (purement informatif)
- initrd.img-VERSION
- System.map-VERSION
- vmlinuz-VERSION
plus
- le répertoire grub contenant fonts grub.cfg grubenv i386-pc locale unicode.pf2
- le repertoire extlinux vide
Il me semble qu'une fois chrooté c'est le journal du système "normal" qui est lu.
Dans le doute :
journalctl --directory=/mnt/root/var/log/journal
Remplacer le répertoire de montage que j'ai indiqué avec le bon chemin vers le fichier binaire "journal", qui se trouve dans le répertoire log du disque du serveur.
Merci pour cette astuce !
Je ne vois pas grand-chose de super intéressant, des messages concernant dockerd-rootless.sh que justement j'étais en train de tester, des messages kernel "perf: interrupt took too long lowering kernel.perf_event_max_sample_rate" qui n'indique rien de grave a priori.
Bon j'ai 3 minutes de message de plus que dans les fichiers log mais ça ne semble pas m'expliquer pourquoi mon srv ne boote pas.
Si je comprends bien mon srv a démarré vers 21:41, démarrage qui s'est terminé peu après.
░░ All system services necessary queued for starting at boot have been
░░ started. Note that this does not mean that the machine is now idle as services
░░ might still be busy with completing start-up.
░░
░░ Kernel start-up required 8280436 microseconds.
░░
░░ Initrd start-up required INITRD_USEC microseconds.
░░
░░ Userspace start-up required 38427843 microseconds.
Très très étrange tout ça. Il a booté a 21:41, les logs s'arrêtent à 21:45 et depuis aucun boot possible.
Je ne comprends rien mais je sais que je n'ai rien pu faire qui ai changé la config l'empêchant de booter. (mon laptop venait justement de se bloquer, j'ai mis plusieurs minutes à le redémarrer cherchant les magic-sysrq qui fonctionnent)
IL y a beaucoup de données à récupérer ?
Dans la mesure où le disque semble accessible depuis le mode rescue, il est possible de transférer les données sur un autre serveur.
Faute d'avoir la main sur la machine, je ne pourrais que conseiller de prendre un autre kimsufi en parallèle, d'y transférer les données importantes et de lâcher le serveur HS.
Il serait intéressant de comprendre l'origine du dysfonctionnement, notamment pour ne pas reproduire, mais sans logs et sans KVM-IP, ça va être chaud :D.
Je pars sur cette solution. Mais pour moi ça va être bye bye kimsufi. Je vais payer plus mais je veux du raid et surtout une sorte de kvm/ip
Merci pour ton aide
Bonjour,
c'est dans des cas comme ça ou le fait de virtualiser ces services devient intéressant en terme de gestion.
Note : RAID+KVM il faut taper dans la gamme SYS (Cf : https://eco.ovhcloud.com/fr/?display=list&range=soyoustart)
Cordialement, janus57