MT [AF>Libristes] : le topic

[fzs600]

[Antares]

  

[JeromeC]

Ah elle est facile celle là hein !! mes messages d'erreur je les ai pas inventé   

D'ailleurs, puisqu'on en parle : je peux utiliser boinccmd, boinctui aussi, depuis mon terminal (sans sudo je précise, depuis mon compte utilisateur de base), en revanche impossible de lancer le boinc manager graphique, il me pète une erreur de droits à nouveau sur ce même fichier de mdp !! j'ai repassé toutes les commandes de lepingouin, toutes ont fonctionné correctement (sur cette nouvelle VM toute neuve je le rappelle), rebooté, ben pareil, il dit qu'il peut pas lire le fichier de mot de passe...

Bref je me passerai du BM graphique, boinctui fait très bien l'affaire - et lui sait accéder à ce *même* fichier lui...

[Maeda]

Si l'envie te prend, tu peux essayer ce qui est proposé ci-dessous par une IA qui glane les infos (y compris les conneries) d'il y a quelques années sans réel réflexion (des fois que, ça peut aider ).

quote=I'A ou I'A pas ?
L'erreur "impossibilité de lire le fichier gui_rpc_auth.cfg" avec BOINC Manager sous Debian est souvent liée à des problèmes de permissions ou de configuration. Voici quelques étapes pour résoudre ce problème :

1. **Vérifiez les permissions du fichier** : Assurez-vous que le fichier `gui_rpc_auth.cfg` a les bonnes permissions. Vous pouvez utiliser la commande suivante pour ajuster les permissions :

Code Sélectionner Étendre

sudo chmod 664 /etc/boinc-client/gui_rpc_auth.cfg
   Assurez-vous que le propriétaire est `root` et le groupe est `boinc`.

2. **Redémarrez le client BOINC** : Après avoir modifié les permissions, redémarrez le client BOINC pour que les modifications prennent effet. Vous pouvez utiliser la commande suivante :

Code Sélectionner Étendre

sudo systemctl restart boinc-client
3. **Ajoutez votre utilisateur au groupe BOINC** : Si l'erreur persiste, essayez d'ajouter votre utilisateur au groupe `boinc`. Cela peut aider BOINC Manager à lire les fichiers nécessaires. Utilisez la commande suivante :

Code Sélectionner Étendre

sudo usermod -aG boinc, votre_nom_utilisateur

4. **Utilisez le mot de passe manuellement** : Si le fichier `gui_rpc_auth.cfg` est vide ou corrompu, vous pouvez essayer de fournir le mot de passe manuellement lorsque vous lancez BOINC Manager. Utilisez la commande suivante :

Code Sélectionner Étendre

boincmgr --password=votre_mot_de_passe

Essayez ces étapes et voyez si cela résout le problème. Si l'erreur persiste, il peut être utile de consulter les forums BOINC ou les dépôts GitHub pour des solutions spécifiques à votre version de Debian et de BOINC.

[JeromeC]

L'IA m'a donc mis sur la piste avec le point 3, j'ai réalisé que contrairement à ce que je disais en lançant dans le terminal 'boinccmd --get_state' j'avais la même erreur en haut sur la lecture de gui_rpc_auth.cfg sauf qu'il affichait quand même du texte dessous et ça faisait remonter l'erreur que je n'avais pas vu (et la VM est dans une petite fenêtre)

ET surtout dans le texte de l'erreur elle même il écrit qu'il faut aller voir là https://boinc.berkeley.edu/gui_rpc.php ! et là ils disent

'Can't be read' errors

If you get an error message like gui_rpc_auth.cfg exists but can't be read, the problem is file permissions. You can generally fix this by adding yourself to the 'boinc' group:

sudo usermod -a -G boinc $USER
exec su $USER

Donc je l'ai fait et donc tout marche


Quant à mon truc sur "j'ai mis le mdp dans /var/lib et il est pas allé dans /etc" bah en fait j'avais fait une faute de frappe en créant le fichier en .bfg au lieu de .cfg...

C'était bien entre la chaise et le clavier que le problème se situait


Ce qui reste malgré tout bizarre c'est que c'est bien la 1ère fois que je suis obligé de faire ce truc de me mettre dans le groupe boinc, et dans les années passées j'ai quand même mis boinc en place dans des debian pas mal de fois (sur ces VM locales, OVH, Joe...)

Mais bon, la victoire est en nous

[lepingouin]

[JeromeC]

Bon là je me remets à regarder ma VM pour faire du yafu, bientôt, et vous savez quoi ? plus rien ne marche de nouveau (sur celle que je pensais avoir réparé).

