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: Plus de framebuffer/X
Bon. J'ai un début de piste et ça commence à être gavant. 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). Là, on se retrouve avec des PATH dans des scripts de démarrage qui ne contiennent plus que /sbin:/bin. J'ai un tas d'erreurs au démarrage (erreurs naturellement non logguées et qui n'apparaissent que sur la console, même pas dans le dmesg). Je suppose que la génération de l'initramfs est foireuse même si elle ne retourne aucune erreur. Il y a des distributions basées sur debian qui n'utilisent ni systemd ni (encore et heureusement) l'horreur usrmerge. Qu'est-ce qui empêche les développeurs de Debian de coller mount.nfs dans /sbin et de conserver les paths classiques (sauf à vouloir imposer à toutes les distributions dérivées l'utilisation d'usrmerge) ? Il y a des tas de raisons pour ne pas en vouloir, à commencer par la gestion des partitions en ro de systèmes embarqués. Tout le monde ne veut pas un gros /usr en rw, surtout sur des machines sans console et inaccessibles physiquement ! 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 ? Merci de ne pas répondre en essayant de me convaincre de l'intérêt de cette "chose". J'ai bien réfléchi, je la trouve merdique au possible pour mes applications, je n'en veux pas. Si elle se trouve imposée, je changerai plutôt d'OS. JB signature.asc Description: OpenPGP digital signature
Re: Plus de framebuffer/X
ajh-valmer a écrit : > On Sunday 07 January 2024 19:47:19 BERTRAND Joël wrote: >> ... apt dist-upgrade (qui s'est achevé sans erreur). >> Aujourd'hui, je rallume la machine en question et je n'ai plus de >> session graphique ... : > > Sans doute, suite à l'upgrade, le nouveau noyau de Devuan > ne reconnaît plus le module de la carte graphique. > Il faut essayer de booter avec un ancien noyau, > sinon de trouver un pilote vidéo adaptable. J'ai l'impression que dans l'upgrade, l'ancien noyau a été retiré. J'ai essayé avec un vmlinuz-6.5.0-5-amd64 et un vmlinuz-6.5.0-3-amd64. Même motif, même résultat. Ce qui me fait tiquer est que je n'ai pas autre chose que la console 80x25 (même en mode texte). Bien cordialement, JB signature.asc Description: OpenPGP digital signature
Re: Plus de framebuffer/X
Michel Verdier a écrit : > Le 7 janvier 2024 BERTRAND Joël a écrit : > >> Hier, j'ai du configurer ce qu'il fallait pour pouvoir accéder à des >> bluerays. Très bien, ça fonctionnait. Mais pour cela, j'ai du passer un >> apt dist-upgrade (qui s'est achevé sans erreur). > > As-tu fais update et upgrade --without-new-pkgs comme préconisé ici : > https://www.debian.org/releases/stable/i386/release-notes/ch-upgrading.fr.html#upgradingpackages > >> 2024-01-07T19:27:37.012530+01:00 heisenberg kernel: Kernel command line: >> BOOT_IMAGE=pxelinux.cfg/vmlinuz-heisenberg root=/dev/nfs >> initrd=pxelinux.cfg/initrd.img-heisenberg >> nfsroot=192.168.10.128:/srv/heisenberg ip=dhcp rw splash >> intel_iommu=on,igfx_off >> >> 2024-01-07T19:27:37.012533+01:00 heisenberg kernel: Unknown kernel >> command line parameters "splash >> BOOT_IMAGE=pxelinux.cfg/vmlinuz-heisenberg >> nfsroot=192.168.10.128:/srv/heisenberg ip=dhcp", will be passed to user >> space. > > C'est juste un warning qui indique que les paramètres sont passés à la > suite. As-tu refais le kernel et le initrd qui sont utiisés ? Oui. J'ai vérifié par deux fois. > Quelle est ta version de kernel ? Quelle est ta carte graphique ? root@heisenberg:/var/log# uname -a Linux heisenberg 6.5.0-3-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.5.8-1 (2023-10-22) x86_64 GNU/Linux La carte graphique est une intel intégrée au CPU : Intel(R) Core(TM) i5-4570S CPU @ 2.90GHz JB signature.asc Description: OpenPGP digital signature
Re: Plus de framebuffer/X
On 1/7/24 19:47, BERTRAND Joël wrote: Bonjour à tous et bonne année. Il m'arrive un truc étonnant sur une machine qui me sert de serveur multimedia. Cette machine est diskless et fonctionnait parfaitement jusqu'à hier (pas noté la version du noyau). Ce n'est pas une Debian, c'est une Devuan, mais les paquets et la configuration sont identique en dehors du système d'initialisation. Hier, j'ai du configurer ce qu'il fallait pour pouvoir accéder à des bluerays. Très bien, ça fonctionnait. Mais pour cela, j'ai du passer un apt dist-upgrade (qui s'est achevé sans erreur). J'aurais essayé /usr/bin/startx /usr/bin/icewm puis voir en détails (avec less) less messages dans /var/log/Xorg.0.log et la sortie de dmesg Librement -- Basile Starynkevitch (only mine opinions / les opinions sont miennes uniquement) 92340 Bourg-la-Reine, France web page: starynkevitch.net/Basile/
Re: Plus de framebuffer/X
Le 7 janvier 2024 BERTRAND Joël a écrit : > Hier, j'ai du configurer ce qu'il fallait pour pouvoir accéder à des > bluerays. Très bien, ça fonctionnait. Mais pour cela, j'ai du passer un > apt dist-upgrade (qui s'est achevé sans erreur). As-tu fais update et upgrade --without-new-pkgs comme préconisé ici : https://www.debian.org/releases/stable/i386/release-notes/ch-upgrading.fr.html#upgradingpackages > 2024-01-07T19:27:37.012530+01:00 heisenberg kernel: Kernel command line: > BOOT_IMAGE=pxelinux.cfg/vmlinuz-heisenberg root=/dev/nfs > initrd=pxelinux.cfg/initrd.img-heisenberg > nfsroot=192.168.10.128:/srv/heisenberg ip=dhcp rw splash > intel_iommu=on,igfx_off > > 2024-01-07T19:27:37.012533+01:00 heisenberg kernel: Unknown kernel > command line parameters "splash > BOOT_IMAGE=pxelinux.cfg/vmlinuz-heisenberg > nfsroot=192.168.10.128:/srv/heisenberg ip=dhcp", will be passed to user > space. C'est juste un warning qui indique que les paramètres sont passés à la suite. As-tu refais le kernel et le initrd qui sont utiisés ? Quelle est ta version de kernel ? Quelle est ta carte graphique ?
Re: Plus de framebuffer/X
On Sunday 07 January 2024 19:47:19 BERTRAND Joël wrote: > ... apt dist-upgrade (qui s'est achevé sans erreur). > Aujourd'hui, je rallume la machine en question et je n'ai plus de > session graphique ... : Sans doute, suite à l'upgrade, le nouveau noyau de Devuan ne reconnaît plus le module de la carte graphique. Il faut essayer de booter avec un ancien noyau, sinon de trouver un pilote vidéo adaptable.
Plus de framebuffer/X
Bonjour à tous et bonne année. Il m'arrive un truc étonnant sur une machine qui me sert de serveur multimedia. Cette machine est diskless et fonctionnait parfaitement jusqu'à hier (pas noté la version du noyau). Ce n'est pas une Debian, c'est une Devuan, mais les paquets et la configuration sont identique en dehors du système d'initialisation. Hier, j'ai du configurer ce qu'il fallait pour pouvoir accéder à des bluerays. Très bien, ça fonctionnait. Mais pour cela, j'ai du passer un apt dist-upgrade (qui s'est achevé sans erreur). Aujourd'hui, je rallume la machine en question et je n'ai plus de session graphique. De la même manière, la console reste en 80x25 (avant, j'avais une console graphique avec des tous petits caractères, l'écran est un truc en 2560x1440. Si je lance sddm à la main, il ne se passe rien (le processus tourne, aucune erreur dans les logs de sddm). kern.log indique plusieurs choses étranges (je ne sais pas si le noyau indiquait la même chose dans la configuration fonctionnelle) : 2024-01-07T19:27:37.012530+01:00 heisenberg kernel: Kernel command line: BOOT_IMAGE=pxelinux.cfg/vmlinuz-heisenberg root=/dev/nfs initrd=pxelinux.cfg/initrd.img-heisenberg nfsroot=192.168.10.128:/srv/heisenberg ip=dhcp rw splash intel_iommu=on,igfx_off 2024-01-07T19:27:37.012533+01:00 heisenberg kernel: Unknown kernel command line parameters "splash BOOT_IMAGE=pxelinux.cfg/vmlinuz-heisenberg nfsroot=192.168.10.128:/srv/heisenberg ip=dhcp", will be passed to user space. Effectivement, splash ne fonctionne plus non plus. Mais j'ai aussi ceci : root@heisenberg:/var/log# grep conflict kern.log 2024-01-07T18:05:19.599573+01:00 heisenberg kernel: ACPI Warning: SystemIO range 0x1828-0x182F conflicts with OpRegion 0x1800-0x187F (\PMIO) (20230331/utaddress-204) 2024-01-07T18:05:19.599573+01:00 heisenberg kernel: ACPI: OSL: Resource conflict; ACPI support missing from driver? 2024-01-07T18:05:19.599577+01:00 heisenberg kernel: ACPI Warning: SystemIO range 0x1C40-0x1C4F conflicts with OpRegion 0x1C00-0x1FFF (\GPR) (20230331/utaddress-204) 2024-01-07T18:05:19.599578+01:00 heisenberg kernel: ACPI: OSL: Resource conflict; ACPI support missing from driver? 2024-01-07T18:05:19.599578+01:00 heisenberg kernel: ACPI Warning: SystemIO range 0x1C30-0x1C3F conflicts with OpRegion 0x1C00-0x1C3F (\GPRL) (20230331/utaddress-204) 2024-01-07T18:05:19.599579+01:00 heisenberg kernel: ACPI Warning: SystemIO range 0x1C30-0x1C3F conflicts with OpRegion 0x1C00-0x1FFF (\GPR) (20230331/utaddress-204) 2024-01-07T18:05:19.599579+01:00 heisenberg kernel: ACPI: OSL: Resource conflict; ACPI support missing from driver? 2024-01-07T18:05:19.599579+01:00 heisenberg kernel: ACPI Warning: SystemIO range 0x1C00-0x1C2F conflicts with OpRegion 0x1C00-0x1C3F (\GPRL) (20230331/utaddress-204) 2024-01-07T18:05:19.599582+01:00 heisenberg kernel: ACPI Warning: SystemIO range 0x1C00-0x1C2F conflicts with OpRegion 0x1C00-0x1FFF (\GPR) (20230331/utaddress-204) 2024-01-07T18:05:19.599583+01:00 heisenberg kernel: ACPI: OSL: Resource conflict; ACPI support missing from driver? 2024-01-07T18:05:19.599583+01:00 heisenberg kernel: lpc_ich: Resource conflict(s) found affecting gpio_ich 2024-01-07T18:11:36.030703+01:00 heisenberg kernel: ACPI Warning: SystemIO range 0x1828-0x182F conflicts with OpRegion 0x1800-0x187F (\PMIO) (20230331/utaddress-204) 2024-01-07T18:11:36.030703+01:00 heisenberg kernel: ACPI: OSL: Resource conflict; ACPI support missing from driver? 2024-01-07T18:11:36.030708+01:00 heisenberg kernel: ACPI Warning: SystemIO range 0x1C40-0x1C4F conflicts with OpRegion 0x1C00-0x1FFF (\GPR) (20230331/utaddress-204) 2024-01-07T18:11:36.030708+01:00 heisenberg kernel: ACPI: OSL: Resource conflict; ACPI support missing from driver? 2024-01-07T18:11:36.030709+01:00 heisenberg kernel: ACPI Warning: SystemIO range 0x1C30-0x1C3F conflicts with OpRegion 0x1C00-0x1C3F (\GPRL) (20230331/utaddress-204) 2024-01-07T18:11:36.030709+01:00 heisenberg kernel: ACPI Warning: SystemIO range 0x1C30-0x1C3F conflicts with OpRegion 0x1C00-0x1FFF (\GPR) (20230331/utaddress-204) 2024-01-07T18:11:36.030710+01:00 heisenberg kernel: ACPI: OSL: Resource conflict; ACPI support missing from driver? 2024-01-07T18:11:36.030710+01:00 heisenberg kernel: ACPI Warning: SystemIO range 0x1C00-0x1C2F conflicts with OpRegion 0x1C00-0x1C3F (\GPRL) (20230331/utaddress-204) 2024-01-07T18:11:36.030713+01:00 heisenberg kernel:
