Using Linux to Identify Motherboard Model

Posted on by
2

The most obvious way to identify the make and model of a computer motherboard is to take the cover off the machine and have a look. However, sometimes this isn’t practical or desirable

Ideally, if you’re going to remove a cover from a computer you want to shut it down first. You could do it with the system still running but you’ve only got to drop a case screw into a turning fan to give yourself an expensive day

You may also be unable to directly access the computer which you wish to identify the motherboard within. It could be in another building on a distant site or installed in a server rack which could be time consuming to remove it from.

Linux and dmidecode finds your motherboard info

If your computer is running linux (and in this article we assume that’s exactly what it is running!) you can quickly and easily find the motherboard model using dmidecode.

dmidecode is a tool which interrogates the computer’s System Management BIOS from the command line.

It can read various hardware information with greater or lesser reliability. How solid the information is depends upon how much care and effort the hardware manufacture put into their product.

dmidecode your motherboard from the command line

dmidecode can read various records from SMBIOS but the one in which we are interested in is the motherboard.

To issue the command, you need root (or sudo) privileges either in a terminal on the local machine or via an SSH session remotely.

The required dmidecode command on linux to read motherboard information is:

dmidecode -t 2

If you prefer to be more verbose, the following command will have the same effect:

dmidecode -t baseboard

Where the -t 2 switch instructs dmidecode to read the 2nd table which is “Baseboards” or motherboard as we require.

This should print the motherboard information in a format similar to:

Base Board Information
        Manufacturer: ACME Motherboards
        Product Name: Motherboard 2000
        Version: 2.0
        Serial Number: 12345

dmidecode can also interrogate the SMBIOS tables for a lot of other information about installed hardware.

You can see all of the available tables which dmidecode can read along with the output options by issuing the command:

man dmidecode

Have fun talking to your system and if you use dmidecode for anything particularly clever, or find any unusual output from your system, let us know in the comments below!

Flashing Tasmota on a Sonoff Basic Without Soldering

Posted on by
Reply

If you’ve arrived here, the chances are you know what a Sonoff Basic network connected switch is. You may also have an idea what Tasmota firmware is and have an urge to flash your Sonoff Basic.

⚠️Warning: Sonoff network switches are mains-power devices. You mess with them entirely at your own risk! ELECTRICITY CAN KILL!⚠️

 

The layout of the Sonoff basic switch is super-simple. An ESP32 microcontroller with WiFi controls a relay which can switch the live wire on a 240v 10-amp load. A neutral pass-through is provided but no ground wire.

The Sonoff Basic is designed to be fitted in-line on a power cable to an appliance (a table lamp in my case).

Flashing the Sonoff without any soldering

First of all, if you’re going to flash your Sonoff Basic over serial/GPIO, make absolutely sure the Sonoff is disconnected from mains power (preferrably, completely unwired).

Also bear in mind that my method is a bit Heath-Robinson to avoid soldering so you could break your Sonoff Basic completely or destroy your GPIO flashing device too.

For my flashing method, I used an original model Raspberry Pi Model B as the GPIO host. It just so happened that I had one readily available that I wouldn’t be too upset about if it got fried. I had some 1×40 header pins and DuPont jumper cables from another project.

In order to access the GPIO header, I needed to get the lid off the Sonoff Basic. It’s obviously a push-fit lid but prying it off can be tricky. It’s held by four lugs at the long edges. The best bet seems to be running a finger-nail along the gap to gently force it open.

Sonoff Basic Lid Removed Lugs

Two of the four lugs that hold the Sonoff Basic’s lid on.

The GPIO connections are in the middle of the PCB next to the microswitch and are unpopulated. Some firmware flashers have soldered directly onto these contacts or soldered header pins in place. I, however, wanted to see if I could get away without any soldering.

Counting away from the microswitch, the GPIO pins are 3.3v, RX, TX and GND. The fifth hole is GPIO 14 and unused.

I broke off a strip of five of my header pins, utilising the fifth hole purely for stability. I pre-connected the four DuPont jumper wires and placed the header pin block into the GPIO holes.

