Andree's Debian & General Musings

EeePC 901 with Ubuntu Intrepid Ibex

2008-11-03T23:02:00.020+11:00

I have finally bought an EeePC 901, mainly to use for travelling.

I had been holding off for some weeks because I had hoped (in vain) that the Linux version with 20GB SSD and without a Windows XP license would become available here in Australia.

Anyway, I decided to try putting brand new Ubuntu Intrepid Ibex on it and I must say it worked really well. Here is what I did:

Downloaded the standard Intrepid i386 Desktop CD and put it on a USB memory stick using UNetbootin.
Installed with the following disk layout: / on 4GB SSD, 1GB swap and 7GB /home on 8GB SSD. (I setup a 1GB swap partition for hibernation and also used ext3 even though some sources say that the flash memory may die during the lifetime of the box.)
One issue I noticed was that my static IP configuration did get lost between reboots. Eventually I created a new connection from scratch and that worked fine.
After installation, I added the Ubuntu EeePC kernel and assorted tools which resolved the WLAN problem (even though I have not actually connected to any access points yet) and got all of the Hot Keys to work.
I thought the screen was a bit dark, so I looked around and found that using the following command makes it much brighter: setpci -s 00:02.1 f4.b=ff. (This may fry the screen apparently, so use at own risk.)
Also, the sound volume was very low. Appending the following to /etc/modprobe.d/alsa-base fixed this: options snd-hda-intel model=auto

Everything else is pretty much ok. Apart from smaller fonts and makingg windows go above the top panel (with: gconftool-2 --set /apps/compiz/plugins/move/allscreens/options/constrain_y --type bool 0), I have not really made any changes.

I am typing this on the little keyboard of the 901 and it is actually quite usable even though I would not want to type pages and pages on it. (Somehow the Blogger editor behaves a bit funny, but I guess this has nothing to do with the hardware but if anything with Firefox 3.)

So far, I think this is an excellent little machine - it even plays Big Buck Bunny in 720p without any problems. ;-)

Etch Upgrade - Sweet As

2007-05-07T07:42:00.000+10:00

I upgraded my little file & print server and firewall (in UML) VIA C3 box on the weekend.

Everything went perfectly smooth, it even worked to upgrade via the apt-proxy that's running on the box. Super cool!

The only issue I had was non-working HTTP connections via my Telstra Bigpond cable connection after the upgrade of the firewall UML. In the end I fixed it by forcing the same MTU on the cable-facing as on the LAN-facing interface. It may be related to NAT, but it worked with the same 2.6.18 kernel before the upgrade, so maybe it is an iptables thing.

Mondo Rescue 2.2.2 Packages Ready

2007-05-02T19:16:00.000+10:00

New packages for amd64 and i386 are in unstable now. I did have to fix a few things here and there to get it to work. The biggest change is internal, however, I've finally moved to using upstream's install.sh script for the Debian package.

I've tested with kernels 2.6.18-4-amd64 (amd64) and 2.6.18-4-k7 (i386) and the usual assortment of nasties, i.e. NFS, AFS, LVM & RAID using NFS as restore media and amd64 and i386 as platforms.

Looks like 2.2.3 will be hot on its heels because of a bzip2-related issue with 2.2.2. (I normally use gzip, i.e. '-G' option, because it is heaps faster and compression rates are really only slightly worse.)

IA64 Support for Mondo Rescue!

2007-03-05T20:35:00.000+11:00

The first fruit of my work on Debian IA64 packages for Mondo Rescue are now on http://people.debian.org/~andree/packages/. It took a bit longer than I had anticipated and there was a bit of an interruption while I stayed on beautiful Norfolk Island for two weeks.

Everything should be fine and dandy apart from the fact that restores will currently miserably fail on IA64 because parted2fdisk expects an older version of parted than what Etch and Sid contain.

So, why publish IA64 packages at all if they don't even work, I hear you scream. Well, firstly I thought I give a bit of an update and show that things are actually moving forward. Secondly, maybe I'm lucky and someone is interested in helping out with getting parted2fdisk to work with newer versions of parted or (better) in getting mondo migrated to using parted natively on all platforms (pending Bruno's approval).

Other than that, the packages have a few user-visible improvements and fixes across all supported architectures and they bring the Debian packages a fair bit closer to upstream - see the changelogs for details.

As usual, check out the new packages, let me know if something doesn't (or does) work, get involved! ;-)

linux.conf.au 2007 Gleanings

2007-01-24T20:28:00.000+11:00

I was fortunate enough to attend lca2007 last week and to meet Bruno Cornec, the Mondo Rescue project leader, for the first time in the flesh.

The conference was pretty cool, and I found the quality of the program to be generally impressingly high: Excellent topics, superb presentation skills, humor and genuine passion for the topic at hand. The atmosphere and organisation were great, too - extremely well done, 7 Team!

My personal two highlights were:

Andrew Tanenbaum's keynote because he really sticks to his guns and even after 20 years or so finds new aspects that could make microkernel architectures appealing. This time it is system self-healing and robustness. Even though I yet have to try out the Minix 3 CD I found in my conference bag, I guess he may have a point (and moving functionality into user space has been a happening thing for years now). I found the keynote to be both amusing and instructive and dealing with a pressing topic. Also, even though it probably is far from usable in real-world scenarios, at least with Minix 3 there is code and an actual system to demonstrate the ideas and concepts.
Christopher Blizzard's keynote about OLPC, his participation in the Debian Miniconf distribution discussion and a conversation that we had over lunch after. (Admittedly, I was so excited during parts of the latter that I couldn't decide what topic to bring up, oh well.) My impression is that Chris is a person of integrity and real compassion for Free Software. He appears to have a very positive attitude and comes across as genuine. Chris may not have said that much new during his keynote, but I think he worked the subject of relevance for projects well. More importantly, Chris was the only one in the Debian Miniconf distribution discussion to make a firm stand for Open Source as an ideal and against binary drivers. (Not 100% true, AJ was as well, but really more appearing to report what Debian does. And a question for openSUSE: Do you really think a marketing guy on a discussion panel will appeal to people?)

Apart from the conference as such, it was super cool to meet Bruno. We had a number of good conversations and did some nice hacking, burning the midnight oil a couple of times. And HP gave me a (used) zx2000 (which Bruno carried all the way from France to Sydney!) to enable me to work on the (Debian) Itanium port of Mondo Rescue - thank you HP and Bruno! Bruno's talk was well received, and it was great to actually meet people that use the software that I spend quite a bit of time on. :-)

Finally, there is the Linus phenomenon (so you can tell this is my first
Linux conference) - he amazingly is basically left in peace: People who know him obviously talk to him and he participates vividly in discussions and so forth, but everyone else does the business as usual thing - no autographs, no photos, no nothing. I was (positively) impressed and refrained from asking him to sign my copy of Just for Fun (just kidding).

Finally, finally, I propose to find an alternative for the term 'awesome' next year. ;-)

Debian Pre-Release of Mondo Rescue 2.2.1, Take 2

2007-01-14T23:42:00.000+11:00

mindi-2.21~r1021-2 and mondo-2.21~r1021-2 are now on http://people.debian.org/~andree/packages/ with the following changes:

petris works again during restore (self-inflicted, oh well).
Restore of ISO images and friends should now work when gzip (i.e. '-G') is used.
The network interfaces should be fine now when booting into a restored system for the first time.

Other than that:

