Setting up penguin with CentOS 7

Contents

After sinking a ridiculous amount of time into creating and testing a process for building my home file server (I ended up with a 13,000 word document that, if printed, would run to nearly fifty pages,) on Wednesday, October 10 I declared it was “good enough” and decided to actually do the install on the computer running the server.

Despite the great amount of testing I did, installation did not go quite as planned on the actual server.

Unable to boot from USB HDD

First up, a nasty BIOS bug prevented me from booting from the backup HDD containing the CentOS full install and my kickstart file. I was able to boot the network install from the USB device, but there were two complications with that:

1. The keyboard was disabled during the boot phase, meaning I couldn’t select the OS on the flash drive I wanted to use–I was stuck with the default.
2. The network install insists on having a network path to the ISO! No local paths for you, citizen! You said you wanted a network install, and you will do a network install!

At this point I set up my raven system as penguin, sans most of the data restores, save for the CentOS 7.5 ISO so that I could NFS mount it if needed. I also was prepared to fall back to the HP Pavillion in case my penguin computer became unavailable. How could that happen? Well, I found a BIOS update for the Asus F1A75-M LE mainboard in penguin and decided to apply it in hopes it would clear up the issues with starting from USB drives. But there’s a chance the update could fail catastrophically, taking the mainboard and the rest of the system with it.

Fortunately the BIOS update succeeded, and it resolved the booting issues.

Disappearing installation drive

Now that I could reliably start the old penguin server from USB, I set about installing CentOS 7 on it. As part of the new system I intended to swap the boot and backup drives: what once was the boot drive would become the backup, and what once was the backup drive would become the boot drive. I had a reason for this: the backup drive has had considerably less thoughput on it thanks to the fact to date it has spent the majority of its life asleep.

That didn’t go smoothly either–the installer refused to see the backup drive as an installable device. It showed up in fdisk with no problems, but as far as the installer was concerned it didn’t exist. After reading the RHEL 7 installation guide, I found I could set a boot parameter called inst.debug that would write extensive logging information to files in /tmp. One of them was storage.log, and in there I saw that the installer had determined the drive I had intended to install to was once part of a Promise RAID set.

It took a quick web search to clear that up. This entry at SysTutorials gave me the instructions I needed to clear the signature. It’s located in the final half megabyte of the drive, and the following command cleared it:

dd if=/dev/zero of=$DEVICE bs=512 seek=$(($(blockdev --getsz $DEVICE)-1024)) count=1024

That done, the installer found the drive with no problems.

Disappearing network device

When I set up the server it had only 2 GB RAM on it. The on-board video grabbed 343 MB of it, leaving me with only 1.5 GB to work with. Runnng a PCI or PCIe video card would give me nearly 25% more RAM, so I put one in. At first I used a very old ATI PCI card. It was top of the line twenty years ago, but doesn’t cut it for today’s systems. So I replaced it with a PCIe card I had in Raven. It worked beautfully–but the network went offline!

The problem there was RHEL systems use an unconventional naming scheme for their ethernet ports. Older versions would enumerate the available ports and name the first one found eth0, the next one eth1, and so on. While convenient, this meant adding a second network card could move eth0 to eth1. So Red Hat introduced consistent network device naming on en for ethernet, p# for PCI bus, and s# for slot number.

Without the video card in the system, the ethernet device had the name enp3s0. But after I added the card its name changed to enp4s0–and in the process defeating the whole idea behind consistent device naming! I would have expected an empty slot on the mainboard to be enumerated by the BIOS (and this presented to the operating system) as opposed to it popping into existence when a card was put into it.

While annoying, the fix was simple: I modified the ifcfg file names and their contents in /etc/sysconfig/network-scripts to match the new name.