Charles Plessy a écrit :
> Le Sat, Jul 11, 2020 at 10:10:52AM +0200, BERTRAND Joël a écrit :
>>
>> Au lieu de faire cela, les devs de Debian seraient inspirés d'avoir un
>> répertoire /rescue avec le contenu de /bin, /sbin et le gestionnaire
>> de paquets compilé en statique.
>
> Bonjour Joël,
>
> une image Grml prête sur une partition de secours ne serait-elle pas
> suffisante ?
>
Bonjour Charles,
Pourquoi faire simple quand on peut faire compliqué ;-)
Le /rescue de NetBSD par exemple évolue avec le système. Il n'y a pas
de mise à jour nécessaire (plus que celle du système) et les outils qui
s'y trouvent sont toujours ceux capables de dépanner le système (dans
les bonnes versions). Il m'est déjà arrivé des soucis avec une debian et
avec un gestionnaire de paquet dans une version de l'image GRML qui
n'était pas capable de remettre d'équerre le système à dépanner qui
était dans une autre version.
C'est bien pour cela que je trouve très bête (et je suis poli) le fait
d'avoir ces liens de / vers /usr alors que le bon sens voudrait _au
contraire_ que l'on sépare bien ce qui est de l'ordre du mécanisme de
démarrage de ce qui est de l'ordre de l'utilisation du système une fois
celui-ci démarré. Certaines décisions me semblent prises sous l'effet de
la mode (pour ne pas dire sous l'effet de la drogue...) par des gens qui
n'ont pas réfléchi plus que cela à ce qui se faisait par ailleurs. Si
/bin, /sbin, /usr/bin et /usr/sbin ont été séparés depuis trente ans, il
y a peut-être des raisons fondamentales, ceux qui ont fait ces choix
n'étant pas plus bêtes que nous.
Dans un NetBSD, il n'y a typiquement pas besoin d'avoir une image
rescue quelque part parce qu'il existe ce répertoire /rescue et que
/bin, /lib et /sbin (et /etc) ne servent qu'au démarrage.
Exemple :
legendre:[~] > uname -a
NetBSD legendre.systella.fr 9.0_STABLE NetBSD 9.0_STABLE (CUSTOM) #6:
Sat Jun 6 16:01:51 CEST 2020
r...@legendre.systella.fr:/usr/src/netbsd-9/obj/sys/arch/amd64/compile/CUSTOM
amd64
legendre:[~] > du -hs /bin
1.7M .
legendre:[~] > du -hs /sbin
12M /sbin
legendre:[~] > du -hs /lib
18M /lib
legendre:[~] > du -hs /rescue
20M /rescue
legendre:[~] > du -hs /stand/amd64/9.0
23M /stand/amd64/9.0
Pour peu que tu aies cela sur une partition séparée (en lecture seule),
tu peux toujours redémarrer même ne cas d'effacement d'une bibliothèque
critique (/rescue est là pour cela). /rescue te permet de travailler sur
le vrai système sans jouer du mount -o bind et autres joyeusetés qui
sont assez rapidement plantogènes pour peu que le noyau de l'image ne
soit pas celui en cours sur le système à dépanner.
En mettant un lien de /sbin vers /usr/sbin, tu t'interdis cela (disons
que tu augmentes les chances que ça se passe mal). Exemple sur un
serveur Debian :
rayleigh:[~] > uname -a
Linux rayleigh 5.6.0-2-amd64 #1 SMP Debian 5.6.14-1 (2020-05-23) x86_64
GNU/Linux
rayleigh:[~] > du -hs /bin
12M /bin
rayleigh:[~] > du -hs /usr/bin
1,1G /usr/bin
rayleigh:[~] > du -hs /usr/sbin
64M /usr/sbin
rayleigh:[~] > du -hs /sbin
17M /sbin
Pour démarrer, j'ai _déjà_ besoin d'accéder à une partition en forme
(assez en forme pour être montée en ro) de 1,2 Go, voire deux partitions
en forme dans le cas où /usr est distinct et où on joue avec initramfs.
Et si une bibliothèque cruciale est corrompue, je n'ai que mes yeux pour
pleurer, je n'ai aucun utilitaire compilé en statique pour réparer.
Quiconque a déjà essayé de recompiler un apt en statique verra de quoi
je veux parler.
Remarque bien, pour démarrer correctement un linux de nos jours, il
faut aussi que l'initramfs soit correct. Encore un truc qui est une
aberration sans nom puisque les scripts appelés ne sont pas forcément
ceux de /etc, mais ceux qui ont été copiés dans l'initramfs. Je conçois
qu'on embarque des modules dans un système de fichiers spécial pour
contourner les problèmes d'initialisation liés au bios. Mais on peut
faire largement mieux avec un système comme grub2 sans passer par cette
horreur qu'est l'initramfs et qui est une source d'ennuis.
Bien cordialement,
JKB
