Bonjour, steve, on 2021-06-25: > Le 25-06-2021, à 09:09:32 +0000, Hugues Larrive a écrit : > > Sur un système avec tout dans la même partition ça ne devrait pas poser de > > problème, même en mettant tous les binaires dans un dossier unique avec > > des liens symboliques de leurs dossiers d'origine pointant dessus ça devrait > > fonctionner. Le problème c'est si tu distribues des chose, par exemple un > > script shell commençant par #!/bin/sh fonctionnera dans tous les cas (tant > > qu'il y a un symlink de /bin -> /usr/bin, mais s'il commençait par > > #!/usr/bin/sh il ne fonctionnerait pas sur un système où sh se trouve dans > > /bin. Ou si tu as une configuration avec /usr sur une partition séparée, > > dans ce cas il faut que tout le nécessaire pour monter cette partition soit > > dans l'initrd. […] > /dev/sdb5 on / type ext4 (rw,relatime,errors=remount-ro) > /dev/sdb6 on /usr type ext4 (rw,relatime) […] > /dev/md0 on /var type ext4 (rw,relatime) […] > Risqué de se lancer dans cette opération de merge ? À vue de nez, pas tant que ça. Les prérequis pour monter / et /usr sont les mêmes, c.-à-d. supporter le Sata et l'Ext4 ; donc soit tout va bien, soit rien ne marche du tout. Peut-être que vous voudrez vous assurer de la présence des modules raid, et de mdadm, dans l'initrd, au moins pour la partition /var, mais cette partie me semble indépendante d'usrmerge : $ lsinitramfs /boot/initrd.img-$(uname -r) | grep -e md/raid -e bin/mdadm usr/lib/modules/5.10.0-7-amd64/kernel/drivers/md/raid0.ko usr/lib/modules/5.10.0-7-amd64/kernel/drivers/md/raid1.ko usr/lib/modules/5.10.0-7-amd64/kernel/drivers/md/raid10.ko usr/lib/modules/5.10.0-7-amd64/kernel/drivers/md/raid456.ko usr/sbin/mdadm Le risque zéro n'existe pas (donc faites une sauvegarde complète et préparez une clé de récupération avant toute manipulation de ce type ;), mais pour peu que les pilotes soient effectivement présents dans l'initrd, un usrmerge devrait bien se passer, au moins pour ce qui est de l'intégrité du système d'exploitation au prochain redémarrage. Pour information, certains programmes peuvent ne pas prendre correctement en charge les configurations usrmerge, comme d'anciennes versions de vrrender, affectées par #958089[1]. C'est le seul bug de ce genre que j'ai pu croiser ceci dit, et maintenant il est clôt. À moins d'être configurés avec --prefix=/ ou /usr (ce qui entrerait potentiellement en conflit avec le gestionnaire de paquets), les programmes tiers, normalement rangés dans /opt ou /usr/local, ne devraient pas être impactés par usrmerge. [1] : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=958089 Historiquement parlant, le premier schisme entre / et /usr aurait eu lieu quand K&R sont arrivés au bout de l'espace disponible sur la bande / de leur DEC PDP-11, si j'en croie les archives de la liste de diffusion de Busybox[2]. Les considérations techniques sont apparues ensuite pour permettre à la machine de démarrer correctement sans avoir immédiatement la bande /usr à disposition. Aujourd'hui le rôle d'un tel / a dérivé vers l'initrd (voir vers le chargeur de démarrage), du coup le schisme n'a théoriquement plus vraiment lieu d'être, en dehors de maintenir la compatibilité avec l'existant ; du coup, je peux comprendre que certains pensent que / et l'initrd fassent un peu double emploi. [2] : http://lists.busybox.net/pipermail/busybox/2010-December/074114.html Pour ma part, mes machines tournent en usrmerge depuis que ce mécano existe. Ce changement a été transparent pour moi. Au jour le jour, je n'ai tout simplement pas conscience qu'il est en place. Bonne journée, :) -- Étienne Mollier <emollier@emlwks999.eu> Fingerprint: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da Sent from /dev/pts/4, please excuse my verbosity.
Attachment:
signature.asc
Description: PGP signature