The crash in mondorestore when nuking from tape has disappeared. I have no idea what caused it or why it went away again, though...
Kernel 2.6.18-3-k7 hangs when 'acpi=off' is specified (which is the default as per mindi's ADDITIONAL_BOOT_PARAMS, so restore fails with this kernel). I have filed bug #406809 which may or may not be related to #389931.
The issue with booting a (NTFS) Windows partition failing after a restore appears to be normal as per the ntfsclone manpage:
Usually, Windows will not be able to boot, unless you copy, move or restore NTFS to the same partition which starts at the same sector on the same type of disk having the same BIOS legacy cylinder setting as the original partition and disk had.

I have tried a few things playing with parted and ntfsresize, but so far the only thing that works reliably in order to get Windows to boot is resizing the partition using gparted. I still have to figure out what it is that gparted does differently. (If you know, please tell me!)

Off to bed now so that I'm fine and dandy when I pick up Bruno from the airport in the morning for lca2007. :-)

Debian Pre-Release of Mondo Rescue 2.2.1

2007-01-08T23:15:00.000+11:00

Preliminary Debian packages for Mondo Rescue 2.2.1 are available at the usual place: http://people.debian.org/~andree/packages/. (r1021 is the SVN revision of the actual 2.2.1 release.)

The new version comes with quite an impressive list of fixes and enhancements as can be seen on the Mondo Rescue website. The new '-G' option which allows for using gzip as the compressor is my personal favourite as it really speeds things up! Also, I've finally gotten around to fixing #222065 and there is no more unsolicited creation of directories in /var/cache anymore (neither submitted upstream yet).

Unfortunately, there are a few issues:

Links in directories that actually are links themselves are not resolved correctly (fixed in the Debian package.).
nuke restore from tape makes mondorestore crash (at least on amd64). The workaround is to use automatic or interactive mode.
Windows 2000 does not boot after a restore (at least on amd64). The data is restored but there is something wrong with how fdisk creates the partition (I believe). This actually also happens with 2.2.0 as well, so it is not a regression. I have to look into this more. The workaround is to use gparted (or similar) and resize the windows partition/filesystem by a few MB.
petris doesn't start when restoring (again at least on amd64). Surely the most minor issue I noticed so far...

Anyway, apart from the above, things seem to be ok. Give it a try if you like! If you do find more issues, let us know via the mailing list and - even better - send a patch. ;-)

Other than that, (belated) Happy New Year to everyone! :-)

Mondo Rescue Debian News

2006-12-26T22:55:00.000+11:00

I've used the Christmas time to do some work on Mondo Rescue:

I've uploaded mindi-2.20-2 which fixes RC bug #403454 and important bug #404315. Luckily, I only had to apply patches provided by Matija & Bruno - thanks guys! I've asked for the new version to be allowed into Etch but haven't heard anything yet (maybe I should have waited a few days first or something?).

Also, I've packaged the new pre-release version of Mondo Rescue. You can grab it from here: http://people.debian.org/~andree/packages/. I would much appreciate feedback on how things are working on Etch. So, if you take them for a spin, please let me know how it went, good or bad! The upcoming new release fixes a substantial number of bugs and comes with some notable improvements, so it should definitely be worth checking out.

Finally, when doing some testing I came across a problem with the stock Debian 2.6.18 kernel when used on a Mondo Rescue recovery media. It sometimes already hangs while booting and sometimes starts the restore only to hang later during formatting or even later during restore. This seems to only happen on i386 whereas amd64 is fine. It may also be restricted to my hardware (although it hangs in Qemu as well). 2.6.17 is fine btw. If anyone has an idea what could be causing this, that would be great as I haven't got the foggiest at the moment (there is no message whatsoever, it just hangs).

Upgrade Testing with QEMU

2006-12-03T10:45:00.000+11:00

I have been really busy until two weeks ago [Shameless plug: If you need a (technical) project manager and/or hands-on Basis person to get your SAP R/3 system upgraded to ECC6, get in touch.]. Which means I've been a bit slack - so slack in fact that Andreas Barth had to resolve an RC bug in one of my packages - mea culpa.

Ridden by guilt I decided to finally do what I've been wanting to for some time: Putting the steps together to do a Debian test upgrade using QEMU. I chose QEMU because it is free and readily comes with Debian. It is slower than VMware, at least without the non-free kernel module, but still usable on somewhat reasonable hardware. The actual upgrade steps given below are independent of the virtualisation technology used, so they will apply to VMware as well.

Without further ado, here goes:

install the qemu package
optionally install the kqemu module:

install the kqemu-source package (from 'non-free')
run 'module-assistant prepare'
run 'module-assistant auto-build kqemu' (Daniel, in case you read this: This may be easier than running make-kpkg as suggested in the README.)
install built package with 'dpkg -i kqemu-modules-[kernel version]'
possibly change permisisons/ownership of '/dev/kqemu' to allow non-root users
run 'depmod -a' and 'modprobe kqemu' to load module

create a disk image (Using qcow means we are not using a sparse file, so compressing and decompressing does not inflate the file.): qemu-img create -f qcow hda_40GB_sarge.qcow 40G
get a sarge install CD, e.g. 31r4 netinst
install the initial sarge system:

start qemu e.g. like this: qemu -m 512 -hda ./hda_40GB_sarge.qcow -cdrom ./sarge-31r4-i386-netinst.iso -boot d
start the installer and go through the normal motions
restart qemu like this: qemu -m 512 -hda ./hda_40GB_sarge.qcow
finish the installation:

select a mirror (Note that DNS is not setup - fix this or use IP addresses for repositories. Also, something like apt-proxy comes in quite handy.)
choose 'manual package selection' in the installer
update the packages as suggested by aptitude
quit aptitude and finish the installation

now would be a good time to take a copy of the fresh sarge install before continuing:

