Ça va, je suis sauvé : j’ai dû à l’époque tester sur une machine virtuelle, ouffffffffffffff !
Mais du coup, et en relisant l’autre fil, on se dit qu’on ne sait plus trop sur quel pied danser.
Bah, plus qu’à attendre la 13…
Ça va, je suis sauvé : j’ai dû à l’époque tester sur une machine virtuelle, ouffffffffffffff !
Mais du coup, et en relisant l’autre fil, on se dit qu’on ne sait plus trop sur quel pied danser.
Bah, plus qu’à attendre la 13…
D’abord, ce qu’on ne fait pas : utiliser dpkg-fsys-usrunmess inclus dans les versions récentes du paquet dpkg dans testing pour revenir en arrière. Plusieurs cas de systèmes inutilisables suite à cela ont été rapportés.
Depuis buster, toutes les nouvelles installations ont /usr fusionné par défaut et ça n’a pas été l’apocalypse annoncée. En ce qui me concerne en tant qu’utilisateur standard, la seule contrainte est que je dois maintenant utiliser
dpkg -S $(which -a <commande>)
au lieu de
dpkg -S $(which <commande>)
précédemment pour identifier quel paquet installé contient l’exécutable <commande>
.
Les problèmes avec /usr fusionné relevés par le mainteneur de dpkg ne concernent pas la plupart des utilisateurs.
Tu suggères sérieusement d’utiliser l’installateur de stretch puis de mettre à jour vers buster puis bullseye ? Il y a plus « sain » : lancer l’installateur stable en mode « expert », et après l’étape de partitionnement créer à la main les répertoires /bin, /lib{,32,64,x32} et /sbin avant d’installer le système de base.
Oui tout a fais, ou utilisé une autre distribution.
Pour installer Debian ?
Non je propose juste d’allez voir ailleurs si le fonctionnement ou le contenu ne plais pas … il y a pas mal de distribution basé sur Debian et qui propose des alternatives à ça ou autre chose (systemd etc …).
Et tu me dis dans mon post que je n’aurais pas dû le faire sur ma unstable. Bref…
Donc, ça vaut pour l’équipe Debian sur les projets Stable, mais moi, pour résoudre le problème relevé, je n’aurais pas du le faire.
(je vais me taire - je préfère)
Au fait, en passant, il y a clairement eu un apt-listchanges à-propos de which
…
Bref.
Quand j’ai écrit cela, j’ai confondu la décision du comité technique et la position du mainteneur de dpkg, ce dont je me suis déjà expliqué. Néanmoins, encore maintenant j’estime que cela aurait été plus prudent parce que d’une part
et d’autre part
En ce qui me concerne, ma dernière installation de stable a été faite sans fusion d’/usr et toutes les suivantes le seront également idéalement jusqu’à ce que les problèmes soient corrigés, au minimum que la situation soit clarifiée ou à défaut que cette organisation ne soit plus supportée.
Suppression annulée depuis.
Désolé, je ne comprends pas ton propos !
Là, encore, si c’est une affirmation, tu ne prouves strictement rien.
Quant au reste, tu as ton avis sur la question d’usrmerge, tout le monde l’a compris ; perso, je ne regrette pas d’avoir fait ce choix. Voilà.
(et, personnellement, je ne cherche pas à revenir en arrière)
Ton lien annonce la suppression de la commande which
dans le paquet debianutils en date du 30/08/2021. Or un changelog ultérieur en date du 21/01/2022 annule cette suppression.
https://metadata.ftp-master.debian.org/changelogs//main/d/debianutils/debianutils_5.7-0.2_changelog
- Revert deprecation of which (no. 2).
Bonjour,
pour participer un peu :
lors de la migration 10 → 11, j’ai suivi il y a quelques mois le tuto proposé ici-même et tout s’est bien passé.
Au final (11.3 maintenant), il ne m’a rien été demandé à propos d’un quelconque merging et pourtant, quand je regarde l’arborescence de /
avec mc
, je vois bien que
~bin pointe sur usr/bin (sans le "/")
~lib " " usr/lib (idem)
~lib64 " " usr/lib64 (idem)
~sbin " " usr/sbin (idem)
confirmé par un
$ ls -lGg
total 25852
lrwxrwxrwx 1 7 9 mai 2020 bin -> usr/bin
drwxr-xr-x 4 4096 7 mai 18:33 boot
drwxr-xr-x 16 3300 18 mai 08:47 dev
drwxr-xr-x 147 12288 18 mai 10:40 etc
drwxr-xr-x 5 4096 11 sept. 2020 grub
drwxr-xr-x 3 4096 4 janv. 2021 home
lrwxrwxrwx 1 23 30 mars 18:04 initrd.img -> boot/initrd.img-5.10.84
lrwxrwxrwx 1 7 9 mai 2020 lib -> usr/lib
lrwxrwxrwx 1 9 9 mai 2020 lib64 -> usr/lib64
drwx------ 2 16384 16 juin 2020 lost+found
drwxr-xr-x 8 4096 14 mai 19:59 media
drwxr-xr-x 10 4096 7 mai 18:56 mnt
drwxr-xr-x 8 4096 26 mars 13:28 opt
dr-xr-xr-x 225 0 18 mai 08:47 proc
drwx------ 31 4096 18 mai 11:27 root
drwxr-xr-x 30 820 18 mai 08:58 run
lrwxrwxrwx 1 8 9 mai 2020 sbin -> usr/sbin
drwxr-xr-x 2 4096 9 mai 2020 srv
dr-xr-xr-x 12 0 18 mai 08:47 sys
drwxrwxrwt 17 360 18 mai 10:39 tmp
drwxr-xr-x 12 4096 12 mars 11:55 usr
drwxr-xr-x 11 4096 7 oct. 2020 var
lrwxrwxrwx 1 20 30 mars 18:05 vmlinuz -> boot/vmlinuz-5.10.84
lrwxrwxrwx 1 24 30 mars 18:05 vmlinuz.old -> boot/vmlinuz-5.10.84.old
(enlevé 4 lignes de points2montage pour mes "gros" disques)
Et dans synaptic il n’y a pas de paquet usrmerge installé.
hth,
PS : pas compris pourquoi cette discussion s’est retrouvée après un split dans « Pause café » ?
OK, merci. Modification faite dans le post en question
Avec quelle version de Debian l’installation initiale a-t-elle été faite ?
L’arborescence avec /usr fusionné est mise en place lors de l’installation depuis Debian 10.
Moi non plus.
Je ne sais plus (c’est loin…) Probablement une 10.4 ou 5.
Tu peux retrouver des traces de l’installation initiale dans la ligne deb cdrom:
dans /etc/apt/sources.list (si tu n’as pas effacée) ou dans /var/log/installer/lsb-release.
Effacé, et pour l’autre fichier, je n’ai pas, alors
$ locate lsb-release
/var/lib/dpkg/info/lsb-release.list
/var/lib/dpkg/info/lsb-release.md5sums
/var/lib/dpkg/info/lsb-release.postinst
/var/lib/dpkg/info/lsb-release.postrm
On ne va pas aller loin avec juste ça…
Qu’est-ce que tu as dans /var/log/installer ?
Rien, ce dossier n’existe pas ! (/var/log/
oui)
Pourtant il est présent sur toutes mes installations faites avec l’installateur classique. Tu as fait l’installation depuis un système live ou l’installateur classique ?
Moi non plus mais mon installation date de Potato.
Oui, j’aurais dû préciser « toutes mes installations depuis jessie (Debian 8) ».