I've added links on my Linux page and my Links page to Torrentocracy. This is a project I am working on which combines RSS + Bit Torrent + Your TV. In a nutshell, it enables a cool new way for you to get the media (audo/video) which you watch on your TV.

When it dawned on me that when I move to California in September, I won't be able to take my Time Warner DVR with me, I decided to cut the commercial teather and build my own dvr. Using the afore-linked HOWTO to setup MythTV I was probably able to save myself a ton of heartache, but the process has not been entirely smooth. In fact, until I saw this message on the users list yesterday, there was a good 10 day period where I couldn't figure out why my system magically stopped showing tv video (I'm an apt noob and got burned by an automatic bad upgrade ... guess i'm in-apt ... sorry, bad joke).

Anyway, in back-revving to the working version of ivtv, I realized it is a perfect candidate to be dkms-ified. One Sunday afternoon later, and here you go (or directly at ivtv-0.1.9-25dkms.noarch.rpm). This DKMS-enabled ivtv RPM contains both the utility portions of the ivtv package pre-compiled as well as the ivtv driver source which DKMS then builds for whatever kernel you're running (which means it replaces both the old ivtv RPM and the the ivtv-kmdl RPM).

From what I've seen with mythtv, the previous convention was to use "kmdl" to mark kernel driver RPMs, but why limit yourself to pre-compiled binaries for only one kernel at a time, when you can utilize DKMS to do all the dirty work for you? Moreover, you can satisify the hard-core types that only want to build from source on their own box while satisfying us lazies who just rely on an RPM. Plus, now, as you boot into new kernels, DKMS will automatically build and install the ivtv package for you (assuming you have your kernel sources installed). If people think this is a worthwhile thing, let me know and I'll perhaps go repackage the other kmdl rpms for myth.

Oh yes, and speaking of feedback, does anybody know:

- How I can convince X that my TV is not as wide as it thinks? I'm using a Hauppauge 350 card, and while the tv output fits the screen perfectly, all the background myth menus get the left hand sides cut off. Also, for some reason, they mythconfigure pays no attention to my X and Y offsets which I would think would be useful in attenuating this problem.

- Why audio is coming out of the RCA audio jacks on the 350 and not the headphone jack? I direct the audio into the MIC of my soundcard, but when I then output that through my stereo, it's rather crackly.

- Why when I try to bring the menu up during live tv playback, it hangs my entire system?

As you can tell, it's all a work in progress. But hopefully dkms will make this process easier for everyone.

The March edition of Dell's Power Solutions magazine includes a paper I co-authored with Matt Domsch on Simplifying Linux Management with Dynamic Kernel Module Support. It's more current than the Linux Journal article and is also focused more towards using dkms from the systems administration perspective.

Yesterday, I stumbled across blogs.redhat.com. It looks like they got off the ground towards the beginning of March and are currently chronicling their "state of Linux" world marketing tour. I'd be skeptical of dark-side marketers too, but I did see this: "I'm the manager of the Marketing Communications department at Red Hat. I'm one of the people fighting to keep Red Hat from becoming too Corporate and Capitalized." We shall see. Apparently, they're making a documentary.

Today marks the arrival of http://linux.dell.com. I've been working on getting site setup inside Dell for some time now. It serves as Dell's "customer-supported" resource aggregator. More specifically, my hosting of the devlabel and dkms projects will move there.

Devlabel - http://linux.dell.com/devlabel
DKMS - http://linux.dell.com/dkms

Be sure to check out the "What's New" section for a blog of Dell Linux Updates:

http://linux.dell.com/blog

Devlabel 0.45.01 is now available (tarball or RPM):

* Added a check in scsi_unique_id written by Dan Clark to determine if Page80/Page83 indentifier data are supported before checking for the identifier. This was suggested in Red Hat Bugzilla #112585 to help with older devices which might not support these fields.

Devlabel 0.44.01 is now available (tarball or RPM):

* The ignore_list is now kept in /etc/sysconfig/devlabel.d and not /var/lib/devlabel. Though /var/lib is generically a more appropriate place for application state information to live, it was necessary to have these files located on the root partition. This is to make sure that these files are available during boot after the root partition has been mounted but before any other partition has been mounted (such as /var).

Devlabel 0.43.18 is now available (tarball or RPM):

* Changed the check for root user until after it ensures that /usr/bin is in the system PATH to ensure that usage of the program /usr/bin/id works correctly.

DKMS 1.00 is now available (tarball or RPM):

* Bumped the version to 1.00. That's all.

I just stumbled over some good documentation on the usage of devlabel in Red Hat's Enterprise Linux 3 System Administrators Guide. I've gotten some emails of people looking for this specific type of thing, so hopefully this will fill that need.

Interestingly, at work on Friday, a co-worker and I discovered that when you plugged a usb key into his old desktop system with a funky cd-rom drive, devlabel's algorithm to find the device's uuid was causing the cdrom to eject the cdrom drive every 30 seconds. Our conjecture was that scanning for the devices uuid was, for some internal design reason of the cdrom, causing a bus reset which led to the eject action. Happily with the latest devlabel which implements an internal ignore list to avoid such bad devices, the problem went away. Unfortunately, the older devlabel is on the RHEL 3 gold cds.

DKMS version 0.99.01 is now available (tarball or RPM):

* Bumped the version to 0.99 to convey impending 1.00 release status. The intention is to iron out any remaining issues and move out of beta phase in the coming weeks.