Then, to ensure at least a reasonable contact with the conductors, I used a wood dowel, gently pushed between the plastic DuPont connectors and the capacitor behind them to force the pins tight against the hole edges. (be warned, this is probably quite a good way of damaging your board!)

If you intend to use something other than a wooden dowel, ensure whatever you use in non-conductive!

At the Raspberry Pi Model B side, I connected just the RX and TX and GND cables, leaving the 3.3v off while I installed the required software (esptool etc) as described on the Tasmota wiki.

Getting the right Tasmota firmware

I also needed to download an appropriate Tasmota firmware image. Quite a few people were having trouble with the 6.x versions on the Sonoff Basic so I started out with the 5.14.0 firmware. The file itself being sonoff-classic.bin.

Note: On the Raspberry Pi Model B, I substituted /dev/ttyAMA0 where it stated /dev/ttyS0 in the Tasmota wiki article due to the older naming conventions on that version of the Raspberry Pi.

Getting the Sonoff Basic into flashing mode requires holding down the microswitch while connecting the 3.3v cable to the Raspberry Pi. This can be tricky as the button atop the microswitch is flexible and can un-make the switch without you noticing.

The next step was to erase the flash memory (remove the factory firmware) by having my Raspberry Pi issue:

esptool.py --port /dev/ttyAMA0 erase_flash

This should take just a few seconds and the result (hopefully successful) will be echoed to the console.

I then removed the 3.3v cable to power down the Sonoff.

Then, once again holding down the microswitch, I reconnected the 3.3v cable to power it up.

I had the Raspberry Pi issue:

esptool.py --port /dev/ttyAMA0 write_flash -fm dout 0x0 /path/to/downloaded/sonoff-classic.bin

This takes a little longer as the firmware image is written to the flash memory on the Sonoff.

Once again, I removed the 3.3v power to the GPIO.

Flashing a Sonoff Basic With a Raspberry Pi Model B

The Sonoff / Raspberry Pi Model B solderless flashing setup

Next, I set up a listening serial terminal on the Raspberry Pi Model B using:

miniterm.py /dev/ttyAMA0 115200 -e

Reconnecting the power to 3.3v pin, this time without pushing the microswitch, causes the Sonoff to boot the Tasmota firmware and echo the output to the Raspberry Pi. Hopefully it all starts well!

Of interesting note, whenever I connected the 3.3v to the Raspberry Pi B, the LEDs on the Pi dimmed for a few moments and the SSH connection to the Pi paused but then recovered. It might be a symptom of my less-than-perfect connection to the Sonoff GPIO pins. Don’t forget, this method is imperfect and could wreck both your Sonoff and your Raspberry Pi!

If you intend to flash many Sonoff Basic units and have access to a 3d printer and some parts, there is a Sonoff Basic programming clip on thingiverse that might help your workflow.

What Next?

To configure my newly installed Tasmota firmware, I used the button-press methods detailed here.

Asus UX305 Screen Brightness Linux Control Fix

Posted on by
Reply

If you have an Asus Zenbook UX305 upon which you’ve installed Linux (in this case Linux Mint 18 Sarah) they you may have found that while practically everything works ‘out of the box’, screen brightness control with the Function keys does not.

In fact, on the UX305, I found that while Linux Mint would dim the display after a predetermined period, direct control over screen brightness was not possible using the system-settings panel or the taskbar widget.

After getting sore eyes from what is a very good backlight, I went off in search of a solution. I found a bug report discussing the problem on some newer Asus laptops in Ubuntu over at launchpad.net. The various methods being tried seemed to involve a bit of hit and a lot of miss depending on the hardware platform. However, I found a solution that worked for me with a UX305.

(The following assumes some competence dealing with your system’s internals and don’t forget to back up anything you cant afford to lose!)

To begin with:

Comment #10 on the discussion suggested the following:

In /etc/default/grub add (as root):

acpi_osi=

In the quotes on the line:

