Xenorg's Stuff

I recently purchased some 2950 switches from ebay, only to find they had had there flash erased.

Booting the switch dropped me to the rommon prompt as it couldn’t find a boot image -

Boot Sector Filesystem (bs:) installed, fsid: 3
Parameter Block Filesystem (pb:) installed, fsid: 4
Loading “”…: permission denied

Error loading “”

Interrupt within 5 seconds to abort boot process.
Boot process failed…

The system is unable to boot automatically. The BOOT
environment variable needs to be set to a bootable
image.

switch:

First step is to set the baud rate to 115200 to speed up transferring of the IOS image -

switch: set BAUD 115200

Then reconnect with ZTerm set to 115200 baud.

Now change the ZTerm transfer protocol to XModem-1k by selecting Settings->Transfer Options… menu item, and changing the Default Protocol for Send to “XModem-1k”.

Now select the File->Transfer Convert->Binary Data menu item. If you leave the transfer convert option on Smart MacBinary, you will get errors like the one below, when you try to boot the image -

Loading “flash:c2950-i6q4l2-mz.121-22.EA14.bin”…flash:c2950-i6q4l2-mz.121-22.EA14.bin: magic number mismatch: bad mzip file

Back at the switch: prompt enter the following command to get the switch ready for the transfer of the IOS image.

switch: copy xmodem: flash:c2950-i6k2l2q4-mz.121-22.EA14.bin
Begin the Xmodem or Xmodem-1K transfer now…
CC
### Send (X) c2950-i6k2l2q4-mz.12#10D571.bin: 3722814 bytes, 8:06 elapsed, 7656
cps, 66%
……………………………………………………………………..
……………………………………………………………………..
……………………………………………………………………..
……………………………………………………………………..
……………………………………………………………………..
……………………………………………………………………..
……………………………………………………………………..
……………………………………………………………………..
……………………………………………………………………..
……………………………………………………………………..
……………………………………………………………………..
………………………..
File “xmodem:” successfully copied to “flash:c2950-i6k2l2q4-mz.121-22.EA14.bin”

Now choose File->Send Xmodem-1k… menu item, and select your IOS image, and the transfer will begin.

Once the copy has completed, set the baud rate back to 9600, reconnect at 9600 baud, and boot your switch with the new IOS image.

switch: set BAUD 9600
switch: boot flash:c2950-i6k2l2q4-mz.121-22.EA14.bin

Since cisco UCM is only compatible with VMWare and not Virtual Box, the following commands need to be run from the commandline to make virtualbox look like vmware.

VBoxManage setextradata "" "VBoxInternal/Devices/pcbios/0/Config/DmiBIOSVersion" "6 "
VBoxManage setextradata "" "VBoxInternal/Devices/pcbios/0/Config/DmiSystemVendor" "VMware"
VBoxManage setextradata "" "VBoxInternal/Devices/pcbios/0/Config/DmiBIOSVendor" "Phoenix Technologies LTD"
VBoxManage setextradata "" "VBoxInternal/Devices/pcbios/0/Config/DmiSystemProduct"

sudo automount -vc

Here’s an interesting talk about zfs and tuning.

The original can be found here.

The Problem

Having recently updated my solaris 10 fileserver with kernel patch 141445-09, i noticed that zpool status was now prompting me to upgrade my zfs file system version. I had a look at http://hub.opensolaris.org/bin/view/Community+Group+zfs/xx to see what had changed since the version i was currently running, and though I may as well upgrade.

First I ran

sudo /usr/sbin/zpool upgrade data

to update my main data pool. It worked fine, so proceeded to update my root pool…

sudo /usr/sbin/zpool upgrade rpool

which also worked without issue.

A few days later I rebooted the system to install a new version of VirtualBox, and got greeted with the following prompt -

grub>

It took a while to figure out, but it seems that if you update the zfs version, you also have to reinstall the grub boot loaders….

Solution

After upgrading the root pool zfs version run the following commands.

bash# installgrub /boot/grub/stage1 /boot/grub/stage2 /dev/rdsk/c0t1d0s0 (or whatever your root drive is)

bash# bootadm update-archive

