Firstly, the testing network and business card installers would segfault when booting. A known problem which hasn’t yet been fixed.

No matter, I just switched to the stable network installer and began my journey. Problem is, it gets stuck at configuring packages. Just sits there at 1% forever. When I see the log, I notice that it’s prompting me to confirm the installation of packages, which is hidden from the main screen and therefore what was causing it to die.

Changing root into /target I ran a few commands myself and noticed that apt-get update said that the GPG keys from debian-archive-keyring were invalid.

DAMN. What’s going on..

So I tried everything I could to fix it. Googled and Googled and Googled to no avail. Lots of people had similar issues, but forcing a re-install of debian-archive-keyring fixed it for them. Others said to use a different mirror.

I was about to curse Debian for no-longer caring about PPC and then it hit me. Check the date of the machine. Yes, sir, it was 3rd January 1904 – as far as Debian was concerned, the keys were well and truly invalid.

So a simple, apt-get install ntpdate && ntpdate ntp.internode.on.net and everything was sweet. Why it didn’t do this properly when I configured the time during the installer I don’t know. Nevertheless, I’m happy again.

Silly me.

-c

This means that they will lose native ZFS support (probably one of the biggest attractions), I don’t think that ZFS over Fuse will really be an acceptable option. It’ll be interesting to see if they pick up on Btrfs instead

The decision wasn’t easy, but was required due to users constantly wanting new features which were just too hard to put into the existing system. Bugs were also a major factor, saying:

My decision to use Linux for the next version was because there are too much bugs in the core FreeBSD system. Simply have a look into the bug tracker. FreeNAS does not run on many systems, mainly new hardware makes trouble. The main reason is the driver problem with FreeBSD which seems to be no problem with Linux because there are great companies in the back that support it. Also the Linux developer community is much greater than the FBSD one.

Volker also lists some of the pros:

- Text and grahical installer that can be customized. This means no hand written install scripts anymore which causes some problems in FreeNAS
- WOL works in Linux
- lmsensor – A WORKING sensor framework which is a really needed feature in FreeNAS to check the CPU/MB temps and fan speeds
- Better Samba performance
- Ability to implement HA features
- System can be updated via ‘apt-get’ or any other deb package manager
- Better driver support
- Maybe ‘ZFS’ over FUSE (there is already one commercial product available that uses this feature)
- NFS4
- …

These machines do not have a BIOS (or even any emulation), they use EFI and as such won’t boot the standard Linux install media. I knew that Fedora could boot EFI, so that’s where I started, with Leonidas (version 11). Unfortunately, the install media just wouldn’t work on this device, presumably as it has no BIOS emulation.

To cut a long story short, I had to learn how EFI works in order to get it booting and it wasn’t an easy thing to discover!

Booting EFI
In short, the Apple EFI boots and scans all available drives (including USB drives) for a GPT partitioned device which has a FAT formatted partition on it. Inside this partition it looks for an efi directory.

In that directory must be another from the list of approved vendor named directories, such as redhat or apple. The default is boot and this is what I used.

Inside that boot directory, EFI looks for a binary EFI file, which it can run. In my case, this is a GRUB2 EFI binary. The name of the file must match your architecture, so for me it is called bootia32.efi but if you’re running a 64bit system it should be bootx64.efi.
NOTE: Your Mac must have a 64bit EFI to load the 64bit EFI Linux installer (bootx64.efi)). Else, try choosing the 64bit options when using the 32bit EFI installer (bootia32.efi), but either way your system must have a 64bit CPU.

The GRUB2 EFI binary I am using looks for the standard GRUB config file, which is called grub.cfg. This must also be in the efi/boot/ directory of the USB device. The kernel and initramfs for the net installer should also be in that directory.

I have made a Debian Squeeze, Fedora Constantine and Ubuntu Karmic installer which you can download and extract onto your USB device (sha1sum). You will still need to partition and format your device, so more on how to do that later.

Partition USB Boot Device
So, once we understand how EFI works, next we need to get a bootable GRUB happening in order to install Linux.

