Bobulate


Archive for the ‘FreeBSD’ Category

Free(BSD) Graphics

Wednesday, June 23rd, 2010

Sebas wrote about Free and fast graphics a while back, which has led me to try the same on FreeBSD. I have a similar setup, with two monitors attached to a Radeon 4350. I’ve written about the 4350 on FreeBSD before. The minor challenge this time around was to get compositing working with a dual-head setup and to get the dual-head setup to show up on startup. Perhaps there’s a KDE-ish way of doing this, but I ended up setting up a xorg.conf with the desired layout. Without an xorg.conf, I’d get nicely mirrored displays, which I could manipulate sensibly with xrandr, but I couldn’t properly place the one monitor beside the other — xrandr kept complaining that my maximum screen size was 1650×1650.

So, manual configuration it is. I’m using X.Org X Server 1.7.5, Release Date: 2010-02-16, built on FreeBSD 8-STABLE, amd64, using the radeon driver v.6.13.0.

Thanks to the much improved auto-configuration in Xorg, the configuration file doesn’t have to be very long. The bits needed were a Device section, two Monitor sections, and a Screen section, like so:

Section "Device"
Driver "radeon"
Option "Monitor-DVI-0" "Monitor206"
Option "Monitor-VGA-0" "Monitor430"
EndSection

(I’ve left out the Identifier and BusID lines, among others — they’re not relevant; I tried the radeonhd driver, but that didn’t yield quick results). The important thing here is the explicit identification of monitor identifiers with XRandR outputs — I have a Samsung 206S monitor connected to the DVI output, for instance. From here, we go to the two monitor sections. I’ve set preferred modes on both for their native resolution. When I didn’t, I got them both at the lowest common resolution, 1280×1024, which was ugly as sin.

Section "Monitor"
Identifier "Monitor206"
Option "Primary" "true"
Option "PreferredMode" "1680x1050"
EndSection
Section "Monitor"
Identifier "Monitor430"
Option "RightOf" "Monitor206"
Option "PreferredMode" "1280x1024"
EndSection

You can see that the 206S is my preferred monitor — this sets it up as the main monitor, which means that the KDE startup thing shows up there and most notifications do as well. The other monitor — a six year old Iiyama E430 — is off to the right, and houses Konversation and Akregator and other non-essential attention-grabbers. The difference in color reproduction between the two is striking, so much so that I give the second monitor a very different background just so I notice the color difference less.

The last bit is setting up the Screen for X. Here I’ve left out Identifier, Device, Default depth; the important bits seem to be the monitor and the Display, which define a primary monitor (again?) and the side of the desktop. In this case, the desktop size is the sum of the horizontal widths and the greater of the heights.

Section "Screen"
Monitor "Monitor206"
SubSection "Display"
Depth 24
Virtual 2960 1050
EndSubSection
EndSection

Unlike Sebas, I don’t seem to have OpenGL compositing in this setup. That could be because of the card, the software — Sebas points out that it’s a little finicky with versions of kernel and video drivers — or something else. Switching to XRender gets me something that’s good enough.

VirtualBox on FreeBSD

Saturday, April 17th, 2010

For some of the things I would like to do with the EBN code-quality checking machine — things outside the immediate realm of quality checking — I need some VMs beyond what FreeBSD’s jails give me.

In particular, I need Solaris running on the machine as well as FreeBSD, so I looked into VirtualBox. I’ve used it on Solaris for various purposes (including running FreeBSD) so it seemed appropriate. There’s no binary version of VirtualBox for FreeBSD, but you can compile the Open Source Edition from ports, so that’s what I did. The results — missing USB passthrough and no RDP — are things I can live with, as it just means I’ll do most of my work on the VMs through ssh.

Installation (of VirtualBox OSE 3.1.6) is pretty non-eventful, the remember-to-load-the-kernel-driver reminder at the end of installation useful, and it just works.

