Forum Linux.debian/ubuntu 'Durcir' un serveur Debian

Posté par  . Licence CC By‑SA.
Étiquettes :
1
28
juil.
2020

Salut,
Chaque fois que j'ai une coupure ou une micro-coupure de courant @home mon serveur Debian qui sert à la domotique et de backend TV ne redémarre plus. Grub ne fonctionne plus. Ça foire à 100% à chaque coupure.
Le serveur est un NUC (Brix en fait).
Obligé de le sortir de son emplacement avec son alimentation, de le connecter à un clavier/écran et de réparer le boot Grub en bootant sur un livecd Ubuntu.
J'en ai, un peu, marre …
La question est donc : comment je configure le bouzin pour qu'une coupure de courant de l'empêche plus de booter ?
Le serveur n'est pas spécialement chargé et le filesystem est ext4.
Changer de filesystem serait une bonne idée ? Si oui, lequel mettre ?

  • # cause?

    Posté par  (site web personnel) . Évalué à 5.

    C'est bizarre ton histoire. J'ai éteint pas mal de fois des PC à l'arrache, ça ne m'a jamais fait ça, même pour mon raspberry qui se prend souvent des coupures et est allumé H24.

    J'imagine que ton ordi est allumé en permanence, si tu essaie de l'éteindre proprement est ce que tu as le même problème?

    Est-ce un PC UEFI ou BIOs Legacy? Je ne pense pas que le problème vienne de ta partition ext4 qui contient la configuration de grub si tu as un BIOS, car tu devrais alors avoir d'autres soucis. Par contre, en mode BIOS il y a une partie de grub qui est dans le MBR du disque, il faut voir si c'est ça qui est endommagé (fais un test SMART sur le disque).

    Dans le cas de l'UEFI, grub est installé dans une partition spéciale formatée en fat32, peut être que c'est elle qui a un problème ou qui se fait corrompre par un démontage pas propre. Ce système de fichier n'est pas journalisé, il est donc plus fragile.

    Un LUG en Lorraine : https://enunclic-cappel.fr

    • [^] # Re: cause?

      Posté par  . Évalué à 3. Dernière modification le 28 juillet 2020 à 15:45.

      il existe une variante d'un OS sur Rasberry PI qui possède un mode read-only ; c'est justement bien pratique, dans le cas que tu décris.

      De mémoire, il s'agit de ARMbian. Tu procèdes à l'installation, la configuration. Et quand tout te semble pret, tu lances l'utilitaire de configuration et passe (de mémoire), la racine de l'OS en lecture seule ; tout ce qui est modifié après le reboot, est dans une branche indépendante et volatile ; volume en https://fr.wikipedia.org/wiki/Copy-on-write

      lien : https://docs.armbian.com/User-Guide_Advanced-Features/#how-to-freeze-your-filesystem-outdated

      autre lien : https://wiki.debian.org/ReadonlyRoot

      • [^] # Re: cause?

        Posté par  . Évalué à 3.

        Sympa cette fonctionalité de Armbian, j'étais passé à côté.

        Sinon la solution hardware de contournement du problème c'est d'éviter les coupures de jus en ayant une UPS (onduleur ou modèle purement en courant continu) Il y a sans doute moyen de trouver un modèle qui envoie une commande d'extinction à l'OS si la coupure dure trop longtemps.

  • # firmware de merde?

    Posté par  . Évalué à 4. Dernière modification le 28 juillet 2020 à 17:08.

    Je ne sais pas si ça va aider, mais j'ai déjà eu ce type de symptômes dans 2 cas différents:

    • beaglebone black, systèmes ARM dont le firmware est UBoot, vieille version (personne, moi inclus, n'a jamais pris le temps d'essayer d'upgrade). Je soupçonne très fort un bug logiciel du firmware.
    • cartes mères… dont je ne me souviens plus le nom, étrange, j'ai pourtant passé un paquet d'heures dessus à, justement, identifier (autres autres) un problème de ce type.

    Vu que la machine ici est de marque GigaByte, je vais expliquer comment le problème a été "résolu": il s'avère que si l'UEFI pensait booter sur windows 7, au moins dans le cas d'une alim en mode AT, ça bugguait. S'il pensais booter sur windows 8, le problème disparaissait magiquement. Oui, c'étaient les deux seuls choix d'OS, et je ne vois vraiment pas ce que c'est censé changer, mais ça a bel et bien résolu le problème (je bosse plus la bas depuis 6 mois, mais ça faisait quelques temps que j'avais appliqué ce diff et ni les tests ni la prod n'ont eu ce problème a nouveau à ma connaissance. Enfin, pas causé par du logiciel, hein. Quand certaines parties du hard sont pas correctement protégée des parasites, c'est une autre histoire).

    Donc voila ma suggestion: essaies de mettre à jour le firmware, ou contactes directement le vendeur.
    Idéalement, trouves un firmware libre, au moins, s'il y a de la merde dedans, quelqu'un pourra le corriger, peut-être. Et si tu en trouves un compatible avec du matos récent, prière de nous donner le lien :) (oui, je connais coreboot, mais peut-être qu'il y en a d'autres qui supportent d'autres CM: on peut rêver?).

    Ah, j'allais proposer d'installer un watchdog matériel (proposition que j'ai faite a peu près 1 fois par mois pendant plus de 2 ans au taf, n'a jamais été suivie, aurait évité quasi tous les déplacement (y compris alsace-normandie, une paille) lié à des problèmes logiciels ainsi qu'une partie liée au hardware), mais on dirait que dans ton cas une intervention manuelle est nécessaire.
    Vu que tu ne la détailles pas, on ne peut pas vraiment identifier mieux l'éventuelle cause du problème.

  • # Suite et fin demain

    Posté par  . Évalué à 1. Dernière modification le 28 juillet 2020 à 22:16.

    Salut,
    Demain je prends mon courage à deux mains et je répare le grub.
    Je sais que c'est bizarre. J'ai plusieurs machines linux en VM et jamais de problème avec.
    Je mettrai toute la procédure ici. Ça sera la 3eme fois donc je devrais y arriver sans problème ;)
    Sinon c'est de l'UEFI avec un processeur Celeron.

  • # fait

    Posté par  . Évalué à 1. Dernière modification le 30 juillet 2020 à 10:41.

    Okay, réparé.
    Comme promis la procédure :

    sudo su -
    mount /dev/mapper/debian--vg-root /mnt
    mount /dev/mapper/debian--vg-var /mnt/var
    mount /dev/sda2 /mnt/boot
    mount /dev/sda1 /mnt/boot/efi/
    mount --bind /dev /mnt/dev
    mount --bind /dev/pts /mnt/dev/pts # needed
    mount --bind /proc /mnt/proc
    mount --bind /sys /mnt/sys
    mount --bind /run /mnt/run
    chroot /mnt

    apt-get install --reinstall grub-efi
    grub-install /dev/sda
    update-grub
    sync
    exit

    shutdown -h now

    Et voilà. C'est reparti jusqu'à la prochaine panne d'électricité.
    J'en ai profité pour changer la pile du serveur mais je ne vois pas trop comment le reset des paramètres du bios pourrait empêcher le serveur de booter vu que le seul paramètre que je change c'est désactiver l'audio.

    • [^] # Re: fait

      Posté par  . Évalué à 2.

      apt-get install --reinstall grub-efi
      grub-install /dev/sda

      est-ce vraiment nécessaire de reinstaller le paquet à chaque fois ?

      normalement juste le grub-install /dev/sda et le update-grub devrait etre nécessaire

    • [^] # Re: fait

      Posté par  (site web personnel) . Évalué à 2.

      La vrai question est plutot: qu'as-tu comme message d'erreur au boot post coupure de courant ?

      Prochaine coupure vérifie le contenu de /boot/efi avant de reinstaller grub.

      Si c'est le bios qui perd la séquence de démarrage il peut être intéressant de regarder ce que dit efibootmgr et de faire juste le grub-install
      voir même de copier /boot/efi/EFI/debian/grubx64.efi dans /boot/efi/EFI/BOOT/BOOTX64.EFI, c'est le boot-code utilisé par défaut en l'absence de paramètrage spécifique dans le BIOS / efibootmgr.

      • [^] # Re: fait

        Posté par  . Évalué à 1. Dernière modification le 30 juillet 2020 à 22:38.

        Salut,
        Le message c'est :

        error: no such partition.
        Entering rescue mode…
        grub rescue>

        J'espère ne pas revoir le message avant un bon moment ;)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.