Grab a USB memory stick and let’s prepare it. Please know what device it is you’re partitioning!! I’ll use sdz just for example purposes only.
Unmount it
su -c 'umount /dev/sdz1'

Partition and format it
Partition and format it
su -c 'parted -s /dev/sdz mklabel gpt mkpartfs EFI fat32 0% 100% toggle 1 boot'

It should now automatically mount. If not, unplug it and plug it in again, or mount it manually.

Prepare USB Boot Device
Next you can extract my tarball onto the device, ensuring that it maintains the efi/boot/ directory structure on it and not create an extra directories because of the archiver. If it’s not right, then re-arrange things and eject the device.

You should now be able to plug it into your Xserve and turn it on.

Hold down the Option key (Alt key on non-Apple keyboards) until you see the boot option. It should show “EFI” on the usb stick. Boot this and you should see the GRUB menu load. Choose the distro you want to install and away you go! See the “Installation” section below and skip the next few.

Manual preparation – Building GRUB2
Before we can compile GRUB, we need some dependencies. If you’re using Debian or Ubuntu, then run the following:
sudo apt-get build-dep grub2
sudo apt-get install libusb-dev

We need to check out GRUB from CVS and build it for EFI systems. Note, my Xserve is 32bit only, so I’m installing 32bit version. If you’re using 64bit then use a 64bit OS. You can cross compile, see the link above for info if you need to.

Check out source from CVS:
cvs -z3 \
-d:pserver:anonymous@cvs.savannah.gnu.org:/sources/grub \
co grub2
cd grub2

Or get source from Debian (which is more likely to compile):
apt-get source grub2
cd grub2*


Build grub2:
./configure --with-platform=efi
make

Now, make a temporary directory in which to put the GRUB EFI binary.
mkdir -p efi/boot/

Next we need to create the GRUB2 EFI program, and will specify a bunch of modules to include. This was a big stumbling block for me because someone removed the ability to read config files from module “configfile” and put it into “minicmd” requiring “sh”. The documentation I was following was not updated and I couldn’t work out why GRUB2 couldn’t parse my config (typing it in manually at the GRUB2 command prompt worked however). After lots of wasted time I emailed the GRUB list and had an answer within 20 minutes, which was a big relief.

./grub-mkimage -d . -o bootia32.efi part_gpt hfsplus fat ext2 normal sh chain boot configfile minicmd linux loadbios reboot appleldr halt search
sudo cp bootia32.efi efi/boot/

The efi/ directory now just needs to be copied onto your FAT USB stick. Don’t forget to make sure the directory structure is correct, as laid out above.

Now you just need to create a GRUB2 config file, which we’ll do below after getting the kernel and initramfs.

Manual preparation – Linux installers
I am using the netboot installers for each distro. This basically consists of a kernel, initramfs (which includes the installer). To know how to boot these in the GRUB config file, I read the isolinux configs included on the install CDs.

So, download the network installer of your choice in ISO format. Mount loop it and copy the kernel and initramfs onto the efi/boot/ directory on your USB disk.

For example (32bit), Ubuntu, Fedora, Debian Squeeze (note that Fedora does actually have an EFI boot disk which you can dd directly to a USB stick and boot, however this didn’t work on my Xserve but it might be useful to grab the kernel and initramfs from as it’s smaller).

Mount loop ISO:
mkdir /tmp/iso
sudo mount -o loop boot.iso /tmp/iso

Copy the kernel and initramfs from /tmp/iso onto your USB stick. You might need to look at the isolinux.cfg files under /tmp/iso in order to find out which is the kernel. On Debian and Ubuntu the kernel is called linux and the initramfs is called initrd.gz, both in the root directory.

GRUB Config File
Now that you have the GRUB2 EFI binary (bootia32.efi), kernel and initramfs on the USB stick, we need a config file for GRUB to read when it loads.

