So, just installed a GT730 or other HDMI-enabled nVidia video card and now your Dell T7400 has lost audio? Messages like “no output device” or “audio not responding”? Well, after 2 hours of useless searching, finally found that the T7400 BIOS allows 3 settings for the onboard audio: OFF, AUTO, and ON. Turns out that if you set the onboard audio to AUTO, it will disable the onboard audio system if another audio system (such as an HDMI video card) is installed. If you wish to keep the built-in audio working, set the onboard audio to ON and then reboot. Windows 8.1 found it this way, others should as well. Once you reboot, you’ll need to open your Playback and Recording from the System Tray and make sure you direct output to the correct device (not nVidia HD audio).

So, I bought a Pi Zero right after they came out and have left it languishing on the shelf since as I haven’t had sufficient time to mess with it. However, I recently decided to take a look at some home automation using various IoT concepts and thought this might make a nice little gateway. I ran into several issues getting the device to work, however, for several reasons.

First, I didn’t have a USB hub available to run multiple devices at the same time. With only 1 OTG (on the go) cable available, I was out of luck in that department. (I’m trying to do some gateway / server testing without purchasing new equipment at this point. Second, I don’t have an HDMI TV available, nor do I have any type of adapter to convert to an old-style RCA jack video connection. What I needed was to create the SD card with the image on it, modify the image to support everything, and then remote into it via SSH to run the raspi-config program to configure the rest.

To get the project off the ground, I downloaded the latest image of Raspbian Jessie and installed it on my 64 GB micro-SD card. Note that I’m running Xubuntu 16.04 LTS and the SD card shows up as /dev/mmcblk0. Since DD gives no feedback, I decided to use DCFLDD in its place (which required running sudo apt-get install dcfldd to install the package). The command I used to write the image to the micro-SD card was:

sudo dcfldd bs=1M if=~/Desktop/rasp-jess.img of=/dev/mmcblk0

After this was completed, the number of blocks written was displayed, but it took about 2 minutes to finish emptying the cache and return to the prompt. Be patient, don’t eject the card thinking that it has locked up. Also, make sure before you eject the card it hasn’t been mounted to any locations.

Once the image is written and you’ve ejected the card, re-insert and mount the second partition (probably /dev/mccblk0p2) if it doesn’t automatically mount after 30 seconds or so. From here, you’ll need to edit 4 files to get the image to a useful (headless) state. Not all of these require editing with root rights, but I used sudo for them anyway to avoid error messages.

First, figure out where your card was mounted. Mine was in /media/brian/7f…/, with the 7f being a long 32 character (maybe, I didn’t actually count the characters) string of text. This is where the command line TAB key expansion capability comes in handy.

Use nano or other favorite text editor (remember, sudo may be required) to edit /path_to_partition2/etc/network/interfaces. I wanted to add a static IP address, so my file edited the following section:

auto wlan0 <<=== added this line
allow-hotplug wlan0
iface wlan0 inet static <<=== changed keyword manual to static
address 192.168.3.40 <<=== added the remaining static IP info and wpa
netamsk 255.255.255.0
gateway 192.168.3.1
wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf

At this point, you can save the file. Note that one gotcha may ultimately be that your wireless device doesn’t try to enable as wlan0. In this section and others, you might need to boot the Raspberry Pi Zero, wait for it to boot (90 seconds max usually), plug in the wireless device (mine was a generic type WN-250gi), allow it to boot for 10 to 20 seconds, then shut the Raspberry down and read the syslog file from the SD card. This file will be located in the /path_to_partition2/var/log/syslog location once the card is mounted. Make sure you don’t accidentally read the syslog for your system… Makes you feel kinda dumb for troubleshooting something for 20 minutes only to realize… This file will give you an idea of which interface name is in use but you’ll need to read through it.

Once again, use your favorite sudo’d editor to add the following information to /path_to_partition2/etc/wpa_supplicant/wpa_supplicant.conf. Especially notice that if your SSID is not broadcast you will need to include the scan_ssid=1 line, otherwise omit it.

country=US
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1

network={
ssid=”rpihost”
scan_ssid=1
psk=”12345678912345678912345678″
key_mgmt=WPA-PSK
}

The country was changed on line 1, then the network entry was added; the other lines were left as found. The SSID is the name of your wifi, scan_ssid=1 is required if SSID is not broadcast, psk is your key (mine is using a 26 character key), and key_mgmt can be something besides WPA-PSK if you have different wireless capabilities. However, you’ll need to look up the changes necessary to make the correct wpa_supplicant.conf entries for WEP or other types of security. Also, this is another place where the syslog file can be your friend. If you’re not getting a connection, you might be missing a firmware file for your wifi adapter. This is usually stated in plain text and will usually give the name of the file needed. Use the Internet to find the correct file, rename it if needed, and use sudo to copy it into /path_to_partition2/lib/firmware.

Now, sudo edit the file /path_to_partition2/etc/resolv.conf to include the name servers that you need. If you have a DNS server on your network (or more than one) you’ll need to include that address; I have both a DNS server and my router to act as DNS servers, so my entries appear as follows:

nameserver 192.168.3.22
nameserver 192.168.3.1

If there are any other lines and you don’t see a need for them, you can comment them out with a # symbol. As you’re manually editing this card until all errors have been resolved, you can always uncomment if needed.

After those changes, the Pi booted up great and responded to pings in 3 to 6 ms, but absolutely refused to allow an SSH connection to configure the damn thing. Every attempt resulted in a “connection refused” message on port 22. I wasn’t able to find a description of how sshd (the ssh daemon) gets enabled on the Pi other than I needed to run raspi-config on the Pi. The whole point of this exercise is that I can’t connect to the bloody thing to enable ssh. Finally, I sudo edited the file /path_to_partition2/etc/rc.local to include the following 2 lines PRIOR TO exit 0. These lines will cause the sshd server to load and run but it is a temporary solution only and should be removed as soon as you can run raspi-config to enable ssh through the Advanced Options.

insserv ssh <=== this line might not be necessary but I put it in anyway
service ssh start

At this point, go ahead and unmount everything cleanly and boot the Pi with the wifi adapter installed. Give it sufficient time then start pinging. If pings are successful, then attempt an ssh connection using:

ssh pi@192.168.3.40 (or whatever your address is)

The password for the user pi is raspberry. You can then change the password once you’re logged in and able to run raspi-config.

If the wifi adapter doesn’t appear to come out (lights are blinking properly) or address doesn’t appear to be properly assigned, load the syslog file from the Pi and examine it carefully. It is really your best source of troubleshooting assistance.