Creating a Gentoo Workstation in a VMware Virtual Machine

Gentoo Linux and VMware—a perfect match!

Today I’m going to walk through the process of creating a development workstation on Gentoo Linux as a (VMware Workstation) virtual machine. This is something that I do myself with somewhat high frequency, and in a way, this page contains notes to myself so that this fairly manual process becomes a great deal less manual. Perhaps it will be interesting to you, the reader, as a Gentoo Linux installation delves deeply into Linux system-level configuration, and provides a great way to familiarize yourself with how things work.

We’re going to be building up a workstation in such a way that we could easily take it from the virtualized hardware, and restore it onto a bare-metal system. Certainly this would require a kernel reconfiguration as the drivers will be different, but there are a few choices along the way that would tie us more closely with a hypervisor that I will avoid (some of those hypervisor-centric choices make life easier, so I’m certainly not saying that they are the wrong choices).

Our workstation will be enabled on the corporate network using LDAP. Naturally, your mileage may vary, so some sections will contain placeholder settings that you will have to replace with your own specific settings. As I take down these notes, I have the following set-up:

  • I happen to be running a Windows 7 host with VMware Workstation 12.0. The host OS hopefully shouldn’t matter.
  • My corporate network supports LDAP user accounts, Windows domains, and LDAP auto-mounted file-shares.
  • I am running on a 4 year old machine with a slightly under-powered graphics card, which will come into play below.
  • I’ve got 8 CPU cores to play with, and 18GB of RAM, so I’m basically going to have a lot of processing power left after I create my VM.

Now, let’s get into it!

Creating the VM

The first step is to gather our installation media. Gentoo images may be found here. We will use the x86_64 (a.k.a, amd64) “Minimal Installation CD” to proceed.

Create a new VM with the following settings; the points below should mirror the virtual machine creation wizard:

  • Workstation 12.0 support. You could probably get away with less, as I’m not using massive scale or EFI.
  • Select the ISO image from Gentoo for your installer image. This manifests in the VM as a CD-ROM in the drive.
  • There is no reasonably recent Linux kernel available for the “Select a Guest Operating System” screen, so go ahead and pick whatever 64-bit Linux flavor amuses you. This is really just for VMware Tools installation, which would be nice, but we have other options that work with the 4.x Linux kernel.
  • We’re going to do a 4 processor (1 core per processor) system with 8GB of RAM to start. Prefer processors to cores because this lets vNUMA do its thing. I have, however, run similar machines with 1 CPU and 4 cores, without noticeable degradation.
  • Use a bridged network connection to more adequately simulate a physical workstation.
  • We may as well use the SAS SCSI connector rather than the parallel one, as it appears some OSes (Windows) are considering dropping support for the non-SAS SCSI. The default SATA connection is fine, as well, and won’t affect any of the instructions to come.
  • For Gentoo, 32GB is more than enough for the entire system (the final image with everything described below takes about 16GB), so that will be our disk size. We can always add disks later for development space, and other applications.
  • Before exiting the wizard, “customize” the hardware. Specifically, go to the USB controller, and bump it up to USB 3.0. Go to the “Display” screen, and enable 3D graphics acceleration, and (if desired) specify monitor settings.

Once we’ve created the VM, go back and edit the settings. Now we have options to modify…

  • Use the “Enhanced keyboard” if available.
  • Report the battery information if you have a laptop.
  • Enabling VNC might be useful if you’re running Linux and don’t want to bother with a lot of server-side set-up.
  • Don’t bother with time sync—we’ll just use NTP and pretend like we’re running a physical server.
  • You can select “Boot with EFI instead of BIOS” in the “Advanced” settings. We will not do this, mainly because the current physical hardware around my office uses BIOS. Selecting EFI will also change how the kernel should be configured, so be warned. Supposedly UEFI only allows FAT32 for the boot partition’s file-system, which is pretty unacceptable as well.

Booting Into the Installer

Let’s power this bad-boy on!

If you encounter a message about not being able to use 3D acceleration, you may have a graphics card on your host that doesn’t support the latest-and-greatest version of DirectX. Now you have to go into your VM’s VMX file, and add the following (power off the machine, and close it in the Workstation UI first):

In older versions of VMware Workstation, you shouldn’t see a problem, but recently (v12) the graphics rendering has been re-worked such that my aging hardware needs this work-around.