halt the (qemu) system
copy the image file, e.g.: cp hda_40GB_sarge.qcow hda_40GB_sarge_pristine.qcow
compress the copy (The uncompressed image is ~ 1GB, the bzip'ed one ~ 100MB.)

install X:

start aptitude, select 'x-window-system-core' and install
leave all X config settings standard, except:

mouse device: /dev/psaux
mouse type: PS/2
screen size: 1024x768 (or similar)

install Gnome (That's just what I use, KDE or others are equally fine.):

start aptitude and select the following packages and install:

'gnome-desktop-environment'
'xscreensaver'
'gdm'
'gdm-thmes'
'synaptic'
'menu'
'menu-xdg'

quit aptitude
restart gdm: invoke-rc.d gdm restart

now might be a good time to take another copy of the sarge install before continuing:

halt the (qemu) system
copy the image file, e.g.: cp hda_40GB_sarge.qcow hda_40GB_sarge_gnome.qcow
compress the new copy (The uncompressed image is now ~ 2GB, the bzip'ed one ~ 540MB.)

install other software as desired that you want test the upgrade with, e.g.:

'mondo'
'mondo-doc'

perform the upgrade (following the preliminary Release Notes):

get to the command line in the qemu system, e.g. by running 'invoke-rc.d gdm stop' in a gnome-terminal
change apt source from sarge to etch
run 'apt-get update'
upgrade the kernel by running 'aptitude install linux-image-2.6-486' (This is not what the Release Notes say but it works for me.) (Say 'Yes' to removing the running kernel.)
upgrade aptitude by running 'aptitude update aptitude'
upgrade the system by running 'aptitude -f --with-recommends dist-upgrade'
if applicable, rerun and keep rejecting offerings to resolve conflicts until the one upgrading mondo is offered (I'll have to look into this.)
run 'aptitude -f --with-recommends install gnome-desktop-environment' to reinstall Gnome

All in all, things seem to work ok. However, this is far from hitting the friendly green upgrade button and it just happens. So, I thought I try the next best thing to the friendly green upgrade button which is synaptic. Doing an upgrade with synaptic does actually work quite smoothly. It needs to be restarted a few times, leaves some cruft in terms of obsolete and orphan packages and the reboot doesn't really work from within Gnome, but other than that it is ok. Most notably, it didn't leave me with an unusable system in the middle of it all.

Robert Collins made some interesting remarks about the challenges of upgrades last week when we had dinner with Martin Krafft and a number of other great people. It looks like the Ubuntu folks are working on improving update-manager but also the underlying infrastructure to smooth out the upgrade process. Maybe there could be an opportunity to work together on this and achieve a situation where upgrades become as smooth as installs are now due to the fantastic work of the d-i people.

New Upstream Mondo Rescue Packages

2006-10-09T23:22:00.000+10:00

I have just uploaded mindi and mondo 2.20 (version numbers are now the same for mindi and mondo).

This release marks a bit of a milestone in that we can ship the pristine upstream source in Debian for the first time because the busybox binaries were removed upstream. This together with the numerous bug fixes and stability improvements and combined with the fact that there are no revolutionary new features (despite the version number jump) made me decide to try and push the new upstream version into etch.

'Try' because although I've tested things quite thoroughly on both amd64 and i386, there is always a residual risk (one of my favourite alliterations ;-) ) of something bad slipping through. I think that taking this risk is justified, though, because 2.20 should be a definite improvement over 2.09. Bruno and I worked really hard to get this released in time for etch (Thank you, Bruno, for making my priority your priority!).

While testing, I found #389931, #389729 and #390653 (Thanks for your great help, Russ!). I've also found that archiving to tape doesn't work for me (still gathering more information, so no bug report yet), but it also fails with 2.09, i.e. there is no regression.

Main testing was performed on:

sid, amd64, linux-image-2.6.18-1-amd64 (2.6.18-2), with NFS & AFS mounts, LVM, RAID1 & RAID5, onto NFS

sid, i386, linux-image-2.6.18-1-k7 (2.6.18-2), with NFS & AFS mounts, onto DVDs

Oh, and this also contains the fix for RC bug #391127.

People seem to be using Mondo Rescue on 'vintage' versions of Debian which is presumably due to Mondo Rescue being disaster recovery software. So, I've made a change to post-nuke suggested by Augustin Amann (Thank you, Augustin!) to make people using the latest packages on sarge happier. I'm still in two minds about adding versioned depends on grep and binutils to make the life of woody (!) users a bit easier as well.

Freedom vs. Engineering, Part II

2006-10-08T22:30:00.000+10:00

Ingo: What you describe is still an engineering problem, not one of freedom. If you can't do it yourself, you could find someone to do it for you. The point is that all the bits and pieces are freely accessible.
If you truly believe that the dependencies on tmpfs and udev should only be recommends, then I think you should file bug reports against the affected packages.

PS: I've had trouble with package dependencies as a user myself. I've also had a bug filed against one of my packages where I did reduce a depends to a recommends. So, I think I understand where you are coming from and generally agree that dependencies can be a chore. My point is merely that this is not about freedom but about engineering.

PPS: Seems like the PS turned out as long as the post. ;-)

RE: Being forced into non-freeness of choice by Debian packages

2006-10-08T16:09:00.000+10:00

Ingo: Maybe I am a bit over-sensitive here, but whilst I feel your pain, your complaint is a pure engineering issue and has nothing to do with (software) freedom. You have all the freedom to take the software packages you mention and change them so you don't have to use udev or tmpfs.

Debian Voting Galore

2006-10-08T14:08:00.000+10:00

I've crawled out from underneath my Mondo Rescue stone and looked in bewilderment at the various vote messages in my inbox. (It's not quite as bad, I've followed things to some detail passively on private and planet.)

The main questions seem to be:

Is it good or bad to collect money to pay people for getting specific tasks done in Debian? Does involvement of the DPL in such an initiative constitute a conflict of interest?

What is more important to the project, freedom of the content or hardware compatibility of the system shipped with Etch?

Here is how I've voted and why:

a65763d3-b1e2-4530-8ff8-aa5915274eb4
[ 1 ] Choice 1: Re-affirm DPL, wish success to unofficial Dunc Tank
[ 2 ] Choice 2: Re-affirm DPL, do not endorse nor support his other projects
[ ] Choice 3: Further discussion

49a98df6-2bd4-40c8-a559-7e15212dbd26
[ ] Choice 1: Recall the project leader
[ 1 ] Choice 2: Further discussion

I think AJ is trying to improve things in Debian and that Dunc Tank is one attempt to do so. I believe it is a worthwhile attempt and can understand that he wants to be involved. While I also understand the concerns raised by other people, I believe that only time will tell whether Dunc Tank is in fact good or bad for Debian (I hope it's good). As far as the conflict of interest issue goes, I think it's less than ideal but the smaller evil to keep AJ as DPL whilst he's involved with Dunc Tank. I don't think AJ should run again if he stays involved in Dunc Tank as he is at the moment. I think that we need to consider integrating Dunc Tank into Debian if it is still alive and kicking in 12 months time. (Or to set up something similar as part of the project.)

c2d43675-9efa-4809-a4aa-af042b62786e
[ 1 ] Choice 1: Release Etch even with kernel firmware issues
[ 2 ] Choice 2: Special exception to DFSG2 for firmware as long as required [3:1]
[ ] Choice 3: Further discussion

22fc4edd-1f6c-454f-b204-6aa0bad0ce1d
[ ] Choice 1: DFSG #2 applies to all programmatic works
[ 1 ] Choice 2: Further discussion

I believe that we should indeed release Etch as planned even if that means shipping a number of firmware blobs. I do not think that an ongoing exception is appropriate here. If this is still not resolved by the time we want to release Etch+1, let's have an other GR.

I am not sure what "program" really means in DFSG #2 - I've always taken it to mean the software, documentation, fonts and artwork that we ship as part of Debian. It likely has to comprise more than that, but I am convinced there have to be some exceptions:

It defeats the purpose and very nature to modify licence texts. If people can change a licence at will, there is not much point having one in the first place.
It equally defeats the purpose to modify logos (and thus their representations as files of whatever format). Logos allow users to recognise more easily what content is available. It does not make sense to allow modification or use in a different context of such a logo as it would then be more confusing than helpful.*

I believe that these are just two examples of potentially many where 'free' versus 'non-free' are inadequate categories to think in.

Finally, the DFSG are part of the Social Contract and not the other way round. I like this because I value doing the best for our users higher than some rules. The DFSG exist to empower our users - I don't believe that removing firmware blobs from the kernel serves this purpose. That said, we should by all means strive towards free firmware, but I view this as more of an incremental, ongoing task of convincing vendors over time.

* I believe for example that the dispute over Firefox would be best resolved by Debian using the Firefox logo (and name) and the Mozilla folks dropping there requirement for patch review.

Pre-Release mindi and mondo Packages Available

2006-09-24T22:50:00.000+10:00

I have some hopes that mindi 1.20 and mondo 2.20 will be released sufficiently early for the freeze (i.e. soon ;-) ). To help ensuring that things are indeed in good shape at release time, I thought, I make some pre-release packages available.

Please test and send feedback - good or bad!

I've done some testing myself on amd64/DVD and i386/NFS with good results apart from the missing fixes for #320152 and #379966 - they will be in upstream or the final package versions though.

Yeah - OpenOffice packages for amd64!

2006-09-24T15:06:00.000+10:00

Just noticed the new native 2.04~rc2 OpenOffice packages for amd64 in unstable. My first impression is: Wow, I've never seen writer starting up so fast! (Way under a second.)

Congratulations to the Debian OpenOffice.org Team!

Bending the DFSG a little...

2006-09-20T22:39:00.000+10:00

...is what Mike Connor appears to be suggesting here. As far as I can tell, this has already happened - the way I interpret #8 of the DFSG, it is not just about Debian and derivatives but absolutely everyone including Osama Bin Laden and George Walker Bush and even John Howard. ;-)

Seriously, though, I perfectly understand that Mozilla needs to protect its brand and they certainly have every right to do so. And we have every right to change the name and modify the code without asking anyone for approval. A right that we will have to exercise by the looks of it. How about 'freefox' (probably too close) or the 'browser otherwise known as firefox', short 'bokaf' (anyone?).

I believe that Mozilla is doing the free software movement a disservice when they are as hard-nosed about their brand as it appears they are. They certainly need to put mechanisms in place to protect themselves from the Dr. Evils of the world. Debian most definitely does not belong into this category (neither do Redhat nor Suse nor any other Linux distribution I can think of). So why not just let sleeping dogs lie?

Eric Dorland and Steve Langasek are my heroes for remaining calm and on topic in the discussion.

AFS Support for Mondo Rescue

2006-09-19T21:17:00.000+10:00

I've finally uploaded mondo-2.09-3 packages which contain the changes to get Mondo Rescue working with AFS to fix #385790. I should have communicated better with Bruno because he has done some work in parallel on this. We have come largely to the same conclusions, though, which is always reassuring.

2.09-3 also has some more changes done in the post-nuke arena. I felt that because it is now an integral part of the Debian package it needed some more love. Changes are:

Log the fact that no post-nuke script was found during restore.
Perform after nuke steps even if we dropped back to interactive mode because of issue with mount list.
Ask user after nuke to wait until s/he is returned to command prompt before rebooting.
Use run_program_and_log_output() instead of system() to get output of post-nuke logged.
Output screen messages about post-nuke.

With these changes added, post-nuke behaviour is still not perfect but probably good enough for now. Hopefully, Bruno agrees and accepts the changes upstream.

Finally, I've managed to get hold of a VXA-1a tape streamer. It's IDE which sucks because Debian removed ide-scsi from the standard kernels a while back, so the vxaTool doesn't work (yes, I know how to compile kernels, but I like to run a standard environment so that I can pick up on and reproduce issues). Then again, it's just for testing anyway and I can report that I've successfully done test runs with Mondo Rescue using it.

Speaking of testing, mondo-2.09-3 was tested:

on sid amd64
running kernel 2.6.17-2-amd64 (2.6.17-9)
using DVD and tape (!!) as backup media (NFS is still stuffed)

(mindi-2.09-2 which I uploaded a few days ago was basically tested the same.)

Easy Peasy AFS on Debian

2006-09-12T21:08:00.000+10:00

Bug #385790 prompted me to set up an AFS client on my sid installation. This is something I hadn't done since I left uni almost nine years ago. Back then it was a bit fiddly to get the Transarc AFS client for Linux to work if I remember correctly.

Things have quite obviously improved since then. The following is all that was required (with some helpful information provided by the submitter - thanks, Kevin!):

install packages openafs-modules-source and module-assistant
follow the instructions in /usr/share/doc/openafs-modules-source/README.modules, i.e:

module-assistant prepare openafs-modules
module-assistant auto-build openafs-modules
dpkg -i /usr/src/openafs-modules-.deb

install package openafs-client and configure like this:

leave AFS cell of workstation at default, i.e. local domain
leave cache at 50000 kb
leave DB server host for home cell blank
answer 'Yes' to 'Run Openafs client now and at boot?'

if this doesn't work, run dpkg-reconfigure openafs-client like this:

leave AFS cell of workstation at default, i.e. local domain
leave cache at 50000 kb
answer 'Yes' to 'Run Openafs client now and at boot?'

answer 'Yes' to 'Look up AFS cells in DNS?'
answer 'Yes' to 'Encrypt authenticated traffic with AFS fileserver?'
answer 'Yes' to 'Dynamically generate the contents of /afs?'
answer 'Yes' to 'Use fakestat to avoid hangs when listing /afs?'
leave DB server host for home cell blank
answer 'Yes' to 'Run Openafs client now and at boot?' (again)

...and restart openafs-client afterwards

(The need to reconfigure may be a bug, not sure.)

In summary, OpenAFS and Sam Hartman's packaging effort make AFS a breeze to install on Debian!

Now all I have to do is find the time to fix the bug. ;-)

[Update] Important detail I forgot to mention: Open port 7001 on your firewall for UDP.
[Update] Added what to answer, i.e. 'Yes'. Doh.

SAP on Debian

2006-09-10T19:29:00.000+10:00

SAP has supported Linux for many years. Debian, though, is not one of the supported distributions which I find unfortunate because I am an SAP consultant and a Debian developer. ;-)

I have manually installed an SAP Testdrive system on Debian from RPM packages years ago which was very painful. Gregor Wolf's instructions on SDN make things look much less daunting for a regular install. Hopefully, I'll have a chance to try this in the next couple of months...

Mark Shuttleworth on Debian

2006-09-10T19:00:00.000+10:00

Mark's take on what Debian's strengths and weaknesses are makes for an interesting read. The way I interpret it, he wants us to be the plateau that other parties can put their spikes on top of (to use his symbolism). He mentions etch towards the end as one of those spikes, but essentially suggests we focus pretty much all our energy on sid because this is what we are good at and where our passion lies.

I beg to differ.

I firmly believe that Debian must remain relevant as an end-user distribution. Not only because essentially this is what our Social Contract is all about but also because without (relevant) releases I very much doubt we'd be able to keep the momentum and attract (or even keep) good people as (new) developers.

From Mark's point of view, his line of argumentation certainly makes sense: The better sid, the better a derivative like Ubuntu. From our point of view I believe it doesn't.

And by the way, I do run sarge on my machine as "production" environment and I am thus much looking forward to the release of etch.

That said, I do think that Ubuntu is better than Debian in some ways (but certainly not all), so on this I agree with Mark. I am just not sure that this really has to stay this way. Competition is good. ;-)

