I have performed a number of OpenBSD installations in the past, and have always used the installer to set the timezone. One system that I recently built didn’t have a timezone set, which required me to run the zic(8) utility manually to change the timezone on the system. To set the servers timezone to Eastern with support for daylight savings time, I executed zic with the “-l” (Use the given time zone as local time) option and the timezone I wanted to use:
$ zic -l EST5EDT
Once the timezone was set, I used the rdate utility to synchronize the time on the server:
$ rdate -nv pool.ntp.org
If your not certain which timezone to use, you can check the directory /usr/share/zoneinfo. The zoneinfo directory contains the full list of timezones that can be passed to zic.
I run OpenBSD on a few Soekris 4801s. To get an image “prepped” for the Soekris, I use the directions on the Installing OpenBSD on Flash website. Periodically I need to apply patches to the images, which requires me to adjust the “make install” process to install the package to an alternative location. To apply a patch to a package and install it to an alternate location, I first apply the patch to the package that contains the errata:
$ cd /usr/src/usr.sbin/dhcpd
$ patch -p0 < 006_dhcpd.patch
After the patch is applied, I use the build procedure outlined in the patch header to create the binaries and supporting infrastructure:
$ make obj && make
/usr/src/usr.sbin/dhcpd/obj -> /usr/obj/usr.sbin/dhcpd
cc -O2 -pipe -Wall -c /usr/src/usr.sbin/dhcpd/bootp.c
cc -O2 -pipe -Wall -c /usr/src/usr.sbin/dhcpd/confpars.c
cc -O2 -pipe -Wall -c /usr/src/usr.sbin/dhcpd/db.c
cc -O2 -pipe -Wall -c /usr/src/usr.sbin/dhcpd/dhcp.c
cc -O2 -pipe -Wall -c /usr/src/usr.sbin/dhcpd/dhcpd.c
cc -O2 -pipe -Wall -c /usr/src/usr.sbin/dhcpd/bpf.c
cc -O2 -pipe -Wall -c /usr/src/usr.sbin/dhcpd/packet.c
cc -O2 -pipe -Wall -c /usr/src/usr.sbin/dhcpd/errwarn.c
cc -O2 -pipe -Wall -c /usr/src/usr.sbin/dhcpd/dispatch.c
cc -O2 -pipe -Wall -c /usr/src/usr.sbin/dhcpd/print.c
cc -O2 -pipe -Wall -c /usr/src/usr.sbin/dhcpd/memory.c
cc -O2 -pipe -Wall -c /usr/src/usr.sbin/dhcpd/options.c
cc -O2 -pipe -Wall -c /usr/src/usr.sbin/dhcpd/inet.c
cc -O2 -pipe -Wall -c /usr/src/usr.sbin/dhcpd/conflex.c
cc -O2 -pipe -Wall -c /usr/src/usr.sbin/dhcpd/parse.c
cc -O2 -pipe -Wall -c /usr/src/usr.sbin/dhcpd/alloc.c
cc -O2 -pipe -Wall -c /usr/src/usr.sbin/dhcpd/tables.c
cc -O2 -pipe -Wall -c /usr/src/usr.sbin/dhcpd/tree.c
cc -O2 -pipe -Wall -c /usr/src/usr.sbin/dhcpd/hash.c
cc -O2 -pipe -Wall -c /usr/src/usr.sbin/dhcpd/convert.c
cc -O2 -pipe -Wall -c /usr/src/usr.sbin/dhcpd/icmp.c
cc -o dhcpd bootp.o confpars.o db.o dhcp.o dhcpd.o bpf.o packet.o errwarn.o dispatch.o print.o memory.o options.o inet.o conflex.o parse.o alloc.o tables.o tree.o hash.o convert.o icmp.o
Once the package is built, I use the DESTDIR variable to control where the package is installed:
$ DESTDIR=/usr/images/img make install
install -c -s -o root -g bin -m 555 dhcpd /usr/images/img/usr/sbin/dhcpd
install -c -o root -g bin -m 444 dhcpd.cat8 /usr/images/img/usr/share/man/cat8/dhcpd.0
install -c -o root -g bin -m 444 dhcpd.conf.cat5 /usr/images/img/usr/share/man/cat5/dhcpd.conf.0
install -c -o root -g bin -m 444 dhcpd.leases.cat5 /usr/images/img/usr/share/man/cat5/dhcpd.leases.0
install -c -o root -g bin -m 444 dhcp-options.cat5 /usr/images/img/usr/share/man/cat5/dhcp-options.0
I poked around on google to see which variables are available to control the build process, but was unable to find a complete list. There is a ton of cool stuff in /usr/ports/infrastructure/mk/bsd.port.mk, and I plan to cover some on the niftier variables in a future post.
I have used Veritas Volume Manager (VxVM) and Veritas File system (VxFS) for as long as I can remember. All of my VxVM and VxFS experience has been on Solaris, so I thought I would install both products on a Linux host to see if anything was different. The Linux installation turned out to be nearly identical to the Solaris installation (the Linux installer install RPMs versus SVR4 packages), and the vx* commands are located in the same place in both operating systems. Since I wanted to get my hands dirty and play with VxVM and VxFS on a Linux host, I first ran the vxdisksetup utility to initialize a few devices:
$ /usr/lib/vxvm/bin/vxdisksetup -i hdc
VxVM vxdisksetup ERROR V-5-2-1814 hdc: Invalid disk device for 'cdsdisk' format
Gak! After pondering the error for a few minutes, it dawned on me that as of VxVM 4.0 the “cdsdisk” disk format is used by default. The new format allows devices to be transported between different operating systems and hardware architecures (e.g., you can deport a Solaris disk group on a SPARC host (big endian) and import and access it* on an x86 (little endian) Linux host). After sifting through the Veritas support site to see if cdsdisk had any limitations, I came across infodoc 278178. Infodoc 278178 states that the cdsdisk format can only be used on SCSI disks, and showed how to use the vxscsi command to see if the cdsdisk format could be used with a device:
$ /usr/lib/vxvm/diag.d/vxscsi -g sdd
Cannot get disk geometry on /dev/vx/rdmp/hdd !
The IDE disk drives I was using with the Linux host don’t fit into the cdsdisk supportability matrix, so I decided to the use the “sliced” format since the devices were used purely for testing:
$ /usr/lib/vxvm/bin/vxdisksetup -fi hdc format=sliced
$ /usr/lib/vxvm/bin/vxdisksetup -fi hdd format=sliced
Once the disks were initialized, I added them to a disk group, carved up a new volume, and created a VxFS file system on the volume:
$ vxdg init datadg hdc hdd cds=off
$ vxassist -g datadg make vol01 512m layout=concat
$ mkfs -t vxfs -o bsize=8192 /dev/vx/dsk/datadg/vol01
version 6 layout
8380416 sectors, 523776 blocks of size 8192, log size 2048 blocks
largefiles supported
I plan to fire up my Sun multipack this weekend to see if the Solaris to Linux migration works as well as the folks at Veritas say (based on past experiences with the Veritas product suite, I am relatively certain it will work well).
To deal with endianness issues, you need to use the fscdsconv utility.
I grew up listening to hard rock, and used to bang my head to the likes of Motley Crue, Cinderella, Guns N’ Roses, Ratt, Warrant, Skid Row and the rest of the bands who made the 1980s special. Most of these bands are still touring in one capacity or another, and I recently had the opportunity to see two of these bands, Cinderella and Poison. Both bands were a huge success in the 1980s, and I was curious to see if they could still jam.
Cinderella was the first band to take the stage, and they began their setlist with what sounded like “Fallin’ Apart at the Seams.” The lead singer (Tom Keifer) was having problems hitting the high notes Cinderella is known for, but the show was amazing none the less (Tom Keifer told the crowd that his voice was strained, but he chose to go on tour to make all of us Cinderella fans happy! Awesome!). In addition to playing “Fallin’ Apart at the Seams,” the band also played classic hits such as “Don’t Know What You Got,” “Gypsey Road,” “Shake Me,” “Push Push,” “Shelter Me,” “Heartbreak Station,” and “Coming Home.” Even with Tom’s strained voice, the band sounded awesome, and the crowd loved every minute of their performance.
After Cinderella completed their set, the roadies cleared the stage in preparation for Poison. Eventually the lights dimmed, and Bret Michaels, CC Deville, Rikki Rockett and Bobby Dall popped up out of nowhere to perform “Look What the Cat Dragged In.” The guys sounded incredible, and I had a blast watching CC Deville jam on the guitar. The band played most of their hits, including “Unskinny Bob,” “Every Rose Has It’s Thorn,” “Your Momma Don’t Dance,” “Nothin’ But a Good Time,” “Talk Dirty to Me,” “Fallen Angel,” and “Something To Believe In.” Each hit sounded just like it did back in the 1980s, and I have to say I enjoyed listening to Poison (I was never a huge fan of their music).
Once the show was over and we found our car (we thought we lost it), I met some cool folks and reminisced about the hair band music that made the 1980s the century of rock. The show was a blast, and I would have to say I loved every minute of Cinerella’s performance. They have tons of hits, and are well worth seeing live.
I recently had a friend contact me because he was getting an error similar to the following in his Redhat Linux system log (I didn’t save the error while debugging the problem, so I grabbed this one from the web):
kernel: disk I/O error: dev 08:01, sector 25590410
kernel: SCSI disk error : host 0 channel 0 id 0 lun 0 return code = 28000002
At first glance, I thought the disk drive had failed, and told him to back up all of his data to safe media. Once the data was backed up, I decided to run a full SMART self test on the disk drive to check the drives health:
$ smartctl -t long /dev/hda
smartctl version 5.36 [sparc-sun-solaris2.10] Copyright (C) 2002-6 Bruce Allen
Home page is http://smartmontools.sourceforge.net/
=== START OF OFFLINE IMMEDIATE AND SELF-TEST SECTION ===
Sending command: "Execute SMART Extended self-test routine immediately in off-line mode".
Drive command "Execute SMART Extended self-test routine immediately in off-line mode" successful.
Testing has begun.
Please wait 84 minutes for test to complete.
Test will complete after Sun Aug 27 19:41:01 2006
Use smartctl -X to abort test.
The SMART long test completed successfully, but dd was failing when attempting to read sector 25590410 (we weren’t using the continue on error option). Since all modern disk drive controllers contain logic to remap faulty sectors when they are detected, and the number of reallocated sectors as reported by smartctl was well below the manufacturers failure threshold, I wondered if the sector was “stuck.” To test my theory, I booted from a Linux CD, and ran the Linux badblocks utility on the disk partition (I didn’t save the badblocks output from his drive, so the following is a sample from another machine):
$ badblocks -sv /dev/hda
Checking blocks 0 to 8192016
Checking for bad blocks (read-only test): 222400/ 8192016
Badblocks completed successfully, and an fsck of the file system reported that the file system was clean (We also used the ext3 file system debugger to see if a file was using the block. It wasn’t, so my theory is that the errors occurred when a new file was being created). Next we rebooted the system, and the number of reallocated sectors reported by smartmontools had increased by one. This completely surprised me, and I am still confused why the disk controller didn’t remap the sector when we were booted from the disk drive. I had fun debugging this problem, and learning about how IDE disk drives work.