Here is an example for all four distros that I use in my provided tarball.
set timeout=10
set default=0
menuentry "Debian Squeeze" {
linux /efi/boot/linux-squeeze priority=low vga=normal video=efifb
initrd /efi/boot/initrd-squeeze.gz
}
menuentry "Fedora Leonidas" {
linux /efi/boot/vmlinuz-leonidas nomodeset xdriver=fbdev noselinux
initrd /efi/boot/initrd-leonidas.img
}
menuentry "Ubuntu Jaunty" {
linux /efi/boot/linux-jaunty priority=low vga=normal video=efifb
initrd /efi/boot/initrd-jaunty.gz
}
menuentry "Ubuntu Karmic" {
linux /efi/boot/linux-karmic priority=low vga=normal video=efifb
initrd /efi/boot/initrd-karmic.gz
}

Note that for Fedora I had to turn kernel based mode-setting off, and specify the Xserver driver.

The USB keyboard just wouldn’t work on either Ubuntu, but Debian Squeeze worked fine. I ended up choosing Fedora.

Manual preparation – Install Linux
Once you have all the required files, plug the stick in and turn on the Xserve. Hold down the Option key (Alt key on non-Apple keyboards) until you see the boot option. It should show “EFI” on the usb stick. Boot this and you should see the GRUB menu load where you can boot your network installer of choice.

Installation
When installing, you need to follow the same partition structure as the USB stick. I completely blew away all Apple partitions and am booting only Linux. The drives need to be GPT and to have a small FAT partition at the beginning with the efi/boot/ directory, GRUB2 EFI binary, GRUB config, kernel and initramfs.

There’s probably a better way to do this, I’m sure some distros will support GRUB2 and EFI out of the box soon. In the mean time I install the OS without a boot loader and create the efi/boot/ system manually. This means every time you update your kernel, you need to copy the kernel and initramfs, and update the GRUB config file.

The config file should be the same as the one used on the USB stick, except that the names of the kernel and initramfs will be different. For example:

set timeout=10
set default=0
menuentry "Fedora Leonidas" {
linux /efi/boot/vmlinuz-2.6.28-13-generic nomodeset xdriver=fbdev noselinux root=/dev/sda3 ro
initrd /efi/boot/initrd.img-2.6.28-13-generic
}

Conclusion
These are some rough notes to hopefully help others out there trying similar things. Please let me know how it works for you. I installed Fedora on my Xserve and it’s running quite well!

In response to my article comparing Yum and Apt (at least I think it was my article, might have been someone else’s I guess), lead developer of Yum, Seth Vidal, wrote his own test script and performed some Yum benchmarks of his own.

He wrote:

Always a fun comparison. It’d be even more fun if any of the numbers seemed accurate.

His ran his test and concluded that Yum is “pretty good” and offers for others to run the test and post their results. So I did, on the same computer I used for the my article. I also compared the results to Ubuntu, as that’s really what my article was talking about

So what did I find?

Scripts
Firstly, here is the script he wrote:
http://skvidal.fedorapeople.org/misc/yum-test.sh.txt

Here is the script I modified for Ubuntu:
http://christophersmart.com/files/apt-test.sh

Preparation
Before running the tests I first deleted all old repo data as I wanted as clean a system as possible. I then ran “yum check-update” and “yum install -y –downloadonly zziplib-utils” on Fedora so that I had an up-to-date package database and the files locally. I did the same thing on Ubuntu (but obviously not with “yum”).

Then I uninstalled “yum-plugin-downloadonly” and “yum-plugin-download-remove-with-leaves” and rebooted, so that it would not negatively affect the speed of Yum having to load extra plugins outside of the default.

I also ran the tests in single user mode so that other system processes such as PackageKit would not interfere.

After I had run both scripts, I also re-ran each of the tests individually (which below I call “freshboot”), rebooting in between each one so that memory caching would not manipulate the results. After all, running all those commands one after another is bound to overlap and I don’t think provides an accurate benchmark of each package management component.

Results
Results for Fedora 11 are here, followed by results on a freshboot:
http://christophersmart.com/files/simple-yum-results.txt
http://christophersmart.com/files/simple-yum-results-freshboot.txt

Ubuntu 9.04 results are here, followed by results on a freshboot:
http://christophersmart.com/files/simple-apt-results.txt
http://christophersmart.com/files/simple-apt-results-freshboot.txt

Analysis

Search by keyword
Yum provided 5 results and took 4.746s
Apt provided 12 results and took 1.366s

