I needed to query a card to get its permanent mac address (the value programmed into the card, even if the admin has ifconfig'd it differently). This can be done with the linux kernel's ethtool API, but the ethtool command doesn't currently support it and google didn't know how either. I had to figure it out myself.
Now google, you no longer have an excuse - I expect you to know next time I ask.
posted at: 14:46 | path: /tech | permanent link to this entry
2.6.24 kernels targeted for etch are available for testing in etch-proposed-updates. Some architectures are missing for this first upload, but fixes are pending for the next upload.
posted at: 00:30 | path: /tech | permanent link to this entry
Adeodato mentioned using ctrlproxy, so I thought I'd ramble a bit about my experience w/ IRC proxies in general.
dircproxy was the first IRC proxy software I tried. It did the job, but the thing that annoyed me the most was that only one client could connect at a time. I'd get home and realize I was still connected at work, and then have to login and send a kill signal to xchat.
When I found out about ctrlproxy, and that it supports multiple clients, I was very excited. It did the job, but occasionally it would hang and need to manually killed/restarted, and it had this weird problem of writing logs for one channel to the log file of another.
Most recently (and for probably a year now) I've been using bip. I immediately hit an issue with one server - bip would constantly reconnect/disconnect. Upstream immediately went to work on the problem, determined it was a bug in the server itself, and (iirc) sent the server maintainers a patch. Now that's support! bip has been stable for me for nearly 2 years now.
I'd also suggest comparing the bug pages for dircproxy, ctrlproxy, and bip. That's not always a good way to measure relative stability, but it resembles my experience in this instance.
posted at: 15:19 | path: /tech | permanent link to this entry
Last night I decided to install etch on my pre-built MythTV system. The process is documented here
posted at: 13:52 | path: /tech | permanent link to this entry
HP announced support for Debian 4.0 ('etch') on ProLiants today. See the HP/Debian page for details.
posted at: 14:45 | path: /tech | permanent link to this entry
That's a mouthful. We had a customer asking for information on this, so I did a couple screen captures using byzanz to demonstrate.
The first shows howto setup a system to do bios over serial. I did this w/ the remote java console, but you can also do this locally on the system (or the ActiveX console I suppose, but I've never tried this myself). In brief, you need to choose a serial port to map to the VSP (I use COM2 aka ttyS1), and tell the system to redirect the BIOS to the same serial port at your desired baud (115200 in this example).
The second shows me initiating an ssh session, setting up a virtual cd-rom, and booting the debian installer. Of course you could use local media or even PXE boot. But either way you need to tell the installer to direct its console to the same port that you've configured as the VSP and at the same baudrate (console=ttyS1,115200n8 in this example).
Note that if the screen goes blank after attempting to boot from the CD it is likely that the installer is displaying a graphical splash screen. Simply hit F1 to transitition to a text-mode help screen.
posted at: 17:12 | path: /tech | permanent link to this entry
svn-load, a DFSG-free replacement for svn_load_dirs, is now in unstable. John Wright has been working on adding support for doing preset pattern-based moves, which I hope will be ready in the next upload.
posted at: 15:29 | path: /tech | permanent link to this entry
Users of subversion may have noticed that the svn_load_dirs script was removed from Debian due to a lack of a license from upstream. So far, attempts to get a DFSG-free licensed version have failed, so I've begun a new python implementation that is licensed under GPLv2. 0.1 is functional and uses the same syntax as the original, but is missing a few features that prevent it from being a drop-in replacement. I hope to remedy this in the coming weeks.
posted at: 17:05 | path: /tech | permanent link to this entry
I suffer from an in ability to successfully monitor multiple sources of information. For example, I rarely check on lists that I have procmailed out to their own folder. If its a list I need to stay on top of, I have to dump it to my primary inbox. For one list, I even dump messages to my inbox *and* keep a copy in a subfolder. That way I can keep on top of what's going on, but also keep a low-barrier-to-delete since I know I have an archival copy. I do think its important for me to check e-mail regularly, but there is some part of my brain that considers e-mail to be a time sink, and prevents me from going beyond what it considers the bare-minimum: Inbox messages.
Another instance of this disorder struck me with RSS. There are web pages that I check every day, and not all of them have RSS feeds. I played with a few different RSS readers a while back, and decided that straw was my favorite. But I could not get myself in the habit of bringing up a second application. Later I started using Firefox, and I thought I'd have better luck with something like Sage. But even that was easy to avoid because it requires actually opening up the sage panel. I would either never check it or, in times of boredom, check it too often. Since then I've given up on RSS readers. These days I've stolen an idea from Alex Chiang and just keep a bookmark folder called "daily" and one called "monthly". Every morning I hit the "Open All in Tabs" item in the daily folder, and quickly ctrl-w through pages w/ no new content. My daily folder includes things like bug reports I'm monitoring for activity, gitweb views of files where I'm waiting for a fix, blogs, parcel tracking, comics, wiki watch lists, etc. Since a few of these pages are rather important, I always remember to do it and therefore force myself to browse the others as well. Most days I spend less than 10 minutes "wasting time" going through them.
Its strange to both be aware of poor working habits, yet know from years of experience that I'll be more successful if I work around them rather than trying to retrain myself.
posted at: 16:33 | path: /tech | permanent link to this entry
We're trying to mitigate the severity of #404927 by working around the issue in udev. But, to do that, we need someone to provide us with udevinfo output for these controllers. If you have access to one, please help!
posted at: 14:40 | path: /tech | permanent link to this entry
posted at: 13:42 | path: /tech | permanent link to this entry
As announced in August, HP has now gone live with support for ProLiant. More information is available at http://hp.com/go/debian.
Admittedly its odd to announce sarge support right before etch releases, but hey - we had to start somewhere.
On a similar topic, I started a wiki a while ago to track the status of sarge and etch on various ProLiant models. I think it'd be cool to have similar pages for various vendors. By linking to d-i installation reports, I hope this will reduce duplicate information.
posted at: 15:17 | path: /tech | permanent link to this entry
Good idea Tollef. Here's an xchat port.
posted at: 12:17 | path: /tech | permanent link to this entry
hpodder is awesome, thanks John!
posted at: 11:12 | path: /tech | permanent link to this entry
After doing the last 4 rounds mostly by hand, I've started automating a lot of
the process with a make system. Essentially, make
I need help testing! Please checkout the wiki for details.
posted at: 10:12 | path: /tech | permanent link to this entry
HP ProLiant servers have a device called the iLO that lets you do things like get remote console, power cycle, etc. There's a java interface for getting a graphics console, but I've always been more than happy to ssh into the device and use the "remcons" command, which lets me view the VGA console remotely. It only deals with text, but why do I need framebuffer/X on a remote server anyway? Anyway, I just received a new "G5" system, which has an updated controller called "iLO 2". So I ssh in to install it and, surprise, the remcons command is gone.
So, I spent a few days playing with this machine, trying to avoid installing a Java plugin or actually walking into the machine room with a monitor/keyboard. What I did discover is that the ssh interface has a "Virtual Serial Port" option, and I can configure the BIOS to redirect its output through the serial port. Turns out, this is actually better than remcons - remcons somehow captured the text being displayed via VGA, probably by snooping the framebuffer. This resulted in a oft difficult to read display due to random artifacts. But, good ol' serial doesn't have this problem - pump it up to 115200, and its quite interactive and easy to read.
So, to all of the people for whom I've suggested the remcons command in the past, try vsp instead - its a lot nicer.
posted at: 17:27 | path: /tech | permanent link to this entry
The next kernel update for sarge is being prepared; testing is welcome - please note your status on the wiki.
Also, for those job seeking types, HP has some jobs open in the Open Source and Linux Organization. You can search for them here.
posted at: 11:10 | path: /tech | permanent link to this entry
I switched to evolution from mutt a little over a year ago. I found that I really need a side-panel list of folders and some better calendar integration. Since then, I'd discovered muttng and other ways of dealing w/ calendar stuff at work, but I just couldn't make myself go through the MUA switch again.
Today I have a couple new reasons. (No offense intended to the gnome/evo guys - they've been responding quickly, and ia64 doesn't have a huge desktop userbase - its something I've wanted to do for a while anyway).
I spent a couple hours splitting out configs so that I can share all of my common settings across machines, and have customizations where necessary for specific locations/situations. I used the 'source file|' syntax to call a shell script that uses heuristics to guess at my environment & generate relevant pieces of muttrc.
I'm already (re-)impressed by how much quicker I can process mail, and of course, the fact that I can customize every little property of the MUA. And I can use my $EDITOR again :)
Now I guess I should take another look at calendaring tools to go with it - I hear sunbird has pretty good support for read/writing calendar info via WebDAV...
posted at: 17:56 | path: /tech | permanent link to this entry
Upstream released 2.6.16 yesterday, and thanks to the non-me members of the kernel team/ftp-master teams, packages are making their way into sid. I tried to get ia64 working before the upload, but got sidetracked debugging an issue that turned out to just be out-dated firmware on my box and didn't get the new configs tested in time. Anyway, I cleaned up the ia64 configs today, and took care of hppa while I was at it, so maybe we can try a 2.6.16-2 tomorrow.
posted at: 15:54 | path: /tech | permanent link to this entry
I've been working on generating complete USB stick d-i installs - (with all necessary packages, not just base) on the stick. The way I ended up doing it is by starting with the d-i manual's instructions for booting from a usb stick w/ an embedded netinst ISO image. I did all this on the first 128MB partition of a 2G stick, then created an ext2 filesystem for a second partition containing an archive of all the packages I wanted available in the second stage (sarge-based d-i, so still has a second stage).
I had problems getting the stick to boot from the first partition - the install-mbr tool didn't do the trick for me. Instead, I cat'd the mbr.bin file from the syslinux source package (not currently included in the syslinux binary package) onto the raw block device. Its also important to make sure your syslinux-configured partition has the bootable flag set (parted /dev/uba -- set 1 boot on) - syslinux doesn't appear to chain to partitions that don't.
It might be better to combine the netinst ISO and the full archive into a single archive embedded in an ISO so that no manual mounting/apt configuration is necessary. But it'd also be cool if the ISO scanning in the second stage was capable of scanning local partitions for archives as well.
posted at: 15:52 | path: /tech | permanent link to this entry