Forum Linux.général [RÉSOLU] synchroniser les changements dans /boot vers /mnt/boot[23]

Posté par  . Licence CC By‑SA.
Étiquettes :
0
1
juil.
2023

Bonjour,

J'ai un PC RAID1 avec 3 disques.
Pour pouvoir booter quoi qu'il arrive, j'ai donc 3 partitions UEFI réparties sur les 3 disques.

Une est montée sur /boot , et les deux autres sur /mnt/boot2 et /mnt/boot3.

Je voudrais synchroniser tout changement dans le répertoire /boot (installation de kernels, ou modification de la config de boot) vers /mnt/boot[23].

Pour ce faire, j'ai essayé d'utiliser systemd-path mais je ne m'en sors vraiment pas.
Quand je le lance, le service est triggé alors qu'il devrait attendre.
Ensuite, comme je lui ai demandé, il se relance au bout de 10 secondes mais trigge à nouveau le ExecStart. Avant de se relancer au bout de 10 secondes, et ainsi de suite…

Comment faire en sorte que le ExecStart ne soit lancé qu'en cas de modification d'un fichier de /boot ? Et non toutes les dix secondes ?

# replique_boot.path

[Path]
PathChanged=/boot

[Install]
WantedBy=default.target

# replique_boot.service

[Unit]
Description=Replique partition boot

[Service]
Type=simple
WorkingDirectory=/boot
ExecStart=/bin/bash -c "date >>/tmp/replique_boot.txt"

Restart=always
RestartSec=10

[Install]
WantedBy=multi-user.target

Merci de m'avoir lu.

  • # inotify ?

    Posté par  . Évalué à 3. Dernière modification le 01 juillet 2023 à 23:31.

    Je ne sais pas par contre si inotify sait gérer les filesystem fat/fat32 si tu montes /boot/uefi.

    un exemple: https://github.com/leeyiw/inotify-sync

    Mais en cherchant il doit être possible de trouver un truc qui soit mieux adapté au besoin, truc basé sur inotify.

  • # Lecture de systemd.service(5)

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

    Je pense qu'il faut absolument lire la doc sur les types de service. Déclarer un Type=simple implique qu'on s'attend à avoir un démon qui tourne. Or ici une commande est exécutée, bash termine, ce que systemd corrige en redémarrant après un délai de 10 secondes, obéissant aux directives Restart*.

    J'imagine que se débarrasser de ces directives, basculer sur Type=oneshot devrait faire ce que tu souhaites. À tout le moins, cela devrait être une meilleure base de travail.

    Debian Consultant @ DEBAMAX

  • # Raid

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

    Pour faire la même chose, j'ai monté un raid logiciel avec MD ADM.

    Pour cela, j'ai mis les trois partitions dont j'avais besoin qu'elle soit synchronisée en raid miroir.

  • # synthèse des réponses

    Posté par  . Évalué à 3. Dernière modification le 02 juillet 2023 à 10:36.

    Merci pour vos réponses et pour les heures supp' du dimanche :)

    Je n'avais pas pensé au fait que fat32 n'était peut-être pas surveillable comme une partition supportant inotify.
    J'ai essayé de changer le path à surveiller vers mon home (qui est sur un partition RAID1 formatée en EXT4). Cela ne change rien, le service est triggé dès le lancement.

    Effectivement après lecture du man de service, il apparait que « type=simple » lance le service à l'init de celui-ci.
    « oneshot » ne modifie pas le comportement, et empêche seulement le service de se relancer, comme son nom l'indique.
    Je ne comprends pas que le service soit lancé, alors que la condition n'est pas remplie.

    Peut-être n'est-il simplement pas possible de surveiller un répertoire dans sa globalité. Dans les exemples que j'ai trouvé, ce qui se rapproche le plus de ce que je voudrais faire (surveiller tout changement dans /boot et ses sous répertoires) sont des « Path=/toto/*csv ». Donc une surveillance de fichiers prédéfinis. Qu'en est-il des nouveaux fichiers ? Je ne peux même pas vérifier vu que le service est lancé dès que le « systemctl start » est réalisé.

    Je pense changer de méthode avec soit:
    - un raid sur du FAT32 comme suggéré ici. Il semble que changer le type de partition en FD00 (linux raid) ne perturbe pas la majorité des BIOS et ne bloque pas le boot UEFI.
    - un bête rsync lancé deux fois par jour. Ça ne sera pas instantané, mais surement suffisant. Et puis je peux toujours le faire à la main dans les rares cas où je modifie ma configuration de boot. Le cron serait là en cas d'oubli de ma part.

    Discussions en français sur la création de jeux videos : IRC libera / #gamedev-fr

    • [^] # Re: synthèse des réponses

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

      Il n'y a ni condition ni relation déclarées.

      L'unité service étant activée pour multi-user.target, elle est bien sûr lancée automatiquement au démarrage. N'étant pas reliée à l'unité path, elle n'est bien sûr pas lancée quand l'unité path est activée.

      Ceci semble faire le job — mais je ne vais pas m'amuser à redémarrer mon laptop pour vérifier le comportement au démarrage.

      kibi@tokyo:~$ cat /etc/systemd/system/replique_boot.path
[Path]
PathChanged=/boot
Unit=replique_boot.service

[Install]
WantedBy=default.target

kibi@tokyo:~$ cat /etc/systemd/system/replique_boot.service 
[Service]
Type=oneshot
ExecStart=/bin/sh -c 'echo boot | logger -t test'


kibi@tokyo:~$ sudo systemctl enable --now replique_boot.path && sudo touch /boot/test

      Debian Consultant @ DEBAMAX

      • [^] # Re: synthèse des réponses

        Posté par  . Évalué à 2.

        Merci d'en avoir remis une couche, j'avais tout simplement oublié de lancer l'unité path … j'avais le message « the unit file has changed », mais uniquement quand je modifiais le service et je ne n'ai pas percuté.

        Pour le nom d'unité, j'avais vu dans le manuel que par défaut, l'unité path utilisait un service du même nom. Je n'ai donc pas spécifié « Unit » (après vérif avec et sans, ça fonctionne aussi bien).

        (extrait du man systemd.path)

        By default, a service by the same name as the path (except for the suffix) is activated. Example: a path file foo.path activates a matching service foo.service.

        Merci encore pour l'aide, je devenais chèvre.

        Discussions en français sur la création de jeux videos : IRC libera / #gamedev-fr

        • [^] # Re: synthèse des réponses

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

          OK, désolé pour ce point. N'ayant pas croisé ce genre d'unités dans la nature, j'ai regardé si je pouvais trouver un exemple et monter un PoC localement, et je n'ai pas vérifié sa page de manuel étant donné le comportement que tu décrivais et qui semblait s'expliquer par cette absence (perçue).

          Debian Consultant @ DEBAMAX

  • # Supplément du dimanche : proxmox-boot-tool

    Posté par  . Évalué à 4.

    Il existe dans Proxmox un outil nommé proxmox-boot-tool, qui sert justement à maintenir les partitions EFI synchro entre elles, et semble pouvoir être généralisé hors de Proxmox.

    Ce n'est pas directement une solution à ta question, mais comme c'est un sujet proche, je voulais le signaler.

Suivre le flux des commentaires

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