GRUB_CMDLINE_LINUX_DEFAULT “”

Not forgetting to then run

update-grub

After rebooting, I tried Function keys F5 and F6 and found they brought up the brightness level overlay and adjusted it but the actual backlight level stayed the same.

Asus UX305 Screen Brightness on Linux

The brightness overlay now working

Next, Comment #69 provided the solution to getting the backlight to actually respond to the backlight control.

First create a file called

20-backlight.conf

in

/usr/share/X11/xorg.conf.d

And add the following lines to the file:

Section “Device”
Identifier “card0”
Driver “intel”
Option “Backlight” “intel_backlight”
BusID “PCI:0:2:0”
EndSection

I then rebooted and found that the Function keys were happily now controlling not just the backlight overlay but the backlight itself.

šŸ™‚

It’s not impossible that this fix interferes with some other functionality but I’m yet to encounter any problems.

Piwik 2.11.0 curl_exec Operation timed out – Bug Fix

Posted on by
Reply

A server I administer running Piwik 2.11.0 web analytics encountered a problem during an automatic upgrade from Piwik 2.11.0 to Piwik 2.11.1.

The error given after clicking the automatic upgrade link was similar to:

curl_exec: Operation timed out after 9984 milliseconds with 12801064 out of 13344050 bytes received.

Hostname requested was: builds.piwik.org

Close, but no cigar. Curl tries to download the 13 megabyte piwik upgrade archive and nearly succeeds but the default curl timeout stops it just short. On servers with huge bandwidth capacity this is probably never a problem but it’s all about getting the file within the default time limit. With insufficient bandwidth, the timeout is reached before the server can finish downloading.

This issue is fixed by using a longer timeout in the latest version. However, if you’re on version 2.11.0 like I was, it doesn’t fix the immediate problem of running into the curl_exec Operation timeout when you try to automatically upgrade to the latest version.

There is a way around which involves editing one line of one file in your current Piwik install. Remember to back-up both your Piwik installation files and your Piwik database before fiddling with the installed files. Misadventure could lead to a broken installation or worse, loss of your analytics data!

Piwik offers this fix in /piwik/plugins/CoreUpdater/Controller.php: https://github.com/piwik/piwik/commit/76e4378b18b2e24853846c38f7eded956ee0eb57 which indicates that the timeout (in seconds) can be changed from 30 to 120 which appears to be the path before the 2.11.2 release but I was stuck on version 2.11.0 which had line 175 reading:

Http::fetchRemoteFile($url, $this->pathPiwikZip);

I therefore changed this line to read:

Http::fetchRemoteFile($url, $this->pathPiwikZip, 0, 120);

I then saved/re-uploaded the file to the server and re-executed the automatic updater which took me straight to the now current 2.11.2 version.

Job done šŸ™‚

Installing NoIP2 on Ubuntu 14.04LTS

Posted on by
3

IĀ  look after a server which is connected to some temperature sensors on a remote site. The site is connected to the internet via a RADSL link on the end of 1.5km of very old copper cable. The reliability of the connection is weak at best and the dynamically assigned IP address tends to change every time the connection drops which can be several times a day.

I recently updated the server from Ubuntu 13.10 to Ubuntu 14.04 Long Term Support which, as it is supported until 2019, should see out the antiquated hardware’s days

In order to communicate with the server remotely, I need to know the current public IP (dynamically assigned) so I need to run a dynamic DNS client on the server to update a remote service. The service I chose for this purpose is No-IP. They offer a free basic DDNS account which meets my needs.

Client wise, I have previously (some years ago) used ddclient to update the IP address to No-IP but have more recently struggled to get the configuration working reliably.

Instead, I now use the NoIP2 client in the following fashion:

First of all, working locally on the server (because that ADSL connection really is that bad!) I download the NoIP2 client:

wget http://www.noip.com/client/linux/noip-duc-linux.tar.gz

Then I extract the archive and cd to the resulting directory:

tar -xvf noip-duc-linux.tar.gz
cd noip-2.1.9-1