After powering on, you should have booted cleanly into Gentoo’s minimal OS. First, we will want to set up SSH access because the Linux console is quite slow and can actually block commands’ execution while waiting on stdout. Of course, connecting to SSH also lets me copy from this page into the terminal.

  • Update your root password to something memorable (passwd root).
  • Check with /etc/ssh/sshd_config that the PermitRootLogin option has been set to yes.
  • Run: /etc/init.d/sshd start
  • Check your IP (with “ifconfig” or “ip addr”), and now you can access the VM with SSH.

Now it’s time to bust out the old Gentoo Handbook (for AMD64). This is the canonical (and quite well detailed) instruction manual for how to install and set-up Gentoo. It explains what we’re doing here in less terse (but also less specific) verbiage.

Setting Up Disks

Master Boot Record (MBR) is fairly straightforward to set-up with fdisk, but GUID Partition Table (GPT) allows partitions larger than 2TB, so we’ll use that. Note that Windows will not boot in BIOS mode if it sees a GPT label, so dual boot would not be possible on a physical box with Windows and Linux. This is not a concern for us—especially with virtual machines where we could just create a virtual Windows installation instead of a dual-boot.


We’re aiming for a disk layout like this:

Potential File-system Layout
Mount Point Size FS Device Notes
/boot 256MB ext2 /dev/sda1 Only contains kernel and bootloader.
(swap) 2GB swap /dev/sda2 Ideally, match the RAM size.
/ 1GB ext4 /dev/sda3 Basic system functionality here.
/opt 2GB ext4 /dev/sysvg0/opt Useful for manual installations.
/tmp 1GB ext4 /dev/sysvg0/tmp Temporary space.
/usr 16GB ext4 /dev/sysvg0/usr Majority of application data.
/var 6GB ext4 /dev/sysvg0/var Logs and so on.
/var/tmp/portage 16GB ext4 /dev/datvg0/bldtmp0 Useful for building large packages (LibreOffice, Firefox).
/stgdev ??GB ext4 /dev/datvg1/stgdev0 Whatever space required for development.

Notice that we’re calling for at least three Logical Volumes—sysvg0, datvg0, and datvg1. The sysvg0 volume contains the system, and will occupy the 32GB disk that we’ve allocated. For datvg0 (intended to hold temporary, large-size data) and datvg1 (intended for development file-systems), we’ll leave the disk backing as an exercise for the reader. What we haven’t listed here (and we will get to it next) is that the GRUB boot-loader needs a dedicated partition for its bits with GPT (not MBR, though)—just 1–2MB will be fine, and its not mountable, so not worth adding to the table.


The first thing we need to do now is set up the disk drives and file systems.


Run “parted -a optimal” on your disk (likely /dev/sda).

  • Create the label: mklabel gpt
  • Create the partitions:

You will notice that the numerical IDs for the GPT partitions correspond exactly to what the kernel adds to the /dev directory. Since we edited /dev/sda, the device for BOOT0 will show up as /dev/sda1.

I’d like to throw in the following flags, but they don’t seem to be implemented. Perhaps they are only for UEFI.

Now let’s create the Logical Volume Manager (LVM) set-up. I love LVM—especially for VMs because creating a virtual disk is as difficult as writing a new file to the host’s file system. This means if I’m running out of space, I just add another disk with what I need and LVM gives the flexibility to expand my undersized file-system.

  • First we’ll add the physical volume to the system: pvcreate /dev/sda5
  • Next, create the Volume Group: vgcreate sysvg0 /dev/sda5
  • Finally, we will create the logical volumes as follows:

Now, let’s make the file systems:

I give them labels, but I never really use the label. You would specify this instead of the device name in /etc/fstab, which would make things more tolerable to device name changes. Also note that I haven’t really specified many file-system options. The ext4 file-system is good at analyzing a disk partition and selecting reasonable defaults for performance.

Now that we’ve created all the storage, it’s time to actually mount and use it. This is a skeletal layout of what our new system will look like, and we’re about to drop real files onto these file-systems.

Installing Gentoo Staging

Now that we have persistent storage, we will put down a snapshot of a basic OS. From this snapshot, we will be able to compile packages, and ultimately install the software we really want to run.

