Re: /sbin -> /usr/sbin

[Stephane Ascoet]

Le 11/07/2020 à 10:10, BERTRAND Joël a écrit :

éviter ce comportement à la noix. La justification de la chose est
vraiment spécieuse et c'est vraiment ce genre de truc qui fait que
j'abandonne de plus en plus les linuxeries. Et le fait que Debian est la
dernière à franchir le pas n'est vraiment pas un argument valable.


Bonjour, en haut de 
 
on peut lire:

"This is based on the Fedora feature for the same topic"

Tout s'explique. Red Hat/Fedora, les fossoyeurs de GNU/Linux! et Debian 
qui suit sans rien remettre en question...

--
Cordialement, Stephane Ascoet

Re: /sbin -> usr/sbin

[BERTRAND Joël]

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

Re: /sbin -> usr/sbin

[Klaus Becker]

Le 11/07/2020 à 15:06, 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 ?

Bon week-end,

Charles


Pas besoin de partition de secours. Il suffit de mettre l'image Grml à 
/boot/grml et de faire "update-grub".


ciao

Klaus

Re: /sbin -> usr/sbin

[Charles Plessy]

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 ?

Bon week-end,

Charles

-- 
Charles Plessy
Akano, Uruma, Okinawa, Japan

Re: /sbin -> usr/sbin

[BERTRAND Joël]

Charles Plessy a écrit :
> Le Sat, Jul 11, 2020 at 12:10:07AM +0200, BERTRAND Joël a écrit :
>>
>>  Je viens d'installer une debian/testing toute fraîche sur un portable
>> Toshiba et j'ai été surpris de trouver dans / des liens vers /usr :
> 
> Bonjour Bertrand,
> 
> c'est dans les notes de publication:
> 
> https://www.debian.org/releases/stable/amd64/release-notes/ch-whats-new.fr.html#merged-usr
> 
> Bonne fin de semaine,
> 
> Charles

Merci à tous, ça m'avait échappé.

Je viens de parcourir les liens fournis et c'est vraiment une bêtise
monumentale d'autant que je n'ai vu aucune option, nulle part, pour
éviter ce comportement à la noix. La justification de la chose est
vraiment spécieuse et c'est vraiment ce genre de truc qui fait que
j'abandonne de plus en plus les linuxeries. Et le fait que Debian est la
dernière à franchir le pas n'est vraiment pas un argument valable.

Je cite :

"Amélioration de la compatibilité avec les autres Unix / Linux dans le
comportement. Après la fusion avec /usr, tous les binaires deviennent
disponibles respectivement dans : _
_ “/bin <–> /usr/bin”
_"/sbin <–> /usr/sbin _
"/lib <–> /usr/lib"
_simplement parce que /bin devient un lien symbolique vers /usr/bin,
resp /sbin vers /usr/sbin… _
Cela signifie que les scripts/programmes écrits pour d’autres Unix ou
d’autres Linux et portés à la distribution courante n’auront plus besoin
de correction pour les chemins de système de fichiers des binaires
appelés, ce qui est par ailleurs une source majeure de frustration.
/usr/bin et /bin (resp. /Usr/sbin et /sbin, …) deviennent tout à fait
équivalents."

J'ai rarement lu un truc aussi bête. /bin et /sbin contiennent les
binaires nécessaires du démarrage du système, /usr/bin et /usr/sbin les
autres. C'est simple, carré. Par ailleurs, les scripts doivent utiliser
une variable PATH, donc ce problème n'existe pas.

"Amélioration de la compatibilité avec les systèmes de compilation GNU:
la majeure partie du logiciel Linux est construite avec GNU autoconf /
automake (c’est-à-dire GNU autotools), qui ignorent la division /usr
spécifique à Linux. Le maintien de la division /usr nécessite une
gestion non triviale du projet dans le système de génération en amont et
dans les packages de votre distribution. Avec la fusion /usr, ce travail
devient inutile et le portage des paquets vers Linux devient plus simple."