For testing purposes and to satisfy some curiosity on my part I decided to install the Maemo development environment provided by Nokia (hey, maybe I’ll write my first GTK+ program like that). This turns out to be a VMDK (VMWare) file, not a OVF file, so a little bit of fiddling about was necessary. There are installer scripts available with lots of disclaimers for VBox 2, but none for version 3. So I tweaked and twiddled a little, and ended up with this installer script that calls VBoxManage a bunch of times to set up the machine. This is largely cribbed from Nokia’s script, adapted for new syntax in version 3.

One thing to note here is the invocation with –usb on. That could be combined with other calls to VBoxManage, but since the OSE has no USB passthrough, this will fail. For those using the non-OSE version, the call will succeed. Run the script with either –add or –remove from the directory containing the .vmdk file and it’ll set things up or tear them down.

In the resulting VM I haven’t gotten any further than starting esbox and quitting it again — but it shows that the VM works, that the apps work. I can ssh in for whatever command-line work I need to do.

The upshot — after all, the Maemo dev environment is just an experiment — is that a Solaris VM will happen real soon now. I was hoping for something jeos-like, but I hear that the people responsible for that have left Oracle now (this looks like a common theme: all the nifty Open Source but non-revenue projects are bailing out). So I’ll have to find another means of installing a fairly-minimal OpenSolaris version into the VM (which, thanks to Jignesh, is a matter of VBoxManage import). For my purposes no X is needed, so that saves us at least one (if not two) desktop environments in the disk image.

Credits where credit is due: to Jignesh Shah for the OSOL image and to Miwi for not only porting KDE4 to FreeBSD but also acting as source of information for VirtualBox.

Moving and Updating a FreeBSD Boot Disk

Wednesday, April 14th, 2010

Part of my FreeBSD update effort consists of tackling a peculiar problem. I haven’t found the problem described online anywhere else, so I’m going to detail the steps taken. But first, an effort to pin down the problem itself.

I have a (remote) server. It has no DVD drive. It should remain up as much as possible. It’s currently running 6.1-STABLE, which is horribly old. It does have a spare drive in the machine, available for whatever. So what I want to do is make that spare disk a bootable 8-STABLE disk remotely, set up the 8-STABLE system as much as possible (still remotely), then reboot into the new system in one swell foop.

Let me rephrase: how do I add a new boot disk to a FreeBSD system and create a full bootable system on it without using the CD installer?

Or with different emphasis: I want to upgrade FreeBSD to a new major release and want to keep a complete bootable old version around just in case.

Preliminaries: let’s assume you have a full /usr/src for the system you want to end up running (for me, that’s 8-STABLE, and it actually lives in /mnt/sys/src-8); also a full ports tree; also that the system is currently running and that the new disk is /dev/ad6. The desired end situation is that /dev/ad6 is bootable and contains the whole new system.

Note, though, that 6-STABLE can’t even compile 8-STABLE from a source checkout, because of libelf header file problems. You need to go through two stages here: go from 6- to 7-, then 7- to 8-. However, one might hope that the second step is less invasive (in my case, no need to update ports into 7-, so I can boot 7-STABLE just once to update to 8-STABLE).

Make backups now. Really. This is all about messing around with the fundaments of the system with the intention of not touching the installed system and keeping a safe “way back”, but it’s still hazardous. Make backups now. Make sure they’re on physically removable media and remove them. Make another copy. Take it to a remote location. Store it in a dragon-proof safe.

You may also want to take a look at this upgrade tutorial for some other preliminaries.

Setting up the disk: we have the (new, presumed empty) disk attached as /dev/ad6. We’ll slice and partition it so that it can be used. We will use the whole disk, but not in “dangerously dedicated” mode. So we’ll put a single slice on it (partition in Linux and just about everybody else’s parlance).


fdisk -BI /dev/ad6 # Single slice on whole disk
fdisk -a1 /dev/ad6 # Make that slice active