Vista rocks, AIGLX/Compiz is so, so

2006-09-04T22:59:00.000+10:00

Nothing like the above to get a bit of an audience, I guess... ;-)

I tried the freely available (i.e. no Passport account or other crap required) pre-RC1 build of Windows Vista sometime last week. Whilst I didn't delve all that deeply into new stuff that's under the bonnet, I played around with the new Aero GUI a bit. And I must say that I'm somewhat impressed. I thought the Luna style of XP was totally, utterly and completely ridiculous when I first saw it. Compared to that, Aero is quite neat and subtle. I rather like the frosted glass effect of the window title bar, the way windows are stacked at an angle for easy selection, the glowing window buttons and a few other bits and pieces.

I've since wiped that disk and installed Fedora Core 6 Test 2 to have a look at AIGLX/Compiz. I thought I use Fedora since this is where AIGLX originates. I'm not at all excited about XGL because it appears to pretty much require proprietary drivers - not good. (I've actually got a Radeon 9600 which has experimental but AFAICS working 3D acceleration in Xorg from version 7.0). So far, so good. I got the cube thing working, wobbly windows, window and menu shadows, minimise/restore window effects, the 'film' desktop chooser, transparency on move and likely more that I can't recall right now. It's all working and not crashing. The only issue is that it doesn't feel "natural" (for lack of a better word). Maybe it's because there is a bit of a lag when doing something for the first time or after a while, i.e. moving a new and large window or spinning the desktop cube. I certainly think that my Radeon 9600 card should be up to it - after all it spins the cube at break-neck speeds. When doing similar things on OSX or even Vista it feels like this is just what you do; with AIGLX/Compiz it more feels like "Look what I can do!" without that certain matter-of-course-ness. Or, to reveal my age ;-), it feels a bit like early eighties pop music that had just discovered the possibilities of digital synthesizers. (Also, and this can probably be considered a real bug, scrolling in Firefox is dead slow with AIGLX/Compiz.)

Having said all that, I'm surely and truly excited about the possibilities of a vectorised desktop and think it's got oodles of potential. And I'm equally surely and truly appreciating the work people have put into this. I've merely come to realise that the blurred videos on youtube may not necessarily convey the current state of affairs with total accuracy.

linux.conf.au

2006-09-01T21:57:00.000+10:00

linux.conf.au will be held from 15 - 20 January 2007 in Sydney, Australia.

Hopefully, Bruno and I will be given the opportunity to share with others our experience with upstream/downstream maintenance of Mondo Rescue. The presentation we have submitted about this is called "Mondo Rescue & Debian - an Example for Upstream/Downstream Collaboration".

It would be positively fabulous to actively participate in the conference and to be surrounded by people that share the same interest in FOSS. And meeting Bruno in person would be cool, too - after all, we've worked quite closely together for a year now without even speaking to each other. Maybe we'd even get some hacking done! ;-)