Euh... J'utilise les autotools depuis 25 ans, je n'ai jamais constaté
cela (sauf si les scripts sont écrits par des pieds, mais dans ce cas,
pourquoi mettre un cataplasme sur une jambe de bois ? On corrige en
amont, on ne fait pas n'importe quoi en aval !). Les autotools sont
_justement_ faits pour gérer ce genre de problème. Quant à parler de la
compatibilité Solaris, il y a un truc que les gens oublient, c'est que
Solaris est livré comme un tout et que, à l'instar des BSD, /usr
concerne le seul système. La dernière fois que j'ai eu un Solaris entre
les pattes (un 10, j'avoue), les programmes autres que ceux du système
étaient dans /opt ou /usr/local. Chez Debian, ce n'est pas le cas, ils
sont dans /usr/bin.

Un système Unix, quel qu'il soit, doit démarrer avec un système racine
qui contient :
- /etc
- /bin
- /sbin
- /lib
et c'est tout. Je sais bien qu'on peut bricoler avec initramfs, mais ça
reste du bricolage pour contourner un problème qui ne devrait pas
exister. initramfs est déjà un truc qui ne devrait pas exister dans un
système de démarrage bien conçu (et qui est source d'un certain nombre
de problèmes amusants).

/usr qui contient les programmes utilisateurs doit être monté plus
tard, comme /usr/local s'il est sur une partition à part, /opt, /var et
/home.

Comme chez Debian, on se prend les programmes installés dans /usr (donc
dans /usr/bin et /usr/sbin), on se trimballe une partition /usr qui peut
assez rapidement être énorme. Cette décision pourrait à la limite être
compréhensible si les paquets non nécessaires au système étaient dans
/usr/local ou /opt, mais pas en vrac dans /usr.

Sur mes serveurs critiques (enfin, ceux qu'il me reste à fonctionner
sous Linux), j'ai un / qui occupe 2Go (sur du raid1), alors que /usr en
fait une quarantaine. Certaines partitions sont même en read-only pour
éviter les problèmes. Vous allez me dire que c'est encore possible en
jouant de l'initramfs. Certes, mais si /usr est montée en rw et dégage
sur une corruption du fs, c'est tout le système qui est mort, alors que
si / est en ro, on redémarre.

Il faut vraiment que je trouve le temps de rajouter dans NetBSD les
quelques trucs qui me manquent pour remplacer mes derniers serveurs
Linux par des BSD. Entre dbus qui fait des siennes, systemd qui est
d&#x

Re: /sbin -> usr/sbin

[Charles Plessy]

Le Sat, Jul 11, 2020 at 12:10:07AM +0200, BERTRAND Joël a écrit :
> 
>   Je viens d'installer une debian/testing toute fraîche sur un portable
> Toshiba et j'ai été surpris de trouver dans / des liens vers /usr :

Bonjour Bertrand,

c'est dans les notes de publication:

https://www.debian.org/releases/stable/amd64/release-notes/ch-whats-new.fr.html#merged-usr

Bonne fin de semaine,

Charles

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Akano, Uruma, Okinawa, Japan

Re: /sbin -> usr/sbin

[l0f4r0]

Bonjour,

11 juil. 2020 à 00:10 de joel.bertr...@systella.fr:

>  Quel est l'intérêt d'une telle chose ? Normalement, un système doit
> pouvoir booter avec un / minimal et n'a pas besoin de /usr. Cela
> signifie même que ce système ne serait plus bootable si /usr était sur
> une partition séparée (mount est dans /usr/bin/ alors que dans une
> installation plus ancienne, il est dans /bin qui n'est pas un lien vers
> /usr/bin).
>
>  J'avoue que je ne saisis pas le pourquoi du comment de ce mélange. Je
> suis donc preneur de toute explication.
>
C'est normal, il s'agit d'une nouveauté depuis Buster :

* 
https://www.debian.org/releases/buster/amd64/release-notes/ch-whats-new.fr.html
(cf. "/usr fusionné pour les nouvelles installations")

* https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/(en 
anglais)

Bonne fin de soirée !
l0f4r0

Re: /sbin -> usr/sbin

[etienne . mollier]

Bonjour Joël,

BERTRAND Joël, on 2020-07-11 00:10:07 +0200:
>   Je viens d'installer une debian/testing toute fraîche sur un portable
> Toshiba et j'ai été surpris de trouver dans / des liens vers /usr :

Ce comportement provient du paquet "usrmerge" dont quelques
détails sont accessibles depuis le wiki:

https://wiki.debian.org/UsrMerge

En Debian Testing, debootstrap va installer usrmerge par défaut.
Je ne sais pas si ce comportement est réglable dans les images
ISO alpha, mais je crois que ces approches devraient être
possibles:

  - en partant de Debian Buster, faire une upgrade vers bullseye
en spécifiant éventuellement "usrmerge-" pour être sûr que
le paquet ne va pas s'installer,

  - ou alors effectuer une installation manuelle de Debian
testing via debootstrap avec l'option qui va bien:

# debootstrap --no-merged-usr bullseye /mnt/target/

>   Quel est l'intérêt d'une telle chose ? Normalement, un système doit
> pouvoir booter avec un / minimal et n'a pas besoin de /usr. Cela
> signifie même que ce système ne serait plus bootable si /usr était sur
> une partition séparée (mount est dans /usr/bin/ alors que dans une
> installation plus ancienne, il est dans /bin qui n'est pas un lien vers
> /usr/bin).
> 
>   J'avoue que je ne saisis pas le pourquoi du comment de ce mélange. Je
> suis donc preneur de toute explication.

Je ne suis pas allé regarder en détail (il y a de la lecture),
mais les liens suivants (en anglais) devraient vous fournir des
éléments de réponse, si ça peut éclairer votre lanterne:

https://lists.debian.org/debian-devel/2018/11/msg00374.html
https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/

En survolant ces deux pages, de ce que je comprends, ça permet
avant tout d'améliorer l'intéropérabilité entre les divers
Unices qui se sont multipliés dans la nature.

Amicalement,
-- 
Étienne Mollier 
Old rsa/3072: 5ab1 4edf 63bb ccff 8b54  2fa9 59da 56fe fff3 882d
New rsa/4096: 8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/6, please excuse my verbosity.


signature.asc
Description: PGP signature

/sbin -> usr/sbin

[BERTRAND Joël]

Bonjour à tous,

Je viens d'installer une debian/testing toute fraîche sur un portable
Toshiba et j'ai été surpris de trouver dans / des liens vers /usr :

danielle@nietzsche:/$ ls -al | grep ^l
lrwxrwxrwx   1 root root 7 juil. 10 14:20 bin -> usr/bin
lrwxrwxrwx   1 root root29 juil. 10 14:35 initrd.img ->
boot/initrd.img-5.7.0-1-amd64
lrwxrwxrwx   1 root root29 juil. 10 14:25 initrd.img.old ->
boot/initrd.img-5.6.0-2-amd64
lrwxrwxrwx   1 root root 7 juil. 10 14:20 lib -> usr/lib
lrwxrwxrwx   1 root root 9 juil. 10 14:20 lib32 -> usr/lib32
lrwxrwxrwx   1 root root 9 juil. 10 14:20 lib64 -> usr/lib64
lrwxrwxrwx   1 root root10 juil. 10 14:20 libx32 -> usr/libx32
lrwxrwxrwx   1 root root     8 juil. 10 14:20 sbin -> usr/sbin
lrwxrwxrwx   1 root root26 juil. 10 14:35 vmlinuz ->
boot/vmlinuz-5.7.0-1-amd64
lrwxrwxrwx   1 root root26 juil. 10 14:25 vmlinuz.old ->
boot/vmlinuz-5.6.0-2-amd64
danielle@nietzsche:/$

Quel est l'intérêt d'une telle chose ? Normalement, un système doit
pouvoir booter avec un / minimal et n'a pas besoin de /usr. Cela
signifie même que ce système ne serait plus bootable si /usr était sur
une partition séparée (mount est dans /usr/bin/ alors que dans une
installation plus ancienne, il est dans /bin qui n'est pas un lien vers
/usr/bin).

J'avoue que je ne saisis pas le pourquoi du comment de ce mélange. Je
suis donc preneur de toute explication.

Bien cordialement,

JKB