Just to be safe, let’s give the clock a quick update. I’m going to:

  • Set the time-zone to my local one: export TZ=EST5EDT
  • Set the time: date MMDDhhmmYYYY

Download the images as described in the Gentoo Handbook. Make sure the following file lives under your /mnt/gentoo directory. There used to be a few, but as of this article, there is only stage3-amd64-YYYYMMDD.tar.bz2 (from “releases/amd64/autobuilds/current-stage3-amd64”).

Now extract the “stage” archive:

Now that we have a basic system on the disk, we should put down an /etc/fstab. It will look something like this:

Building A New System

Since we have finished with the disks, we can start to make the system real. The first thing we do is configure the system-wide settings that will be used to build everything. Edit etc/portage/make.conf, and make it like this:

Beware of the compiler option, “-fno-stack-protector”. It’s probably best to leave it out, frankly, as I’ve just kept it here because of a naïve perception of reduced performance that is based on nothing. Also, strip down LINGUAS to whatever languages you prefer.

Now do:

Since your network admin may block rsync traffic, you may wish to edit gentoo.conf so that sync-type is set to “webrsync”, and comment out sync-uri.

Entering the New System

Now we’re going to chroot into the new system so we can begin manipulating it from there. Perform the following steps to bring all the data from the installer’s environment into our new system:

Now enter your system:

Rebuilding the Stage

First, let’s unmask some really interesting packages. Create the following files with the following content:

  • /etc/portage/package.accept_keywords/clang
  • /etc/portage/package.accept_keywords/compiz
  • /etc/portage/package.accept_keywords/emacs
  • /etc/portage/package.accept_keywords/firefox
  • /etc/portage/package.accept_keywords/gcc
  • /etc/portage/package.accept_keywords/gdb
  • /etc/portage/package.accept_keywords/open-vm-tools (this is our substitute for the VMware Tools that come with Workstation)
  • /etc/portage/package.accept_keywords/tcsh (it seems the current unmasked version of this doesn’t actually run with a newer GCC)
  • /etc/portage/package.accept_keywords/xf86-video-vmware (which would need to be something else if we move this Gentoo system to bare-metal)

Accept some licenses by adding this to /etc/portage/package.license:

Customize your USE flags for individual packages. Ideally, this would be in /etc/portage/package.use/ in a file by the same name as the package being customized. I’m showing them all together for brevity:

Add to /etc/portage/package.mask/autofs because the latest version crashes:

Because Clang has a top-of-tree package, let’s mask it to pick only the latest release version. Create /etc/portage/package.mask/clang with:

Configure the locales. If you don’t do this, GLIBC builds a bunch of (about 500) language catalogs that you’ll probably never use, and this takes a while. I narrowed mine down to this (by editing /etc/locale.gen):

Now just run this to regenerate the catalogs: “locale-gen”. Run “eselect locale” to choose your default LANG setting.

Since we’ve bumped up the GCC version, we should probably just rebuild GCC now, and then we can have all our system built against it (in our case, it’s the difference between a 4.x GCC and 5.x, so it’s a more interesting difference).

Let’s just rebuild everything now that we’ve switched an important component. This is totally optional because we’re just making sure all the pre-installed packages use our new GCC with custom -march flag.

Setting Up A Basic System

Before we go on, let’s set the root password. We don’t want to forget, and have to boot into the installation CD just to get some known credentials on the system when we’re done: passwd root


Let’s install a kernel for the new OS. This takes us one step closer to being able to boot into the real system instead of the installation CD.

  • Run this to download (and install) the kernel sources: emerge gentoo-sources
  • I have a minimal kernel configuration file that allows us to boot into Linux on a VMware Workstation VM. Copy this file to .config in /usr/src/linux/. Unfortunately, I have lost the complete steps of what options to change, but the kernel’s build system should be able to upgrade an older configuration file like this one here.
  • Run “make menuconfig” to make any last minute changes.
  • Build the kernel: make -j5
  • Install kernel modules in their permanent home: make modules_install
  • Now we can put the kernel executable where the boot-loader can find it (make sure /boot is mounted): make install
  • Get rid of all the build objects unless you plan on rebuilding soon. They take up a bit of disk space: make clean


