Recherche
Filtre actif, cliquez pour en enlever un tag :
Cliquez sur un tag pour affiner votre recherche :
Résultat de la recherche (7 notes) :
Journal du lundi 23 décembre 2024 à 19:39
J'ai commencé le Projet GH-271 - Installer Proxmox sur mon serveur NUC Intel i3-5010U, 8Go de Ram le 9 octobre.
Le 27 octobre, j'ai publié la note 2024-10-27_2109 qui contient une erreur qui m'a fait perdre 14h !
# virt-customize -a noble-server-cloudimg-amd64.img --install qemu-guest-agent --run-command 'systemctl enable qemu-guest-agent.service'
[ 0.0] Examining the guest ...
[ 4.5] Setting a random seed
virt-customize: warning: random seed could not be set for this type of
guest
[ 4.5] Setting the machine ID in /etc/machine-id
[ 4.5] Installing packages: qemu-guest-agent
[ 32.1] Running: systemctl enable qemu-guest-agent.service
[ 32.6] Finishing off
Je n'avais pas fait attention au message Setting the machine ID in /etc/machine-id 🙊.
Conséquence : le template Proxmox Ubuntu contenait un fichier /etc/machine-id avec un id.
Conséquence : toutes les Virtual machine que je créais sous Proxmox avaient la même valeur machine-id.
J'ai découvert que l'option 61 "Client identifier" du protocole DHCP permet de passer un client id au serveur DHCP qui sera utilisé à la place de l'adresse MAC.
Conséquence : le serveur DHCP assignait la même IP à ces Virtual machine.
J'ai pensé que le serveur DHCP de mon router BBox avait un problème. J'ai donc décidé d'installer Projet 15 - Installation et configuration de OpenWrt sur Xiaomi Mi Router 4A Gigabit pour avoir une meilleure maitrise du serveur DHCP.
Problème : j'ai fait face au même problème avec le serveur DHCP de OpenWrt.
Après quelques recherches, j'ai découvert que contrairement à virt-customize la commande virt-sysprep permet d'agir sur des images qui ont vocation à être clonées.
"Sysprep" stands for "system preparation" tool. The name comes from the Microsoft program sysprep.exe which is used to unconfigure Windows machines in preparation for cloning them.
Pour corriger le problème, j'ai remplacé cette ligne :
# virt-customize -a noble-server-cloudimg-amd64.img --install qemu-guest-agent --run-command 'systemctl enable qemu-guest-agent.service'
Par ces deux lignes :
# virt-sysprep -a noble-server-cloudimg-amd64.img --network --install qemu-guest-agent --run-command 'systemctl enable qemu-guest-agent.service'
# virt-sysprep --operation machine-id -a noble-server-cloudimg-amd64.img
La seconde commande permet de supprimer le fichier /etc/machine-id, ce qui corrige le problème d'attribution d'IP par le serveur DHCP.
À noter que je ne comprends pas pourquoi il est nécessaire de lancer explicitement cette seconde commande, étant donné que la commande virt-sysprep est destinée aux images de type "template". Le fichier /etc/machine-id ne devrait jamais être créé, ou tout du moins, automatiquement supprimé à la fin de chaque utilisation de virt-sysprep.
Maintenant, l'instanciation de Virtual machine fonctionne bien, elles ont des IP différentes 🙂.
Prochaine étape du Projet GH-271 :
Je souhaite arrive à effectuer un déploiement d'une Virtual instance via cli de Terraform.
Journal du jeudi 07 novembre 2024 à 13:38
Même après l'upgrade vers Fedora 41, je rencontre toujours le même bug depuis août 2024.
Pendant une longue période, comme conseillé dans ce commentaire, je suis resté sur un kernel 6.9 jusqu'à la sortie des kernel 6.11.
Je pensais que la résolution de cette issue avait corrigé le problème : 7840h/780m system crash after update to linux kernel 6.10 (#3497).
Mais, je constate que non.
J'ai décidé de prendre un peu de temps pour soumettre au meilleur rapport de bug, que je souhaite dans un premier temps publier dans un commentaire, dans le thread suivant : Persistent System Crashes and Performance Issues on Fedora 40 with ASUS Vivobook 15 - Fedora Discussion.
Aujourd'hui, j'ai eu deux crash de gnome-shell.
À 13:13:33, au moment où j'ai branché le câble USB-C de mon moniteur externe sur mon laptop.
Voici-ci les logs du kernel :
13:13:33 t14s kernel: retire_capture_urb: 58 callbacks suppressed
...
13:13:54 t14s kernel: amdgpu 0000:33:00.0: [drm] REG_WAIT timeout 1us * 100 tries - dcn31_program_compbuf_size line:141
13:13:54 t14s kernel: ------------[ cut here ]------------
13:13:54 t14s kernel: WARNING: CPU: 12 PID: 30057 at drivers/gpu/drm/amd/amdgpu/../display/dc/hubbub/dcn31/dcn31_hubbub.c:151 dcn31_program_compbuf_size+0xd1/0x230 [amdgpu]
...
Version plus complète de ces logs : https://gist.github.com/stephane-klein/dff0d32c20af4307c3b85bbbf03b7b59
J'ai retrouvé la ligne 151 du fichier code source qui génère le warning : drivers/gpu/drm/amd/display/dc/hubbub/dcn31/dcn31_hubbub.c#L151
J'ai fait une recherche sur le gestionnaire d'issues du projet drm/amd avec dcn31_program_compbuf_size comme mot clé et je suis tombé sur cette issue : AMD GPU screen blanking for seconds with a warning
I run Fedora 40 on a ThinkPad T14 Gen3 - comes with AMD Ryzen 7 PRO 6850U with Radeon Graphics. I have my monitor connected via the ThinkPad dock, which is over a USB-C connection.
Yesterday, I updated to F41 with the 6.11.5-300.fc41 kernel. The screen blanking shot up to maybe 30x per minute, with 1-2s blanking each time, effectively giving me an unusable display.
J'ai le même hardware que cette personne et j'ai l'impression que je rencontre le même problème.
Toutefois, j'ai l'impression d'avoir eu des crashes de gnome-shell même sans l'action de brancher un moniteur externe en USB-C 🤔. Je pense être victime de plusieurs bugs.
4 secondes plus tard, Discord génère un coredump :
#JaiDécouvert la commande coredumpctl :
$ coredumpctl list --since "2024-11-07"
TIME PID UID GID SIG COREFILE EXE SIZE
Thu 2024-11-07 10:09:21 CET 352125 1000 1000 SIGTRAP present /app/main/mattermost-desktop 10.6M
Thu 2024-11-07 13:13:58 CET 54929 1000 1000 SIGABRT present /usr/lib64/discord/Discord 56.9M
Voici le contenu de :
$ coredumpctl info 54929 # /usr/lib64/discord/Discord
https://gist.github.com/stephane-klein/56b9097e1a22390ef3350757bf3132dc
Et celui de :
$ coredumpctl info 352125 # /app/main/mattermost-desktop
https://gist.github.com/stephane-klein/1b3790d45aef6383f98341f31ea40444
Voici le message que j'ai posté sur Discourse Fedora : https://discussion.fedoraproject.org/t/persistent-system-crashes-and-performance-issues-on-fedora-40-with-asus-vivobook-15/128526/20
Journal du mardi 29 octobre 2024 à 12:20
Après quelques heures d'utilisation de Hasura, j'ai l'impression que le projet manque de soin :
Journal du vendredi 27 septembre 2024 à 09:13
#bug très frustrant dans le Flatpak de Signal Desktop : Database Error
Le bug est arrivé dans cette Merge Request https://github.com/flathub/org.signal.Signal/pull/729/files.
Bug dans Signal-Desktop : Database Error prevents Signal-Desktop to start.
En lisant ce commentaire, je pense comprendre que --password-store=basic ne corrige pas directement le problème, mais permet d'éviter que le problème se reproduise après un reset.
Voici ma tentative d'ajout de --password-store=basic dans le fichier .desktop de Signal :
$ cd `flatpak info org.signal.Signal -l`
$ find . | grep "desktop"
./export/share/applications/org.signal.Signal.desktop
./files/Signal/signal-desktop
./files/bin/patch-desktop-filename
./files/bin/signal-desktop
./files/share/applications/org.signal.Signal.desktop
Après analyse du contenu de ces fichiers, j'ai l'impression que je dois modifier ./export/share/applications/org.signal.Signal.desktop.
$ sudo nvim ./export/share/applications/org.signal.Signal.desktop
J'ai ajouté --password-store=basic dans la ligne Exec= :
Exec=/usr/bin/flatpak run --branch=stable --arch=x86_64 --command=signal-desktop --file-forwarding org.signal.Signal --password-store=basic @@u %U @@
J'ai relancé Signal Desktop, mais je n'ai aucune idée si ma mise à jour a été prise en compte ou non. J'ignore comment vérifier cela 🤔.
Journal du mardi 13 août 2024 à 16:32
Je suis victime du bug suivant depuis 2 ou 3 jours sous ma Fedora :
Unexpected Logouts and System Instability: The second, more critical issue I’ve been facing is unexpected system logouts. Over the past two days, my screen has suddenly gone black as if the system has shut down. After less than a second, the login screen reappears, and upon logging in, I find that all my applications have closed. Yesterday, August 11, 2024, this happened twice within a three-minute span. Today, August 12, 2024, while studying with only Firefox open, I suspended my laptop and left.
-- from
J'en apprends plus ici :
A new regression for AMD APU’s is present in kernel 6.10 that wil cause intermittent full system crashes in combination with Mesa 24.1.5. The only option is to power down and restart the machine.
Kernel 6.9 is unaffected.
Issue upstream : https://gitlab.freedesktop.org/drm/amd/-/issues/3497
Je vais donc reboot sous un kernel 6.9 🤷♂️.
Je suis sûr qu'Alexandre va me dire qu'il n'a aucun problème sous ArchLinux ! Mais je ne le croirai pas, c'est un bug upstream !
Voir aussi ma doctrine Linux Desktop.
2024-08-22 : J'ai posté ce message AMD APU regression (full halt) on kernel 6.10 - how to best report?
2024-09-12 : J'ai posté ce message How to list Mesa versions included in my flatpak applications?
2024-10-15 : J'ai posté ce message.
Journal du lundi 29 janvier 2024 à 20:00
Sujet : Doctrine Linux Desktop.
Suite aux bugs décrits dans ma note du 2024-01-28, je pense que si je devais installer un Linux Desktop pour des amis non hackers, comme ma petite amie ou ma mère, je choisirais une version de Fedora n-1.
La dernière version de Fedora est actuellement la numéro 39, donc j'opterais pour la version 38.
Les versions de Fedora sont maintenues pendant un an.
Après six mois, les mises à jour se concentrent exclusivement sur les corrections de bugs et de sécurité, sans mise à niveau du kernel ou des autres composants principaux.
Bien que la version la plus récente de Fedora soit très stable, les mises à jour sont fréquentes et proches des versions upstream.
Cela peut exposer les utilisateurs à des bugs upstream, comme cela m'est arrivé récemment.
Dernière page.