Apt was 3.47 times faster.

Fresh boot
Yum took 3.380s
Apt took 1.240s

Apt was 2.73 times faster.
NOTE: I don’t know why this results were faster on a freshboot, they should be about the same as the first test was on a fresh boot anyway!

Search by file provide
Yum took 10.654s
Apt took 2.291s

Apt was 4.65 times faster.
NOTE: I have discovered that running “yum provides” builds a cache and so subsequent searches are much faster. Debian has two tools for this, apt-file and dpkg, but dpkg only works for installed packages while apt-file does the entire repository. Also, apt-file needs to be updated like apt-get does, so perhaps a better comparison is needed.

Fresh boot
Yum took 10.903s
Apt took 2.354s

Apt was 4.63 times faster.

List installed pkgs

Yum listed 1,092 packages and took 1.756s
Apt listed 1,188 packages and took 0.191s

Apt was 9.19 times faster.

Fresh boot
Yum took 3.924s
Apt took 0.187s

Apt was 20.98 times faster.

Install pkg + deps
Yum installed two programs and took 9.775s
Apt installed two programs and took 4.868s

Apt was 2.01 times faster.
NOTE: I didn’t install the same program for my tests, but in my article Apt was about 3 times faster.

Fresh boot
Yum took 14.097s
Apt took 5.671s

Apt was 2.49 times faster.

Removing package

Yum took 3.714s
Apt took 2.337s

Apt was 1.56 times faster.
NOTE: For the tests in my article I used yum with “–remove-leaves”, which checks to see if any other programs requires the dependencies of the package you’re using and if not, removes those too. This was not done here, which is most likely the cause of the big difference between these and the results in my article. In my article I used tomboy for my tests (after I had removed all mono applications and then re-installed tomboy) which had to remove 7 dependencies. The test used in this script is not really testing all that.

Fresh boot
Yum took 10.137s
Apt took 4.916s

Apt was 2.06 times faster.

Conclusion
Seth’s test seem to confirm my own findings, with the exception of installing and removing packages. Naturally I installed different packages than were used here and I also used the remove-with-leaves plugin for Yum to make it remove no-longer needed dependencies.

These two tests probably caused the most eyebrow raising (as in my article it shows Ubuntu as being 3 and 5 times faster, respectively) but they aren’t really addressed in Seth’s script. The results from his script are in Ubuntu’s favour to a factor of 2.5 and 2, respectively so it’s not crazily out of proportion. I’d be interested to see some results on this. Also, a better test for searching by provides would be useful.

Of course it is hard to compare these when they all use different packages and pull in different dependencies. This is why I also had a test to install from a file rather than the database. My test installed Skype via an rpm and deb (ugly I know, but it was the only 3rd party application I could find which provided native packages for both distros), which had zero dependencies and was not in the local database. In my tests Ubuntu was faster than Fedora by a factor of 7. I’d like to see this included in his script too.

It is interesting to see that Apt is faster still, when running from a fresh boot.

Never-the-less, I would invite any others who wish to test to do so also and let me know how it went. Sure, Yum might have bucket loads more metadata and maybe it can do lots more fancy things, but at the end of the day it still comes in at second place here.

And while I’m writing all this up, I want to clarify that I’m not a Yum hater. I do agree with Seth that Yum is “pretty good”, but I just wish it would be better. Actually, I also really like Fedora.

As I concluded in my original article, maybe no-one cares how fast or slow their package manager is. Then again, maybe some people do. Personally, I’d love to see Yum become the best package manager on the planet

What I now want to know are all the tweaks and configurations people do to their Yum systems to get better performance. Tips anyone?

I really like the Fedora project. Really. I like their stance on proprietary drivers and codecs (and of course free software) and these days they seem to be pushing the technological envelope more than others. Sure Red Hat drives the direction of the project somewhat, but I don’t mind Red Hat either.

In fact, I wish I could use Fedora as my main distro! But every time I try it I just get so frustrated with Yum. Sure it’s better than up2date, but it’s so damn slow and annoying. That’s a problem for someone like me who manually updates his package database first thing every morning and checks to see what packages are available and updates the system by hand. Why do I do that? Cause I like to.