Now that we’ve got a disk with a FreeBSD slice on it — and the rather simple FreeBSD boot manager in the MBR — we can set up partitions in the slice so that we can allocate filesystems. This requires thinking about the disk layout and sizing filesystems (we wouldn’t have to do that if we used ZFS, but I’m sticking to ZFS on OpenSolaris only for now, even if it is no longer considered experimental in FreeBSD). This means editing the label using $EDITOR, so I’ll show the end result as well.


bsdlabel -w /dev/ad6s1 # Create standard label
bsdlabel -e /dev/ad6s1 # Edit the label

When using the -e option to bsdlabel, you get a text editor to futz around with the partition layout and you can screw it up pretty badly if you try. I used this setup, which makes use of the modern size deisgnators and auto-offset so you can read it as “4G for this, then three of 8G, then all the rest”. Partition c is historically the whole disk.


# /dev/ad6s1:
8 partitions:
# size offset fstype [fsize bsize bps/cpg]
a: 4G 16 unused
b: 8G * swap
c: 143363997 0 unused 0 0 # "raw" part, don't edit
d: 8G * unused
e: 8G * unused
f: * * unused

I’ve left all the fstypes as unused except for swap, since they will get updated by newfs(8) later and it saves typing. Not to mention that the parameters are all pretty uninteresting or not worth tuning at this point.

In FreeBSD you can refer to a filesystem through its device (e.g. /dev/ad6s1a) or through its label — at least, if you have GEOM labels enabled in your kernel or loaded as a module. The label allows you to assign a human-readable name to a disk partition or filesystem so you can later refer to it by name. The name is independent of the physical location of the partition, so you can label something “myroot” and later refer to /dev/label/myroot regardless of where the disk has gotten shuffled off to. That’s really quite handy when you swap drives or cables around or add another SATA controller that potentially bumps device names around. So we’ll label everything, including swap:


glabel label myswap /dev/ad6s1b
newfs -U -L myroot /dev/ad6s1a
newfs -U -L mytmp /dev/ad6s1d
newfs -U -L myvar /dev/ad6s1e
newfs -U -L myusr /dev/ad6s1f

Now that all the filesystems are created and named, we can move on to filling them up with an installed base system. Do note that we’re not done with making the disks bootable — but for that, we need the right bits from the still-to-be-populated filesystems.

Populating filesystems: the newly-created filesystems are available in the running system, so we’re going to mount them and then put the updated system in them. Let’s assume we have a mountpoint /mnt/newsys in the running system to begin with. So we will start with mounting them all to re-create the future filesystem hierarchy under that mountpoint. We’ll throw in devfs for good measure.


mount /dev/ufs/myroot /mnt/newsys
mkdir /mnt/newsys/{tmp,var,usr,dev}
mount /dev/ufs/mytmp /mnt/newsys/tmp
# Similar for var and usr
mount -t devfs devfs /mnt/newsys/dev

If we were to chroot to the (still empty) /mnt/newsys we’d see the filesystem layout we want, including devices and everything. But we still need to populate them, so it’s time to build a new world. We assumed that /usr/src contains the sources for the system we want to end up with (e.g. it’s been csup’ped to RELENG_8). Plan another activity for an hour or so while the next steps complete (depending on the compile speed of your running machine).


cd /usr/src
make world DESTDIR=/mnt/newsys
make buildkernel installkernel DESTDIR=/mnt/newsys
make distribution DESTDIR=/mnt/newsys

You’ll note that some of those commands show up in the jail(8) manpage, which is where I cribbed them from. Because setting up a new bootable system is a lot like setting up a jail, just with disk, filesystem, kernel and boot blocks thrown in. Speaking of which, let’s update all the boot bits with the newly-generated files.


boot0cfg -B -b /mnt/newsys/boot/boot0 /dev/ad6
bsdlabel -B -b /mnt/newsys/boot/boot /dev/ad6s1

