Trouble Shooting

Why can't I boot the Network Security Toolkit?

There are several conditions which might prevent your test system from booting the Network Security Toolkit.

Using the 64 bit Version 32 bit Hardware

The Network Security Toolkit is available for both a 32 bit (i686) and 64 bit (x86_64) hardware. The 32 bit version can be used on 64 bit capable hardware. However, the 64 bit version can not be used on 32 bit hardware.

BIOS Set To Boot Hard Drive

If you are using a system which typically boots from the hard drive, it is possible that the BIOS has been configured to boot directly from the hard disk. This minimizes the boot time as the BIOS doesn't need to waste time checking for a floppy or DVD each time the system starts. However, this also means that it won't boot from the Network Security Toolkit DVD.

To get around this issue, you will need to reboot the machine and quickly press the keys necessary to enter your BIOS setup. From your BIOS setup, you should be able to set the BIOS boot order.

Some systems have a BIOS which lets you select the boot device each time the system boots. If your system has this option (again you'll need to read your boot screen quickly), you can use this feature instead of reconfiguring the BIOS.

For Apple hardware, you can typically press and hold the Option key and then turn on the system to get to the list of boot choices.

BIOS Halts On Errors

A typical BIOS will stop the boot process if vital system components are missing (think keyboard here). This can become a problem if you are converting an existing computer to a bare minimal Network Security Toolkit system by removing the video card, keyboard, mouse, etc. While removing hardware is fine as far as the Network Security Toolkit is concerned, the BIOS will complain that its missing some vital component (like the keyboard) and fail to boot the NST.

To remedy this problem, you typically need to temporarily connect a keyboard and monitor to the system, enter into the BIOS configuration and configure the BIOS specific options to prevent the BIOS from halting the boot process when it detects errors. If you're smarter than me, you'll remember to do this BEFORE you strip the components from the system you are converting into a headless NST.

Finicky DVD Drive

We have seen cases where a DVD burned in one system will boot on the system which burned the DVD, but fails to boot in another system. This is a frustrating issue and tends to happen more frequently with rewritable media.

If you run into this issue:

• Double check the MD5 check sum value on your ISO image file.
• Make sure that the media type used is readable on the target system. For example, if your system won't read DVD+R media, make sure you use DVD-R media.
• Try burning your DVD on a different system or at a slower speed.
• If you were using rewritable media, try DVD-R or DVD+R media instead.

Managed NIC

I have a 3COM 3C905C-TX-M™ managed Ethernet card. This Ethernet card has its own BIOS and attempts to boot from the local area network before falling back to booting from the local hard disk. When this feature was enabled, the system would fail to boot from the Network Security Toolkit DVD. The BIOS configuration utility built into the Ethernet card did not appear to have a means to disable this feature. I used the hardware approach to fix this issue and replaced the card.

Kernel/CPU Mismatch

We currently build the Network Security Toolkit for the i686 and x86_64 platforms. If you have a old generation CPU (like a original Pentium), it is unlikely that it supports the i686 architecture. You will not be able to boot the NST on these systems.

Insufficient RAM

A live boot of the NST likes lots of memory. If your system runs low or out of memory, the NST will die. You may be able to boot the live NST on systems with less than 256MB of RAM, but you'd better boot to a Console mode, and don't expect to do a lot before needing to reboot the system.

What's Wrong with My Console Keyboard and Fonts?

When you boot the Network Security Toolkit, it assumes that you will be using a "us" style keyboard and uses the default font from your computer's BIOS (I'm guessing a bit on the font statement).

If you don't have a "us" keyboard, you will find this quite aggravating as some keys that you press will not yield the desired results. For example, the @ and " characters appear to be swapped on a "uk" keyboard.

To fix the keyboard problem, you will want to run the loadkeys utility.

[root@probe root]# loadkeys uk
Loading //lib/kbd/keymaps/i386/qwerty/uk.map.gz
[root@probe root]# 

Knowing that the loadkeys and setfont utilities are available on the system is useful. However, knowing what choices are available can be a bit tricky. The following command can be used to list the available keyboard maps:

[root@probe root]# (cd /lib*/kbd/keymaps; find . -name "*.map.gz") | less
./amiga/amiga-de.map.gz
./amiga/amiga-us.map.gz
./mac/all/mac-fr_CH-latin1.map.gz
./mac/all/mac-de-latin1.map.gz
./mac/all/mac-es.map.gz
./mac/all/mac-it.map.gz
./mac/all/mac-de-latin1-nodeadkeys.map.gz
./mac/all/mac-fr.map.gz
./mac/all/mac-template.map.gz
./mac/all/mac-be.map.gz
./mac/all/mac-de_CH.map.gz
./mac/all/mac-pl.map.gz
./mac/all/mac-pt-latin1.map.gz
./mac/all/mac-dk-latin1.map.gz
./mac/all/mac-us.map.gz
./mac/all/mac-uk.map.gz
./mac/all/mac-fi-latin1.map.gz
./mac/all/mac-dvorak.map.gz
./mac/all/mac-se.map.gz
./mac/include/mac-euro2.map.gz
./mac/include/mac-euro.map.gz
./i386/qwerty/cz-cp1250.map.gz
./i386/qwerty/ruwin_alt-CP1251.map.gz
./i386/qwerty/cz-lat2.map.gz
:q
[root@probe root]#

NST 18 Issues

The carl9170-firmware Package And yum update Issue

Shortly after we released the public version of the NST 18 ISO image (nst-18-4509.i686.iso), Fedora released some updates to the linux-firmware package which conflicted with the the carl9170-firmware package provided by the NST. This would result in the following error when using the yum update command:

[root@probe-p2p1 ~]# yum update

... Lot's of output as yum determines what packages need to be updated/installed ...

Transaction Check Error:
  file /lib/firmware/carl9170-1.fw from install of linux-firmware-20130418-0.1.gitb584174.fc18.noarch conflicts with
    file from package carl9170-firmware-1-1.nst18.noarch

Error Summary
-------------

[root@probe-p2p1 ~]# 

To work around this issue, you have the following choices:

• Remove the carl9170-firmware package and it's dependencies.

yum remove carl9170-firmware

• Subscribe to the NST Pro service to get access to the updated NST yum repositories.
• Check out and build the NST software and set up your own local yum repository (see HowTo Build NST 18 for some tips).

After taking one of the above actions, yum update should work as expected.