On Sun, Dec 14, 2008 at 10:43 AM, M. <mbg at onsneteindhoven.nl> wrote:
> Just a wild guess here...
>
> Log in to Solaris and start the GUI Package Manager. In the Search
> input-box type, "gnome". Write down the exact names of all installed
> packages.
>
> turn off the GUI interface as system5 wrote: pfexec svcadm disable gdm
>
> If you are now able to reboot into a terminal you can start removing
> packages with the pkgrm command. For example, "pkgrm SUMWgnome-cd". You
> would have to repeat this for each and every gnome-related package, although
> some packages may be removed automatically due to dependencies.
>
> If this works and it doesn't break your install, could you let us know,
> please? I think there are more people here who would like use OpenSolaris as
> a server.
>
>
Firstly, pkgrm does not automatically remove "dependencies". It just warns
you that there are dependencies. You also don't have to run pkgrm for each
package, you can specify multiple package names on a single command.
I don't know whether the above would work, but you can safely test it easily
enough ... if you have a ZFS root.
Start by creating a new Live upgrade Boot Environment, in the examples below
I call it "sansgnome":
If you already have used Live Upgrade, then use a command like this (run all
these as root):
lucreate -n sansgnome
If you have never used LiveUpgrade, then use:
lucreate -n sansgnome -c old
Note: The above can be done if you do not have a ZFS root, but requires
additional options, as well as more disk space, and also lumake to copy the
existing boot environment.
Next, activate the "sansgnome" boot environment (BE)
luactivate sansgnome
Check the status using lustatus
$ lustatus
Boot Environment Is Active Active Can Copy
Name Complete Now On Reboot Delete Status
-------------------------- -------- ------ --------- ------ ----------
snv_102 yes no no yes -
snv_103 yes yes no no -
sansgnome yes no yes no -
Then reboot using either the "init 6" or "shutdown" commands only.
Once the new boot environment is running, you can "safely" play around with
it - disable and uninstall packages. Should things go wrong, regress to
your original boot environment by using luactivate to turn on the old boot
environment, and reboot (using init 6 or shutdown)
To get a list of all gnome related packages into a file, do this:
pkginfo | grep -i gnome > /tmp/gnome_package_list.txt
The file will list about 440 odd packages. Make a backup of the file and
remove any lines for packages you want to keep. Then use a command like
this to parse the list and remove all the specified packages (the second
word in each line is the package name:
awk '{print $2}' /tmp/gnome_package_list | xargs pkgrm
Press y for every prompt to overide the "dependancies check".
As a test I removed only the following packages:
GNOME2 SUNWgnome-base-libs GNOME base GUI libraries
GNOME2 SUNWgnome-base-libs-devel GNOME base GUI libraries -
development files
GNOME2 SUNWgnome-base-libs-java Part of Java-Gnome - Java core
bindings
GNOME2 SUNWgnome-base-libs-java-devel Part of Java-Gnome - Java core
bindings - development files
GNOME2 SUNWgnome-libs GNOME platform libraries
GNOME2 SUNWgnome-libs-devel GNOME platform libraries -
development files
GNOME2 SUNWgnome-libs-root GNOME platform libraries - /
filesystem
I then disabled cde-login (You might have to disable gdm-login in stead)
using svcadm, and rebooted. After the system came back up I logged in on
the command line, tried to "start" the cde-login, which presented me with a
login box but failed to actually log in (as I expected) - proving that Gnome
was properly broken.
Now: The proble is that many of the apps that you may want to use under
Xfce, or whatever other display manager you choose, may depend on the Gnome
Libraries. Thus you might end up not saving much disk space at all due to
having to keep the Gnome bits arround *and* having to install all the Xfce
bits in addition.
Note: If you are not using Nevada / Solaris Express, then you may not have
Live Upgrade. Live upgrade has got its days numbered. I yet have to make
time to figure out how OpenSolaris does its updates/roll backs. I need to
build my time machine now so I can make enough time to do all the things I
have on my todo list, but alas I don't have time to build it.
Note: Live Upgrade is buggy. Somtimes it doesn't update the Grub Menu.
Sometimes it fails to delete a boot environment, or or or. You are likely
going to run into some issues, and you may well end up with a system which,
when you fail back to your old boot environment, gets stuck at a SMF failure
on mounting local file systems (because some directories are "not empty",
which is tedious, but not impossible to fix.)
Note: I wrote this email in pieces, while doing the testing. Now I'm too
lazy to fix the logical following of things. Also do forgive my sloppy use
of english.
Regardless, hope this helps.
_J
--
Any sufficiently advanced technology is indistinguishable from magic.
Arthur C. Clarke
My blog: http://initialprogramload.blogspot.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/opensolaris-help/attachments/20081215/c89fb6ca/attachment.html>
