you are here: http://jnfuller.freeshell.org/
fail: do-release-upgrade from intrepid to jaunty; re-fail: jaunty apt-get dist-upgrade failures
I just finished upgrading an intrepid server to jaunty and ran into a potentially catastrophic yaird failure during the upgrade. If I had not been paying attention to the apt-get warnings and rebooted the server after the upgrade I would have ended up with a boot failure as the ramdisk for boot can't be generated!
This is exactly the sort of crap that keeps GNU/Linux out of Grandma's house and in the geek basement.
The error looks like this:
Setting up linux-image-2.6.28-11-server (2.6.28-11.42) ...
Running depmod.
yaird error: bad device link in /sys/block/cciss!c0d0 (fatal)
*Failed to create initrd image.*
Basically what Failed to create initrd image means is that the initial ramdisk, a temporary file system commonly used in the boot process of the Linux kernel didn't get created. An initrd is used for making preparations before the real root file system can be mounted. If you reboot without one of these things you've created a very expensive GNU/paperweight.
Luckily, it's not too hard to get around this error!
First...
vi /etc/kernel-img.conf
and change
ramdisk = /usr/sbin/mkinitrd.yaird
to
#ramdisk = /usr/sbin/mkinitrd.yaird
and then save the file.
you should be able to
apt-get install -f
and recover a failed upgrade.
It might be a good idea to do an
update-grub
and
update-initramfs -u
before rebooting just to be on the safe side if you're not 100% sure the initrd got built correctly.
This doesn't fix the bad device link error but will keep you up and running to get that all sorted out.
It turns out that this bug has to do with compaq smart controllers according to a patch discussion that I found in nabble for yaird 0.0.11-11...
diff -urN -x {arch} -x .arch-ids -x configure -x aclocal.m4 -x depcomp -x missing -x Makefile -x Makefile.in
-x install-sh -x INSTALL p73/perl/Plan.pm p74/perl/Plan.pm
--- p73/perl/Plan.pm 2005-10-24 23:51:03.000000000 +0200
+++ p74/perl/Plan.pm 2005-10-24 23:50:57.000000000 +0200
@@ -426,6 +426,22 @@
return 1;
}
+ #
+ # compaq smart controllers in 2.6.13 also lack the hardware link.
+ # plan B: assume that a cciss is a cciss.
+ # complication: there's a discrepancy between /sys and /dev:
+ # /sys/block/cciss!c0d0 and /dev/cciss/c0d0, but this turns out
+ # to have no further consequences.
+ #
+ # note that there also exist /dev/ida/c0d0 devices with cpqarray
+ # underlying devices, but no reports about those so far.
+ #
+ if ( =~ /^cciss!c\d+d\d+$/) {
+ ModProbe::addModules (, [ "cciss" ]);
+ ->add("mkbdev", ->yspecial, sysname => );
+ return 1;
+ }
+
return 0;
}
None yet... I plan to check out Yaird from CVS or SVN or whatever they use for revision control and see if it fixes the bug in the latest code because I don't think the Debian GNU/Linux repos are up to the same patch level for Yaird. (NOTE: I actually did this but the bug still crops up in yaird: version 0.0.12 so it isn't fixed in the current Jaunty apt-repos.)
Right now the only solution I can find is to keep yaird commented out.
It looks like this may be an ongoing issue with Jaunty as things are still hosed with yaird: version 0.0.12. I just ran into this issue again during an apt-get dist-upgrade that makes me question the OS version as viable for production...
Setting up linux-image-2.6.28-13-server (2.6.28-13.44) ...
Running depmod.
yaird error: bad device link in /sys/block/cciss!c0d0 (fatal)
Failed to create initrd image.
For syntax see system.conf.sample
span=1,0,0,esf,b8zs
span=1,0,0,d4,ami
For syntax see system.conf.sample
bchan=1-23
dchan=24
For syntax see chan_dahdi.conf.sample
[channels]
;--- PRI interface options
; Switchtype: Only used for PRI.
;
; national: National ISDN 2 (default)
; dms100: Nortel DMS100
; 4ess: AT&T 4ESS
; 5ess: Lucent 5ESS
; euroisdn: EuroISDN (common in Europe)
; ni1: Old National ISDN 1
; qsig: Q.SIG
switchtype=national
context=incoming-from-dahdi ; defined in extensions.conf
signalling=pri_cpe ; should be pri-cpe for customer side
Once you've defined groups in chan_dahdi.conf.sample they can be referenced in extensions.conf
[channels]
;--- PRI interface options
. . .
group=1 ; reference for hunting method in extensions.conf
channel=>1-23 ; follows b-channel provisioning
For syntax see chan_dahdi.conf.sample
; unknown: Unknown
; private: Private ISDN
; local: Local ISDN
; national: National ISDN
; international: International ISDN
; dynamic: Dynamically selects the appropriate dialplan
; redundant: Same as dynamic, except that the underlying number is not
; changed (not common)
For syntax see chan_dahdi.conf.sample
"international" : A fully formed E.164 phone number.
[channels] . . .
; PRI Dialplan: The ISDN-level Type Of Number (TON) or numbering plan, used for
; the dialed number. For most installations, leaving this as 'unknown' (the
; default) works in the most cases. In some very unusual circumstances, you
; may need to set this to 'dynamic' or 'redundant'. Note that if you set one
; of the others, you will be unable to dial another class of numbers. For
; example, if you set 'national', you will be unable to dial local or
; international numbers.
pridialplan=unknown ; Asterisk default
For syntax see chan_dahdi.conf.sample
"international" : A fully formed E.164 phone number.
; PRI Local Dialplan: Only RARELY used for PRI (sets the calling number's
; numbering plan). In North America, the typical use is sending the 10 digit
; callerID number and setting the prilocaldialplan to 'national' (the default).
prilocaldialplan=national ; Asterisk default
For syntax see extensions.config.sample
; g: select the lowest-numbered non-busy DAHDI channel
; (aka. ascending sequential hunt group).
; G: select the highest-numbered non-busy DAHDI channel
; (aka. descending sequential hunt group).
exten => 1,1,Dial(DAHDI/g1/8675309) ; ascending sequential hunt group (LIDL towards provider)
exten => 2,1,Dial(DAHDI/G1/8675309) ; descending sequential hunt group (MIDL towards provider)
; deprecated zaptel example
; exten => 1,1,Dial(ZAP/g1/8675309)
; exten => 2,1,Dial(ZAP/G1/8675309)
iMac:~ UserAcct$ ps -A|grep lert 420 ?? 0:11.58 /Applications/iAlertU.app/Contents/MacOS/iAlertU -psn_0_172074 1698 ttys000 0:00.00 grep lert iMac:~ UserAcct$ kill 420
It's pretty funny that iAlertU just happened to have a process id of 420 when it decided to spazz out and quit responding. You just can't make up weed humour like that.
Fixing MIBS search path in Wireshark OS X
The current version of Wireshark-- 1.0.8-- for OS X has a MIBS search path error that is extremely easy to fix with a few symbolic links.
The following errors were found while loading the MIBS:
-:0 1 module-not-found failed to locate MIB module `IP-MIB'
-:0 1 module-not-found failed to locate MIB module `IF-MIB'
-:0 1 module-not-found failed to locate MIB module `TCP-MIB'
-:0 1 module-not-found failed to locate MIB module `UDP-MIB'
-:0 1 module-not-found failed to locate MIB module `SNMPv2-MIB'
-:0 1 module-not-found failed to locate MIB module `RFC1213-MIB'
-:0 1 module-not-found failed to locate MIB module `IPV6-ICMP-MIB'
-:0 1 module-not-found failed to locate MIB module `IPV6-MIB'
-:0 1 module-not-found failed to locate MIB module `SNMP-COMMUNITY-MIB'
-:0 1 module-not-found failed to locate MIB module `SNMP-FRAMEWORK-MIB'
-:0 1 module-not-found failed to locate MIB module `SNMP-MPD-MIB'
-:0 1 module-not-found failed to locate MIB module `SNMP-NOTIFICATION-MIB'
-:0 1 module-not-found failed to locate MIB module `SNMP-PROXY-MIB'
-:0 1 module-not-found failed to locate MIB module `SNMP-TARGET-MIB'
-:0 1 module-not-found failed to locate MIB module `SNMP-USER-BASED-SM-MIB'
-:0 1 module-not-found failed to locate MIB module `SNMP-USM-DH-OBJECTS-MIB'
-:0 1 module-not-found failed to locate MIB module `SNMP-VIEW-BASED-ACM-MIB'
....followed by the local path information.
In OS X 10.5.x the MIBS are in /usr/share/snmp and not where Wireshark is looking. This isn't technically a bug because OS X comes with Net-SNMP and Wireshark expects Samba's libsmb to be installed. (It's not a bug, it's a feature!)
Short of using port or fink to install libsmb the easiest way to fix this is to create symbolic links to point to the mibs to make the error go away.
Open up Terminal.app and ''sudo -s'' to become administrator.
cd /usr/local/share
ln -s /usr/share/snmp/mibs/ mibs
cd mibs
ln -s . iana
ln -s . ietf
ln -s . site
ln -s . tubs
Running as admin and adding the path for Net-SNMP to the mibs/pibs path in Name Resolution doesn't seem to work for me. You may wish to delete your ~/.wireshark folder before trying this just in case you have any old preference files with bad permissions.

What fucktard at Apple decided that this was a good default setting?
tonight's dinner: tandoori chicken, dahl and rice
Simmer lentils in a covered pot in the water until well cooked. In a seperate frying pan or wok, saute onion in oil until translucent. Add spices and coconut and cook for a few minutes more. Lower the temperature to minimum, and add cooked lentils and yogurt. Stir until well mixed and heated through (5-10 minutes). Serve over rice, topped with a bit of extra coconut.
If you actually need a recipe to cook rice you are too stupid to live.
Nice try, Britney. The Poster Children only did this in 1991.
iPod Touch Skyhook Geolocation
I've recently moved from New Westminster, BC, to Coombs, BC, and my iPod Touch still geolocates to my old address based upon the information in the Skyhook database.
If you move you can update your MAC information in Skyhook and in about five weeks the information will be populated in the production databases.
I'll be really glad when the information updates because it really sucks to have all my geolocation polls come up with my old information.
Out of all the stuff I used to listen to I still regularly listen to a few bands: Joy Division, New Order, Skinny Puppy, My Bloody Valentine, Hüsker Dü, Jazz Butcher and New Model Army.
Here are some bands I like that I've listened to recently: TV on the Radio, Seabear, Cloud Cult, I Love You But I've Chosen Darkness, Matthew Good, Arcade Fire, Hank III, Whiskeytown, Sigur Ros and Dan Le Sac VS Scroobius Pip.
jnfuller -AT- freeshell -DOT- org
My Resume
plain text format
Social Networking
me on Facebook
me on Twitter
Music
my music on iLike
my music on archive.org
my music on the mod archive
Wikis
me on pqlug.org
me on voip-info