The last step — bsdlabel — might not work just like that, as there’s issues with (re-)labeling mounted disks. You may have to copy the new boot file to the running system, umount the whole newsys tree and then label. I don’t remember exactly what I did. Regardless, make sure that the filesystems are mounted again afterwards. You may find this blog post which mentions bsdlabel helpful, although I can’t figure out gpart(8) myself and it doesn’t seem to work under a running 8-STABLE system either. Some futzing required if the dreaded bsdlabel(8) “Class not found” error pops up.

But carrying on, once the filesystems are mounted again, you’ll need to add several files to the newly-populated system for it to boot and be useful. These are: /boot/loader.conf (kernel modules) and /etc/fstab (otherwise it won’t mount / and get confusing during boot; feel free to use the labels of the partitions if you add glabel_load=”YES” to loader.conf) and /etc/resolver.conf and /etc/rc.conf. Generally you could copy them over from the running system.

Testing: after all this, we have a filesystem filled with an updated system, created pretty much as if we were building a jail. Make sure devfs is mounted in there, and you can actually use it. Let’s assume you have an interface configured with IP 192.168.43.70 for the jail to run with. You could run a shell in there:


jail /mnt/newsys newsys 192.168.43.70 /bin/sh

You could even use the traditional /etc/rc instead of /bin/sh to bring the whole jail up, but this is fraught with peril. As in “Danger, Will Robinson!” This is particularly so when the jail and the running system do not share a kernel version. I experimented with a 7-STABLE system and an 8-STABLE jail, and noted the following (these are not bugs):

  • ls works, but ls -la fails with “unsupported system call”.
  • uname reports the kernel version of the running system, so pkg_add -r will use the running system, not the new system, as a source for packages. Fetch them manually.
  • Some shell constructs just hang. I tried to build the libtool22 port and it hung with /bin/sh spinning at 100%. Again, probably a syscall problem.

On the other hand, being able to check that the new system is functional enough to compile something is useful.

Deployment: the last step is to reboot the machine into the new system. If you have a console (yay ILOM! or otherwise yay physical access!) it’s easy to babysit the system. In my testing I just swapped disks around (yay hot-swap SATA bays in my desktop machine!) but on the remote system, I’m going to want it to boot the boot manager from the first disk — which is now the old system disk attached as /dev/ad0 — then chain to the new bootloader on the new system disk /dev/ad4 and then boot from there.

Frankly, that’s something I have not tested or tried yet. I expect that the following will work: boot0cfg -s 5 -o noupdate -t 40 /dev/ad0 ; bootcfg -s 1 -o noupdate -t 40 to chain from one to the next with 2-second timeouts on both, but again: not tested. Yay ILOM.

A Return to FreeBSD

Wednesday, April 14th, 2010

After a great deal of procrastinating, I’ve rearranged my home office again and restored my FreeBSD machine to its rightful place under the desk. It must have been switched off for several months now, as the update (buildworld for 7- and 8- as well as portupgrade -aPP) is taking forever. There’s a reason for running through this routine: there are a few things I want to test with systems upgrades and jails. In addition, I’d like to document how the EBN is set up, to the level of detail of including package names. This is part of an effort to clean up the EBN code and separate the tools from the website a little; that in turn is in advance of adding some new features to Krazy / EBN in general.

It’s kind of nice to be back on FreeBSD again. I’ll have to take note and compare the FreeBSD KDE packages with the OpenSolaris ones I produce.

PS. There’s nothing like cleaning your desk with a shovel and just dumping everything in a box never to be looked at again. I did retrieve several Bluetooth dongles and SD cards that I’d thought lost.

What price Freedom (2)?

Monday, November 30th, 2009