Mon sang ne fait qu'un tour : je fous tout à la benne (la VM pas mon mac) et je réinstalle la dernière debian via l'iso officielle, je reprends toutes mes notes

- galère avec l'iso standard : plein de commandes "n'existent pas" depuis le terminal, je réalise que /usr/sbin n'est *pas* dans le path par défaut, et donc rien ne marchait... ça maintenant je sais réparer, c'est OK (mais à la réflexion c'est quand même incroyable...)

- install de boinc propre : mêmes problèmes avec impossible de se connecter à boinc par aucun moyen, ce coup ci je fais direct les 2 commandes prises chez berkeley plus haut (sudo usermod -a -G boinc $USER puis exec su $USER) et là je peux utiliser bointui et boincmd

- je peux aussi me connecter via RPC depuis BoinctTasks Js sur le mac

- mais impossible de lancer Boinc Manager, il peut pas se accéder au fichier, ce qui est délirant puisque "tout le monde peut à part lui" maintenant

Donc je vais en rester là : ça me convient très bien de pouvoir gérer depuis BT sur le mac + boinctui et boinccmd fonctionnent dans la VM, mais c'est quand même dingue d'avoir tous ces problèmes sur une installe neuve / propre alors qu'avant j'avais jamais ces problèmes !

En tous cas je suis ready pour bientôt, yafu yafu

[[CSF] Christian Carquillat]

C'est fou ce parcours Dukan bâton à chaque fois qu'il faut gérer un Linux, faut pas être dyslexique ni nul en orthographe

Heureusement qu'il y a parfois du bon à l'acharnement dans l'audace, mais je reste surpris de ce que leur clean install réserve en calvaire

J'espère qu'elle va tenir sur le long terme ta bestiole

[JeromeC]

Pour un usage standard d'un ordinateur de la majorité des gens normaux qui font un usage normal (pas comme nous) je pense que ce genre de galère ne doit plus vraiment exister sur du linux (?) mais ça mériterait de définir ce qu'est un "usage normal" d'un ordinateur, qui par définition devrait permettre de faire "tout ce qu'on a envie" puisque c'est une machine programmable universelle

Mais bon il faut raison garder, ça reste "la majorité des besoins de la majorité des utilisateurs" qui dicte l'effort de développement et de stabilité de ceux qui font les OS et les programmes

Mais sinon je pense que j'ai expérimenté, en proportion du temps que je l'ai utilisé, plus de galère avec linux que sur les autres OS (dans un passé "pas trop ancien", je ne parle pas du passé des veilles versions über-merdiques de windows, ou de linux aussi d'ailleurs). Enfin je dis "les autres", mais sur macOS il est très très rare que j'ai de vrais galères (mais ça m'est arrivé)

Enfin ça doit peut-être aussi dépendre des distributions de linux dont on parle, car la force de linux est aussi sa diversité

[lepingouin]

Ces derniers jours, j'ai voulu faire une migration de Ubuntu 22.04 vers 24.04.
Résultat, ça ne boote toujours pas au troisième jour de dizaines de manips diverses et variées glanées sur le Net 
Que même certains ont jetés l'éponge et sont reviendus en 22.04, ce que je risque de faire également d'ici peu de temps.   

[JeromeC]

Si même les pingouinos professionnels sont largués alors...... 

[lepingouin]

Finalement, j'ai trouvé la cause racine 
Un bug dans la configuration du GRUB qui redémarrait systématiquement dans le BIOS.
Merci aux ceusses qui ont trouvé le bug !

[JeromeC]

Le bug que tu montres et les commentaires remonte à août 2022, c'est normal que ça n'ait jamais été résolu ?

Et archlinux et ubuntu c'est "pareil" ?

[lepingouin]

GRUB est commun aux distributions.

Ce qu'il faut faire dans l'ordre :

• Appliquer le patch ci-dessus, puis :
• sudo grub-install
• sudo grub-mkconfig -o /boot/grub/grub.cfg

[JeromeC]

Après le glop (glop), le grub (grub). A quand le gmik (gmik) ?

[fzs600]

Hello 

Pour un double boot avec un windows 11 et ubuntu j'ai dû désactiver le secureboot.
Je peut rester le secureboot désactiver ou je doit le réactivé ?

[[CSF] Christian Carquillat]

 

Psychologiquement je l'activais mais j'ai dû le couper pour un dual boot
Je ne pense pas que cela soit dérangeant de le laisser désactivé, ni risqué tant que tu ne forces pas des choses douteuses

[fzs600]

Psychologiquement je l'activais mais j'ai dû le couper pour un dual boot
Je ne pense pas que cela soit dérangeant de le laisser désactivé, ni risqué tant que tu ne forces pas des choses douteuses

Ça marche.
Merci.