I am excited!

POSIX Documentation

2006-08-30T23:18:00.000+10:00

For some reason, I always thought that it costs money to access the POSIX Standard. Not so - it's freely available (and they even provide a Firefox search plugin)!

Cheap Thrills (mondo 2.09-2)

2006-08-30T21:50:00.000+10:00

I've just uploaded mondo 2.09-2 which comes with a number of improvements and bug fixes (one reported and more unreported):

No more garbled screens or error messages because of insufficiently escaped strings used in system() or popen(). (Well, not quite true, but the one known issue should be fixed now with new function module mr_stresc() that can be used wherever else needed.)
mondorestore will now ask in non-nuke mode whether an existing post-nuke script is to be executed. (Doing this is generally a good idea on Debian as the post-nuke script in the package updates the initrd image to adjust for RAID and other system changes.)
Fixed issue where stabgrub-me would fail if /etc/grub.conf is a symbolic link preventing the user from editing the grub config file. (This requires readlink which I've added to mindi-busybox, hence the new mindi-busybox package version.)
I was getting segmentation faults in space_occupied_by_cd() - it's not a good idea to do fin = popen(...) followed by fgets(...,...,fin) without checking the success of the former. Fixed this by evaluating errno after the popen() call. (Strangely, with the errno checking in place, popen() doesn't seem to fail anymore, which might indicate a different underlying issue althogether - we'll see.)

Whilst working on the above I also experienced problems with ntfsclone and the still very present NFS issue with kernel 2.6.17.

Because of bespoke NFS issue I tested with DVDs as backup media on amd64 with kernel 2.6.17-2-amd64 (2.6.17-7).

Blast from Your Past...

2006-08-25T21:30:00.000+10:00

...is not only an interesting Ringo Starr album, but also describes quite fittingly the nature of an email I received today from Nathanael Nerode.

In his email, Nathanael inquires about #16827, which I had filed a whopping eight years and 231 days ago today.

I hadn't used neither olvwm nor LyX for many years (although especially the latter served me extremely well at the time). But I thought that Nathanael boldly going where noone had gone for more than eight years deserved an equally bold answer, so I installed and tested. The good news is that the issue does indeed appear to be fixed! :-)

Aurelien Jarno is my hero! (New mindi-busybox package)

2006-08-20T10:12:00.000+10:00

There was this long-standing problem with Mondo Rescue that during restore runs the virtual consoles wouldn't work on amd64. I managed to finally track this down to a rather bizarre bug in glibc.

The problem is actually fixed in glibc 2.4. When I found out that 2.4 is not going to make it into etch, I asked whether the fix could be backported to 2.3. To my total delight, this is exactly what Aurelien did! Thank you a lot, indeed! :-)

Without further ado I thus bring you mindi-busybox-1.2.1 with working virtual consoles. (The only other noteworthy change is that there is a link now from /etc/mtab to /proc/mounts in the restore system to keep the new upstream busybox happy.)

Testing was done on:

sid, i386, stock Debian kernel 2.6.17-2-k7 (2.6.17-6) to NFS
sid, amd64, stock Debian kernel 2.6.16-2-k8-smp (2.6.16-17), LVM & RAID to NFS

Of New Hardware, New Packages, Bugs & Kernels

2006-08-13T20:47:00.000+10:00

I decided that before my socket 939 ASUS A8V Deluxe motherboard becomes obsolete, I should do an upgrade to dual-core. It so happened that my dealer had an Athlon64 X2 4800+ returned to him the other week, so I went for it. It's the fastest that the board supports and comes with juicy 2x 1MB L2 cache (which apparently got axed by AMD now as part of the price-battle with Intel). My only concern was about power/heat/noise because it's the 110W model, but to my delight it appears to be running cooler and quieter than the (130nm) 3500+ I had before. Cool! ;-) While I was at it I also doubled the RAM to 2GB and bought two SATA hard disks and a swappable tray system for them.

The latter was mainly so I could do some tests in regards to #380703. The outcome is that restore works fine with SATA disks on above motherboard using its Via SATA controller (haven't tried the Promise one yet). So far, so good - or rather bad, because I can't produce the problem.

At least I do have a fix for #379966 which basically entices the introduction of a new function mr_stresc() to properly escape things when using system() or popen(). It's gone through a few revisions both by the submitter and upstream (Thanks Steve & Bruno!) and should be in upstream soon.

For the time being, I have just uploaded mindi-1.09-1 and mondo-2.09-1. They are purely new upstream versions and don't close any of the open bugs - hopefully, this will follow soon. Testing was done on an etch system using a SATA disk and a sid system using PATA. The archiving mode was NFS both times and the kernel used was also the same, i.e. 2.6.16-2-amd64-k8-smp (2.6.16-17).

I am experiencing problems with 2.6.17 kernels and creating ISO images on NFS mounts using mkisofs. mksiofs would just hang sooner or later whilst writing the image file. With 2.6.16 there is no such issue. And neither cp nor dd have this problem with 2.6.17. Weird. I'll have to do some more testing and probably will bring it up on the debian-kernel list before I file a bug report.

The best way to find out whether a bug is gone...

2006-07-26T23:10:00.000+10:00

...is to close the bug report and to see what happens. Or so it seems:

I decided to finally close #291975 last week after having been unable to reproduce the problem for some months. I've done this once before about a year ago but the issue resurfaced straight after. :-( (I have filed #290722 and later #351367 in regards to this.)

Anyway. A few days after having closed the bug report for the second time, version 0.52.2-5.1of libnewt0.52 is released and brings the problem back again - I've filed a new bug for this: #379938. (Maybe I should have just updated #351367 instead, but then again the issue is so very clearly tied to version 0.52.2-5.1 of libnewt0.52 - and also, I'm sure Alastair will merge as required.)

In light of this, becoming superstitious looks like a viable option...

I really enjoyed reading this...

2006-07-26T00:55:00.000+10:00

Greg must have given an amazingly insightful, inspiring, and amusing keynote at OLS:

http://www.kroah.com/log/linux/ols_2006_keynote.html

I truly enjoyed reading this, maybe you will, too...

mindi-kernel package is going

2006-07-24T22:28:00.000+10:00

I've taken a deep breath and finally filed a request to get the mindi-kernel package removed from etch and sid.

mindi-kernel has been obsolete and hasn't been used by mindi for some time with apparently no detrimental effects, also it has always been i386-only and thus was never available for amd64.

What got me finally over the line was the announcement that we will not ship etch with 2.4 kernels - yeah!

Bag of Little Fixes

2006-07-22T19:35:00.000+10:00

mondo-2.08-2-3 and mindi-1.08-2-1 are now in incoming and hopefully soon at a Debian mirror near you.

Apart from (finally) fixing the compiler warnings on amd64 by changing some int variables to long and a fix for image sizes getting wrongfully changed in mondorestore's partition editor, this is mainly about reducing screen corruption during restore - for people using RAID and/or LVM, the newt screens should not get partially or totally overwritten by some crap anymore.

I spent quite some time on the screen corruption fixes, partially because I have little knowledge of newt, partially because restore runs are always a pain to trouble-shoot and partially (especially in retrospect) because I can be a bit thick at times. ;-) However, I feel that fixing these types of "cosmetic" issues is well worth the effort, because it improves user experience and increases faith in the software - pretty important, particularly the latter, especially for disaster recovery software like Mondo Rescue. (It obviously still has to live up to it! ;-))

The new versions were tested on sid amd64 and i386 with native kernels and using NFS as backup media. Oh, and mindi should now also build out of the box on Ubuntu Dapper Drake.

New mondo package: Fixes for some (longstanding) bugs & Ubuntu

2006-07-07T19:45:00.000+10:00

mondo-2.08-2-2 fixes three bugs, namely #369321, #222052 and #292782.

I am particularly happy with the two latter ones even though they were only minor and wishlist, respectively. But they were fairly longstanding, and it makes me feel good that I finally got around to fixing them.

I've also gone through all the remaining bugs again, nagged the submitters where appropriate and closed some (with submitter agreement), especially the ones about LVM and RAID because I feel they have been fully addressed now. The result is that mindi has currently no open bugs and mondo is down to nine. Certainly not as cool as what Steinar H. Gunderson is doing to the RC bug count, but still not bad. ;-) Hopefully, I'll be able to get the bug count down even further.

I've also worked on Ubuntu support with the result that things should function out of the box on Dapper now, i.e. the package should build and run fine.

mondo-2.08-2-2 was tested on:

NFS on i386 sid with kernel 2.6.16-2-k7 (version 2.6.16-15) with command line parameters

DVD on amd64 sid with kernel 2.6.16-2-amd64-k8 (version 2.6.16-15) in interactive mode

DVD on i386 dapper with kernel 2.6.15-25-686 (version 2.6.15-25.43) in interactive mode

Enjoy. ;-)

Meeting Melbournian Debian Developers

2006-06-29T09:11:00.000+10:00

I only sent a [VAC] message on Sunday asking people whether they'd be interested to meet in Melbourne this week. To my great surprise and delight, this resulted in a nice Japanese dinner at Ginza with Russell Coker, Hamish Moffat, Anibal Monsalve Salazar and Jason (sorry, no full name) followed by a drink in a pub in the city. (The drink was actually free as in beer due to Russell organising some vouchers - very good! ;-) )
We had interesting conversations about various topics including Debconf6 which Anibal had attended and it was really good to meet some other Debian developers. Hamish stayed a bit longer and we had a good conversation about packaging, Ubuntu and the general direction of Debian.
In summary a very nice evening - thanks guys! ;-)

Sometimes Things Just Work

2006-06-27T09:11:00.000+10:00

I'm in Melbourne for the week, so I thought I take a laptop with Ubuntu Dapper from work with me to see how Mondo Rescue works on it.
I had prepared myself well by making sure that all build dependencies where installed - or so I thought. It turned out that I couldn't install the freshly built packages because some binary dependencies where not installed - very clever. Not.
I didn't have Internet access in the hotel, the winmodem in the laptop doesn't work with free software and there were no (free) WLAN access points. I did, however, have my Treo 650 with an SD memory card. Also, I noticed for the first time that the laptop actually has an SD card slot. I tried the card from the Treo in the laptop and amazingly enough it just worked. (There you go, another glorious Ubuntu success story...) So, I downloaded the necessary packages using the Treo's Blazer webbrowser (which didn't go all that smoothly, downloading stalled all the time basically, but removing and reinserting the SD card helped here), and then installed from the SD card onto the laptop.
Looks like Mondo Rescue is running quite well on Ubuntu Dapper at least in the standard install, i.e. no RAID and no LVM. Cool. Writing to DVDs directly literally takes hours, though. No idea why that is, so I haven't run out of things to keep me entertained yet. ;-)

New x.0.8 Mondo Rescue Debian Packages

2006-06-18T19:19:00.000+10:00

mindi-1.08-2-1, mindi-busybox-1.00-7 and mondo-2.08-2-1 are now in incoming. The main changes apart from being new upstream versions are:

LVM support,
includes Debian-specific post-nuke script to update initrd images after restore,
fixed DHCP support, i.e. using something like 'nuke ipconf=dhcp:eth0' should work now (feature done by Bruno, I just ironed out some scripting buglets).

I have switched over to upload amd64 packages partially because I wanted to and partially as a workaround for the still unamended Packages-arch-specific file. If anyone can tell me how to get this changed, I'd be very grateful. Other than that, I have double-checked that i386 builds in pbuilder, so fingers crossed that i386 packages are going to get built automatically.