I recently had to debug an java application at work that appeared to be having contention type issues while reading and writing files. The application consists of 7 modules. The first module polls a directory (a) for new files, when a file appears it does some work and copies it to directory (b). The next module polls directory (b), does some work and copies the file to directory (c), and so on and so forth. The errors we were getting appeared to hint at modules picking up files before the previous module had finished writing them.

To confirm this I used the following dtrace script to watch the modules opening and closing the files, to see where the modules overlapped.

#pragma D option quiet

BEGIN
{
printf(“Action\t\tProcess\tPID\tFilename\n”);
}

syscall::open*:entry
/pid==21086 || pid==21080 || pid==21077 || pid==21092 || pid==21074 || pid==21083 || pid==21089/
{
self->fileopen = arg0;
printf(“Open:entry\t%s\t%d\t%s\n”, execname, pid, copyinstr(self->fileopen));
}

syscall::open*:return
/pid==21086 || pid==21080 || pid==21077 || pid==21092 || pid==21074 || pid==21083 || pid==21089/
{
printf(“Open:return\t%s\t%d\t%s\n”, execname, pid, copyinstr(self->fileopen));
self->fileopen = 0;
}

syscall::close:entry
/pid==21086 || pid==21080 || pid==21077 || pid==21092 || pid==21074 || pid==21083 || pid==21089/
{
self->fileclose = fds[arg0].fi_pathname;
printf(“Close:entry\t%s\t%d\t%s\n”, execname, pid, self->fileclose);
}

syscall::close:return
/pid==21086 || pid==21080 || pid==21077 || pid==21092 || pid==21074 || pid==21083 || pid==21089/
{
printf(“Close:return\t%s\t%d\t%s\n”, execname, pid, self->fileclose);
self->fileclose = 0;
}

This produced the following output (i removed the uninteresting parts)

Action Process PID Filename
Open:entry java 21092 /blah/1807
Open:return java 21092 /blah/1807
Open:entry java 21086 /blah/1807
Open:return java 21086 /blah/1807
Close:entry java 21092 /blah/1807
Close:return java 21092 /blah/1807
Close:entry java 21086 /blah/1807
Close:return java 21086 /blah/1807

Here you can clearly see that the file 1807 is being opened by process 21092, then opened by 21096, after which it is closed by 21092, and then 21086. Due to the overlap, we can conclude the 2 processes are accessing the file at the same time.

Are you finding your splunk install has become incredibly slow all of a sudden? Maybe even timing out running any search at all. I recently had this problem, and found it was due to a recent crash of splunk. When splunk crashes, it doesn’t get to clean up some lock files it creates, and the next time it’s run, will wait for these locks to clear before it can run a search…ie it will wait forever… The solution is to kill splunk, then clean up the .lock files from /var/lib//db/
Now when you restart splunk it will actually respond to your queries

Well i received my Supermicro AOC-USAS-L8i 8 port SAS UIO card last night. These cards are made for the supermicro UIO slots, found on some of their motherboards, however it seems that really they are just a PCI-E card in disguise.

The cards have the pci bracket reversed, and all components (resistors, caps etc) are on the top of the card, instead of the bottom like a normal card. To make it fit in a regular pci-e slot, you just need to remove the pci bracket. I tried the card in my intel s3210shlc motherboard in the first pci-e slot, and the system booted up and detected the card as if it was a regular pci-e card. Solaris 10 booted, and recognised it as a LSI hba (mpt driver), with 3 750gb wd disks attached. I then added the 3 disks as a raidz set to my existing zfs pool, and everything seems to be working without a hitch.

So i can confirm this card works in the pci-e slot of my intel s3210shlc, however no guarantees about any of the other supermicro uio cards…

Had a problem with my new install of solaris incorrectly binding my usb backups rs to the hid driver instead of ugen. After a bit of googling I found this page. What needs to be done is to remove the ugen driver, then attach it again to the correct device. Only 2 commands are needed. In my case -


sudo /usr/sbin/rem_drv ugen
sudo /usr/sbin/add_drv -i '"usb51d,2.106"' -m '* 0666 root sys' ugen


You can find the correct device info using the command ‘prtconf -v’

Found OpenNMS tonight…looks like it could be useful.