Undefined reference to `log' when compiling on Ubuntu 13.10 with gcc

After I upgraded to Ubuntu 13.10, I inexplicably started getting errors in a build that had been perfect for a very long time. It turned out, there was a significant change in the linker and a bug introduced. The fix is described beautifully on this blog post, but for convenience sake:

Add '-Wl,--no-as-needed' to your LDFLAGS

Slow login times in Ubuntu 13.10 (not just SSH)

I recently setup a new install of Ubuntu 13.10 for a server and found that a lot of my login times were slow when remotely logging in (and not just via SSH). The culprit turned out to the the /etc/nsswitch.conf file:

This line:
hosts: files mdns4_minimal [NOTFOUND=return] dns mdns 4 mdns

Should be changed to this line:
hosts: files dns

... to resolve the issue

Developing a cape for the BeagleBone (Black)

Due to the needs of our company, we're developing an in-house cape for the BeagleBone Black to integrate it with our equipment. Yes, there are numerous capes already in existence, but they each provide a singular function that would require stacking in combination with other capes to meet our needs. Additionally, it increases the number of external vendors on which we must rely to meet our demands. Instead, we've chosen to create a custom cape that has multiple extensions on the same cape and integrates nicely with our existing board stacks. Unfortunately, I'm not that familiar with BeagleBone Black capes, so I'm going to be learning how to create the software necessary for a new cape and configure it using the Device Tree system on the BeagleBone Blacks. I'll be tracking my progress and things that I've learned on this blog for my own future reference and hopefully it'll even help out somebody else.

Recovering the root password on a BeagleBone Black

I recently went to use a BeagleBone Black board on which I'd never booted from the eMMC before (that I could recall) and had been instead booting off of a microSD card. To the best of my knowledge, the root password on this board should never, ever have been changed from the default (blank password), but apparently it was. None of the passwords that I had ever used for any of my BeagleBone Blacks was working, which created a problem: I needed to recover the root password to this BeagleBone Black so that I could use it for my projects again. I was in luck. The BeagleBone Black has the tools that I needed to do it. I'm writing this blog post (like many other posts in the blog) so that I can have a reference to come back to if I ever need it in the future.

To recover the root password of a BeagleBone Black, you'll need the following items:

• A 5V, minimum 1 A dedicated power source (you shouldn't really be powering the board off of the micro USB port)
• An SD card (and reader, of course)
• An FTDI USB-to-serial cable for accessing the debug serial port of the BeagleBone Black.

Once you've acquired all of the required items above, perform the following steps:

1. Flash the SD card with an image that you can obtain from BeagleBone.org/GettingStarted.
2. Insert the SD card into the *unpowered* BeagleBone Black.
3. Apply power.
4. The BeagleBone Black should boot from the SD card (assuming that you've flashed the correct image)
5. Connect the FTDI serial cable to the board and your compter, and open your serial client of choice to connect to the board.
6. Hit enter once or twice, and a command prompt should come up, assuming you've used the correct settings:
1. 115200
2. 8N1
7. Log in using root and a blank password (should be the default on the SD card image that you downloaded from the BeagleBoard.org website.)

You're now logged into the image running on the SD card. However, we can't change the root password now because that will only change it for the root user on the SD card image. We need to change it for the permanent image stored on the BeagleBone Black's embedded eMMC flash. Being logged in as you are, perform the following steps to mount the eMMC image and change the password for that image's root user:

1. Mount the eMMC flash:  mount /dev/mmcblk1p2 /media/card
2. Change the root of the file system to be the partition on the eMMC flash which you just mounted: chroot /media/card
3. Change the password of the root user to something you know: passwd root
4. Exit out of the changed root: exit
5. Shutdown the BeagleBone Black : shutdown -h now
6. Disconnect the power from the board
7. Eject the microSD card.
8. Reconnect the power to the board
9. Watch the board boot up, and log in as root. You should be able to log in with the password that you just set.

Implicit rules with Makefile

In my ongoing quest to make my builds less complex and faster, I've been going through my Makefiles and trying to learn as much as possible to simplify it and leverage Make as much as I can. To that end, I discovered something incredibly useful today that I suppose I would have known had I taken the time to read the man page for Make:

make -p

This command will list all of the implicit rules for make, which you can then use to optimize the living crap out of your Makefile.

Installing NTP on an Ubuntu server

NTP is used to synchronized time between machines. You can read the Ubuntu HOWTO here.

Installing a TFTP server using xinetd on Ubuntu

I recently had need to redo an old server that had been running an ancient Gentoo installation for which there was no longer a software upgrade path, so I chose to install Ubuntu on it. Part of the requirements of the server were that it runs a TFTP server for hosting files for configuring embedded devices. I had previously found an article on how to setup TFTP through inetd, but I could find it, so I'm cobbling this tutorial together from various sources.

1. # apt-get install xinetd tftpd
2. Ensure that the following lines are in the /etc/services file:
1. tftp     69/tcp
2. tftp     69/udp
3. Open the /etc/xinetd.d/tftp file (create it if it doesn't exist) and ensure that it contains the following:

   # default: off
   # description: The tftp server serves files using the Trivial File Transfer \
   #    Protocol.  The tftp protocol is often used to boot diskless \
   #    workstations, download configuration files to network-aware printers, \
   #    and to start the installation process for some operating systems.
   service tftp
   {
       socket_type     = dgram
       protocol        = udp
       wait            = yes
       user            = root
       server          = /usr/sbin/in.tftpd
       server_args     = -s /tftpboot
       disable         = no
   }
   

4. # /etc/init.d/xinetd restart

5. Test the server:# tftp localhost

   tftp> get hello.txt
   Received 23 bytes in 0.1 seconds
   tftp> quit 

You should now be good to go. The (abridged) instructions for this were retrieved from this article.

Digging into Raspberry Pi: Part 2

So, further into my quest to build a control system with the Raspberry Pi, I've been looking around at ways to have simple input from the user for a simple system. The first thing that came to my mind was using an Xbox controller to provide input from the user:

• It's simple for the user to use, and given that many people grew up with game consoles, it'll be intuitive and not require retraining the user.
• The Xbox controller plugs into USB and should therefore provide an easy way to integrate a controller for my system.
• The command to download joystick support for the Raspberry Pi was dead simple: 
• sudo apt-get install joystick

The post located here also shows some options for the joystick on the Raspberry Pi. I'll post more information as I learn how to use the library to access the device.

Digging into Raspberry Pi

I've recently purchased several Raspberry Pi boards so that I could use them with the RasPlex distribution to run Plex clients and connect them to my TVs and stream media from a central box in my house. However, I've now realized that with their ability to output to HDMI by default, I can use them as video controllers for projects at work. On my blog I'm going to document my experiences with the Pi, mostly as a list for me to follow if I ever have to recreate my work.

Today, I started off by doing the following :
1. Running NOOBS
2. Installing Raspbian
3. Used 'sudo apt-get install fluxbox' to install the Fluxbox window manager.
4. 'touch ~/.xsession' and 'vi ~/.xsession' and appended 'fluxbox' to the end of the file to start fluxbox when X starts.

Converting a .cer and .pvk to a .pfx file

The Windows SDK comes with a built-in tool for performing this conversion, the details of which you can find here. The command you'll need looks something like the following :

pvk2pfx /pvk MyCert.pvk /pi inputpassword /pfx MyCert.pfx /po outputpassword /spc MyCert.cer

Journey to robust windows services: killing a service that failed during OnStartup and now won't stop (even though Stop() has been called)

I've found that sometimes I don't exactly get my service configuration right the first time, and this can cause a failure when calling OnStartup. As a result, when I call Stop() during the exception handling in OnStartup(), the service gets stuck in the 'Stopping' state in the services manager. Here's a quick command line to help you out with that :

TaskKill /F /FI "Services eq [service name as diplayed in the service's properties]"

This will get your process knocked off so that you can resume debugging and building.

System.ArgumentException: Unable to find the requested .Net Framework Data Provider when using SQLite with MSTest unit tests in Visual Studio 2012

I recently encountered the exception in the post title while migrating solutions from Visual Studio 2010 to Visual Studio 2012. Going back and forth between versions, the problem only occurred for me in Visual Studio 2012, it otherwise did not appear in 2010. I ran across this post on StackOverflow about another developer in a similar circumstance, but I didn't want to depend on whatever machine I was using having the SQLite Db Provider installed in the GAC, so I chose a different route: I added [DeploymentItem]s for each of SQLite.Interop.dll, System.Data.SQLite.dll and System.Data.SQLite.Linq.dll to the top of each of my test suites that require them.  It's perhaps not an ideal solution, but it does seem to be the most pragmatic one for my circumstances.

Journey to robust web services: Fixing an error 404.3 message in IIS 7.0 / 8.0

I've recently had to go out of town, and only had my personal laptop to take with me. I usually develop in a Windows 7 environment with IIS 7.0 / IIS Express 7.5, but my laptop is Windows 8, so of course I have to go through the process of setting up my development environment all over again. One of the common errors I see when setting up a new environment is error 404.3: Not found. I run into it over and over again and when I fix it, it seems like such a trivial thing and I never remember to write down the fix to reduce my setup time in the future. Today that changes. The problem can be caused by a couple of things:
1) You don't have the application setup in IIS. You need to setup the application in IIS, *and* you need to point it to your web project directory.
2) You don't have all the requisite components installed in IIS. In order to properly install WCF, you must have IIS installed, you must have ASP.NET installed, and you must have WCF registered. Up to Windows 7 / .NET 4.0, this means you must have, at some point, run aspnet_regiis.exe -ir. On Windows 8, this means you must have installed ASP.NET 3.5 / 4.5, and installed HTTP activation for each (as well as corresponding activations for any other protocols such as net.tcp.

Journey to robust Windows Services: Overriding the default web site when deploying your applications from the command line

I recently ran into a problem where I wanted to deploy a new application to the default web site on an old IIS 6 instance via MSDeploy on the command line from my build machine. Unfortunately, it decided to deploy the application in a folder immediately underneath the default web site, rather than as the default website itself. This post on the IIS forums provided the solution.

Journey to robust Windows Services: NHibernate throws with System.InvalidOperationException: Unable to generate a temporary class

Recently I've been trying to deploy a new web application to an old machine running Windows Server 2003 (not by choice). When I would start the application, NHibernate would thrown in its class constructor with a message along the lines of :

System.InvalidOperationException: Unable to generate a temporary class (result=1).
error CS2001: Source file 'C:\WINDOWS\TEMP\wz58eig4.0.cs' could not be found
error CS2008: No inputs specified

The problem was caused by the fact that the user under which I was running the application didn't have access to the 'C:\Window\Temp' folder where the temporary folder was being created. The solution was simple: update the security settings of that folder to allow Read and List for the Users group. The idea was given to me by answers to this question on Stack Overflow.

How to fix the ugly ass Ubuntu boot splash OR Damn, Ubuntu, you ugly

TL;WR: http://news.softpedia.com/news/How-to-Fix-the-Big-and-Ugly-Plymouth-Logo-in-Ubuntu-10-04-140810.shtml

If you've had Ubuntu for a while and you've got an nVidia video card, chances are you've got the ugly ass default boot screen. Fortunately, you can fix this. You just need to follow the instructions above. I hope you're comfortable with the command line.

Changing the password complexity requirements on Windows Server

To change the password complexity requirements on Windows Server (2008 at least) (for whatever reason), do the following :

Start -> Run -> gpedit.msc -> Computer Configuration -> Windows Settings -> Security Settings -> Account Policies -> Password Policy

Then in the right-hand policy pane, set 'Password must meet complexity requirements' to 'Disabled' (right-click -> Properties)

Journey to robust windows services: Service could not be installed. Verify that you have sufficient privileges to install system services

This is an annoying and almost entirely useless error. It can be caused by any number of things. However, in my case today, it was caused by the fact that the EventLog Source hadn't been created when I tried to install my Windows Service using the WiX installer that I had developed (which it turned out wasn't quite complete). Fortunately, WiX (at least as of 3.5) has built-in support for creating Windows Event Log sources as part of the installation process. Fortunately, I was able to rely on this article on stackoverflow.com to guide me through the process. The gist of the article:

1. Add the "http://schemas.microsoft.com/wix/UtilExtension" namespace to your .wxs file root XML element
2. Add a util:EventSource Log="Application" Name="MyServiceLogSourceName" EventMessageFile="%SystemRoot%\Microsoft.NET\Framework\v2.0.50727\EventLogMessages.dll" element to each component which requires an Event Log source
3. Problem solved

Journey to robust windows services: debugging your WiX custom actions

I've recently had some trouble getting WiX custom actions to work, and after searching around for a while, I found this article. It gives the reader two options for how to debug WiX custom actions, but I had to use both in combination to get it to work. I'll repeat the steps here, just in case the link goes stale:

1. Follow all the necessary steps to create a WiX setup project, along with a separate Custom Action project (available as a project type in the New Project dialog in Visual Studio 2010+ with WiX 3.7)
2. After you've created your custom action method and gotten the project building, add System.Diagnostics.Debugger.Launch(); at the beginning of your custom action method. This will kick the custom action into the debugger so that you can debug it (assuming you've got the wixpdb in the same directory from which you launched the installer).
3. Go to Control Panel -> System -> Advanced System Settings -> Advanced (tab) -> Environment Settings (button) -> System Variables (group) -> New .... (button) 
4. In the dialog that comes up, create a new variable called 'MMsiBreak' (without the quotes) and give it the value of your custom action method (e.g. MyCustomActionMethod)
5. Now run the debug version of your installer and it should get kicked right into your method and allow you to debug your custom action.

Journey to robust windows services: creating custom actions for your WiX installers

I've lately been trying to update my WiX installers to perform custom actions so that I can do some security configuration of my applications after they're installed. I got started with this article on CodeProject, but it was missing some information. Apparently, in addition to creating the separate project for the CustomAction DLL, you need to include as part of that assembly a CustomAction.config file with the following contents:

xml version="1.0" encoding="utf-8" ?>
<configuration>
    <startup useLegacyV2RuntimeActivationPolicy="true">
        <supportedRuntime version="v2.0" />
        <supportedRuntime version="v3.5" />
        <supportedRuntime version="v4.0" />
    </startup>
</configuration>

But what really got the thing working was targeting the CustomAction DLL to .NET framework v3.5, rather than 4.0 because I was getting some bad image format exceptions when trying to run it. Thankfully I found the MSDN article on enabling MSI logging. These two articles on stackoverflow.com also really helped out.