* Added MODULES_CONF_OBSOLETE_ONLY[#] directive array available in dkms.conf. This array, when set to "yes", informs DKMS to only modify /etc/modules.conf if it finds an obsolete reference within it as specified in the MODULES_CONF_OBSOLETES[#] array.

* Changed DKMS so it will now only bother to remove /etc/modules.conf entries during an uninstall if REMAKE_INITRD is set, or if you are uninstalling your module from the last kernel that it is installed on.

* Fixed mktarball so that the file that it creates cannot have a filename >255 chars

* Updated the man page

DKMS 0.46.04 is now available (tarball or RPM):

* DKMS mktarball --binaries-only now includes a copy of the dkms.conf within the tarball such that ldtarball can load a binaries only tarball if you specify --force. This is still a bad idea, however, since if you load a binaries-only tarball into your DKMS tree without the module source already added to your tree, you won't be able to build the module using DKMS.

* dkms_autoinstaller now installs to /etc/init.d instead of /etc/rc.d/init.d for cross-distro happiness.

DKMS 0.45.01 is now available (tarball or RPM):

* Changed the logic behind when modules.conf gets edited during a remove. Previously, after a remove would complete, DKMS would automatically re-add references into modules.conf for that module regardless of whether the module which was just removed was active on that kernel or not. Now, DKMS only adds the references back into modules.conf if that module was active for that kernel and, if and only if, there is at least one other kernel which still has that module installed on it.

* Added hugemem kernel prep support for RH hugemem kernels.

DKMS 0.44.05 is now available (tarball or RPM):

* Changed $MODULES_CONF_ALIAS_TYPE to an array that is a part of the $BUILT_MODULE_NAME[#] / $DEST_MODULE_NAME[#] array family. This allows you to specify different alias types for different modules within a single DKMS package. $MODULES_CONF_OBSOLETES[#] (explained below) is also part of this directive array family.

* Added DKMS directive array $MODULES_CONF_OBSOLETES[#]. This directive should be used to specify the modules that your newer module makes obsolete. During install, DKMS will look for entries for these modules in /etc/modules.conf if the corresponding $MODULES_CONF_ALIAS_TYPE[#] entry is set and will remove these. As you uninstall modules, DKMS will first try to put an original module back into the kernel. If it does this, it will leave the reference to the non-obsolete module in modules.conf. If no original_module exists in the kernel, but an obsolete module does, DKMS will put the obsolete module reference back into modules.conf and remake the initrd. If neither exist, it will just remove the non-obsolete reference and replace it with nothing.

* As well, the $MODULES_CONF_OBSOLETES directive can be used to specify multiple modules which are made obsolete. This should be done by setting the variable to a comma-delimited list (eg. ="megaraid,megaraid_2002"). During uninstall, if no original module is found, DKMS attempts to instead use an obsolete module giving priority to the leftmost entry in the variable.

* Updated the man page to better explain how DKMS handles modules.conf changes.

DKMS 0.42.03 is now available (tarball or RPM):

* Added --binaries-only option usable during mktarball. This will create a DKMS tarball which does not contain source. This helps in keeping down the size of the tarball if you know that the target system already has the source installed. DKMS will only load a binaries-only tarball with ldtarball, if the target system already has source for that module/module-version added to the tree. If it does not, DKMS will not load the binaries-only tarball and will exit out.

DKMS 0.41.15 is now available (tarball or RPM):

* During install of a module, if depmod or mkinitrd fail, it automatically backs out of the install and goes back to the built state

* During uninstall of a module, if mkinitrd fails, it warns loudly.

DKMS 0.41.11 is now available (tarball or RPM):

* Moved dkms from /sbin/dkms to /usr/sbin/dkms

* Thanks to the work of Matt Domsch, there is now a Red Hat kernel preparation routine which removes the time consuming make dep stage for module builds on Red Hat kernels. In order to utilize this improved process, you kernel sources must be in a pristine state as delivered by the Red Hat kernel-source RPM (they've never had make dep or make mrproper run on them). So, if you've previously used DKMS for a kernel, you'll either have to reinstall your kernel source, or stick with the "General" preparation routine as before.

* Added /usr/sbin/dkms_mkkerneldoth to enable the quicker Red Hat prep routine

* Fixed a bug in dkms_autoinstaller which was causing it not to run correctly

* Fixed a bug during uninstall where original_modules were not actually getting reinstalled even though it told you they were

* Fixed DKMS to unset all arrays before using them.

* Changed expected driver disk file "module-info" to "modinfo" in order to support legacy Red Hat driver disk formats

* Fixed mkdriverdisk such that it actually copies the rhdd-6.1 file into the driver disk image

* Kernel makefiles are no longer edited during kernel preparation. Instead KERNELRELEASE=$kernel_version is passed to make commands.

* Removed the unnecessary depmod during uninstall of a module

Devlabel 0.43.16 is available (tarball or RPM):

* Created a device ignore list in /var/lib/devlabel/ignore_list such that devlabel can keep track of devices it shouldn't query for IDs since it knows they won't return IDs and likely will only spew errors to the screen instead. The ignore_list is cleared every time devlabel is restarted or after /proc/partitions has changed since the last time devlabel has run.

* The previous version (0.42.05) had a bug in it due to the way it used sfdisk -V to determine if a device should be ignored or not. This bug will make devlabel unable to use any device that has trivial problems in its partitioning scheme (eg. paritition does not end on a cylinder boundary). This has been fixed in this version.

* Added mktemp as a required package.

DKMS 0.40.11 is available (tarball or RPM):

* `dkms add` no longer copies dkms.conf and any post script into the /var/dkms tree. To avoid duplication, it now just uses these directly from the source_tree in /usr/src/<module>-<module_version>/. This change to the tree architecture caused me to bump the dkms_dbversion from 1.00 to 1.01.

* Got rid of the options --postadd, --postremove, --postinstall and --postbuild. Replaced these with equivalent directives in dkms.conf POST_ADD=, POST_REMOVE=, POST_INSTALL= and POST_BUILD=. This was to go along with the above change. All script path names should be given relative to the root directory of your module's source.

* Added the flag --rpm_safe_upgrade. This flag should be used in all dkms-enabled RPM modules during the ADD and REMOVE. Thus, in your spec file, all adds should be: dkms add -m <module> -v <version> --rpm_safe_upgrade. All removes in RPM spec files should now be: dkms remove -m <module> -v <version> --all --rpm_safe_upgrade. Using this rpm_safe_upgrade flag makes sure that in all RPM upgrade scenarios (rpm -Uvh), dkms behaves appropriately. See the man page for more details.

* Added a sample dkms.conf to /usr/share/doc (called sample.conf)

DMKS 0.39.17 is available (tarball or RPM):

* Modified mktarball format to remove dependency on $source_tree and $dkms_tree. This means that regardless of these values between systems, you can now count on the tarball to properly load on another system with ldtarball. Note that because of this, any tarball made with mktarball before this version will not load properly anymore.

* Modified ldtarball to handle the new mktarball format. As well, ldtarball can now be used on any tar archive which contains a dkms.conf within it. It first checks to see if the tarball is made by mktarball. If not, it then finds the dkms.conf within the archive and then adds that archive to the dkms tree. This is very handy and can serve as an unpack routine as discussed in this thread.

* Ldtarball now uses the --archive option instead of the --config option. --archive is new and was created to alleviate any confusion over options.

* Added --kernelsourcedir option as well as $kernel_source_dir DKMS variable to allow specification of an alternate kernel source directory if it is not found as expected in /lib/modules/$kernelver/build

* Driver disk files for Red Hat driver disks are now looked for within the ./redhat_driver_disk directory within your sources

* Added $tmp_location variable available in /etc/dkms_framework.conf to specify an alternate location for your systems /tmp directory. The default is /tmp.

* Added diff checking in status command. Now, when a module is in the installed state, dkms checks to make sure that the module in the /lib/modules tree matches the one saved within the DKMS tree. This will help alleviate confusion if other packages start overwriting things that DKMS has put into place.

* Changed the build-arch of the RPM to noarch as my beautiful shell scripts are arch independent.

* Other miscellaneous changes which are available within the SRPM spec file changelog.

Here's a good Dell Linux read with the above title. You can find it here.

Also, there's an interview with a Dell exec about Dell's Linux strategy for the Sky Radio Network (the one for the airlines). Hear it here.

DKMS 0.38.03 is available (tarball or RPM):

* Fixed mkdriverdisk to correctly create kernel/driver tree within the driver disk modules.cgz

* Added support in mkdriverdisk to put modules for more than one kernel within the disk image. With Red Hat installs, this will allow the RH installer to place these extra modules directly into the various kernels it installs on your system (smp, etc).

* Moved driver_disk directory location to underneath the $module_version directory. This is more fitting since driver disks can now contain modules from various kernels.

* Fixed a temp_dir_name typo in ldtarball.

Over on domsch.com, Matt has uploaded a DKMS enabled megaraid2 RPM which we put together today.

You can download it here.

DKMS 0.37.10 is available (tarball or RPM):

* Don't allow installs of modules onto kernels which don't exist

* Suppressed stderr on the output of some commands

* Fixed brain dead bug for REMAKE_INITRD

* During uninstall, don't remake initrd if it was never installed

* Fixed ldtarball to first unload into a unique temp directory and then clean up after itself.

DKMS 0.37.04 is now available (tarball or RPM):

* Changed PATCH directives to an array based system. All patch filenames should be given in the PATCH[#] array. If the patch should only be applied when building for certain kernels, then a corresponding regular expression should now be placed in the PATCH_MATCH[#] array which matches against those kernels. This new array system is not only cleaner, but allows matching against regular expressions (ala egrep) whereas the old system was limited to substring matches. If no corresponding entry is found in PATCH_MATCH, then the patch will automatically be applied.

* Changed MAKE directives to an array based system. The default make command should now be specified in MAKE[0]. All other MAKE directives should fill out this array and will only be used if their corresponding regular expression in the MAKE_MATCH[#] array matches against the kernel being built for.

* Changed the MODULES_CONF directive to an array based system.

* Fixed known-filename exploit issues in invoke_command (thanks to Oron Peled: oron () mail ! artcom ! co ! il ).

* Changed autoinstaller bootup priority from 08 to 04.

DKMS version 0.36.05 is now availabel (tarball or RPM):

* In dkms.conf, when specifying the name of your module, you should no longer append the .o or .ko to the end. Instead, based on what kernel you are building a module for, DKMS will figure out the suffix (if <2.5 then .o, otherwise .ko) and will work appropriately. The example below shows this change from the old format to the new.

* Removed the DKMS directives LOCATION and MODULE_NAME. Replaced them with the arrays BUILT_MODULE_NAME[#], BUILT_MODULE_LOCATION[#], DEST_MODULE_NAME[#] and DEST_MODULE_LOCATION[#]. This allows much more flexibility in finding and renaming modules and placing them in various locations of your /lib/modules tree. Whereas, before you would specify something like:

MODULE_NAME="qla2200.o:qla2200_6x.o qla2300.o:qla2300_6x.o"
LOCATION="/kernel/drivers/addon/qla2200"

you would now specify it as:

BUILT_MODULE_NAME[0]="qla2200"
DEST_MODULE_NAME[0]="qla2200_6x"
DEST_MODULE_LOCATION[0]="/kernel/drivers/addon/qla2200"

BUILT_MODULE_NAME[1]="qla2300"
DEST_MODULE_NAME[1]="qla2300_6x"
DEST_MODULE_LOCATION[1]="/kernel/drivers/addon/qla2200"

This above example doesn't show usage of BUILT_MODULE_LOCATION which is optional. This is used if your built modules are spread out within your source tree, and you need dkms to find them. It should be given relative to the root directory of your module source (eg. relative to the directory which holds your dkms.conf file).

If you do not intend to rename the modules after they have been built, then DEST_MODULE_NAME is optional. As stated above, with DEST_MODULE_LOCATION, you can now install each module to different locations in your /lib/modules tree.

Devlabel 0.42.05 is available (tarball or RPM):

* Added a work-around for devices with bad partition tables. For example, on USB floppy devices containing floppy disks marked as bootable, linux currently errantly reports that the device has 4 partitions even though it does not. Devlabel was probing these bad partitions for UUIDs and this was causing kernel I/O errors. The work-around tells devlabel to ignore partitions which come from devices with messed up partition tables.

There's actually a little bit of irony surrounding this, as I had been tasked to root cause I/O errors in Red Hat's latest beta, only to find out it was my own software which was exacerbating this problem. Of course, if the kernel reported partitions correctly, this would never have reared its face. Still humorous though.

Looks like Dell has a couple new commercials which make reference to Linux. I believe this might be a first, so be sure to keep your eyes open during prime time and football games. Here's a link to the commercials. The ones of interest are "Cold Call" and "Let's Do Lunch".

DKMS version 0.35.01 is now available (tarball or RPM):

* Added PACKAGE_VERSION and PACKAGE_NAME as directives available in dkms.conf. These are strict requirements and DKMS will not function without these present (because these are strict requirements, I also revved the example QLogic DKMS driver which you may need to now download).

This feature was added at the request of Cyril Bortolato who is the creator of gmodconfig. Gmodconfig is a GUI which is intended as a simplified module management system for inexperienced (and experienced) Linux users. It uses dkms as a back-end to install modules and you can read more about it from its kernel-traffic nod.

As well, you can read the thread on the dkms-devel mailing list which spurred these additions.

DKMS 0.34.10 is now available (tarball or RPM):

* Added the dkms_autoinstaller service (/etc/rc.d/init.d/dkms_autoinstaller). Its purpose is to automatically install modules during bootup onto kernels which do not already have that module installed for it. It only does the install, though, if AUTOINSTALL="yes" is set in that module's dkms.conf. If multiple versions of the same module exist in DKMS, the autoinstaller does not install that module and warns appropriately.

* Added the AUTOINSTALL="yes" option available in dkms.conf. See above.

* Added the --no-prepare-kernel and --no-clean-kernel cli options. These were needed to create the autoinstaller service but might be applicable in other areas. --no-prepare-kernel skips any kernel preparation before building a module whereas --no-clean-kernel does not clean the kernel after building a module.

My article on DKMS is now web-accessible to the public. You can read it here.

Here's the errata advisory for the 2.4.20-20.9 errata kernel now available from Red Hat to fix "obsure" bugs. Much respect goes to Robert Hentosh and Matt Domsch of Dell whom I both work with for diagnosing and fixing these race conditions. They don't mention this errata should likely also help fix large memory support for RH9.

I have a 4 page piece about DKMS in this month's Linux Journal. The article can be found here online, but requires a paid subscription to Linux Journal. Go pick a copy up at your local bookstore.

DKMS version 0.33.02 is now available (tarball or RPM):

* Add /var/dkms/dkms_dbversion to track the versioning of the underlying database structure used in DKMS. This is currently set at 1.00.

* Fixed bugs in match which was causing it to fail when matching against multiple modules.

* Added Fred Treasure to the author's list for his SuSE/UL work.

I've resisted commenting on the SCO controversy until now. In anycase, IBM has finally come out and responded pointing out SCO's own distribution of their alleged code. I'm glad someone finally came out and said this. The whole thing is pure Linux FUD.

A couple guys at work just got back from the Ottawa Linux Symposium where apparently there was little discussion on SCO and its implications. That sort of complacency is interesting and probably warranted, but somehow I think at LinuxWorld next week this won't be the case. What else to expect at a marketing driven event? We'll have to see.

Anyway, come visit me in the Dell booth.

Been away from the blog lately mostly moving into my new place and getting it setup. Well, now with everything in order and me blogging via my new 802.11a setup, its only appropriate to include some links on the impending desktop linux explosion.

Walmart sells SuSE desktops

and

Munich makes Microsoft squirm

The latter story isn't really news, but its an interesting in-depth account. Now if only it was actually easy to setup my home wifi we'd be well on our way.

Matt Domsch and I are holding a BOF session about DKMS at the upcoming LinuxWorld. Get more details here.

DKMS version 0.32.04 is now available (tarball or RPM)

* Added support for 2.5 kernels. Specifically, if it detects that you are building for >2.4, it uses a generic make command (make -C $kernel_source_dir SUBDIRS=$build_dir modules) which makes use of advances in the 2.5 kernel series. Also, it doesn't do a make dep (though for SuSE, it still does a make CONFIG_MODVERSIONS=1 dep since I didn't know whether to take this out or not...advice?).

* Added SuSE initrd support. Now, if it detects the SuSE type mk_initrd command, it modifies /etc/sysconfig/kernel if REMAKE_INITRD is set and then calls mkinitrd which should remake all initrds which it knows about. Only during the final removal of a module are the changes removed from /etc/sysconfig/kernel. Because of this methodology, mkinitrd will often return exit status 9 since it attempts to remake all initrds and some kernels don't have the module you just added.

* Changed the kernel preparation stuff so that it does UnitedLinux prep stuff if it finds /boot/vmlinuz.version.h, but otherwise will do RedHat/generic prep routines.

Looks like the slashdot-effect traffic is finally starting to cool down. As a follow-up, given this comment the Axim uptime and usability has dramatically increased. Basically, if you go into Settings > Light & Power > Suspend after, and set it to "never", the panics mostly go away. Looks like they weren't kidding when they said suspend was broken.

Also, a slight rant from something I've learned from this heavy traffic experience. If you run a professional site dedicated to a certain field with a professional looking interface, then you should probably be smarter than to steal bandwidth from others (especially smaller non-commercial websites). In this case, a couple sites (mobi-mania.com and mypdacafe.com) both put my axim pic on their front page-- meaning that for every hit their site got, I too got one for 40K. The term "netiquette" sounds somewhat antiquated by now, but come on guys. Host your own images if you're gonna put them on the forefront of your site. Many thanks to http://www.pocketpcthoughts.com for their courteousness.

Here's the slashdot posting about Linux running on the Axim. Well timed since my monthly bandwidth allotment starts fresh tomorrow.

*** This use of the Dell Axim is not supported by Dell ***

Thanks to the great work of Martin Demin over at handhelds.org, it is now possible to run Linux on the Axim. It currently only supports load from RAM (not ROM) which means you boot it from Windows, but it's a start. Specifically, if you follow these instructions made available by Steve Johnson it's pretty easy. Though, beware that it currently kernel panics after about 15 minutes, and when you do the hard reset, it boots back into Windows at factory default settings (meaning, you lose any files you might have stored on it).

Touchscreen, sound, lcd, serial port, buttons and charging all currently function. Much work still remains on things like the power button, screen rotation support, battery indicator, and loading it into the actual flash ROM, but this really is a great start. Check out the picture below...running a 2.4.19 based kernel on the Familiar Linux distribution.

I've included all this information on my linux page so that these links are readily available outside of this blog entry.

Devlabel version 0.41.01 is now available (tarball or RPM).

* Fixed up scsi_unique_id to better handle identifier types. Specifically, as per the SCSI spec, it now checks page83 identifiers for their association value. If this value is non-zero, the ID is not considered stable and so scsi_unique_id no longer returns it. Thanks to Tom Coughlan (coughlan () redhat ! com) for pointing this out.

* Fixed devlabel to handle multiple identifiers of the same page and type. In this case it just concatenates the ids to form one large identifier.

Zach Brown picked up my post to the linux-kernel mailing list regarding the addition of SuSE support to DKMS. Here's the kernel-traffic write-up.

Devlabel version 0.40.03 is now available (tarball or RPM).

* Changed reverseremap so that if a device returns a bad UUID or no longer exists, it comments out that entry in /etc/sysconfig/devlabel.

* Added a %pre and %post in the RPM which detects if you are using an old version of devlabel which has the old formatting for UUIDs. If it detects this, it calls a devlabel restart before the upgrade (to make sure the values in column 2 are up to date) and after the upgrade it calls a reverseremap (to fix the UUIDs).

Red Hat has accepted devlabel-0.38.07 and it is currently being served up in their RawHide section. Look for the updated version in their next distro. Until then, you can get the RPM right here.

DKMS 0.31.04 is available here.

* Fixed a bug where if you specified a --config and the config was located in /usr/src/linux-, it saves it and puts it back directly after the make mrproper

* Cleaned up and added configs to the Red Hat kernel prep routine

* Added a sample.spec to /usr/share/doc to show how to build an RPM which uses dkms.

From a summary of the latest IDC numbers on CRN:

"Server sales are down, but don't tell that to anyone selling Linux servers. Especially don't tell that to Dell Computer, which enjoyed by far the fastest growth of the top vendors."

Specifically in the first quarter of this year:
* Dell sold 38,000 servers pre-installed with Linux amounting to 124 million in revenue (following this trend, we'll hit a 1/2 billion by the end of the year)
* While these numbers put Dell second behind HP (50,500 servers), Dell's year over year volume growth was 58.7 percent and revenue growth was 77.6 percent

So, while total server revenue declined 3.6 percent, it looks like Dell/Linux is running away with market share. I think this might explain it.

Devlabel 0.38.07 is available here.

* Added an ugly hack for weird hotpluggable hardware. Specifically, things like the "Pen Drive USB Flash Hard Drive" require an initial ioctl ping before Linux can do anything with them. Because of this, when the hotplug script called `devlabel restart`, devlabel was unable to yet see the device and would not create its symlink. Now, devlabel detects if it has been called by a hotplug agent, and if so, it issues a `devlabel status >/dev/null` right off the bat to act as this initial ping. Then, when the rest of the scripts get around to creating symlinks, everything works fine since the ping has occurred.

* Stopped using the readlink command since I didn't want a dependancy on tetex. Instead I wrote my own simple function which accomplishes the same thing.

DKMS 0.30.17 is available here.

* Added SuSE/United Linux kernel preparation support (Many Thanks to Fred Treasure - fwtreas () us ! ibm ! com). I have only tested this on SLES 8, but from what it looks like, this should prepare your UnitedLinux kernel for building a module regardless of which kernel you are currently running. SuSE has a different mkinitrd command so if it detects this, and REMAKE_INITRD is set in your dkms.conf, it tells you to manually fix your initrd. For Red Hat, it does all the mkinitrd work for you. If you have feedback on how to best accomplish this for SuSE/UL, please let me know.

* Added the --directive option. This allows you to specify dkms.conf directives on the command line. You can use the --directive option multiple times on the same command line to specify multiple additional cli directives. Also, if you plan to use to specify the make command during a build, you must use the MAKE= directive and not the MAKE_<kernel-regexp> directives.

* Added an internal readlink subroutine for determining the location of symlinks. I did not want to add a dependency on tetex so this seemed the better approach.

* Added a mkdir -p $LOCATION during dkms installs so that your built modules will get placed in the $LOCATION directory regardless if it existed beforehand or not.

Devlabel 0.38.05 is available here.

* Added the "reverseremap" action. This action is actually quite dangerous and should only be used when you know what you are doing. It wipes out the UUID values (column 3) from /etc/sysconfig/devlabel and using the last known device name (column 2), determines the UUID for that device and from then on devlabel will use that UUID to ensure consistent access. If a device renaming event has occurred on your system, using ReverseRemap will cause devlabel to ignore it and then think no renaming event ever happened.

This feature is especially useful for upgrading between devlabel versions where the UUID format has changed. Specifically, older versions of devlabel did not use the start sector of the partition as part of the UUID. If that older config file is then used on a newer devlabel, it will get confused. Using ReverseRemap is an easy way to get devlabel to repoll for the UUIDs based on the device names already in the config file.

You must specify --force in order for it to work. Without the --force, it prints a rather verbose warning explaining what ReverseRemap actually does. Thanks to Robert Hentosh for the idea (robert_hentosh@dell.com).

DKMS 0.29.09 is available here.

* During a remove, not specifying the kernel-version now results in an error. If you want to remove a module for all kernels, you must now use the new --all option (eg. dkms remove -m module -v version --all).

* Added the file /etc/dkms_framework.conf which gets sourced in every time dkms runs. This allows you to specify alternate locations for $source_tree and $dkms_tree within this configuration file and allow dkms to use them.

* When looking for original modules to archive during an install, DKMS now uses the find command to search the /lib/modules/$kernel tree in the event that its not located in LOCATION. If multiple modules with the same name are located within the tree, it archives the one found in LOCATION. If multiple modules with the same name are located within the tree and none are in LOCATION, it archives nothing. If only one module is found with that name within the tree, it archives that one. Note that after uninstall, when it puts the module back into the /lib tree, regardless of where it came from initially, it will get put back into LOCATION.

* After builds complete, the kernel tree is now cleaned with a make mrproper. While doing a match, this cleaning only occurs after the last module is built.

* If an existing .config file is found in your source tree, DKMS now save it into memory and rewrites it after it does its thing.

* Added grep, cpio and gzip to the RPM Requires clause as they are needed.

I just got my copy of June 2003's Linux Journal in the mail. On page 10, in the "diff -u: What's New in Kernel Development" section (by Zach Brown):

Dynamic kernel module support (DKMS) has come from a developer group at
Dell. A GPLed project, it aims to allow device driver source code to
reside anywhere on the filesystem, not only in the kernel source tree.
This makes it easier for vendors to release new versions of their
drivers and for users to recompile those drivers. As of March 2003,
DKMS is 2.4-specific, and it doesn't take account of some of the massive
reworkings appearing in 2.5, especially with the module code itself.

I'm not sure about the 2.5 comments as there were some threads about the module name it expects back in March, but DKMS should be ready to go regardless of kernel. But, who cares, its some good press.

DKMS 0.28.04 is available here.

* Fixed mktarball and ldtarball so that you are not forced to load your tar archive into /usr/src and /var/dkms. Instead, DKMS honors the variables $dkms_tree and $source_tree and should load everything where you now specify (thanks to Jordan Hargrave, jordan_hargrave at dell dot com).

* Added the mailing list info to the man page: dkms-devel@lists.us.dell.com

DKMS now has its own mailing list. If you'd like to discuss any issue regarding Dynamic Kernel Module Support, its features, its shortcomings, etc., go to Dell's mailing list webpage and join the DKMS-devel mailing list.

And while you're at it, you should also check out Dell's Linux-Poweredge list.

The Ottawa Linux Symposium has accepted my abstract for a Birds of Feather session on Dynamic Kernel Module Support (DKMS). The session will be led by Matt Domsch who is our lead Linux engineer. Here is the abstract. Unfortunately, I won't be there, but I should be in San Francisco a couple weeks later to do something similar for LinuxWorld.

DKMS version 0.27.05 is available here.

* Added "mktarball" and "ldtarball". This is for using DKMS within systems management purposes. Instead of having to rebuild modules on every system within your environment, you can now just build the modules on one system and utilize these actions to transport the built modules to your other systems. mktarball makes a tarball for the specified module/module version. This tarball includes the driver source and the built modules for each kernel. Then, ldtarball can be used to load the tarball on any other DKMS tree. This leaves the drivers in the "built" state and then `dkms install` can be used to install the modules in the /lib/modules tree.

* Added the --force option to be used in conjunction with ldtarball. With ldtarball, if it finds module/versions in your tree already, it normally will not overwrite them with the tarball. This can be overrided with the --force option.

* Changed the dkms.conf option of NEEDED_FOR_BOOT to REMAKE_INITRD. It functions just the same and has the same exact behavior. REMAKE_INITRD is just a more intuitive name.

* Added the dkms.conf option of MODULE_CONF_ALIAS_TYPE. This is to handle deficiencies in DKMS's editing of /etc/modules.conf. Rather than having to specify some static line to be added to modules.conf such as "alias scsi_hostadapter99 qla2200_6x", you now should just specify MODULE_CONF_ALIAS_TYPE="scsi_hostadapter". During install, DKMS will then figure out if modules.conf has a reference in it already for your module, and if it doesn't, it will add as the last alias type number (eg. if you have 4 other scsi_hostadapter devices, it will be set as scsi_hostadapter5). Other common ALIAS_TYPEs include "eth" and "sound-slot-".

* When removing modules, alias references in /etc/modules.conf will now remain if the find command can find other instances of that module name within the /lib/modules tree for that kernel. If no other drivers exist, the alias will be removed.

* The DKMS spec file now installs from the tarball instead of just the SOURCEs

Doug Gilbert posted this message on the linux scsi mailing list today. He was playing with devlabel on RH9 with 2.5.68 and devlabel was causing chaos. ...and its not my fault. He issued a patch to the kernel to improve its error handling.

Only when so many of our fair use rights are being attacked, could such an obvious court ruling make me happy. Thankfully we haven't completely fallen off the deep end. Yet.

While working with some guys in the UK, I found out that VMware can allow you to access your Storage Area Network through their virtual machine. A pretty cool idea. So now you can trick your mainframe into using Linux for SAN accessibility. Here's their white paper.

Devlabel 0.36.06 is available here.

* Added sector start point to the UUID of non-partition specific UUIDs. So, for things like swap partitions, now part of the UUID is its start sector on its disk. This means that all UUIDs that devlabel uses are now absolutely unique and so devlabel should be able to handle all interdisk renaming events regardless of the UUID type. Note that if you start moving your partitions around with parted or something similar, devlabel won't like this. The start sectors are not added to the ends of partition uuids.

* A lot of code cleanup because of all unique UUIDs. I got rid of all the code that had to do determing partitions when using disk ids, etc, etc. Much nicer now.

* Got rid of the --partnum option for when adding by UUID (the -u option). This is no longer necessary because of the changes.

* Thanks to David Balazic (david dot balazic at uni-mb dot si) for the sector start idea.

Devlabel 0.35.21 is available here.

* Added multipath support. Previously, if attempting to add a symlink to a device which was part of a multipath set, devlabel would not allow this because multiple devices returned the same UUID. Now, this can be avoided by adding symlinks with the --multipath option. This will instruct devlabel to create multiple symlinks named YourSymlinkName_multipath# each pointing to a different path that is part of the multipath set. These symlinks can then be used in /etc/raidtab to create a working multipath device which will not succumb to any device renaming problems. Hence, if /dev/sdd1 and /dev/sde1 were multiple paths to the same device, they can now be referenced as /dev/foo_multipath0 and /dev/foo_multipath1 so even if they became /dev/sdb1 and /dev/sdc1 internally, your multipath device would still get created properly from /etc/raidtab since you used the symlink names and not the actual device names.

* Cleaned up how status was returned. It now shows the permissions and ownerships of the underlying device instead of the symlink. As well, raw device status now is of the same format as symlink status.

* Created a make_link function used by add and restart to remove duplication of code

* Devlabel now greps by word boundary instead of looking for a trailing whitespace character (thanks to Todd Martin: todd dot martin at acm dot org)

* I replaced all references of grep -m with equivalent head -1 pipes to accomodate older versions of grep.

* Added coreutils to the requirements of the RPM spec file as readlink is located in coreutils.

* Other minor bug fixes and enhancements.

Devlabel 0.30.08 is available here.

* Added --uid, --gid, and --perms which are usable during an add command.

If these options are specified, when the symlink is made it applies these permissions to the underlying device avoiding any security hazards in the event of a device name change. So, if you have a partition /dev/sdd6 which is readable and writable by everyone on a system and a partition /dev/sde6 which is only readable by root, if /dev/sdd goes down and /dev/sde becomes /dev/sdd, the correct permissions of /dev/sde6 will be applied to /dev/sdd6 to ensure that there are no unauthorized accesses.

I've added DKMS to freshmeat.

The project can be located here.

"I believe that in a couple of years, Linux and Dell will be the dominant computing combination in the enterprise," Ellison said.

Read the article.

I like my job.

Devlabel has magically appeared on Freshmeat. It can be found here. Thanks freshmeat.

Dax Kelson wrote up a really nice review of Red Hat 9 here. He included a nice write-up of devlabel.

Oh yeah, and the review got slashdotted.

As of today, RHN subscribers can download Red Hat 9 (not 9.0). Included in 9, you'll find devlabel :-). Though, its an older version which doesn't support partition specific identifiers. Hopefully I'll get that rectified soon.

Very exciting article here (via slashdot). Hitachi, Sharp, Sony and Toshiba are banding together to flesh out an Internet/TV standard. One day, every website will become its own TV network...very cool. As well it talks about Matsushita and Sony collaborating on Linux based consumer electronics and though no official connection is made in the blurb, I wouldn't mind my tv running on linux either.

Also makes you wonder when Apple will realize the opportunities to become the pre-eminent Linux desktop manufacturer. They've already switched to a Unix base.

Devlabel 0.29.12 is available here.

* Fixed installation script to make it more helpful (it now informs that you need uuid.h to be installed, which can be found in the e2fsprogs-devel package).

DKMS 0.25.14 is available here.

* Added mkdriverdisk support. This will make a floppy driver disk image for the driver that you specify. Currently, the only driver disk distro supported is Red Hat. For example: dkms mkdriverdisk -m qla2x00 -v v6.04.00 -k 2.4.18-3BOOT -d redhat.

* New -d, --distro parameter. This is only used currently with mkdriverdisk. Otherwise, dkms should be distro agnostic.

* Added support to rename drivers after they are built. This can be specified in dkms.conf as such: MODULE_NAME="qla2200.o:qla2200_6x.o qla2300.o". In this particular example, the 2200 driver would be installed as qla2200_6x.o while the qla2300 driver is installed without name change as qla2300.o.

* Internally, symlink locations are now determined by using the readlink command.

* Added the Red Hat BOOT config as one of the config files that dkms looks for during builds. This allows building for redhat boot kernels without having to specify the --config option.

* Fixed a bug in read_conf that caused the wrong MAKE_ subdirective to be used.

* You no longer must be root to run a dkms build

* Updated the man page

* Fixed a bug during install when archiving original modules. Thanks to Kris Jordan (kris at sagebrushnetworks dot com).

For Linux to successfully take root and become a part of the mainstream, it will inevitably require the backing of some large corporate efforts. By all means, Austin is at the forefront of these trends and this is well underway.

First mention, of course, goes to Dell who is leading an organic approach to bringing Linux into the enterprise, certifying and factory-installing Linux on its entire line of Servers and Workstations. As well, in conjunction with Dell, Oracle has opened a Linux center in Austin. IBM's Linux Technology Center, though virtual in nature, is affiliated and centered in Austin. HP and Intel both obviously also have a presence in Austin, and likely do work with Linux here, though I am unaware of any specific efforts (let me know).

Less commercial entities like South By Southwest also have a Linux-twang bringing in the likes of Richard Stallman, founder of Gnu, while also using Linux to stream audio from some of the many SXSW music peformances going on this week. Also worthy of mention are the ongoing Linux Top Gun events which attempt to turn hacking into a spectator sport. Good luck on that one.

So, Linux may not be ready to pervade the home of your neighbor next door, but if concentrated efforts like these continue, it can't be far off. It's nice to be living in a city progressive enough to drive this.

New versions, as always, available here.

* I added patching support in dkms.conf. You can now specify PATCH0=<patch_filename>, PATCH1=..., etc. in your dkms.conf and the patches will be applied in numerical order to your source each time before it builds. All patches are expected to be in -p1 format and should be installed into the /usr/src/<module>-<module-version>/patches/ directory.

* With patching support also comes kernel specific patches. These should be entered in the form of PATCH_<kernel-regexp> in dkms.conf. If the <kernel-regexp> matches to the kernel you are currently trying to build a module for, then this patch will be applied. All kernel specific patches are applied after generic patches.

* All module builds now occur in the directory /var/dkms/<module>/<module-version>/build/. Before each build, the source is copied into this directory for /usr/src/<module>-<module-version>/. If a build succeeds, then this directory is emptied after the build. However, if a build fails or if patches fail to apply, then this directory is left with the source in it so that further troubleshooting can be done.

* There is no longer a limit to how many MODULES_CONF entries can be placed in dkms.conf (used to be a 5 entry limit). As well, the format was changed from MODULES_CONF_<#>=... to just MODULES_CONF<#>=...

* DKMS no longer sources in /etc/init.d/functions as this is Red Hat specific and was not utilized anyway.

* Modules are no longer assumed to end with .o. This means the explicit built name of your module must be specified in dkms.conf.

DKMS got Kernel Traffic'ed. I hope this leads to more feedback on the software as I have seen little as of yet. Kernel Traffic #208 For 7 Mar.

EMC has officially qualified Red Hat Linux 8.0 with Dell Servers. This is with the QLogic 2342, 2340, 2310 and 2200 HBA cards with the 6.04.00 QLogic driver. The Dell supported RPM can be downloaded here. I'll update my Linux page with this information later. Of course, RH Advanced Server 2.1 and RH 7.3 are both also supported with these cards and driver.

I just finished the beginning switchover to Movable Type. Pretty great stuff so far.

Check out DKMS which is on my linux page. Dynamic Kernel Module Support is a framework to allow driver drops built directly from source so that Linux solution providers no longer have to wait for kernel drops to fix driver issues. Its good for other reasons as well, check out my post on lkml for more info. Its released by me under the auspices of Dell under the GPL.

Here's some good reads about Dell and Linux. First, February's Power Solutions magazine is out and its focus is on Transforming the Enterprise with Linux. There are a whole range of technical articles with insight from various Dell engineers on topics of interest regarding Linux. For a less technical read, you can also check out the Feb edition of Dell's Insight quarterly. The focus for February is also on Linux is entitled `Linux gets an Oracle`.