359. Installing Scientific Linux (CentOS, RHEL) via a chroot in a running debian installation

This is a fun post. I've got a small server and I'd like to put Scientific Linux on it. I figure that between using Arch on my laptop, and Debian on my beowulf cluster, my work desktop, my home desktop and on another two laptops what I really need is to become a bit more proficient in the use of RHEL clones.

I've settled on Scientific Linux since I encounter that more often than CentOS.

My mini server lacks any form of video interface though, so the easiest solution is to take out the harddrive and install Scientific Linux via a USB tether and a chroot, similar to how things are done when making standard installs of Arch or Gentoo (it's all coming together...)

In a future post I'll write up how to install debian via a running debian system and a chroot (hint: debootstrap).

Anyway.

1. Install yum on your debian system
sudo apt-get install yum

2. Set up the Scientific Linux repos for yum on your debian system
Because it's easier, we'll disable gpg check.

If you're target is a 32 bit box, change x86_64 to i386 (my little server runs a 32 bit atom cpu and I screwed this up once)

Create /etc/yum/repo.d/sl.repo

[sl]
name=Scientific Linux 6.3 - x86_64
baseurl=http://ftp.scientificlinux.org/linux/scientific/6.3/x86_64/os/
        http://ftp1.scientificlinux.org/linux/scientific/6.3/x86_64/os/
        http://ftp2.scientificlinux.org/linux/scientific/6.3/x86_64/os/
        ftp://ftp.scientificlinux.org/linux/scientific/6.3/x86_64/os/

enabled=1
gpgcheck=0

[sl-security]
name=Scientific Linux 6.3 - x86_64 - security updates
baseurl=http://ftp.scientificlinux.org/linux/scientific/6.3/x86_64/updates/security/
        http://ftp1.scientificlinux.org/linux/scientific/6.3/x86_64/updates/security/
        http://ftp2.scientificlinux.org/linux/scientific/6.3/x86_64/updates/security/
        ftp://ftp.scientificlinux.org/linux/scientific/6.3/x86_64/updates/security/
enabled=1
gpgcheck=0

Test that everything is working by running

yum repolist

sl                                                                  | 3.2 kB     00:00     
sl-security                                                         | 1.9 kB     00:00     
repo id       repo name                                             status
sl            Scientific Linux 6.3 - x86_64                         enabled: 6,399
sl-security   Scientific Linux 6.3 - x86_64 - security updates     enabled: 1,584
repolist: 7,983

It might take 60 s before you get any feedback, so don't interrupt the command.

3. Mount your external harddrive

mkdir $HOME/tmp/jail -p
sudo mount /dev/sdb1 $HOME/tmp/jail

assuming of course that /dev/sdb1 is your intended root partition (see the arch and gentoo install guides for examples of how to use fdisk)

4. Install a basic system on your mounted harddrive

sudo yum --installroot=$HOME/tmp/jail install bash sl-release coreutils yum iputils vim

5. Chroot your mounted harddrive

sudo cp /etc/resolv.conf $HOME/tmp/jail/etc/resolv.conf
sudo cp /etc/yum/repos.d/* /$HOME/tmp/jail/etc/yum.repos.d/
sudo mount -t proc none $HOME/jail/proc
sudo mount --bind /sys $HOME/tmp/jail/sys
sudo mount --bind /dev $HOME/tmp/jail/dev
sudo chroot $HOME/tmp/jail

bash-4.1# head -n 1 /etc/issue.net
Scientific Linux release 6.3 (Carbon)
bash-4.1# ping -c 1 google.com
PING google.com (74.125.237.98) 56(84) bytes of data.
64 bytes from syd01s12-in-f2.1e100.net (74.125.237.98): icmp_seq=1 ttl=51 time=16.0 ms

We are now working in Scientific Linux. Sure, we're still using the debian kernel, but everything else is from the SL repos:

First set up /etc/fstab. I normally do

blkid > /etc/fstab

and then edit it. In this case I ended up with:

UUID=45495a62-a141-4033-a739-8063f0e80a56       /       ext4    errors=remount-ro,user_xattr   0 1
UUID=6dc86d8d-0ad6-4574-8dea-9d28b0151362       none    swap    sw      0 0

Install everything we need to boot our new system and make it run:

yum install kernel openssh-clients openssh-server passwd dhclient

Important:

passwd

If you don't set a password you can't log in.

A. Grub legacy -- I couldn't make this work; see B

yum install grub 

Make the system bootable (the first command is so that df works)

grep -v rootfs /proc/mounts > /etc/mtab
grub-install --no-floppy /dev/sdb

grub-install --no-floppy /dev/sdb
Installation finished. No error reported.
This is the contents of the device map /boot/grub/device.map.
Check if this is correct or not. If any of the lines is incorrect,
fix it and re-run the script `grub-install'.

(fd0)   /dev/fd0
(hd0)   /dev/sda
(hd1)   /dev/sdb

The last command took a LONG time without any visual feedback until the very end.

Create a /boot/grub/grub.conf file:

default=0
timeout=5
splashimage=(hd0,0)/grub/splash.xpm.gz
title Scientific Linux (2.6.32-358.2.1.el6.x86_64)
       root (hd0,0)
       kernel /vmlinuz-2.6.32-358.2.1.el6.x86_64 ro root=UUID=45495a62-a141-4033-a739-8063f0e80a56
       initrd /initramfs-2.6.32-358.2.1.el6.x86_64.img

B. Grub2 -- this worked perfectly for me
Grub and I don't play well together. I'm more at home with grub2 which..well..allows for a bit of stupidity. After spending a fair amount of time trying to figure out grub (legacy) I gave up and did the following:

yum install wget diffutils bison gcc gcc-c++ kernel-devel flex freetype-devel make fuse-libs fuse-devel 
cd /tmp
wget ftp://ftp.gnu.org/gnu/grub/grub-2.00.tar.gz
tar xvf grub-2.00.tar.gz
cd grub-2.00/
./configure
make
make install
grub-mkconfig -o /boot/grub/grub.cfg
yum erase grub
grub-install /dev/sdb

---

Set up the following files:

/etc/sysconfig/network

NETWORKING=yes
HOSTNAME=science!

/etc/sysconfig/network-scripts/ifcfg-eth0

DEVICE=eth0
BOOTPROTO=dhcp
ONBOOT=yes

If you want static inet instead, do

DEVICE=eth0
HWADDR=D4:AE:52:71:79:14
IPADDR=10.1.1.1
NETMASK=255.255.0.0
BOOTPROTO=none
ONBOOT=yes
MTU=1500
TYPE=Ethernet

You're now ready to exit the chroot, unmount everything and reboot. Things to do after the first reboot include setting up a user (useradd -m verahill) and install sudo.
Anyway, there are plenty of guides online for that...

I tried this on physical hardware, and it works  Since the box is headless I only had ssh access, setting up proper rules in /etc/udev/rules.d/ was important so that I could configure the network via /etc/sysconfig/network-scripts files before putting the drive back in the server.

/etc/udev/rules.d/70-persistent-net.rules

SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:0e:b6:2a:a9:30", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:0e:b6:2a:a9:31", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"

This is a headless box (no graphics card, no vga output -- only a serial port), but I wanted to be able to use for a student to use gnuplot etc. in a pinch.

sudo yum install xorg-x11-server-Xvfb xorg-x11-server-Xorg

To set up keyword-less key-based ssh log in, edit /etc/ssh/sshd_config and uncomment

AuthorizedKeysFile .ssh/authorized_keys

mkdir ~/.ssh
chmod 700 ~/.ssh
touch ~/.ssh/authorized_keys
chmod 644 ~/.ssh/authorized_keys

Done.

358. Gentoo in a virtual machine

This post took a LONG time to write, so hopefully someone, somewhere, will find it useful. My enthusiasm was also somewhat tempered during the installation. Gentoo just didn't speak to me. Maybe I'll feel differently in 6-12 months of Arch?

The post...

I'm sure that there are plenty of similar posts out there, and I admit that my main reason for writing this post isn't as much to get anyone else to play with gentoo (although it's certainly an interesting experience -- but probably a bit more fun on native hardware with a bit more oomph) as to provide myself with a written step-by-step instruction set if I should switch my mini-server to gentoo (I use it for testing/educational purposes).

I also realise that given that the most obvious advantage of gentoo is the hardware optimised binaries, running things in a virtual machine isn't going to show off the real strength of gentoo. Hopefully it might give an accurate impression of the complexity (or lack thereof) of gentoo as compared to other distros such as Arch and Debian.

Virtual machine
I'm doing this in a virtual machine. The principal reason is that I don't have any spare metal at the moment. The secondary reason is that because gentoo installation is very interactive, you will most likely not be able to do a complete installation in a single 2-hour sitting the first time (you'll have to look things up, think about modules etc. -- and compiling everything takes time), and doing things in a virtual machine makes it very easy to freeze the system until you have time to continue. Obviously you can also do it the old-fashioned way (simply chroot the system when you are ready to continue), but freezing is easier.

I probably should have switched to KVM by now, but since I'm not really that interested in using virtual machines for work, and since virtualbox is so simple to use, I'll be using Virtualbox here.

I wouldn't recommend trying Gentoo until you first feel somewhat familiar with the basic concepts on Linux (by using e.g. Debian), followed by trying a more hands-on distro like Arch, or one of the BSDs. Obviously, I'm biased since this is the path I've taken, but I still think that you're better off pushing yourself little by little, than suddenly jumping into something unfamiliar which then may turn into something that seems unfriendly and losing all interest as a consequence.

That's not to say that gentoo is difficult. What is or isn't difficult depends on your expectations and frame of reference. What I am saying is that gentoo will make a lot more sense if you have at least a conceptual idea of what is needed for a system to be bootable and useful (if you don't know that you need an X server, you won't enjoy this. If you haven't played with GRUB, you won't enjoy this).

Anyway.

I've followed http://www.gentoo.org/doc/
-- although I've focused on getting a working system quickly rather than spending a lot of time looking into what hardware I really have.

1. Create the virtual machine.
If you need help setting up a virtual machine you are most likely not going to enjoy gentoo (yet -- so come back in a few months), so I won't show that. Suffice to say that I created a machine with 1024 Mb RAM and 15 Gb HDD. The size of the harddisk is due to compilations normally requiring a fair amount of temporary storage space (you can probably get around it with tempfs if  you can spare it).

2. Get a gentoo cd. 
At this point we have an unpartitioned, unbootable harddrive so we need to boot our machine using some form of linux distro that can partition our virtual machine harddrive, as well as chroot gentoo. You don't need the gentoo cds for this, but it does make sense to use them.

You can use a minimal CD,a full DVD, or a stage 3 tarball. I'll use the CD.

Mirrors are found here: http://www.gentoo.org/main/en/mirrors2.xml
You will want to go to /gentoo/releases/amd64/current-iso and pick your architecture, e.g. I did

wget ftp://ftp.swin.edu.au/gentoo/releases/amd64/current-iso/install-amd64-minimal-20130110.iso
wget ftp://ftp.swin.edu.au/gentoo/releases/amd64/current-iso/install-amd64-minimal-20130110.iso.DIGESTS
sha512sum install-amd64-minimal-20130110.iso

77ab0ba00767b6d4668d0f4bf7effbf2af3f38a1bd7cef297a17076478fd46d05b15a80188da473cf7d7f8c220acbe615afd300de4af90011d54185be2697f7d  install-amd64-minimal-20130110.iso

cat install-amd64-minimal-20130110.iso.DIGESTS 

# SHA512 HASH
77ab0ba00767b6d4668d0f4bf7effbf2af3f38a1bd7cef297a17076478fd46d05b15a80188da473cf7d7f8c220acbe615afd300de4af90011d54185be2697f7d  install-amd64-minimal-20130110.iso

3. Boot
Attach the iso to your virtual machine and boot/start.

Hit enter.

The fun begins :)

Note that everything in virtualbox 'just works' since there's a dhcp server etc. Real-world hardware may require a bit more work to get the network etc. up and running. Anyway, the gentoo manual tries to cover most eventualities, which may make it a bit more complicated to follow. We don't have to worry about most options.

4. Partition the drive

ls /dev/sd*

/dev/sda
fdisk /dev/sda

Hit n (for new partition), p (for primary), accept 1, and 2048, set +13G, then n, p, 2, and accept the defaults. Do a, then 1 to make partition 1 bootable. Do t, 2, 82 to set sda2 as swap. Hit w to write. You've now created one bootable root and one swap partition.

mkswap /dev/sda2
mkfs.ext4 /dev/sda1

This isn't the gentoo way -- we're using a single root here instead of making separate partitions for root, usr, home etc. On the other hand, since we're just exploring we might as well keep things simple.

5. Setting up the chroot
Make sure that the date/time is right.

date -s "18:08 20130307"
mount /dev/sda1 /mnt/gentoo
cd /mnt/gentoo
wget ftp://ftp.swin.edu.au/gentoo/releases/x86/current-stage3/stage3-i686-20121213.tar.bz2
tar xvjpf stage3-i686-20121213.tar.bz2

Extracting the stage3 file creates the standard linux file structure (/var, /boot, /dev, /etc, /proc etc.).
Edit the (/mnt/gentoo)/etc/ports/make.conf

vi etc/ports/make.conf

CFLAGS="-O2 -march=native -pipe"
CXXFLAGS="${CFLAGS}"
MAKEOPTS="-j1"
CHOST="i686-pc-lnux-gnu"
USE="bindist"

If you have multiple cores, change the MAKEOPTS accordingly. The USE flag seems to be 'bindist' on i686, and 'bindist mmx sse sse2' on amd64. Presumably they depend on what gentoo detects on boot, and you will probably want to keep these.

mirrorselect -i -o >> /mnt/gentoo/etc/portage/make.conf
mirrorselect -i -r -o >> /mnt/gentoo/etc/portage/make.conf
cp /etc/resolv.conf etc/resolv.conf
mount -t proc none proc/
mount --rbind /sys sys/
mount --rbind /dev dev/

6. Enter the chroot -- set-up

chroot /mnt/gentoo /bin/bash
source /etc/profile
mkdir /usr/portage
emerge-webrsync

This will take a while, so don't give up if it seems stuck on 'Syncing local tree' and there's no network traffic.
.

emerge --sync
eselect profile list

There are seven different profiles on i686 and 13 on amd64 to choose from. I picked number 4 (default/gnome).

eselect profile set 4

I can't stand nano, so

emerge portage
emerge vim

Vim does take quite a while to install, so if you're happy with nano, stick with it.

Edit /etc/portage/make.conf

USE="bindist gnome gtk -kde -qt4"

Keep the USE flags that were there from the beginning and append gnome, gtk etc. I admit that I can't be bothered reading through /usr/portage/profiles/use.desc just in order to check out gentoo.

cp /usr/share/zoneinfo/Australia/Melbourne /etc/localtime
echo "Australia/Melbourne" > /etc/timezone

7. Compile/Install the kernel

emerge gentoo-sources
cd /usr/src/linux

Time to build a kernel! Do

make help|less

and look at the targets. Be aware that if you do 'emerge pciutils' as recommended by the gentoo guide this will take a long, long time since it pulls in 60 packages...but you need to if you want a working lspci.

My approach here is to first use make localmodconfig to get all the currently loaded modules, and then add more support manually via make menuconfig. Remember that if you screw things up you can always go back and redo it later. Build a minimal configuration, then explore what else you need to add (USB support etc.)

make localmodconfig
make menuconfig

IMPORTANT: 
1. Make sure to change 'Device Drivers/Serial ATA and Parallel ATA drivers' from (M) to (*).
2. Go to the submenu and make sure that AHCI SATA support is starred (i.e. not M) as well as 'Generic ATA support' Otherwise you'll probably find yourself consulting this post: http://wiki.gentoo.org/wiki/Knowledge_Base:Unable_to_mount_root_fs due to

VFS: Cannot open root device "sda1" or unknown-block(0,0)
Please append a correct "root=" boot option; here are the available partions:
...
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

Anyway.

make
make modules_install
cp arch/x86_64/boot/bzimage /boot/vmlinuz-3.7.10
cp System.map /boot/System-3.7.10.map
ln -s /boot/System-3.7.10.map /boot/System.map

The first step make took me 16 minutes, which isn't bad for a single-core compile.

While you don't have to (since we have a single / partition), you might as well do

emerge genkernel
genkernel --install initramfs
mv /boot/initramfs-genkernel-x86_64-3.7.10-gentoo /boot/initramfs-3.7.10

You can edit /etc/conf.d/modules and list the modules you want to load. Have a look at the output of lsmod to get an idea. Doing 'lsmod > modules.list' might be a good idea for troubleshooting later.

8. Miscellaneous

Edit /etc/fstab

/dev/sda1    /       ext4    defaults   0  2
/dev/sda2    none    swap    sw         0  0

Set a hostname:

echo 'HOSTNAME="turbotux"' > /etc/conf.d/hostname
echo '127.0.0.1 turbotux localhost' > /etc/hosts

If you don't set a domain name and don't want hostname.unknown_domain to greet you on boot, run

sed -i 's,\\O,,g' /etc/issue

Edit /etc/conf.d/keymap and set keymap.

echo 'en_AU.UTF-8 UTF-8' >> /etc/locale.gen
locale-gen
echo 'LANG="en_AU.UTF-8"'> /etc/env.d/02locale
env-update
source /etc/profile

emerge mlocate vixie-cron sysklogd

rc-update add sshd default
emerge dhcpcd

9. GRUB2
GRUB might be a better, albeit retro, learning experience, but GRUB2 has better auto-configuration features and I'm not interested in hand-configuring grub just yet.

echo 'sys-boot/grub:2' >> /etc/portage/package.accept_keywords
emerge grub:2
mkdir /boot/grub2
grub2-mkconfig -o /boot/grub2/grub.cfg
grub2-install /dev/sda

IMPORTANT: set a root password before restarting or you won't be able to log in:

passwd

exit
shutdown -h now

Remove the CD from the virtual machine. Start the machine again

10. Your first boot
If all went well (i.e. you did exactly what I did above) you'll be greeted with this:

You can now log in as root.

11. Installing Gnome 2

The current version of gnome in gentoo (stable) is 2.32. If you want that, just emerge gnome. If not, the easiest (not safest) way to is switch to testing which might not be the best choice for gentoo novices.
To set up gnome I'm following this post: http://www.gentoo.org/doc/en/gnome-config.xml
If you can't live a single day without gnome 3, then checkout http://en.gentoo-wiki.com/wiki/Gnome_3

Anyway, gnome 2.32:

Then do

emerge --sync
emerge --update --ask world
emerge gentoolkit
equery m gnome

Brace yourself, because this will take a while (549 packages!):

emerge --ask --autounmask-write gnome
dispatch-conf
emerge --ask gnome

Hit Yes when you run the first command (change Use params), u (use new) when you run the second command, and Yes for the third command (emerge new packages). This step took 660 minutes in a virtual machine with a single core assigned.

env-update
source /etc/profile
emerge --sync
rc-update add dbus default
/etc/init.d/dbus start

Create a user:

useradd -m verahill
emerge sudo gksu
echo 'verahill ALL=(ALL) ALL'>>/etc/sudoers
passwd verahill
su verahill
cd ~

Continue setting up gnome:

echo 'export XDG_MENU_PREFIX=-gnome' > ~/.xinitrc
echo 'exec gnome-session' >> ~/.xinitrc
ln -s /etc/xdg/menus/gnome-applications.menu /etc/xdg/menus/applications.menu 
startx

You shouldn't have to do both the XDG_MENU_PREFIX and the symlink, but I had to in order to get a working applications menu.

Without vbox guest additions installed

To install the vbox additions, click on Devices/Install Guest Additions in the virtual machine menu. The CD will fail to mount.

sudo mount -o loop /dev/sr0 /mnt
sh /mnt/autorun.sh

Reboot, then do startx again. If you want gdm to start, then see step three here: http://www.gentoo.org/doc/en/gnome-config.xml

With vbox guest additions installed

Sounds is another story entirely...http://wiki.gentoo.org/wiki/PulseAudio

Anyway, that's enough of Gentoo for me for now.

357. Annoying desktop experience -- zoneminder, nouveau, nvidia and other things

This isn't a how-to post. It's basically just a description of what I went through this morning -- hopefully it'll help someone. I don't like playing around with nvidia -- and I don't have time anyway -- so I won't try to ferret out exactly what went wrong. Maybe everything was due to me failing to discover that the upgrade hadn't finished properly.

So..
(the system in question was running nvidia/kernel 3.7 at the beginning)

I had issues starting virtualbox (playing with gentoo for an upcoming post) the other day, and so decided to reboot after running apt-get upgrade (I only do it once per week/month or so -- it's my futile attempt at stability in spite of running wheezy/testing...).

On rebooting everything looked fine and I was greeted with the login screen in GDM. Trying to log in everything looks fine at the beginning...the screen flickers as if the resolution is being changed, the desktop background looks fine, conky is running...and then I'm thrown back to the GDM login again.

I'm not a stranger to other desktops. Trying KDE, LXDE, etc via GDM gave the same error.

Looking in the terminal I noticed that I had guake segfault errors, and errors along the lines of
"segfault at 968 ip [..] error 4 in libX11.so.6.3.0"

Logging in as another user gives me a message saying that I'm thrown back in to gnome classic due to lack of acceleration. Also, the desktop didn't have menus etc., and with various d-bus related errors.

Looking at
~/.xsession-errors:

update-notifier: Fatal IO error 0 (Success) on X server :0.
No protocol specified

and
/var/log/Xorg.0.log:

Display does not support NVIDIA 3D.

I then ran SMXI with the intent to test Nouveau instead of Nvidia.

As part of its process, SMXI does a dist-upgrade. It's not often I encounter errors during apt-get, so when errors popped up, I paid attention.

Turns out that Zoneminder had some issue -- zoneminder had held back the configuration of packages that I pulled in during the apt-get upgrade at the very beginning. And given that I don't do it very often, there were a lot of packages that were left unconfigured, including Xorg.

I auto-remove zoneminder and completed the upgrade. So far so good!

If that had been the end of it there would be no blog post. Still things weren't working.

Since I was already exploring the possibility of switching to Nouveau, I decided to go through with it. First I backed up my old /etc/X11/xorg.conf which has served me well in the past. Then, using SMXI I installed Nouveau (after blacklisting nvidia, and removing any nouveau blacklisting).

GDM started up fine, but I had no acceleration and GNOME 3 started in fallback mode (gnome 'classic'). I tried glxgears which told me  libGL.so.1 was missing.

However, libGL.so.1 actually existed in /usr/lib/x86_64-gnu/ -- but it pointed to libGL.so.1.2 via a symlink, and libGL.so.1.2 didn't exist.

I flailed about for a little while:
sudo apt-get install --reinstall glx-alternative-mesa
Which seemed to actually do stuff -- pulled in nvidia-installer-cleanup, glx-diversions, glx-alternative-mesa. It added lots of seemingly relevant diversions, but there was still no target for the libGL.so.1 symlink.

I then got fed up with the Nouveau/GNOME 3 combination.

I decided to bet on NVIDIA again, and had the fairly reasonable idea that the issue was the updated Xorg version -- simple nvidia update might've helped

Since I had kernel 3.7 installed, and 3.8 supports NVIDIA/DKMS I figured I might as well install a 3.8 kernel I had compiled on a different computer before continuing.

After upgrading to kernel 3.8, I blacklisted nouveau in /etc/modprobe.d/blacklist.conf ('blacklist nouveau').
I manually made sure that there was no nvidia or nouveau loaded by rmmod:ing them and checking with lsmod.

I then ran smxi and installed debian-nvidia.

Reboot.

Black screen with cursor. No graphical environment.

lsmod showed that nouveau hadn't respected my blacklisting.

Edited my /etc/default/grub to read
GRUB_CMDLINE_LINUX_DEFAULT="quiet nouveau.blacklist=1"
then ran update-grub, followed by restoring my old xorg.conf.

And...then everything worked! lsmod shows that nouveau isn't loading anymore (blacklisting should be ok,  no?) and I can now log in to gnome 3 as normal with normal acceleration.

I'm not sure what the underlying problem was -- nouveau not respecting my blacklisting hasn't been an issue before, so that was a bit of a surprise. But it was probably fine before I installed nouveau (I can't uninstall it for some retarded reason since it pulls too many packages with it), and not the source of the original issues. Probably the new xorg version didn't play fine with the installed version of nvidia, which is almost expected.

I'm still peeved with the Nouveau/GNOME 3 situation though -- binary blobs shouldn't be required to simply to use a basic desktop. I can understand if nouveau isn't a stand in for nvidia -- it's a reverse engineered open source alternative after all -- but why is gnome 3 requiring so much grunt?