Now we install the boot-loader. I’m selecting GRUB2.

  • Install the support applications: emerge grub
  • Now install the boot-loader to your bootable disk: grub2-install /dev/sda—if you get a warning saying “this GPT partition label contains no BIOS Boot Partition”, you have forgotten to “set 4 bios_grub on” in parted.
  • Edit /etc/default/grub, and set the following options (the last two just make things prettier, really):
  • Now we just create the config that the boot-loader uses into /boot: grub2-mkconfig -o /boot/grub/grub.cfg

Time Zones

Set the time zone for our new machine—I’m in Cambridge, MA (USA), so I do:


To make sure we have networking support when we start the new OS, we will change /etc/conf.d/net. First, provide all the silly names that the kernel has come up with over the years:

These symlinks are for init, which will use different configuration settings based on the name of the script that was invoked. Most recently, the ethernet interface has been “eno16777736”, so that’s likely the only link we’ll really need.

Now edit /etc/conf.d/net to set up a basic DHCP configuration (if you have information for a static network configuration, go ahead and do that instead of DHCP):

Installing Useful Packages

Next, we will install some important (non-graphical) packages. These are basic things like sudo and VMware Tools, as well as things that Gentoo lets you choose, like a cron, syslog, and DHCP client implementation.

You will probably need to stuff a few more files into /etc/portage/package.use/ as a result of the “--pretend” dry-run. Once you are satisfied, go ahead and install these items.


Setting up syslog-ng to do log rotation is pretty easy at this point, since we’ve just installed the logrotate tool. All the work in cron has been taken care of for us, so we just edit /etc/logrotate.d/syslog-ng, and change the section like so:


We should configure the tools we’ve installed so far by customizing what’s located in /etc/conf.d/. We will change the host name, domain, and so on. Make the following changes in the following files:

  • ./consolefont: consolefont = "Lat2-Terminus16" (this is a bit less chunky, but the same size as the kernel’s font, so it will be nicer to look at on the plain console)
  • ./hostname: hostname = "my_host01"
  • ./ntp-client: NTPCLIENT_OPTS="-s -b -u ntp_server1 ntp_server2"

Change /etc/issue and /etc/issue.logo from “\O” to “\o”, since the original command rarely contains reasonable output. This is the file the system uses to display a nice welcome message when someone gets a console.

Configuring SMB is slightly more complicated, but not too bad. Some things to note—for my network, I get users and groups from LDAP, so SAMBA should know how to acquire this information as well. If your domain is “”, your LDAP suffix will be “dc=mydomain,dc=foo”. Replace “” with a proper LDAP FQDN.

  • First, create a basic configuration: cp /etc/samba/smb.conf.example /etc/samba/smb.conf
  • Now, edit /etc/samba/smb.conf, add or change the following settings:

Add this to the end of the file to share your development area.

If you are OK with the root account logging into the machine with SSH, you can edit /etc/ssh/sshd_config to set “PermitRootLogin yes”. Most likely, you will log in with a normal user account that can escalate its privileges, so you won’t need to do this.

Customize the “eselect” items. The eselect tool alters system-wide settings on Gentoo for any packages that register with the tool. We will want to check back with this subsystem at various points, so familiarize yourself with it if you have not used it. Most eselect modules support basic list/set/show functionality. Run through the items now (there are only a few) and customize what you like. This is highly dependent upon what’s on your system, so I won’t bother writing down exact command invocations.

Creating a Local User

Create local user so you can still get into the system if LDAP fails you for some reason. Root access is not always available for various window managers or services.

Add this user to the wheel group so it can become super-user when needed. Add it to some privileged groups as well, like: floppy, audio, cdrom, tape, video, cdrw, usb, users, and portage. In fact, you probably want to think about adding any user that you wish to be “administrators” to these groups.

Start Services

Now, let’s add important services to the appropriate run-level so the start after boot-up:

Setting up LDAP

The development workstations at my place of business are a lot more usable when they are set up on LDAP. This way, we can use our account and credentials that are known across the corporate infrastructure, as well as have AutoFS access to network file-systems without hard-coding them in /etc/fstab. Let’s do this before moving on to more complicated pieces of software (read: “the GUIs”).

Find out your local LDAP information. For me, I will be using TLS with certificate-based authentication of the LDAP server, and the following hosts server up LDAP(S) on port 636: and

