L'installation de paquets ne fonctionne pas correctement

Support Debian
#1

Bonjour tout le monde,

Je viens de mettre à jour mon système (réinstallation) sur un pc avec la version 12.4 de Debian.

Ayant un second disque dur interne, j’ai voulu le partitionner avec gparted.
Impossible d’utiliser gparted, que ce soit en ligne de commande ou en cliquant sur son icône.
Quand je fait un « type gparted », le résultat est « gparted : non trouvé ».
Quand je fais un « apt-get install gparted », le résultat est « gparted est déjà la version la plus récente (1.3.1-1) ».
Il se passe la même chose quand je désinstalle gparted et que je le réinstalle.

J’ai les mêmes erreurs avec fdisk et rsynk.

Par contre, installer un paquet normal, style emacs ou ffmpeg fonctionne parfaitement.

Merci pour vos réponses.
Bonne journée.

Edit : je ne sais pas si cela a de l’importance, mais dans le doute :
J’ai xfce et gnome.
Contrairement à xfce, dans gnome, un clic sur l’icône de gparted fonctionne, mais ne fonctionne pas non plus en ligne de commande.
Idem pour synaptic.

#2

gparted il faut être root pour l’utiliser.
utilise le chemin entier pour le lancer car par défaut, un user lambda na pas le path dans son $PATH.

Quelles erreurs? sot plus précis :slight_smile:
Mais ce sont usuellement des commande à faire avec sudo ou en étant root.

#3

Merci pour ta réponse,
j’utilise gparted avec un sudo (je suis dans le fichier sudoers) et en me connectant à root.
J’ai les mêmes erreurs avec fdisk et rsynk que j’ai énuméré avant avec le gparted.

Edit : gparted n’est pas sur le disque dur (type gparted → non trouvé - locate gparted → aucun résultat)

#4

Tu m’as parlé du $PATH.
Je n’ai rien ajouté, mon $PATH root est :

/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games

Est-il suffisant ?

#5

oui, c’est l’erreur
/usr/sbin/gparted
il faudrait /usr/sbin/ dans path

j’ai déjà eu ce pb , mais je ne le comprends pas totalement
selon la façon dont tu deviens root, tu as ou pas le bon PATH

un bon PATH:
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

chez moi :

sudo -s :
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

su root
/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games

su -
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

man su :
-, -l, --login
Démarrer l’interpréteur de commandes comme un interpréteur de connexion avec un environnement similaire à une connexion réelle :

   •   efface toutes les variables d'environnement, à l'exception de TERM et des variables indiquées dans --whitelist-environment ;

   •   **initialise les variables d'environnement HOME, SHELL, USER, LOGNAME et PATH** ;

   •   se place dans le répertoire personnel de l'utilisateur cible ;

   •   définit argv[0] pour l’interpréteur de commandes à « - » pour faire de l’interpréteur de commandes un interpréteur de connexion.
#6

Merci beaucoup dindoun, tu as résolu mon problème.

J’ai mis ce que tu appelles « un bon PATH » dans le .bashrc du root et je n’ai plus d’erreurs.

Merci aussi à Zargos qui m’a parlé du PATH.

Il a dû y avoir un bug à l’installation pour que le sbin soit oublié du PATH !

1 J'aime
#7

justement je ne pense pas que ce soit une erreur, il ne faut donc pas le changer ( mais bon ça marche je l’ai fait aussi sur un de mes ordis ) :

  • as tu mis un mot de passe root ?
  • ton utilisateur est-il sudo ?
  • quand tu te mets en root, utilises-tu sudo -s ( ou -i … ) ou su - ( ou -l … ) car si tu utilises su root, tu gardes ton PATH
#8

Même en root, je ne pouvais pas lancer des commandes se trouvant dans sbin, si ce n’est pas une erreur, pourquoi y mettre des dizaines d’exécutables que l’on ne peut pas exécuter en indiquant uniquement son nom ?
Peut-être question de sécurité…

Mon root a un mot de passe.
L’utilisateur est en sudo.
J’utilise uniquement sudo pour lancer une commande root en utilisateur.

Depuis que j’ai fait ma demande d’aide sur ce forum, j’ai récupéré des fichiers sauvegardés.
Comme je l’ai toujours fait, j’ai fait un lien symbolique vers un des fichiers dans mon home et celui du root pour remplacer les .bashrc. Il y a des PATH dans ce fichier récupéré, dont le sbin.
Je n’aurais pas eu ce problème si je l’avais fait avant !