But every time I’ve tried to get into Fedora that damn package manager has stopped me. I get frustrated after a day or so. I think the longest I’ve had it on was 2 days before I switched.

Recently I installed Fedora 10 and 11 to see if there was any performance increase. Actually, to tell you the truth I was completely surprised by Yum’s agility and speed. The old Fedora I remember was not to be seen.. or so it felt like anyway.

Hence, I thought it might be good to run some tests to see.

Of course as the article points out, does any of this matter? Do we really need a fast a nimble package manager? Well for me it matters. It matters a great deal. For most users though they probably won’t care, as they just let the package manager do its thing in the background.

Still, it makes for some interesting thoughts. I think.

I want the Live CD to boot and automatically log my user into a graphical environment, and I want to do that using the least amount of resources. I installed Squeeze, including LXDE for my graphical environment. This pulled in the GNOME Desktop Manager by default, which I don’t want, so I removed it.

sudo apt-get remove --purge gdm

My plan was to simply edit the inittab and tell it to start up X on a new terminal, so I did this first.

sudo vim /etc/inittab

The default run level for Debian is 3, so under the line:
6:23:respawn:/sbin/getty 38400 tty6

I set the following line:
7:3:once:/bin/su - user -l -c "/bin/bash --login -c startx" &>/dev/null

The command basically says to switch root to my user, “user”, and execute the startx command from a bash session.

Running the command “startx” will of course start the X server, but I need to tell it what environment to load. To do this, I created an .xinitrc in my user’s home directory.

echo "exec startlxde" > ~/.xinitrc

Unfortunately, upon a reboot X wouldn’t start. It took a little while to work out why this wasn’t working as I expected. Turns out that Debian limits who can start an X session, so I had to edit the file /etc/X11/Xwrapper.config and set allowed_users=anybody rather than just “root”.

This can also be achieved by running:
sudo dpkg-reconfigure x11-common

The only issue I have at the moment is that logging out of LXDE and selecting “Restart” or “Shutdown” from the menu does not actually perform said task. I’m assuming this is because my user doesn’t have permissions to do so, as X was not started by root. Well, time to fix that next

-c

Turns out there’s an environment variable you can set to achieve what I want, DEBIAN_PRIORITY. So exporting this variable and unsetting it post install will do the trick, but I still think apt-get -p critical install postfix would be better

-c

I came across a blog post by Martin Michlmayr where he talks about getting Debian working on a CH3SNAS, and mentions he might write an installation guide. I emailed him encouraging him to do so, and that I’d be happy to test it for him and provide feedback. He replied with his information once it had started to take shape. Today I finally had a chance to test it out.

I followed the installation instructions on his website and it worked perfectly! I now have Debian running natively on my little ARM box and it’s very, very awesome.

Although the box has a gigabit network card, it never transferred anything fast enough to prove it. Copying a 4GB ISO file took 31minutes, averaging around 2.2MB/sec rate which is not even 100Mbit speed. So don’t expect to be serving up high definition movies to your network from this box.

Anyway, if you have one of these boxes, then I highly recommend that you give this a shot. Debian on a tiny little appliance.. it doesn’t get much better than that!

-c

Update: There are some things which don’t work, most of which I didn’t care about, except one. Fan control. I figured this meant the fan couldn’t speed up and slow down based on internal temperatures, but it actually means “fan doesn’t work at all”. The result is that drives can run hot, damn hot in that little box without any air flow. Something to think about if you’re going to install native Debian.

Update #2: The fan issue is now solved.

Assume blobs comply with the GPL unless proven otherwise.

BAH! Seriously, what the hell are you guys thinking? If I wanted this sort of crap I’d use Ubuntu! Sure it’s just firmware, but why not distribute the NVIDIA driver too? Afterall it hasn’t be proven in court as to whether it complies with the GPL or not.

How hard is it to just release Lenny with the current GPL-compliant open source firmware and let end users install other binary blobs at their own discretion? I just don’t understand how you can distribute that which you have no idea what it does. Maybe I’m missing something, but this just seems so wrong.