Extract the ISO

Get your install ISO from somewhere and extract it to some directory.

mkdir ./iso
tar -C ./iso -pxf 8.0-RELEASE-i386-disc1.iso
cd ./iso

loader.conf

Next thing to do is to tell the boot loader to start using the serial port. This can be done by putting:

console="comconsole"

somewhere inside boot/loader.conf (obviously inside the iso directory)

Make the ISO!

Now wrap it all up into an iso using:

mkisofs -J -r -b boot/cdboot -no-emul-boot -o 8.0-RELEASE-i386-disc1-serial.iso ./iso

or something of the sort.

You’re done!

Go burn the ISO file and boot a system off the CD. Set your terminal’s baud rate to 9600 and you’ll eventually see things booting up!

Here’s my process:

Verify Anonymous CVS Connectivity

First, you must verify that you can connect to the anoncvs server. You can find instructions in the FreeBSD Handbook for this process.

One thing you should probably be aware of is that there are a very limited number of anoncvs mirrors, which is why I chose the .tw one.

Prepare Your Ports Tree

You need to be sure that you have an updated portsdb installed so portdowngrade is able to find the matching ports with a search.

portsdb -u

Installing & Using portdowngrade

cd /usr/ports/*/portdowngrade && make DEFAULT_CVS_SERVER=\":pserver:anoncvs@anoncvs.tw.freebsd.org:/home/ncvs\" install clean

Note that you may replace the server name with whichever mirror you chose in the earlier step.

Once installed, you may now downgrade the port using:

portdowngrade devel/bugzilla

for instance. From here the documentation will be more than enough to show you how to get the downgraded port checked out and installed.

The Missing Step: Making portupgrade Ignore the Port!

This is easy as pie, but there are two ways to do it. I chose to do both.

Option 1: Edit the pkgtools.conf file

Usually located in /usr/local/etc/, pkgtools.conf will allow you to specify an additional port in the HOLD_PKGS array like such:

HOLD_PKGS = [
    'bsdpan-*',
    'devel/bugzilla*'
]

Option 2: +IGNOREME

Creating a +IGNOREME file in the package directory will stop both portaudit and portmaster from upgrading the port.

touch /var/db/pkg/bugzilla/+IGNOREME

There’s a way more updated version of the iSCSI Initiator on the developer’s public FTP site.

ftp://ftp.cs.huji.ac.il/users/danny/freebsd/

With this version I’m now seeing acceptable IO (around 65MB/s reads/writes) after setting tags=256 in iscsi.conf.

All credits to the developer.

Because I’m in the US, I have fairly bad connectivity to that site. I’ve mirrored it here:

http://uminac.com/mirror/ftp.cs.huji.ac.il/users/danny/freebsd/

As A Target (Server)

The only available iSCSI target software in FreeBSD is the /net/iscsi-target port. This is the iSCSI target from OpenBSD and is absolutely not suitable for production use (or even most non-production uses).

Problems I’ve come across:

• Does not support CHAP.
• Will not allow multiple connections to the same target (LUN). This is useful in the case of VMWare ESX/ESXi.
• Cannot rehash configuration file. If you add/remove a target you must restart the daemon completely, ending all current connections.

As An Initiator (Client)

The iSCSI initiator in FreeBSD 7.2 (currently) suffers from many issues. These issues prevent it from being suitable for production use. There is, however, a newer version of the iscsi_initiator kernel module shipping in 8.0-BETA1 and the -current branch (HEAD). By nature these versions of the FreeBSD operating system are not suitable for production use.

Problems I’ve come across in FreeBSD 7.2:

• No official documentation. While it is a simple configuration, you have to find procedures strewn about the web.
• Poor performance without tags tweak. I achieved no better than 2MB/s transfer rate without setting tags = 256 in iscsi.conf.
• No rc scripts. Devices must be attached after boot by admin or cron.
• System lockups under loads. Copying files to the iSCSI array via gigabit has repeatedly locked the system up. To test I copied the files from a local disk to the array and had the same result.

Problems I’ve come across in FreeBSD 8.0-BETA2:

• It includes an updated version, but it just flat out doesn’t work. When attaching the target with iscontrol -n targetname the iscontrol process hangs forever and cannot be killed with a -9.
• Still no rc scripts of any kind.

Comments are welcome.

options iscsi_initiator

connected to the iSCSI target across the LAN, then I used:

dd if=/dev/zero of=/mnt/testiscsi/file.out bs=65536

to test the speeds after mounting it. I observed horrific speeds (in the range of 300-500KB/s).

To make a long story short, I discovered that using the extra Intel NIC I put in the system’s PCI slots fixed the problem. So I tried to upgrade firmware, but they all seem to be up to date. Looks like I’ll be disabling them in the BIOS and ordering some more Intel cards.

Damn Dell for putting those crappy Broadcoms in there.

Anyway, somebody who I take very seriously told me, very seriously, that I should consider mod_security. So I did. It’s awesome. I’ll never look back.

Everyone who is a user on popsicle should check that everything they had going before is still going!  If not, you know who to contact.

I decided to play with it a bit, and found that it functioned.  It’s got a few problems though (can’t rehash config files to add/remove lun’s without killing all open connections, and restarting).

My ability to code in c is very weak, but I guess maybe I’ll try to investigate how it works, and see if I can’t at least come up with a patch for that specific thing.  The other problems with the code are way above my head, having to do with authentication, and encryption.

Who knows…

/etc/rc.d/named: WARNING: devfs_domount(): Unable to mount devfs on /var/named/dev
devfs rule: ioctl DEVFSIO_RAPPLY: Operation not permitted
devfs rule: ioctl DEVFSIO_RAPPLY: Operation not permitted

The reason for this is that by default in FreeBSD named tries to run within a chroot. The chroot for named requires /dev/zero, and /dev/random, so the rc script that starts named tries to mount a devfs for named. The problem is that jails cannot mount, for obvious reasons.

The quick solution is to tell FreeBSD not to try to run named within a chroot. The idea is that a jail is good enough. You can do this by seting:

named_chrootdir=""

within the JAIL’S /etc/rc.conf.

The other option is to create the chroot dir for named from the host system for the jail before you start it. This really doesn’t have too much of a benefit. But it’s possible by issuing the following commands from the host system for your jail:

# mount -t devfs devfs /jails/jailhost.whatever.com/var/named/dev/
# devfs -m /jails/jailhost.whatever.com/var/named/dev/ rule -s 1 applyset
# devfs -m /jails/jailhost.whatever.com/var/named/dev/ rule apply path null unhide
# devfs -m /jails/jailhost.whatever.com/var/named/dev/ rule apply path random unhide

Once you’ve done that, you can start named in the jail, and you’ll have named running inside a chroot within a jail. This doesn’t quell the error messages, but you can trust that they’re irrelevant, or if you feel like it, you can patch /etc/rc.d/named within the jail to not try to create/destroy chroots. Find these lines of code:

# Mount a devfs in the chroot directory if needed
#
umount ${named_chrootdir}/dev 2>/dev/null
devfs_domount ${named_chrootdir}/dev devfsrules_hide_all
devfs -m ${named_chrootdir}/dev rule apply path null unhide
devfs -m ${named_chrootdir}/dev rule apply path random unhide

and make them look like this:

# Mount a devfs in the chroot directory if needed
#
#umount ${named_chrootdir}/dev 2>/dev/null
#devfs_domount ${named_chrootdir}/dev devfsrules_hide_all
#devfs -m ${named_chrootdir}/dev rule apply path null unhide
#devfs -m ${named_chrootdir}/dev rule apply path random unhide

Now you have to maintain this stupidity, if your mergemaster changes /etc/rc.d/named, but I guess it’s nice not to see errors. You also can’t start your jails automatically at boot, because the chroot won’t exist yet… So…. whatever.

The same benchmark as previously done was redone with the ULE Scheduler. The results were quite odd, as the times were actually slightly higher than recorded without the ULE Scheduler.

This leads me to believe that I probably screwed up somewhere, but I just don’t want to spend more time doing something this … boring.