|
More kickstart fun
Posted on 29 September 2003 02:00 | Permalink
Well, last week was fun, but exhausting, trying to debug problems with the kickstart. I wanted to put up a few notes here about tricks I learned.
E1000.o The biggest obstacle here was getting the whole PXE/Kickstart/boot kernel process to work, particularly getting the right driver for the Intel gigabit ethernet cards. I had found the driver (e1000.o) was included as part of the 2.4.20 kernel, so my initial efforts were directed to putting the e1000.o module from RedHat's update kernels into the initrd sent out in the PXE process. It appears that we must have some pretty new hardware with these NICS as it was a no-go with that driver.
After digging about a bit on RedHat mailing lists (anaconda-devel-list, and kickstart-list, to be precise), I found mention of a process to build newer drivers to match the kernels involved. Bundled with the RedHat kernel-source rpm is a directory at the top of the kernel tree (/usr/src/linux-version/configs) which houses various kernel configuration files that can be used to build kernels and/or modules to meet the specifications of the various redhat kernels. The process goes something like this:
[root@host root]$ cd /usr/src/linux-2.4
[root@host linux-2.4]$ cp configs/kernel-2.4.7-i386-BOOT.config .config
With the config file copied into place, you run make oldconfig which will configure the kernel tree to the specs outlined in the config file. You then run make dep, and then run back to the source directory of the driver. From there I had to tweak the makefile to look in the right spot for the kernel sources, as well as tweak the main Makefile in the top level kernel source directory. In the Makefile there is a line like this near the top:
EXTRAVERSION = -10.......
The -10 in this case is RedHat's release number for their rpms, and it's followed by something like 'BOOT','smp','enterprise','ibcs', etc., depending on which kernel you're building. You need to change the tag to match whatever kernel you're trying to match, be it 'smp', 'enterprise', or 'BOOT' in the case of RedHat's PXE boot kernels.
With these changes made, the module in place in the modules.cgz (a gzipped cpio archive) of the /modules directory of the initrd, and the /modules/pcitable and /modules/module-info files updated (also in the initrd) it looks like it's going to work, but I've got one last hurdle to jump (btw, lspci -n is a great help to make sure you've got the right line in the pcitable file).
We're using Cisco switches in our network, and from what I gather under certain conditions the switch will wait for 30 seconds to allow traffic across a port after the link comes up, unless you specify 'spantree portfast enable' on the given port. That hoses a kickstart install when the system goes to retrieve DHCP information. I have yet to test it out, (waiting on the network guys at corp. HQ), but that would explain the behavior I'm seeing.
Hmmm, looking back over what I've written, I can see a lot of contextual info is missing. This isn't a tutorial for PXE/Kickstart installs, but hopefully might provide a few clues for someone in a similar situation. If nothing else, it should help me to remember 'what-I-done' a few months down the road when we get new hardware in again :-).
Reader comments: 0
Kickstart fun
Posted on 24 September 2003 13:08 | Permalink
11:00 am
Today's task is to get three new machines online, using our kickstart system. The fun is that these new machines have Intel GigE interfaces, using the e1000.o kernel module. so I've worked to put together a new initrd based on the 2.4.20 kernel (which includes the e1000 module) to send via PXE, and have put the e1000.o in there along with the other modules. So far it's been a no go. In the meantime I'm also installing the new RH Severn beta on a Dell C600 laptop.
11:01 am
I remember reading yesterday in a redhat mailing list of someone having similar issues trying to get the e1000.o module to load in a kickstart install. A workaround recommended was to put the e1000.o module in the /tmp directory of the initrd. I'm trying that now.
Wow, that actually worked. It looks like the module loaded (how bizarre....) but now it asks for which interface I want to use to run the kickstart process (how annoying) even though I told it to do it through eth0 on the kernel command line (ksdevice=eth0).
11:08 am
Looks like eth1 is gonna be our winner, actually.
Reader comments: 0
My mini-distro
Posted on 11 August 2003 14:32 | Permalink
12:00 pm
Today I am having fun building a Linux boot image. The overall goal I'm trying to accomplish is to create a 'mini-distribution' that I can send to any given host via PXE. The images would be booted providing serial console and ssh access, so we could use it to diagnose hardware issues. Kind of like a rescue image on steriods. So Friday I spent some time reading through the Linux Bootdisk HOWTO getting accquainted with what I would need in a basic image. Leaving work Friday, I figured the best plan of action was to put everything I wanted in the initrd that I could easily specify as a kernel param via PXE.
So I put together a simple filesystem with dd if=/dev/zero of=my_fs bs=1k count=20000, and then mke2fs myfs. I copied over the /dev files, a few /etc files, etc. and got things ready to send to the test machine via PXE. The first problem I ran into was the kernel bailing, saying "attempt to read beyond end of device". This was puzzling. A little googling for that error message indicated that I needed to use the kernel boot paramater ramdisk_size=20000. I added that and got a little farther, but now the kernel was complaining that it couldn't mount the root filesystem as it was "unable to read superblock". Hrm. I ran e2fsck on the fielsystem, and cleaned up any issues there, but still ran into the problem. More googling brought me to the Linux for PowerPC Embedded Systems HOWTO, which tells me that I need to be also specifying the kernel parameter root=/dev/ram to tell the kernel, yes, I want to use the initial ram disk as my root filesystem.
That brings me to where I am now. The kernel is complaining that it can't find init. That should be easy to fix...
12:24 pm
I made sure /sbin/init was available in my image, and also checked which libraries it needed with ldd. I copied over libc.so.6, /bin/bash to interpret /etc/rc.d/rc.sysinit, and some more required libs for bash, libtermcap.so.2 and ld-linux.so.2. Since I'm not dealing with the constraints of putting all of this on a floppy, I'm not worrying about stripping binaries or other fun stuff to reduce space usage. I also changed the root= boot param to root=/dev/ramdisk, which is a symlink to /dev/ram0, which should be the right spot. I booted up with that in place, and voila, I get init complaining about syntax errors in /etc/rc.d/rc.sysinit. Now things are really getting easy. Looks like I left a quoted string un-terminated.
12:32 pm
Wohoo! Success! My little creation booted up, has the ramdisk mounted, and greeted me with an echo line from /etc/rc.d/rc.sysinit. The rest is easy now. Just add all the binaries I need to do what we want. My co-worker says we should make the boot process run from Perl ;-). Piece of cake.
Reader comments: 1
Xapian
Posted on 31 July 2003 02:00 | Permalink
Today I wanted to put up a link to a very nice "Open Source Probabilistic Information Retrieval library", Xapian. That's a mouthful for what is just a very nice Open Source search engine library. I have found it to be very flexible (with Perl bindings :-D), and a breeze to work with. It does have a prepackaged indexer and search cgi you can use "out of the box", but it also makes it very easy to build your own search engine from scratch using its capabilities.
Reader comments: 0
Portmapper madness
Posted on 23 July 2003 02:00 | Permalink
Ran into a fun little problem on a RedHat box today. For one reason or another, the machine was set to have almost no services start up on boot. So I consoled in via the serial console, got the network up, and then tried to mount up some NFS volumes. The mount command would just hang. So I checked all the network settings, and could ping the NFS server, there were no firewalling rules getting in the way, but the command would just hang. After some head-scratching, it occurred to me that if no services had started up, then likely the portmapper hadn't started, and you kind of need the portmapper running for NFS to work. So I started the portmapper, and voila, it worked. Just a tidbit to file away...
Reader comments: 0
Oracle archive log mode recipe
Posted on 18 April 2003 12:00 | Permalink
Quick recipe for enabling archivelog mode on Oracle8i (Since I seem to keep forgetting):
SQL> shutdown immediate
SQL> statup mount
SQL> alter database archivelog;
SQL> alter database open;
SQL> shutdown immediate
Then take a full backup.
Reader comments: 0
Conserver
Posted on 18 April 2003 02:00 | Permalink
Yesterday I stumbled upon conserver (www.conserver.com) which should make for more convenience when I have to manage remote hosts in our data center via serial console. Previous to now, I have had to ssh to our console host, become root, and use a little script which coaxes minicom to connect to the appropriate serial port (we use some multi-port serial cards). conserver allows me now to simply run a command from my local machine which connects to a daemon running on our console host and connects right to the appropriate serial line. Very nice. It also encrypts the connection between my host and the console server. It supports PAM authentication, so you can set it up to allow console sessions to anyone who has a shell on the console host. I had to do some dancing with rpms to get an up-to-date openssl (our console host is a badly-needs-to-be-upgraded RedHat 6.1 box), but I managed ok, and after applying an rpm update of the pam package from RedHat, everything was working great. One bash alias later, and I'm ready to start adding more hosts to the config file.
One problem I've found as I've been configuring this is that apparently I can't have two entries in conserver.cf pointing to the same serial port. Rats. So much for machine aliases. Still a very useful tool, though.
Reader comments: 0
Setting speed and duplex of Solaris network interfaces
Posted on 11 April 2003 02:00 | Permalink
11 Apr 2003
I found today that the network interface on one of the SPARCS I manage today was only set to 100Mb/s, half-duplex. Yuk. So much for autonegotiation. Well, here's how to check and how to fix such a problem, (Solaris OS). To find out what mode you're operating in you can do the following:
# ndd -get /dev/hme link_mode
1
# ndd -get /dev/hme link_status
1
# ndd -get /dev/hme link_speed
1
If you get all '1's you're in good shape. That means the link is up, (link_status=1), running at 100 Mb/s (link_speed=1), and at full-duplex (link_speed=1). If you get any zeros back, that could be an indication of a problem. link_mode=0 indicates half-duplex, link_status=0 means the if is down, and link_speed=0 means you're only running at 10Mb/s (btw, I wonder what you'd get with a GigE interface at 1000Mb/s...2???). Anyways, to fix such a problem you'll want to do something like this:
# ndd -set /dev/hme instance 0
# ndd -set /dev/hme adv_100fdx_cap 1
# ndd -set /dev/hme adv_100hdx_cap 0
# ndd -set /dev/hme adv_10fdx_cap 0
# ndd -set /dev/hme adv_10hdx_cap 0
# ndd -set /dev/hme adv_autoneg_cap 0
This assumes you're dealing with interface hme0. If not change the /dev file, and instance number accordingly, (e.g., ndd -set /dev/qfe instance 1). If you look at the names of the parameters you are setting you should be able to get a good idea of what this all means. To make this permanent across reboots, put the following in /etc/system:
* Force full-duplex operation
set hme:hme_adv_autoneg_cap=0
set hme:hme_adv_100fdx_cap=1
set hme:hme_adv_100hdx_cap=0
set hme:hme_adv_10fdx_cap=0
set hme:hme_adv_10hdx_cap=0
If for some strange reason you need half-duplex or 10Mb/s, you can probably figure out what to do.
One more note. If you're doing this across a remote link, and manipulating the interface over which you've got your shell running, you may be wondering whether your connection will stay up across these changes. Especially if you don't have a serial console connection to bail you out...well, don't fear. After you run the last ndd command (-set adv_autoneg_cap 0...) your connection will hang for a few seconds, but should come back (I'm writing this here, as none of the docs I could find told me what would happen...) after a few seconds.
Reader comments: 0
Oracle LOB locators
Posted on 03 January 2003 02:00 | Permalink
When examining the sql_text field of the v$open_cursor data dictionary view in Oracle, you may occasionally find yourself seeing sql_text that looks like this: "table_e_400_XXXX_4_0_0". What is this? This OTN article explains what's up. You're seeing open LOB locators. If you see 'table_e' the LOB is open for writing, if it's 'table_4' the LOB is open for reading. What lob is being opened? The number indicated by XXXX above is the object_id. So something like this will shed light on the situation:
SELECT object_name, object_type
FROM user_objects
WHERE object_id = to_number('9999','XXXX');
That, of course, assumes the object_id you saw was '9999'
Reader comments: 0
Oracle deadlock dumps
Posted on 23 July 2002 02:00 | Permalink
>In Oracle deadlock dumps, you'll notice the two lines containign strings looking like: TM-000042f5-00000000. Well, the middle number in that string is the hexadecimal value for the object id of the object in question (i.e., the one the transaction is trying to lock). So just convert the number to decimal, and then do SELECT object_name, object_type FROM dba_objects WHERE object_id=;
Reader comments: 0
<- Prev 10 | Next 10 ->
|
