After updating /etc/profile with some environment variables for installing a package like eclipse and restarting the machine I am getting the following error when logging in as ‘root’ in the GNOME dialog box;
“Could not connect to session bus. Failed to execute dbus-launch to auto-launch D-Bus session”
My profile seems to have been screwed up
How can I revert to a previous profile or a default one to get back in ?
I have tried to do a system repair with the installation disk but no avail…
What can I try in ‘rescue mode’?
Am using SLES11sp3
/etc/profile
When I wanted to edit this file - I noticed that it mentioned about swap space and prompted if I wanted to edit or just read the file , I selected edit…
In general where is the best place to modify environment variables??
Hi
If you press ctrl+alt+F1 to get to a VT (virtual terminal), login as
root user and force the re install of aaa_base which
contains /etc/profile
zypper in -f aaa_base
Normally you tweak your own ~/.profile file with these sorts of things,
if it needs to be system wide then you would modify the one in /etc
after a backup is made
–
Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890)
openSUSE 12.3 (x86_64) GNOME 3.8.4 Kernel 3.7.10-1.16-desktop
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…
[QUOTE=malcolmlewis;15719]Hi
If you press ctrl+alt+F1 to get to a VT (virtual terminal), login as
root user and force the re install of aaa_base which
contains /etc/profile
zypper in -f aaa_base
Normally you tweak your own ~/.profile file with these sorts of things,
if it needs to be system wide then you would modify the one in /etc
after a backup is made ;)[/QUOTE]
The preferred method to “extend” the global profile is by creating your own file(s) in /etc/profile.d - see the following segment from /etc/profile:
[CODE]#
Source profile extensions for certain packages, the super
may disable some of them by setting the sticky bit.
if test -d /etc/profile.d -a -z “$PROFILEREAD” ; then
for s in /etc/profile.d/*.sh ; do
test -r $s -a ! -k $s && . $s
done
unset s
fi[/CODE]
That way, local changes will even survive the update of the aaa_base RPM And of course, they can easily be de-activated by i.e. renaming.
And of course, they can easily be de-activated by i.e. renaming.