Installing the Operating System and Battling “new-host”

With the home server‘s BIOS up to date, it was time to install the operating system. Samba, which would be the server’s cornerstone, is available for most any variant of Linux, so I had a lot of leeway in picking a distribution.

My experiences with Ubuntu had been very good, so I could’ve gone with that. But, I wanted to get more exposure to other branches of the Linux family tree, so I chose version 6.2 of Scientific Linux, a Red Hat derivative.

The Scientific Linux installation generally came off smoothly. The one thing that behaved oddly afterwards was the system’s hostname.

Hostname Weirdness

Even though I had specified a meaningful hostname in the Scientific Linux installer, the system initially identified itself as “new-host”. Even odder, the name would sometimes change upon reboot: “new-host” became “new-host-2”, and then “new-host-3”; and after booting the system from an Ubuntu Live CD (but rebooting under Scientific Linux), it even called itself “ubuntu”!

Some poking around and Googling confirmed what was happening. The hostname I had entered into the installer hadn’t stuck. In its place, the system was accepting a hostname from my Verizon FiOS router (an Actiontec MI424WR)–the origin of the “new-host” names.

The Fix

Entering hostname

The fix was to use the system-config-network utility. On its DNS configuration screen, I entered my desired name into the Hostname field. To ensure the other parameters available on that screen were pulled down from my router, I blanked them out.

Upon rebooting, the login screen appeared with the correct hostname!

Update, 4 May 2012: While this fix got the home server identifying itself by the correct hostname, an additional fix was necessary to get our broadband router (and DNS server) to do the same. See “Battling ‘new-host,’ Round Two” for the details.

Some Notes on Configuring Linux Networking

  • Red Hat’s documentation asserts that, as of version 6.2, system-config-network is no longer needed, with its functionality subsumed by NetworkManager and its Network Connections GUI utility (nm-connection-editor). That assertion appears to be incorrect, though, as that GUI provides no ability to set the hostname. (Watch this space, though.)
  • Based on what find tells me (sudo find /etc -mmin -1 -print), files are updated as follows when I alter values on system-config-network‘s DNS configuration screen and save changes (default networking profile located in /etc/sysconfig/networking/profiles/default):
    This file in default profile updated… Updates pushed to…
    hosts /etc/hosts
    network /etc/sysconfig/network
    resolv.conf /etc/resolv.conf
  • system-config-network updates to the hosts files are purely additive; system-config-network will not remove old hostnames! So, if you name a system host1, but later change its name to host2, the relevant hosts lines will look something like:     localhost.localdomain   localhost   host1  host2

    I don’t imagine this detritus would generally be harmful. Mostly, it just allows the host to ping/connect to itself via old hostnames–a capability of dubious value. I guess it could be problematic if an old hostname were assigned to a different machine and the hosts file were charged with name resolution for that machine, too. The file would then associate two different IP addresses with a single name, with unpredictable results.

BIOS Updates, the Linux Way

Once the home server was assembled, I checked its BIOS against the latest version available on Intel’s Web site. The installed version was several revisions out of date, so I decided to update it before proceeding with other setup tasks.

Intel offers ISO images you can burn to CD and run to update the BIOS of a system not yet possessing an OS installation. I had read elsewhere, though, about setting up a USB drive/thumb drive from Linux that boots to old-school DOS, with the BIOS update then run from there. Intrigued, I elected to use that approach, relying on an existing Ubuntu machine we have to do the setup work.

The Approach

To be clear, I cannot claim credit for coming up with this approach. I read about it in several places on the Web, particularly this post from blogger Daniel. Daniel, in turn, indicates that the information was “[l]ifted entirely”(!) from this post by Michael. What I lay out here is simply a variation on what Daniel and Michael present, with a little more detail for those who may be less familiar with the tools and techniques in the mix.

As is always the case with this stuff, no warranty is expressed or implied. You use the information supplied here at your own risk!

Collecting the Right Files

You’ll need three things to use this approach to update your BIOS:

  • QEMU emulator. May already be installed on your PC. If not, you can probably download it with your package manager.
  • DOS image. Daniel and Michael went with Balder, and it worked fine for me, too.
  • BIOS update files. For the home server’s Johnstown motherboard, Intel makes the files available here > Download Type: BIOS > Result with Status: Latest > Download for Iflash BIOS Update.

Setting Up the USB Drive

The instructions that follow assume that, when you plug in your USB drive, your Linux system assigns a device name of /dev/sdc to it (as indicated by sudo fdisk -l) and auto-mounts it. It’s actually quite likely that a different device name gets assigned; in that case, references below to /dev/sdc should be updated accordingly.

Creating FAT16 partition

  1. Plug the USB drive into your PC. After it auto-mounts, unmount it with umount.
  2. Start the cfdisk partition editor against the drive:
    sudo cfdisk /dev/sdc
  3. In the cfdisk UI, create a primary bootable partition using FAT16 (filesystem type 06).
  4. Start QEMU, associating the Balder image with A: and booting it while assigning C: to the USB drive (more specifically, to the partition on the drive created in the previous step):
    sudo qemu -fda balder10.img -boot a -hda /dev/sdc
  5. In QEMU, format the USB drive and make it bootable:
    FORMAT /S C:
  6. Close QEMU.
  7. Remount the USB drive by unplugging it and plugging it back in.
    You could also do this at the command line.
  8. Copy over the BIOS update files.
  9. Unmount the USB drive with umount.

With that, your USB drive should be ready! To check it out within your Linux session, boot it in QEMU:

sudo qemu -hda /dev/sdc

Booted USB drive in QEMU

Doing the Update

Boot your PC from your USB drive. Follow your manufacturer’s guidance on using the BIOS update files. (If it’s an Intel update, you’ll likely run IFLASH2 with parameters found in an Intel README file.)