A couple of weeks ago, FreeBSD 5.3 was released, marking the first such release of 5.x marked as “stable”. So I got a copy of the installation and started on my own. I’m looking to replace the distinctly aged 4.4 server here, and also the base install at fdisk.org is a creaky 4.5. First stop: find a spare box and a reasonable sized disk. The box turned out to be a 900 MHz AMD CPU on a PCChips M810LR motherboard, and the disk a 20GB Western Digital.
The installation CD came up to the point where the FreeBSD “Chucky” daemon in ASCII art graced the right side of the screen, and a boot options menu showed up on the left. (There has been a request from the touchy to make “Chucky”‘s appearance optional.) I simply left it to do its default thing, which was to… Panic: pmap_mapdev: Cannot allocate kernel virtual memory.
This led to my first round of hair-pulling, which anyone who has seen me lately knows I should avoid. The up-shot was that in order for FreeBSD to boot relibably on this machine, the ACPI loading had to be turned off:
It took a lot of Googling and paying attention to a Spanish-language post to find that tidbit of information.
From there, the install went the usual way FreeBSD installs go, pretty smoothly. The trick, I’ve found, is that once your base set of stuff has been written to disk, immediately move to reboot the machine. Do not adjust options, do not fiddle with X, go directly to exiting the install and rebooting. You see, until that magical first reboot happens, nothing you’ve done seems to been written in stone, or in magnetic domains on the drive, whatever. Bomb out of X with a misplaced parameter, and you have the whole install to do over. Once that first reboot happens, you can fiddle with things to your heart’s content (well, modulo any of the usual ways to make a Unix box unbootable).
I install ports. In fact, I’ve come to regard the ports distribution as my primary source of software for FreeBSD. And the first thing to do with ports is to install cvsup. Go to /usr/ports/net/cvsup-without-gui, then “make” and “make install”. And then I update the ports tree with cvsup, bringing things up to date there. So after that I got to browse through ports and install the various things I want.
Once I’ve got my 20GB disk the way I want it, my plan is to clone it to larger-capacity disks for various sites. FreeBSD, at least in the past, has been quite tolerant of changing between systems. (Except X windows, which needs to know exactly what hardware is under the hood. Fortunately, most of the time nobody needs to use X on these machines.) 20GB drive out, new 120GB drive in. Step 1 in cloning: put a minimal install on the new drive, establishing the partition, marking as bootable, etc. FreeBSD complains that the drive geometry it got handed was nonsensical and that it would be using its own. The rest of the install went fine, then reboot and … Read Error. Reboot again, and this time the system acted like the drive didn’t even exist. I’ll reduce hours of repetitive rounds of installing and fiddling with geometry to a brief synopsis. No, the MB BIOS and FreeBSD could not come to an agreement on what the drive geometry should look like. However, by going into the BIOS immediately after an install, I was able to mark it as a “User” drive, turn off LBA addressing, and change the PIO mode to AUTO. This combination appeared to do the trick. I was able to reboot successively and successfully several times.
With Samba loaded, I’m aiming to use this as a central file server for our various machines here.<= get_option(\'vc_tag\') ?>> = get_option(\'vc_text_before\') ?> 4601 = get_option(\'vc_human_count_text_many\') ?> = get_option(\'vc_preposition\') ?> 1597 = get_option(\'vc_human_viewers_text_many\') ?> = get_option(\'vc_tag\') ?>>