Qu’est-ce que j’ai écrit plus haut entre parenthèses concernant su ?
Sans - l’environnement root est incomplet.
si je rajoute - il ne trouve pas la commande c’est pour ça que je ne l’utilise pas
et sans il me dis très clairement que je suis passée en root et la ligne est suivie de # a la fin, j’estimais la manip correcte
A toutes fins utiles:
$ echo $path # sbin n'est pas dans le path user
# echo $path
/usr/local/sbin /usr/local/bin /usr/sbin /usr/bin /sbin /bin
/usr/sbin/dpkg-reconfigure
Il me dis que /usr/local/sbin est un dossier, pour le moment ok mais que j’ajoute la commande suivante il demande a nouveau d’indiquer le paquet à reconfigurer alors que je lui envois clairement la destination
Ne jamais exécuter dpkg en forçant son chemin dans un environnement root incomplet sous peine d’erreurs lorsqu’il appelle des commandes externes qui ne sont pas dans le $PATH !
Avec un(e) espace entre « su » et « - » comme je l’ai écrit ? M’étonnerait.
Restriction imposée au nouveaux par le forum. Profite-en pour relire la discussion à tête reposée.
Si besoin, envoie un message privé.
1 J'aime
Bonjour
Alors pour répondre à ceci
Et bien si ça fonctionne mais ça change le nom root, quand je tapesutout simple dans le terminal la ligne est suivie de root@id:/home/id#
Alors qu’avec su - j’ai root@id:~# je pense qu’il y avais une sorte de 2 « types » de root, je me trompe ?
Non, c’est normal. Sans -, su te laisse dans le répertoire courant (/home/id) alors qu’avec - su te met dans le répertoire personnel (noté ~) de root (/root).
Revenons au plus important : est-ce que dpkg-reconfigure gdm3 a réactivé le gestionnaire de connexion graphique au démarrage ?
PS : apparemment tu as donné le même nom « id » à la machine et à l’utilisateur. C’est une mauvaise idée, source de confusion.
EDIT : en comparant avec la photo d’écran postée plus haut, j’ai plutôt l’impression que tu as maquillé ces informations sans le dire. C’est également source de confusion.
Il n’y a qu’un et un seul compte root.
le différence c’est le répertoire ou tu te trouves :
Quand tu lance ta console par le lanceur représentant une fenêtre, tu es alors sur le ton compte :
Gv_Froggy@id: ~$ :
Gv_Froggy = ton compte utilisateur.
id = nom de ton ordinateur
~ = c’est un alias qui signifie « ton home » = /home/Gv_Froggy
Puis tu te log en root , le système reste où il était dans l’arborescence, mais ce n’est pas le « home » de root, donc il indique :
root@id : /home/Gv_Froggy : #
Édit :
chez toi Gv_Froggy = id
1 J'aime
OK, désolée je ne savais pas comment décrire autrement -w-"
Par contre, par rapport a cette commande il me dis gdm.service is not active, cannot reload.
et à la suite invoke-rc.d: initscript gdm3, action "reload" failed.
J’avais demandé la sortie de « systemctl status gdm3 », il ne me semble pas avoir vu la réponse.
Tu peux ajouter la sortie de
systemctl status display-manager
cat /etc/X11/default-display-managerj’ai un retour gdm.service - GNOME Display Manager Loaded: loaded (/lib/systemd.system/gdm.service; static) Active: inactive (dead) déc. 16 11:06:10 GV_Froggy systemd[1]: gdm.service: Unit cannot be reloaded
@PascalHambourg je dois patienter 7h maintenant-w-
résultat de la commande :
The unit files have no installation config (WantedBy=, RequiredBy=, Also=,
Alias= settings in the [Install] section, and DefaultInstance= for template
units). This means they are not meant to be enabled using systemctl.
Possible reasons for having this kind of units are:
• A unit may be statically enabled by being symlinked from another unit's
.wants/ or .requires/ directory.
• A unit's purpose may be to act as a helper for some other unit which has
a requirement dependency on it.
• A unit may be started when needed via activation (socket, path, timer,
D-Bus, udev, scripted systemctl call, ...).
• In case of template units, the unit is meant to be enabled with some
instance name specified.
Et les deux autres commandes ?
Que donne
systemctl enable gdm
?
résultatq de la commade
The unit files have no installation config (WantedBy=, RequiredBy=, Also=,
Alias= settings in the [Install] section, and DefaultInstance= for template
units). This means they are not meant to be enabled using systemctl.
Possible reasons for having this kind of units are:
• A unit may be statically enabled by being symlinked from another unit's
.wants/ or .requires/ directory.
• A unit's purpose may be to act as a helper for some other unit which has
a requirement dependency on it.
• A unit may be started when needed via activation (socket, path, timer,
D-Bus, udev, scripted systemctl call, ...).
• In case of template units, the unit is meant to be enabled with some
instance name specified.
Je ne vois toujours pas le résultat des deux autres commandes.
● gdm.service - GNOME Display Manager
Loaded: loaded (/lib/systemd/system/gdm.service; static)
Active: active (running) since Sun 2023-12-17 00:08:49 CET; 9min ago
Process: 740 ExecStartPre=/usr/share/gdm/generate-config (code=exited, stat>
Main PID: 769 (gdm3)
Tasks: 3 (limit: 3856)
Memory: 10.7M
CPU: 172ms
CGroup: /system.slice/gdm.service
└─769 /usr/sbin/gdm3
déc. 17 00:08:49 adascomputer systemd[1]: Starting gdm.service - GNOME Display >
déc. 17 00:08:49 adascomputer systemd[1]: Started gdm.service - GNOME Display M>
déc. 17 00:08:49 adascomputer gdm-launch-environment][777]: pam_unix(gdm-launch>
déc. 17 00:09:06 adascomputer gdm-password][1429]: gkr-pam: unable to locate da>
déc. 17 00:09:06 adascomputer gdm-password][1429]: gkr-pam: stashed password to>
déc. 17 00:09:06 adascomputer gdm-password][1429]: pam_unix(gdm-password:sessio>
déc. 17 00:09:06 adascomputer gdm-password][1429]: gkr-pam: unlocked login keyr>
Apparemment gdm est démarré et actif. L’écran de connexion graphique ne s’affiche toujours pas au démarrage ?
maintenant oui il s’affiche
Donc problème résolu ? Si oui, l’indiquer avec la case à cocher correspondante.
1 J'aime