Let’s take a look at what happens when other Free Software operating systems run on my laptop, in terms of power consumption (and nothing else — I’m not going to explain in detail what’s running on each one, and rest assured that the available apps and toolsets in each of these installs is very different, reflecting what I use each OS for):

  • OpenSolaris, display off, nvidia drivers: 31W
  • OpenSolaris, display on, idle, nvidia drivers: 38W
  • OpenSolaris, display on, disk + network activity, nvidia drivers: 52W
  • Just the power brick: 1W

So it looks like Solaris is marginally (2W) better with power than Kubuntu at idle, and this laptop draws quite a lot in regular use. Maybe Solaris is not switching some hardware feature on, like Bluetooth, rather than being more efficient — but I haven’t noticed anything missing (Bluetooth is not something I’d miss). FreeBSD 8 fares no different — roughly same usage numbers as the other two OSsen.

Many commenters suggested trying the nouveau driver — so I did, whatever is available on Kubuntu 9.04 with no updates applied, and it makes no difference in power consumption, fails utterly at resume-from-suspend (nv got me no video, but I could ssh in, while now it just hangs), and is just as slow on logout as the nv driver. Perhaps there’s newer versions available — not something I’m going to experiment with this week.

IPS on FreeBSD

Thursday, June 11th, 2009

Right. So here’s a foolish plan: I want to publish some OpenSolaris packages to the world. They are not ready for SourceJuicer (submissions there are slightly complicated, and the forest of KDE packages I’m producing is tedious and time-consuming to import there). Last time I tried that publishing thing, I did it on a package server on an OSOL machine at the end of my own DSL line, which pretty much immediately spanked my bandwidth completely. So I want to do it on a machine with better connections.

It may surprise some that all the real servers I have run FreeBSD. I use OSOL as my main desktop operating system. There must be historical reasons for this. In any case, that means building the OpenSolaris IPS package server pkg.depotd on FreeBSD. It turns out to be relatively straightforward, as most of the actual server is written in Python (yay!) and there’s only a few bits of C in there. So my approach was:

  • Fetch the sources for pkg as documented on the pkg project page (thank you Alan Coopersmith),
  • Install necessary development tools on my FreeBSD machine:
    portinstall py-openssl py-cherrypy intltool gnome-doc
    portinstall py25-mako py25-simplejson
  • Run gmake. At this point I realised that the makefile has some bugs leading to No rule to make target `help/C/package-manager.xml' — there is some semi-complicated implicit target stuff going on in there. I built the needed files by hand with
    cd gui
    msgfmt -o help/C/C.mo help/C/C.po
    xml2po -t help/C/C.mo -o help/C/package-manager.xml help/C/package-manager.xml.in

    and stripped out the locales that I didn’t need.
  • Build extract_hostid by hand with
    cd util/misc
    cc extract_hostid.c -o extract_hostid -L/usr/local/lib -R/usr/local/lib -lintl

    This is needed because gettext lives in /usr/local on FreeBSD and the Makefile (obviously) assumes the OSOL setup.
  • Fix the top-level makefile to use python from /usr/local/bin and run gmake again.
  • Patch setup.py to support FreeBSD — there looks to be support for sunos, linux, windows and darwin already (!?). This takes a patch at lines 102 and 194. Run gmake again.
  • Run gmake install
  • Finally,
    cd gate/proto/root_freebsd_amd64
    PYTHONPATH=`pwd`/usr/lib/python2.4/vendor-packages:
    sh usr/lib/pkg.depotd -d ~/pkg/ips -p 10000

And there you have it. FreeBSD machines serving up OpenSolaris packages. For the purposes of KDE4 on Solaris, this means that pkg.bionicmutton will soon be returning and you will be able to install IPS packages instead of having to compile everything from source yourself. YMMV, contains rabid weasels, etc.

[[ And, as an addendum, let me congratulate the pkg / IPS team on the enormous improvement in the packaging system between OSOL 2008.11 and 2009.6; it used to be “ugh” and has reached, for me at least, a level of “hey, that’s pretty neat.” ]]