The packages were tested doing a full archive and restore run on sid i386 (NFS) using kernel 2.6.16-2-k7 (2.6.16-14) and on sid amd64 (ISO/DVD) using kernel 2.6.16-2-amd64-generic (2.6.16-14) (I've had intermittent problems with the OOM killer in -k8 kernels during restore.). The amd64 setup uses a combination of two RAID volumes and two physical LVM volumes one of them on top of RAID with multiple logical volumes. (/boot is a normal partition because I like grub.)

Hopefully, I can now focus somewhat more on the remaining bugs, some of which look like they might entice substantial upstream work. We'll see. Oh, and upgrading mindi-busybox to 1.1.3 would also be nice, there is a problem with mount/mtab support that I have to get to the bottom of first.

All in all, with both RAID and LVM support pretty much there (knock on wood), Mondo Rescue in etch should be much improved over the version in sarge.

Long time, no blog

2006-06-14T20:31:00.000+10:00

I just noticed that I haven't written anything for more than three weeks, so I thought it's time to give a little bit of an update:

Packaging mindi 1.0.8 and mondo 2.0.8 is coming along nicely, albeit with more work involved than I was actually hoping for. I've put together a bit of a list of issues and their workarounds. Interestingly enough, nothing of this stuff is actually related directly to Mondo Rescue.

I have put some effort into LVM2 support and am now able to restore an amd64 Sid system with RAID and LVM2 (on top of RAID; /boot is still a normal partition because I like grub). Also, I have added a post-nuke script that rebuilds initrd images to adjust them to things like different IDE controllers on the restore system. It still has some shortcomings which I hope to address in future versions.

Hopefully, I'll be able to release new packages within the next few days.

Supermarket of Components

2006-05-25T23:32:00.000+10:00

Whilst my contributions are totally dwarfed by those of Joey Hess, I wholeheartedly agree with what he says - Debian should be more than just a large collection of readily available packages. Ubuntu is great, but Debian should be able to innovate in different ways because of its different structure and longer release cycles (which can be both a burden and a blessing). I really would like to see Debian staying relevant to end-users, otherwise many people may eventually just stop contributing. That would be a big blow for all the derivatives as well, not just Debian itself.

[Update: Fixed 'what he says' URL.]

Debian Installer rocks!

2006-05-25T22:46:00.000+10:00

I spent some time the past week looking into virtualisation to make installing and restoring installations with Mondo Rescue a bit less disruptive and more efficient. So, I ended up doing a fair few Debian installations. I figured that with all these virtual machines all of a sudden, it would make sense to upgrade my caching-only name server to handle the local network to save me the effort of having to maintain lots of hosts files.

To my pleasant surprise, I found that this also resulted in the hostname and domain being automatically filled in by the Debian Installer (even without DHCP)! Good stuff! Also, the graphical installer in the i386 daily builds is just awesome!

Conclusion: The d-i people do positively rock big time!

Mondo Rescue RAID Support at Last

2006-05-14T18:29:00.000+10:00

CeBIT Australia ate substantial amounts of my time for the last two weeks (and almost killed both my feet and my voice but was still interesting and fun), so things took a little longer in Mondo Rescue land. But at last, here it is: mindi-1.07-3 and mondo-2.07-2 are in incoming and add the much overdue RAID support for Debian!

What it does (from the shiny new NEWS.Debian file):

This is the first release supporting RAID via mdadm. It is supposed to work with all RAID levels/varieties supported by mdadm and the kernel.

The following limitations and oddities apply:
All information about existing RAID arrays is drawn from /proc/mdstat, the contents of an mdadm.conf file is ignored.
Using RAID for the boot device is currently untested. The system will likely be unbootable after a restore.
Using LVM in conjunction with RAID is currently untested. Restore will likely fail.
Building a RAID5 array may appear to hang the system because of extended screen inactivity. However, disk activity should be high and eventually the restore will continue.
The synchronisation progress bar and the formatting progress bar may overwrite each other leaving the screen somewhat garbled. Not nice but harmless.

I have intensely tested this with various RAID levels, chunk sizes, parity algorithms, with and without spare disks and so forth. In particular, I've done successful full archive and restore runs using NFS as storage media for the following:

amd64, RAID1, kernel 2.6.16-1-amd64-k8 (2.6.16-12)
amd64, RAID5, kernel 2.6.16-1-amd64-k8 (2.6.16-12)
amd64, RAID10, kernel 2.6.16-1-amd64-k8 (2.6.16-12)
i386, no RAID, kernel 2.6.16-1-k7-smp (2.6.16-10)

I'll post the patch to #325877 for reference purposes and will also commit to upstream SVN shortly. Bruno was kind enough to review that patch and likes it, so there shouldn't be a problem (other than some fiddling because I have worked off the Debian 2.07-1 package and not tracked upstream).

Apart from fixing issues with the above, I plan the next steps to be:

support for RAID boot partitions
getting LVM to work

However, I think I'll do a fresh install of Sid AMD64 before that, to ensure that d-i created systems work with Mondo Rescue.

Also, I am experiencing a strange behaviour with busybox on AMD64 in that I get the following message on virtual terminals (and no prompt):

./sh: Cannot set tty process group (Operation not permitted)

when I run:

./openvt 8 ./sh

(where ./openvt and ./sh are both links to ./busybox)

This happens with 1.00 as well but in either case only on amd64, i386 is fine. Also, it only happens if NFS support is enabled for busybox mount.

Parsing Text Output in C

2006-05-02T10:41:00.000+10:00

I'm currently working on a better routine to parse the output of /proc/mdstat in Mondo Rescue to get RAID to work on Debian.

Fiddling around with pointers and doing nasty things in general finally got me to think that there must be a better way.

I'm sure everyone else is in the know, but I was quite happy to find the fine GNU C Library Manual where in turn I found strtok() which allows for much cleaner and safer code. Cool.

Also found www.snippets.org. Cool, too.

Emergency fix: mindi-1.07-2

2006-04-30T14:24:00.000+10:00

Two days after mindi-1.07 hit testing, we have a new user - yeeha.

But guess what - mindi crashes and burns. :-(

Morale:

I must test purging and reinstalling before uploading.
I must test purging and reinstalling before uploading.
I must test purging and reinstalling before uploading.
...

Oh, well. Fixed in mindi-1.07-2 which is currently in incoming.

Mondo Rescue Debian RAID Progress

2006-04-29T17:52:00.000+10:00

Sadly, RAID support in Mondo Rescue on Debian has been broken since the raidtools2 package was removed just before the sarge release.

I have finally started on getting things to work with mdadm (whilst retaining raidtools2 support to get this accepted upstream) and sent an initial patch to bug #325877.

Looks like it generally works, i.e. I have successfully restored a sid amd64 system with a RAID1 and a RAID0 array without manual intervention. However, there are some limitations that I'd like to overcome:

hard-coded chunk size
RAID5 parity algorithm is ignored
spare devices are ignored

The main thing is inclusion in upstream, so I am now waiting for Bruno's verdict on the general approach...

2006-04-28T22:31:00.000+10:00

Amaya -- I am very sorry to hear about your loss of Emacs.

Even more so, as Emacs and my cat shared the strong liking for bathtubs. I dread the day when my cat follows on the same path - at least she's already about 15 and so has lived her life. I think it's going to be a gourmet can of her favourite this weekend. Oh well...

mindi 1.07 & mondo-2.07 Packages

2006-04-17T13:00:00.000+10:00

are available from the Debian unstable repository. It's i386 only atm, but amd64 is hopefully going to follow soon. In fact, I'm writing this from a restored amd64 installation.

The upstream ChangeLog can be seen here: http://www.mondorescue.org/.

The main Debian changes are:

package reorganisation to adjust for upstream changes
fix for #357785
fix for #331060
fix for broken '-I' and '-E' parameter handling (from SVN r468)
fix for verify via NFS not working
fixed compiler warnings on i386

There is still a handful of 64 bit related compiler warnings because the code wrongly assumes that pointers are 32 bit and can thus be cast to int that I am not sure about how to best fix:

newt-specific.c: In function 'popup_changelist_from_file': newt-specific.c:1651: warning: cast to pointer from integer of different size mondo-rstr-newt.c: In function 'redraw_filelist': mondo-rstr-newt.c:1007: warning: cast to pointer from integer of different size mondo-rstr-newt.c: In function 'edit_mountlist_entry': mondo-rstr-newt.c:1374: warning: cast from pointer to integer of different size mondo-rstr-newt.c: In function 'redraw_disklist': mondo-rstr-newt.c:2506: warning: cast to pointer from integer of different size mondo-rstr-newt.c: In function 'redraw_mountlist': mondo-rstr-newt.c:2538: warning: cast to pointer from integer of different size mondo-rstr-newt.c: In function 'redraw_unallocpartnslist': mondo-rstr-newt.c:2575: warning: cast to pointer from integer of different size mondo-rstr-newt.c: In function 'redraw_varslist': mondo-rstr-newt.c:2610: warning: cast to pointer from integer of different size

Other than that things have been tested successfully on amd64 with kernel 2.6.16-1-amd64-k8 using NFS as backup media and on i386 with kernel 2.6.16-1-k7-smp using both NFS and DVD as backup media.

With the etch freeze still some time away, I'll try to focus on the following issues in the given order:

get RAID and LVM to work - this is by far the most important task and there are numerous bugs in BTS
improve FHS and other compliance, in particular default the location of the scratch and tmp directories to something sane (cf. #312546) and move the location of floppy and ISO images away from /root and make it configurable (cf. #222065)
fix things so that NTFS restore leaves Windows in a bootable state rather than requiring the workaround using gparted - this may require switching things from fdisk to parted which Bruno doesn't like much...
IA64 support for mondo - depends largely on what happens upstream and probably also on whether I can get my hands on an Itanium box that I can actually reboot and restore...
general clean-up and wishlist stuff

I think I'll be quite happy if 1. and 2. are done before etch freezes (and all new bugs are addressed as well). We'll see.

I am a Debian Developer!

2006-04-09T13:31:00.000+10:00

Amazing stuff, after almost two years, I've become a Debian Developer! I've certainly learned a lot, met numerous nice people (mostly remotely unfortunately). My password is changed, my gpg key updated - so not long now, until I type the commands to make my first upload, undoubtedly with trembling fingers!

I'd like to thank all the people that were involved in making me a Debian Developer. Specifically, I'd like to thank Héctor for making me co-maintainer of mindi and mondo before I even knew what hit me, Ben for sponsoring me, Matthew for being my AM (We should play pool again one of these days!), and of course Amaya, who has helped in so many ways that I don't even know where to start, so I won't.

Thank you all!

I'm on Planet Debian!

2006-04-04T20:08:00.000+10:00

Thanks to the indefatigable and ever helpful Amaya, I'm now on Planet Debian! Thank you also for your nice introduction, Amaya! :-)

Just to drop a few words about myself and what I do:

I am an expatriate German and have lived in lovely Sydney for almost seven years now. I work as an IT professional mainly programming and maintaining SAP systems.

I have been a Debian user for about a decade now and finally decided to become a maintainer almost two years ago when I started to get involved with the mindi and mondo packages that form the quite neat, flexible and versatile disaster recovery suite Mondo Rescue.

It turns out that I got sucked into Mondo Rescue upstream development reasonably heavily mainly because it is quite a low-level tool and thus needs reasonably extensive tweaking to get it to work properly on Debian (or any other distribution for that matter). Upstream (at the time) wasn't all too fond of Debian, but I was given CVS commit access pretty early on which suited my fine as I could commit my fixes directly upstream.

Since about half a year ago, upstream has become much more active, mainly thanks to Bruno Cornec (sorry no link), the new lead developer. So, hopefully for Etch, we will have a much cleaned-up codebase and fully operational RAID and LVM2 support! In the meantime, give Mondo Rescue a go - it is quite cool as it is right now! ;-)

Hopefully, there will be some time soon to look after a few more (maybe less demanding) packages and to get more involved in Debian in general. Oh, and hopefully I'll be a real Debian developer soon - DAM approval on 27 Mar looks promising - thanks, Joerg! ;-)

mindi 1.06-4 & mondo-2.06-4 are out

2006-03-10T10:40:00.000+11:00

Main changes are:

mindi: fix for #354145 so that VIA chipsets do DMA but non-VIA still works
mindi: syslinux configuration files are now created on the fly; this is basically to ramp things up for including this upstream
mondo: document the need for VFAT in the running kernel closes #315733
mondo: removed potentially threatening and intimidating sequence of questions asked after restore; Bruno agrees with this change and it find its way into upstream one way or the other
some more little cleanups

That's it for the next three weeks - as mentioned before I'll be on vacation - yah!!!

In other news, my motherboard arrived and I'm back to normal with my firewall - also yah! ;-)

No New Packages Yet - Here's Why!

2006-03-06T22:39:00.000+11:00

I really meant to have new packages out by now. It hasn't happened yet. Here is why:

I electrocuted my firewall. Embarrassing, I know, but I did: I've got a little box based on a VIA Epia-PD6000E motherboard. Small, unobtrusive, black and acting as a file and print server and as a firewall (via separate UML). A few weeks ago, it got struck by lightning (well not really, just a surge, I suppose, during a thunderstorm), which took out the ethernet ports both in my cable modem and on the board. Last Thursday, I decided to put in a second fan serialised with the first one to reduce noise but keep airflow up. While I was putting it in, I fumbled around with a life 12V wire and touched one of the connectors of the single PCI slot - there was the tiniest of sparks and me going f@#$%%&ck. After that, the board was history... My dealer tells me I can pick up a new one tomorrow.
I am getting the most spectacular crashes when using (as I have now narrowed down to) linux-image-2.6.15-1-amd64-generic (on amd64). Pretty much towards the end of a restore run, something segfaults and causes the init script to get respawned indefinitely - impressive but annoying. I have decided, though, that this is not related to my packages. Unfortunately, one can't yet report bugs against amd64 packages as the architecture is not yet integrated into the Debian infrastructure. Oh well.

Apart from that, I'll try to get new mindi and mondo packages out before the week is over as (a) I have at least two bugs fixed and some improvements put in and (b) I'll be on vacation from coming Saturday until the end of March (no Internet as I'll mostly be in the Outback) - yah!

Moving my Debian Mondo Rescue Package News to Blog

2006-02-25T19:46:00.000+11:00

Up to now I've manually edited and uploaded the index.html for every news item on the Debian Mondo Rescue page. This was quite tedious. I hope by turning the news section into a blog, I will post more often whilst actually spending less time. We'll see how that works out. ;-)

So, let me start straight away:

mondo 2.07 / mindi 1.07 is quite close, so there will be no more changes, only fixes.
#354145 looks like it could be a catch 22. The change I put into 1.06-2 for Via chipsets may backfire for others. Have to look into this.
I am continuing my work on eliminating any Debian specific code changes:

I'll probably dump IncludeCustomDependencies after discussion with Bruno - it's only used for petris right at the moment anyway, which highlights the fact that it is, erm, redundant.
TryToBeCleverAboutInitrd will be changed to create the required syslinux.conf file on the fly. After this has happened, it will be integrated into upstream mindi.
DebFindFailsafe is very Debian-specific, so it will most get included upstream as is. However, discussion has started on a framework to standardise the way distribution-specific behaviour is handled. This will hopefully also lead to a generic upstream solution for the current problems with RAID and LVM support in Debian.

I've started to look into two quite old Debian bugs: #222065 and #312546. The FHS provides interesting insights for these. So fixing them should also make things more FHS compliant.

That's enough for my first blog entry, I guess... ;-)