Install the LDAP support for Pluggable Authentication Modules (PAM) and Name Service Switch (NSS) as well as the AutoFS service. Note that AutoFS 5.0.7 does not build with GCC 5 apparently, so you may have to unmask a later version (also, only 5.5.1 worked for me, as 5.5.1-r2 actually crashed when attempting to mount a file-system)!

Next, we have to grab the certificate to validate the LDAP servers.

Edit /etc/pam.d/system-auth (order matters):

Edit /etc/ldap.conf, and remove all settings except for the following ones (use your own local LDAP server where applicable):

Edit /etc/openldap/ldap.conf—this is basically the contents of the entire file (note that changing the password is not allowed on my set-up, so I give a helpful message):

Edit /etc/nsswitch.conf, changing the following settings (ignore the others):

Edit /etc/autofs/autofs_ldap_auth.conf to enable TLS. The settings might already be this way:

Finally, edit the AutoFS configuration (/etc/conf.d/autofs). Some of the settings below are left as comments in the configuration because they match the defaults, but they’re still important to know. Similar settings exist in /etc/autofs/autofs.conf, if you prefer to make the changes there:

Now just enable AutoFS on boot, and test that you can talk to LDAP.

Power Off

Let’s reboot and see if the system actually comes up before we take a snapshot. Reboot (even from your chroot environment is fine). If the system doesn’t come up how you like, fix the errors and reboot until it does. After you’ve done all that, it’s smart to power off the VM and take a snapshot (or clone). This can be the base system for any future customizations, like using X, making a web server, etc.

Making A Development Workstation

Let’s make the bare-bones Linux installation a bit more useful. Up to this point, we could have gone in the direction of making a mail server, a Bugzilla site, or whatever. Now we’re going to install a UI and make this more functional as a development workstation. All of this is optional, so feel free to skip any of the below.

Installing X Windows

First, update your USE flags to enable some important settings. We’re slowly adding these flags as we build up the system, so you might end up building packages more than just once throughout the course of installation. This is OK as far as I’m concerned, because I’d rather have a locally-consistent set of libraries and utilities the entire time, rather than save myself 30 minutes of compilation. It’s all a choice, though—if you’re still with me, edit /etc/portage/make.conf accordingly:

Add some more per-package USE flags that facilitate installing the new packages given the new settings (again, preferably in their own file):

Now install Xorg. The new USE flags will make sure everything gets included.

Xorg should be able to automatically configure itself and run, but I prefer to explicitly specify devices, as well as a 1920×1200 screen size to match my physical monitor. Drop this file into /etc/X11/xorg.conf to achieve that. Since you’re currently running in a virtualized Gentoo installation, the VMware graphics drivers provide tons of monitor options, meaning that skipping this step is totally reasonable.

Install some more fonts… why not?

Looking at the 60-latin fontconfig file, we can see that the system prefers some fonts by default:

Make sure to at least install media-fonts/dejavu or media-fonts/ttf-bitstream-vera (included in the command above), because Luxi Sans is a really ugly choice for a bold-face font (which KDE uses a bunch).

You probably want to enable sub-pixel hinting for your fonts and the Liberation font package. Do this with “eselect fontconfig”. The options may be different, so I won’t list them here, but I’m selecting “10-sub-pixel-rgb.conf” for my sub-pixel setting. This same eselect module enables various fonts—be sure to enable the fonts you just installed (if they are not enabled by default).

If you’re content to just run basic X Windows with the TWM window manager, you can add the display manager to your runlevel, and stop here:

You’ve installed X. Doesn’t it seem like a good time to power down and take another snapshot?


Apparently KDE versions 4 and 5 cannot live alongside each other, so you have to choose if you want the old (KDE4) or the new (Plasma). The next two sections should be considered mutually exclusive.

At any rate, you will want to finish populating your USE flags in /etc/portage/make.conf like so:

Once you’ve done this, run “eselect profile list”. What you choose here will determine if you do KDE4 or Plasma (the next sections mention exactly what to select). Choose wisely.


Great, we’re going with KDE 4, which is a solid, nice looking desktop environment. As you will see below, we can even through Compiz into the mix to add eye-candy to an already fairly decent situation. Select “default/linux/amd64/##.#/desktop/kde” as your profile.

Provide /etc/portage/package.use/cmake to disable something pointless that causes circular dependencies:

Throw in PIM support if you’re interested. The desktop widgets already support it. In /etc/portage/package.use/kde-meta:

