Re: Plus de framebuffer/X
C'est bien le fait de ne pas avoir usrmerge qui est le fautif parce que les scripts d'installation ne contiennent plus le PATH canonique ! Je ne dirais pas ce que je pense. signature.asc Description: OpenPGP digital signature
Re: Plus de framebuffer/X
Michel Verdier a écrit : > Le 8 janvier 2024 BERTRAND Joël a écrit : > >> J'ai déjà trouvé par le passé mount.nfs qui n'est plus dans /sbin mais >> dans /usr/sbin (contrairement à ce qu'indique la page man). > [...] >> Que les devs de Debian forcent l'utilisation d'usrmerge sur Debian, >> pourquoi pas. Mais pourquoi vouloir tout faire pour forcer l'utilisation >> de cette horreur sur les distributions dérivées ? > > usrmerge fait un lien symbolique de /bin -> /usr/bin et /sbin -> > /usr/sbin. Le déplacement de mount.nfs est indépendant, mais doit passer > inaperçu si on a usrmerge. Si tu as déjà pris le déplacement en compte > avant l'upgrade il doit s'agir d'autre chose. J'ai un tas d'erreurs dans les scripts d'initialisation parce que le PATH par défaut est /sbin:/bin et non plus /sbin:/bin:/usr/sbin:/usr/bin (ça ne coûtait vraiment rien de le conserver). Là, je fais une archive du système côté serveur avant de passer un coup d'usrmerge. Si c'est bien le problème, je réinstalle un système qui sait faire la différence entre / et /usr. HS: Sur cette machine, usrmerge ou pas n'est pas critique, mais je ne veux pas multiplier les systèmes entre mes machines fixes et les embarquées qui sont souvent à l'autre bout de la France et physiquement difficilement accessibles. Il serait d'ailleurs intéressant que les gens qui poussent ces "nouveautés" aient conscience de ce qui se fait ailleurs que sur les machines de bureau ou les serveurs embarquant des To de disques et de Go de mémoire. Dans l'embarqué, on aime bien avoir un / en ro et par exemple un /usr en ubifs rw sur une émulation de memory device. C'est ce que je fais sur des rPI lorsque le client impose cette architecture. Ça permet d'éviter de cramer des sdcard tous les six mois. Avec un usrmerge, c'est quasiment impossible sauf à bricoler avec des ramdisks vraiment tordus à l'initialisation. Alors oui, ça se fait, mais beaucoup plus difficilement qu'avant. Autre problème, cette joyeuseté complique aussi les mises à jour des équipements. Lorsqu'on a un / et un /usr sur des partitions séparées, qu'on a fait entrer le tout aux forceps dans une eMMC, on ne peut pas forcément copier tout /bin et /sbin vers /usr/bin et /usr/sbin faute de place. Il n'est pas rare dans l'embarqué d'avoir des eMMC de 16 ou 32 Go. Et lorsqu'on doit avoir des données variables, on les colle dans un /var séparé. On est donc relativement à l'étroit. J'ai bien conscience que c'est un cas marginal, mais c'est un cas qui me pourrit l'existence depuis des mois, d'où mon petit coup de gueule parce que j'ai de plus en plus l'impression que les développements récents des distribution Linux laissent tomber tout ce qui n'a pas 1 To de disque et au moins 4 Go de mémoire. Les gueux de l'embarqué, démerdez-vous. signature.asc Description: OpenPGP digital signature
Re: Plus de framebuffer/X
Le 8 janvier 2024 BERTRAND Joël a écrit : > J'ai déjà trouvé par le passé mount.nfs qui n'est plus dans /sbin mais > dans /usr/sbin (contrairement à ce qu'indique la page man). [...] > Que les devs de Debian forcent l'utilisation d'usrmerge sur Debian, > pourquoi pas. Mais pourquoi vouloir tout faire pour forcer l'utilisation > de cette horreur sur les distributions dérivées ? usrmerge fait un lien symbolique de /bin -> /usr/bin et /sbin -> /usr/sbin. Le déplacement de mount.nfs est indépendant, mais doit passer inaperçu si on a usrmerge. Si tu as déjà pris le déplacement en compte avant l'upgrade il doit s'agir d'autre chose. Si tu rajoutes le paramètre kernel debug au lieu de quiet tu auras un fichier debug dans /run/initramfs/
Re: Connexion réseau impossible pour certains logiciels
Envoyé avec la messagerie sécurisée Proton Mail.
Le vendredi 29 décembre 2023 à 13:44, yamo' a écrit :
> Salut,
> benoit a tapoté le 21/12/2023 13:30:
>
> > J’ai réinstallé mon système et les logiciels tels que evolution,
> > libreoffice, firefox-esr, ne parviennent pas à se connecter à internet.
>
>
> Peut-être est-ce lié à AppArmor ou SELinux?
>
> Tu peux jeter un oeil à :
>
> # aa-status
>
> https://debian-handbook.info/browse/fr-FR/stable/sect.apparmor.html
>
Voici ce que me dit mais je ne sais pas comment interpréter ça...
Ca veut dire quoi ?
# aa-status
apparmor module is loaded.
25 profiles are loaded.
23 profiles are in enforce mode.
/usr/bin/evince
/usr/bin/evince-previewer
/usr/bin/evince-previewer//sanitized_helper
/usr/bin/evince-thumbnailer
/usr/bin/evince//sanitized_helper
/usr/bin/man
/usr/lib/NetworkManager/nm-dhcp-client.action
/usr/lib/NetworkManager/nm-dhcp-helper
/usr/lib/connman/scripts/dhclient-script
/usr/lib/cups/backend/cups-pdf
/usr/sbin/cups-browsed
/usr/sbin/cupsd
/usr/sbin/cupsd//third_party
/{,usr/}sbin/dhclient
libreoffice-senddoc
libreoffice-soffice//gpg
libreoffice-xpdfimport
lsb_release
man_filter
man_groff
nvidia_modprobe
nvidia_modprobe//kmod
tcpdump
2 profiles are in complain mode.
libreoffice-oosplash
libreoffice-soffice
0 profiles are in kill mode.
0 profiles are in unconfined mode.
3 processes have profiles defined.
3 processes are in enforce mode.
/usr/sbin/cups-browsed (1406)
/usr/sbin/cupsd (1210)
/usr/lib/cups/notifier/dbus (6623) /usr/sbin/cupsd
0 processes are in complain mode.
0 processes are unconfined but have a profile defined.
0 processes are in mixed mode.
0 processes are in kill mode.
