Mesa 7.9 with Gallium3D entered ~arch

Mesa 7.9 was just added to the portage tree. Along with it came a new eselect module, eselect-mesa, which allows you to switch between classic and gallium drivers.

Especially interesting are the Radeon r300 and software renderer gallium drivers, which can give a significant performance and feature boost over the classic counterparts (enable USE="llvm" for best results). Gallium hardware drivers require DRI2/KMS to be active.

Please give it a good testing and report any issues that you find.

Booting from a btrfs filesystem in a GPT-partitioned USB flash drive attached to a non-EFI system

Previously thought impossible, thanks to syslinux 4 this feat can now be achieved in a few easy steps.

Background

Recently, I had a talk on IRC with the developer of the Arch Linux installer, who wanted to enable Arch Linux installation on legacy BIOS systems with GPT partitioned media.
As I usually carry a bootable USB flash stick with me, containing the netboot installers for various popular Linux distros (don't worry, all of them can be abused to install Gentoo as well), I thought that maybe it is time to get this up to date with the latest and greatest in partitioning and file systems.

• Why GPT?
  GPT, short form of GUID Partition Table, is the standard for EFI systems and is intended to replace MBR style partition tables. Advantages of GPT include support for up to 128 partitions (no distinction between primary and logical), no limitation to 2³² sector disks (2 TiB for 512 byte sectors), and increased redundancy for easier recovery.
• Why btrfs?
  No real reason, other than it being the new hotness (in spite of some design flaws).
  
• Why syslinux?
  EXTLINUX from the syslinux family of boot loaders can boot both from GPT and btrfs. An alternative would be GRUB 2, which however uses not the standardized method described in T13 EDD-4 Annex 1 and needs special patching for btrfs still.

Prerequisites

• A USB flash drive of >256 MiB capacity
• sys-apps/gdisk
• >=sys-boot/syslinux-4.00
• sys-fs/btrfs-progs

Partitioning

When first launching gdisk you will be greeted by a message that either the disk was found unpartitioned and a new GPT has been created, or that your existing MBR has been converted to GPT. In this example we use /dev/sdc as the device and /mnt/usb as the mount point.

# gdisk /dev/sdc
GPT fdisk (gdisk) version 0.6.9

Partition table scan:
  MBR: not present
  BSD: not present
  APM: not present
  GPT: not present

Creating new GPT entries.

Now we proceed to create a partition (gdisk syntax follows fdisk closely) and then enter expert mode to mark this partition legacy BIOS bootable.

Command (? for help): n
(answer the questions)
Command (? for help): x
Expert command (? for help): a
Using 1
Attribute value is 0000000000000000. Set fields are:
Known attributes are:
0 - system partition
1 - hide from EFI
2 - legacy BIOS bootable
60 - read-only
62 - hidden
63 - do not automount
Toggle which attribute field (0-63, 64 to exit): 61

Note that due to a bug in gdisk-0.6.9 and earlier, you need to enter 61 instead of 2. This will be fixed in a future release. Verify that you have the correct attribute flags, which are 0000000000000004. Now write the partition table to disk and exit gdisk.

Installing the MBR/GPT boot code and EXTLINUX boot loader

Install the GPT boot code into the MBR

# dd if=/usr/share/syslinux/gptmbr.bin of=/dev/sdc

Create a btrfs filesystem in the partition

# mkfs.btrfs /dev/sdc1

Install the EXTLINUX boot loader into the partition

# mount /dev/sdc1 /mnt/usb
# extlinux -i /mnt/usb
/mnt/usb is device /dev/sdc1
# cp /usr/share/syslinux/menu.c32 /mnt/usb 

Configuring the boot loader

In this example, we put the Debian Squeeze amd64 netboot installer on the USB drive. Same thing works for the netboot (sometimes called PXE) installers of other distros too.

# mkdir /mnt/usb/debian-amd64
# cd /mnt/usb/debian-amd64
# wget http://ftp.debian.org/debian/dists/squeeze/main/installer-amd64/current/images/netboot/debian-installer/amd64/linux
 http://ftp.debian.org/debian/dists/squeeze/main/installer-amd64/current/images/netboot/debian-installer/amd64/initrd.gz

Create /mnt/usb/extlinux.conf with the following content:

DEFAULT menu.c32
PROMPT 0
MENU TITLE Select Installer

LABEL debian-amd64
   MENU LABEL Debian Squeeze amd64
   KERNEL /debian-amd64/linux
   APPEND initrd=/debian-amd64/initrd.gz

Now your USB stick should be bootable and ready to use.

Other Thoughts

While syslinux supports chainloading on GPT disks, you cannot boot Windows this way, because Windows requires an EFI system in order to boot from GPT.
ChromeOS uses a slightly different method of booting from GPT, which resembles the old syslinux 3 and current FreeBSD way (even using the gpt utility from FreeBSD). If you are interested in their way, look at the ChromeOS installer scripts and the gpt utility.
A nice description of the issues surrounding booting from GPT can be found at the gdisk website.

Three-way mini shootout between GNU screen, tmux and dtach+dvtm

When it comes to terminal managers in Linux, it usually boils down to three choices: screen, tmux or the dtach+dvtm duo. Proponents of each often vigorously tout their solution as the best. So let's see how they compare.

The Contenders

• GNU screen is the oldest and perhaps most widely used of the terminal managers in this comparison. It has been around since the 1980s and made thousands if not millons of users' lives easier since then.
• tmux is a relative newcomer, the first release dating to late 2007. It was developed specifically with the goal of overcoming limitations in the implementation of screen.
• dvtm is best described as tiling window manager for the console. First released in late 2007 too, it lacks the disconnection/reattachment feature of the other two solutions, so it will unleash its full power only in combination with dtach which does exactly that. (Using screen/tmux with dvtm is also possible.) dtach was released in 2004.

The Parcours

The contenders will have to show how they perform in the aspects that matter to the modern geek. This includes mind share, adherence to Unix philosophy, features, efficient use of resources and ease of use.

Mind share

GNU screen has been around longest, so has had more time to capture users. Measuring popularity using Google is a bit difficult, as searching for "GNU screen" (with the quotes) will probably under-report while searching for "screen" will over-report actual numbers. A Google Trends analysis omitting the quotes sees screen in front, with tmux a distant second. This more or less matches the Debian Popularity Contest, which currently clocks screen at position #756, tmux at #6159 and dtach/dvtm at #6242 and #8604 respectively.
Winner: screen

Unix Philosophy

The Unix tools were developed with several precepts in mind, an important one being "Make each program do (exactly) one thing well". In this tradition, dvtm tried not to include everything but the kitchen sink, but instead leaves the disconnection/reattachment function to dtach, and displays auxiliary data such as the status bar and clock via named pipes.
screen and tmux on the other hand integrate all functions in one large binary.
Winner: dtach+dvtm

Features

Besides the ability to open several shells in one terminal/console, all contenders have a scrollback buffer, can do copy and paste and display status information. Both dvtm and tmux have mouse support and are able to align multiple shells nicely, not like in screen's limited fashion. Its client/server model allows tmux however to provide one notable feature, sending/sharing sessions between different connected clients. [Update: A commenter alerts me to the fact that screen can do this too. Still, tmux has more features.]
Winner: tmux

Efficient use of resources

In the time that screen has been around, it was able to accumulate a lot of legacy code, which results in a download size of 821 KiB. tmux is noticeably smaller, only 237 KiB. But this is still huge in comparison to dtach and dvtm, whose combined download size is only 81 KiB. This is probably due to their adherence to Unix principles, which helps to keep the bloat at bay.
But not only the download is smaller, the memory usage of a dtach+dvtm session is significantly below that of the others, too.
Winner: dtach+dvtm

Ease of use

The best way to start screen or tmux is just running the binary. You will be immediately in an environment where you can use all the features. dtach and dvtm have to be started together, and the user himself has to manage the dtach sessions manually.
Winner: Tie between screen and tmux

Conclusion

All contenders have been able to win two of the comparisons. If you are already used to screen and don't need the extra features of tmux, then you can stay with screen.
If you prefer an elegant and Unix-like approach, dtach+dvtm are what you want.
If you however want many features and a solution that Just Works™, then tmux may be for you.

Mesa and Gallium3D

Gallium3D is the new driver architecture for Mesa. In the X11 overlay you will now find an eselect mesa module, which in conjunction with the live mesa ebuild allows you to switch between classic and gallium.

Of course, this only works for drivers which exist both in a classic and gallium version. At the time of writing these are:

• i915, i965: The gallium drivers for Intel chipsets are presently inferior to the classic drivers. There is little reason to use them at this time.
• Radeon r300: The radeong gallium driver works well and has recently surpassed the classic driver in terms of features and performance.
• Radeon r600: The r600g gallium driver was added to mesa a week ago and does not do anything useful yet.
• Software renderer: If Mesa was built with the "llvm" USE flag enabled, then the gallium llvmpipe driver will give you much improved performance over the classic software rasterizer. As a tile based renderer it will use multithreading too. However some graphical glitches are still visible.

If you encounter any issues with eselect mesa, feel free to join #gentoo-desktop on freenode or report a bug, prefixing the summary with "[x11 overlay]".

Update: If you had already installed mesa-9999 from the X11 overlay, please rebuild it to ensure proper functioning of the eselect module.

Nouveau on Gentoo

For some time already, Gentoo has provided packages for the open source nouveau driver for NVidia graphics chipsets. Some users have discovered this and attempted to install nouveau, running into a few problems, most commonly experiencing the API break before libdrm 2.4.18 and after kernel 2.6.33.

Should I run nouveau or not?

Nouveau works strictly better than xf86-video-nv and has the following philosophical and technical advantages over the proprietary driver:

• Open source.
• Can always build with the latest kernel and xorg-server code from git.
• Supports all Riva TNT, GeForce and integrated chipsets, except for the GTX 400 series.
• Kernel Modesetting for framebuffer console at native display resolution and flicker-free vt switch.
• XRandR 1.2 support for dynamic output configuration.

Nouveau does however not yet support some features of the proprietary driver. So if you depend on those, you will have to stay with the blob for now:

• No power management support.
• No video decode acceleration.
• Limited multi-card support (all non-primary cards must be NV50/G80 or later generation, no SLI)
• TV-out only works on NV40 and older.
• 3D acceleration is experimental and not recommended for the timid.

Check the nouveau Feature Matrix for more details.

Installing nouveau on Gentoo

If you have decided that you want to try nouveau, the best way to proceed depends on whether you run a (mostly) stable system, an unstable (~arch) system or whether you always live on the bleeding edge of development.

Before you begin, ensure that eselect opengl is set to x11 and you are not loading the proprietary nvidia kernel module.

Stable users: You can run nouveau on an otherwise stable system with the following packages from ~arch:

• Kernel 2.6.33 (set DRM_NOUVEAU=m or =y)
• x11-drivers/xf86-video-nouveau (latest version)
• x11-drivers/nouveau-firmware (only needed for NV50 generation cards)

However the drm in kernel 2.6.33 is a bit old and will not support the integrated 8200/8300/9300/9400/ION chipsets.

~arch users and stable users who want newer nouveau: You cannot use the nouveau drm in kernel 2.6.33 with the unstable version of x11-libs/libdrm due to the aforementioned API break. So you need the following packages:

• x11-base/nouveau-drm (latest version), see here if it complains about missing kernel options which you cannot find in menuconfig
• x11-drivers/xf86-video-nouveau (latest version)
• >=x11-libs/libdrm-2.4.18

Bleeding edge users, or users who want 3D acceleration: You should run the latest kernel and mesa code for best results:

• Nouveau from Kernel 2.6.34_rc4 or newer, or x11-base/nouveau-drm-9999 from the x11 overlay (needs 2.6.34_rc2 at least)
• x11-drivers/xf86-video-nouveau (latest version)
• >=x11-libs/libdrm-2.4.20
• =media-libs/mesa-9999 from the x11 overlay, built with USE="gallium" and VIDEO_CARDS="nouveau" (only if you want the experimental 3D acceleration for which nouveau developers provide no end user support).

Stop by in #gentoo-desktop on freenode or post in the forums if you have any questions.