Now install everything (this could take a while—like hours): emerge --pretend --deep --with-bdeps=y --newuse kdebase-runtime-meta kde-meta

Once everything has fully installed, modify your /etc/conf.d/xdm file to use the KDE login and display manager by setting “DISPLAYMANAGER="kdm"”.

If you don’t care about preventing root from logging in, edit /usr/share/config/kdm/kdmrc to set “AllowRootLogin=true”. Remember that you can cause some damage with this, so it’s probably best that you just log in with the local user you created earlier and run individual commands as the root user. This mirrors our discussions about SSH.

Once you log in, you can customize all kinds of features like multiple desktops (which I can’t live without) and point-to-focus.


Well, you’re done with KDE4, so now you can (optionally) add some graphical toys. Compiz lets you manifest multiple desktops as the sides of a cube, set tool-tips on fire, and so forth. Its window manager, Emerald, also has some non-superficial customizations as well. When I have a graphics card capable of acceleration, I prefer this over basic KDE. You can configure absolutely everything in Compiz, even to the point of making it provide you absolutely no functionality whatsoever(!).

Compiz is considered the “old way” so it’s worth taking a snapshot of your VM before installing in case things go sideways and you just want to skip it.

Install the packages. We already configured the system (by default, Compiz is masked), so this should just work: “emerge --deep --with-bdeps=y x11-wm/compiz-fusion”. Note: I had to download compiz-plugins-unsupported-0.8.8.tar.bz2 from another machine because it wasn’t online (but you can get it from me).

Before continuing, you probably want to open a terminal window just in case something goes wrong with the next bit. Once you have installed, enable Compiz to replace KWin as the window manager. To do this, in the KDE System Settings application, navigate to “Default Applications” → “Window Manager.” Here you can select Compiz as your different window manager.

Remember how we opened a terminal before starting Compiz? On the console, you might have to just type “emerald” to get some sane behavior. If you can’t seem to get to the Compiz settings from the KDE menu, the command is “ccsm”.

Check off all the reasonable boxes (everything is off by default, even window borders).

  • “KDE Compatibility.”
  • Enable “Window Decoration,” and set the “Command” to “/usr/bin/emerald --replace”.
  • Enable “Desktop Cube,” because otherwise, what’s the point?
  • Enable “Rotate Cube”—change the “Initiate” setting to be something without a Ctrl+Alt, as some versions of VMware claim this key combination.
  • Enable “3D Windows” because this makes your Desktop Cube look a little cooler.
  • Enable “Minimize Effect,” “Move Window,” “Place Windows,” and “Resize Window,” because these are all basic operations that one expects.
  • Shift Switcher—change Next and Previous Window settings to use Alt+TAB.
  • Enable “Workarounds”—particularly the “Fix screen updates in XGL with fglrx” as it fixes some bad redrawing issues.
  • I also like “Session Management,” “Minimize Effect,” and “Resize Info.”

Welcome to your loud-and-proud Compiz desktop. Enjoy!


Eventually, KDE4 will be dropped from support in Gentoo, and the next generation (i.e., “KDE5”) will be the Plasma Desktop. Follow these steps to use the latest and greatest version of KDE.

First, select “default/linux/amd64/##.#/desktop/plasma” as your profile. This automatically installs everything we need on our next emerge.

Now, let’s make some appropriate changes to the USE flags for Plasma, by adding the following to /etc/portage/package.use/kde-plasma:

Installing Plasma now means just a “world” emerge:

Now that everything is installed, we probably want to use Plasma’s display manager. The KDE4 managed, kdm no longer exists, and has been replaced by sddm. Alter /etc/conf.d/xdm to read “DISPLAYMANAGER="sddm"”.

Annoyingly, SDDM does not simply proceed without a configuration, so run the following before starting your X server:

That’s it! Now you’re ready to get computing with the latest KDE environment.

What Else to Install?

Now that you’ve got a pretty basic set-up with a desktop environment, it’s time to decide what you want to run.

Gentoo packages

Here are some useful packages that I install. Installation should be fairly effortless:

  • app-doc/doxygen
  • app-emacs/ebuild-mode
  • app-text/enscript
  • app-text/texlive
  • dev-lisp/sbcl
  • dev-util/global
  • dev-vcs/git
  • media-gfx/graphviz
  • net-ftp/ncftp
  • net-im/pidgin
  • sys-devel/clang
  • virtual/emacs
  • x11-plugins/pidgin-sipe

