Tag Archives: debian

Hi Debian, welcome to 1904

I tried to install Debian onto an old PPC iMac with 300MB RAM without success.

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.


FreeNAS 8.0 will be GNU/Linux, no longer FreeBSD

Looks like FreeNAS will switch from FreeBSD to Debian GNU/Linux for the next major release. In July this year Volker Theile registered a new project called CoreNAS, which is what 8.0 will be based upon.

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
– …

Linux on an Apple Xserve EFI only machine

We have a few of these Apple Xserve machines at work which weren’t doing much, so I thought I’d make better use of them. Naturally, this meant installing Linux on them.

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!

Continue reading

Yum still on the menu?

Update: I’ve tried to post my results back to Seth’s thread but it won’t work, so I’ve emailed him instead.

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?

Continue reading

Having Yum for Breakfast

This week I decided to write a comparative article between Yum and Apt (the package managers). Using Fedora 11 and Ubuntu 9.04, I performed various tests and benchmarked both the time and CPU usage they took. But why? Let me explain.

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.

Changing priorities

I’m scripting some sys admin tasks in Debian which require the installation of packages like Postfix. I don’t want it to prompt me with questions, so I knew I had to set the priority to something higher for this specific package (i.e. temporarily). There doesn’t appear to be a way to pass this to an apt-get command (which was a little disappointing) but debconf can set it system wide under /var/cache/debconf/config.dat, but that’s, well, ugly.

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 πŸ™‚


The long ARM of Debian

I bought a D-Link DNS-323 NAS box a while ago with the mind to put Debian on it (it already ships with Linux, but I wanted more control). Previously I installed Debian under a chroot environment which activated itself on boot, but it wasn’t really clean or nice.

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!


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.

Let’s be firmware about this

I’m not an expert on this subject matter, nor a Debian developer, but I do love Debian. I couldn’t help but be disheartened by the results of the vote on firmware in Lenny.

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.