The directory may differ if the noip2 client version number is updated.

Now I install the client using:

sudo make install

Next, the client needs to be configured. You’ll need the username and password you selected when you signed up for your No-IP DDNS user account.

sudo /usr/local/bin/noip2 -C

The -C flag tells the installed client to create a new configuration where you enter:

  • Your username (email address for No-IP account)
  • Your password (the one for the above)
  • The interval (in minutes) that you wish to update your public IP address to No-IP
  • A command to execute when the update is successful (you can leave this blank)

At this point, I have a working client that will update your public IP to No-IP. Note that you may need to open port 8245 (outbound) on your router if you have a restrictive outbounds ports setup.

However, if the power on the remote site goes down (and it often does, especially during storms) the server will reboot but there is nothing to tell it to restart the noip2 client.

To remedy this, I create a new file in init.d using the nano text editor:

sudo nano /etc/init.d/noip

I add the following to the file (referenced in the README):

#! /bin/sh
case "$1" in
    start)
        echo "Starting noip2"
        /usr/local/bin/noip2
    ;;
    stop)
        echo -n "Shutting down noip2"
        for i in `noip2 -S 2>&1 | grep Process | awk '{print $2}' | tr -d ','`
        do
          noip2 -K $i
        done
    ;;
    *)
        echo "Usage: $0 {start|stop}"
        exit 1
esac
exit 0

The Ctrl-x to exit nano and y to save the file.

I need to make the script executable so I issue:

sudo chmod 755 /etc/init.d/noip

To tell the system it needs to run the script after booting, I open up and edit rc.local

sudo nano /etc/rc.local

Find the line that contains exit “0” and on the line above add:

/etc/init.d/noip start

Again, Ctrl-x to exit nano and y to save.

Now when you reboot your server, the noip2 service should be running.

You can check whether it is running by issuing:

ps aux | grep noip2

You should see the noip2 service listed in the result.

After the update interval that you set when you configured the No-IP client, you should be able to reach services on your server from the no-ip dynamic hostname that you are assigned ie: your-noip-name.no-ip.com. If you’re unsure of this name, you can check it by logging into your No-IP account and looking it up. Don’t forget, you may need to open the relevant ports on your router to match the services you’re trying to reach on your server.

This should provide a relatively simple and free alternative to paying for a fixed ip address for your home or remote Ubuntu 14.04LTS servers. Remember that in order to keep your NoIP hostname, you need to update your IP ever thirty days at the latest or the hostname is released for re-use. Just keep the noip2 client going at a regular update interval and this should not be a problem.

Oculus Rift aticfx32.dll Error With Dual Graphics Workaround

Posted on by
Reply

I’ve been using an Oculus Rift DK2 on an AMD laptop with dual graphics and have encountered the following error when using OVR runtime 0.43 or later.

There is a problem with your Rift configuration.
Interfering software is preventing the Rift from activating. Loaded UMD is reported as ‘aticfx32.dll’.

This causes whichever direct-to-rift demo is in use to start but no output to the Rift.

The laptop has “switchable graphics”. Essentially this is a Radeon 8650M for low power tasks and an 8970M/M290X for gaming and high-performance tasks.

If the software used with the Oculus Rift is set to run using the 8650M [power saving] in Catalyst Control Center’s Switchable Graphics Application Settings, the software will work correctly with the Rift albeit at greatly reduced performance. If the software is set to use the 8970M/M290X[high performance], the black screen and “aticfx32.dll” error will be shown.

It seems that the OVR runtime is not recognising the switch from the low power to high performance cards as the application starts.

 

The only workaround I have so far found is to downgrade the OVR runtime to 0.42.

It is likely that the bug will be eliminated in future versions of the OVR runtime. In the mean time, I intend to experiment with different AMD Catalyst driver versions to see if that makes any difference. I am currently using AMD Catalyst version 14.12.

 

If you’ve had success with another Catalyst version and dual-graphics on a OVR runtime later than 0.42, please let me know in the comments section.