Building the browser is time-consuming, so I’m doing that last.

  • www-client/firefox—this requires larger /var/tmp/portage, so if you set up a data volume group, it’s always nice to have an 8GB partition laying around to have temporary build space.
  • www-plugins/adobe-flash

I used to always install app-text/acroread, but it requires all sorts of x86 compatibility garbage, so beware—Okular does the same job, and is installed with KDE already.

Non-Gentoo packages

There are a few packages outside Gentoo’s package management that will be useful. Let’s talk about those.


Some people use Java. Some people use Eclipse. Some people use Eclipse with Java. I don’t personally do much in Java, but it seems like something reasonable to have on a developer’s workstation.

To use Eclipse, you obviously need a Java Runtime Environment (JRE). By default, Gentoo uses the OpenJDK (code-name: “icedtea”) in a binary format. Installing the binary JRE distribution is as simple as emerging virtual/jre, but I prefer to build what I can from source. I will say that building the JDK requires more than 8GB of disk space, so it’s not a quick task—a binary distribution is quite reasonable.

Get ready to install the JDK you want by creating a file like /etc/portage/package.accept_keywords/jdk:

Unfortunately, building the JDK from source requires ANT, which requires a JDK, so we have a circular dependency. First we install the JDK with a binary distribution, then install the JDK we want (from source), and finally go back and clean out the binary version.

Next we should edit the JDK build configuration to specify that we’re using icedtea instead of icedtea-bin. Edit /etc/java-config-2/build/jdk.conf, and add the following:

Now clean out the binary distribution: emerge --pretend --deep --with-bdeps=y --depclean

Now that our JRE dependency has been satisfied, we can download Eclipse.

For some reason eclipse packages everything under an “eclipse” directory, so if you already have one in place, you’ll have to move it aside. When the coast is clear, you’re going to drop it into the /opt directory. Unpack the archive you downloaded into /opt, and rename it to something version specific:

Perforce (Helix)

In case you haven’t noticed, Perforce has been renamed to Helix. Go to the download page, and get the Helix P4V Visual Client and Helix P4 Command Line. Then we’re just going to drop them into /opt and make symlinks in /usr/local.


Here are some steps to take when things go wrong.

Booting Into the Installer Again

You’re in the middle of installing the OS, and you rebooted, but the system isn’t actually coming up. Plan B is to head back into the installer’s minimal OS, and make modifications to things from there.

  1. Power on the VM and go into the BIOS screen. You need to set the CD-ROM drive ahead of the hard disk in order to boot back into the installation media.
  2. If you’re going to enter the OS through SSH, you may want to sort this out before entering a chroot environment. This is optional (and listed above).
    • Update your root password to something memorable (passwd root).
    • Check with /etc/ssh/sshd_config that the PermitRootLogin option has been set to yes.
    • Run /etc/init.d/sshd start.
    • Check your IP (with “ifconfig” or “ip addr”), and now you can access the VM with SSH.
  3. Set up the LVM:
  4. Chroot into the new environment.
  5. Mount all the disks. “mount -a” should do the trick, but you may need to mount each one by name. Check with /etc/fstab if you can’t remember.
  6. When you are about to shut down, it’s nicer if you do an “umount -a” as well.
  7. Don’t forget to set the boot order back so that you don’t boot from the installation CD.

Taking a Simple Back-up

Let’s say you need to totally reconfigure your disks for some reason. The simplest thing to do would be to save off your data somewhere else, destroy your partitions, and recreate them. This becomes easy with a virtual machine.

Boot the installation CD. We don’t want to have any of the system disks being busy when we read / write.

  • First, create a new disk that’s large enough to back up your files.
  • Now run “parted -a optimal /dev/sdb” (assuming /dev/sdb is the disk you just added).
  • Format: mkfs -t ext4 /dev/sdb1
  • Make a mount point and mount the “backup” area (we’re making a mount point for the “source” of the back-ups as well):
  • Do backups:

Re-partition all your disks how you like them…

Now, we can just restore what we backed up:

You might need to chroot into the restored environment to re-install GRUB and re-write its configuration file.

Leave a Reply

Your email address will not be published. Required fields are marked *