Showing posts with label linux. Show all posts
Showing posts with label linux. Show all posts

Tuesday 28 September 2021

Yet Another New Home Server

This year has seen me doing more in the way of little tech projects at home than I have done for a while, perhaps due to covid lock downs so if that's the case then I'll take this small positive from an otherwise rubbish situation.  Typically for me, these projects have focused around open source projects and some IoT.  More on those in some separate blog posts when I get around to writing them up.  But for now, I wanted to make some notes on my new home server set up.

I've had an array of different low powered home servers of the years that I've previously written about, namely the NSLU2, TinyTuxBox, Joggler and for the past many years a simple ReadyNAS box that I specifically bought for the Intel processor as it made compiling different bits and pieces a whole lot easier back in the day.  However, I have recently relegated the ReadyNAS box from home serving duties, keeping it only for its native NAS services because using it for other things has become increasingly difficult without updating the entire base OS (which is possible by I'm reluctant to do) due to down level software libraries like an ancient version of openssl.

In with the new then and I moved away from Intel architecture as it's now so much easier to compile for Arm chips and went with the, wait for it, drum roll, rather obvious choice of a Raspberry Pi 4.  Specifically, a Pi 4 Model B, 4GB.  I've paired it with the official Pi case power supply, micro HDMI cable and shoved in an A2  SanDisk Extreme 64GB SDXC card.

And so to the notes, my initial target for this new box would be as follows:

The Lounge

IRC might be a bit old hat but tons of open source project still use it for their more synchronous communications.  ZNC is the choice of old for staying connected to your IRC channels.  For those not familiar, it acts as a relay to the IRC servers you want to connect to.  Effectively, it connects as your IRC client to the servers and presents your local IRC client with an endpoint through which you can connect.  This allows you never to miss any messages and see the IRC conversation even when you're not actually online.  Matrix seems to be taking some of the old IRC community's attention with various projects setting up bridges between Matrix and IRC.  However, the relative newcomer project called The Lounge shows just how far web technologies and web sockets have come.  It's a darned site (pun intended) easier to install configure and use than ZNC so I'm a massive convert and big fan of the project.

The project is relatively stable in the master branch and doesn't release particularly often so I've open for the run from source approach to take advantage of all the latest development.  Other than that, I've only made 3 changes to the default configuration prior to starting up my The Lounge server:
  1. host: "127.0.0.1"
  2. reverseProxy: true
  3. theme: "morning"
As you can see, these are all pretty simple and somewhat trivial changes.  The host setting binds the listener to the localhost interface, thus making it suitable for use with a reverse proxy and not exposing the service outside of the Pi 4.  The reverseProxy setting tells the server it's expecting to run behind a reverse proxy (the clue is in the name I guess).  Finally, I've switched to using a dark mode theme rather than the default light mode.  That's it, the remainder of the configuration is all about which IRC servers and channels to connect to along with the usual IRC bits of registering your nick and logging into the nick server.

Mosquitto

This is even simpler to get going than The Lounge due to the fact it's bundled with Raspbian so you can just apt-get install it.  I've created a configuration based on the bundled example config file but changing:
  1. pid_file (probably just because I'm old fashioned like that)
  2. user (to drop privileges)
  3. listener (to specify a port number)
  4. certfile and keyfile (for SSL)
  5. log_dest (create a specific log file for the broker)
  6. clientid_prefixes (a bit of added security to only allow certain client IDs to connect to the broker)
  7. allow_anonymous (quite an important one!)
  8. password_file (so that connections are authenticated)
Hopefully, that gives me something secure as well as providing me with the broker functionality that I need.

Node Red

Again, simple to install as it's bundled with Raspbian.  It does like to run under the default "pi" user though, which is a bit of a shame security wise.  All I've done to the configuration is ensure it's listening only on the local interface and enable the adminAuth section such that I'm required to enter a user name and password to access the user interface.

NGINX
 
Another simple install due to using the bundled version that comes with Raspbian.  However, this time around there's a lot more configuration to do since I'm using it to front a reverse proxy onto The Lounge and Node Red.  This gives me a few advantages such as being able to restart NGINX in order to load new SSL certificates without interrupting the underlying services i.e. something like IRC can stay connected even though new certs are loaded.  Both The Lounge and Node Red support SSL in their configuration so this also means I only need to configure certificates in one place and have a single route through which I can access all my home services.  The idea and bulk of the configuration for doing this comes directly from one of the guides available for The Lounge.

server {
    # redirect HTTP traffic to HTTPS
    listen 80 default_server;
    listen [::]:80 default_server;
    server_name _;
    return 301 https://$host$request_uri;
}

server {
    # SSL configuration
    #
    listen 443 ssl default_server;
    listen [::]:443 ssl default_server;
    ssl_certificate /path/to/your/server.crt;
    ssl_certificate_key /path/to/your/server.key;

    server_name your.server.name.com;
 
    # Add this if you want to do web serving as well
    root /var/www/html;
    index index.html index.htm;
 
    location / {
        # First attempt to serve request as file, then
        # as directory, then fall back to displaying a 404.
        try_files $uri $uri/ =404;
    }
 
    # Configure reverse proxy for The Lounge
    location ^~ /YOUR_PREFERRED_IRC_URL_GOES_HERE/ {
        proxy_pass http://127.0.0.1:9000/;
        proxy_http_version 1.1;
        proxy_set_header Connection "upgrade";
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header X-Forwarded-For $remote_addr;
        proxy_set_header X-Forwarded-Proto $scheme;

        # by default nginx times out connections in one minute
        proxy_read_timeout 1d;
    }

    # Configure reverse proxy for Node Red
    location ^~ /YOUR_PREFERRED_NODERED_URL_GOES_HERE/ {
        proxy_pass http://127.0.0.1:1880/;
        proxy_http_version 1.1;
        proxy_set_header Connection "upgrade";
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header X-Forwarded-For $remote_addr;
        proxy_set_header X-Forwarded-Proto $scheme;

        # by default nginx times out connections in one minute
        proxy_read_timeout 1d;
    }
}
 
Let's Encrypt
From Wikipedia: "Let's Encrypt is a non-profit certificate authority run by Internet Security Research Group that provides X.509 certificates for Transport Layer Security encryption at no charge."

The model for using letsencrypt is pretty simple.  They sign your SSL certificates, free of charge, but their signing expires within 90 days.  Hence, they're encouraging a high turnover of certificates by regular renewals.  This means that realistically you need to automate the process of certificate signing.  To do this I'm using the getssl script which makes life extremely easy when coupled with a cron job to kick off the script on a regular basis.  I'm running it every day and the script decides whether to replace my existing certificates.  It all sits there quite nicely running in the background and doesn't get in the way at all, restarting NGINX only when a new certificate is put in place.  Due to the fact that NGINX is decoupled from the services it is proxying the other services aren't interrupted.

Wednesday 2 December 2020

Open Sourcing a NetworkManager VPN Plugin

It's not every day I find myself publishing a new project to open source and even less so when that requires release approval at work.  I hope, over the years, I've written some useful bits and pieces and this time around I was keen to publish my work on the Internet rather than internally within the company.  This requires following due process of course and seeking the relevant approval for the publication to take place.

Fortunately, in the right circumstances, IBM are very amenable to releasing code to open source.  I was convinced enough that a NetworkManager plugin to add to the existing list of VPN plugins would not conflict with the business that an open source approval would be fairly trivial.  Happily, I was correct, and going through the process wasn't too arduous with a few forms to fill in.  These were, of course, designed much more for bigger releases than I planned so vastly over-engineered for this particular release but at least due diligence was applied.

On to the project and the code.  It's not a world-changer but a small VPN plugin for NetworkManager to drive Cisco AnyConnect and made available as NetworkManager-anyconnect on GitHub.  So I now know more than I'd care to mention about the inner workings of NetworkManager VPN plugins.  They're not very well documented (hardly documented at all in fact) so they're quite hard work to produce by looking over existing code in available plugins.  I started off from the OpenVPN plugin which turned out to be a mistake as the code base is vastly bigger than that required for a plugin as simple as the one I wanted to write.  Were I to start again, I would recommend starting from the SSH VPN plugin instead as this is actually very nicely set out and doesn't include a lot of the shared bloat that comes with other plugins that are formally a part of NetworkManager.


Friday 13 September 2019

Installing Tensorflow GPU on Fedora Linux

Following on from my previous notes on building Tensorflow for a GPU on Fedora, I find myself back at it again.  I recently upgraded my GPU at home and time has moved on too so this is my current set of notes for what I'm doing with Tensorflow on Fedora.  This method, however, differs from my previous notes in as much as I'm using the pre-built Tensorflow rather than building my own.  I've found that Tensorflow is so brittle during the build process it's much easier to work with pre-built binaries and set up my system to match their build.

In my previous blog post I benchmarked the CPU versus GPU using the Keras MNIST CNN example and so I thought it would be interesting to offer the same for this new install on my home machine.  The results are  :
  • 12 minutes and 14 seconds on my CPU
  • 1 minutes and 14 seconds on my GPU
That's just over 9.9 as fast on my GPU as my CPU!

Some info on my machine and config:
  • Custom Built Home PC
  • Intel Core i5-3570K CPU @ 3.40GHz (4 cores)
  • 16GB RAM
  • NVidia GeForce GTX 1660 (CUDA Compute Capability 7.5)
  • Fedora 30 Workstation running kernel 5.2.9-200.fc30.x86_64
Background Information for NVidia Drivers
Previously, I've always used the Negativo17 repository for all my NVidia driver and CUDA needs.  However, the software versions available there are too up-to-date to allow Tensorflow GPU to be installed in a way that works.  This repository provides CUDA 10.1 where as Tensorflow, currently at version 1.14, only supports CUDA 10.0.  So we must use another source for the NVidia software that provides back-level versions.  Fortunately, there is an official NVidia repository providing drivers and CUDA for Linux, so let's use that since it also works quite nicely with the RPM Fusion repositories as well.  Hence, this method relies purely on RPM Fusion and the official NVidia repository and does not require or use the Negativo17 repository (although it would be possible to do so).

Install Required NVidia Driver
The RPM Fusion NVidia instructions can be used here for more detail, but in brief simply install the display drivers:
  • dnf install xorg-x11-drv-nvidia akmod-nvidia xorg-x11-drv-nvidia-cuda
There are some other bits you might want from this repository as well such as:
    • dnf install vdpauinfo libva-vdpau-driver libva-utils nvidia-modprobe
    Wait for the driver to build and reboot to get things up and running.

    Install Required NVidia CUDA and Machine Learning Libraries
    This step relies on using the official nvidia repositories with a little more information available in the RPM Fusion CUDA instructions.

    First of all, add a new yum configuration file.  Copy the following to /etc/yum.repos.d/nvidia.repo:

    [nvidia-cuda]
    name=nvidia-cuda
    enabled=1
    gpgcheck=1
    gpgkey=http://developer.download.nvidia.com/compute/cuda/repos/fedora27/x86_64/7fa2af80.pub
    exclude=akmod-nvidia*,kmod-nvidia*,*nvidia*,nvidia-*,cuda-nvidia-kmod-common,dkms-nvidia,nvidia-libXNVCtrl

    [nvidia-machine-learning]

    name=nvidia-machine-learning
    baseurl=http://developer.download.nvidia.com/compute/machine-learning/repos/rhel7/x86_64/
    enabled=1
    gpgcheck=1
    gpgkey=http://developer.download.nvidia.com/compute/machine-learning/repos/rhel7/x86_64/7fa2af80.pub
    exclude=libcudnn7*.cuda10.1,libnccl*.cuda10.1



    Note that the configuration above deliberately targets the fedora27 repository from NVidia.  This is because it is the location at which we can find CUDA 10.0 compatible libraries rather than CUDA 10.1 libraries that will be found in later repositories.  So the configuration above is likely to need to change over time but essentially the message here is that we can match the version of CUDA required by targeting the appropriate repository from NVidia.  These libraries will be binary compatible with future versions of Fedora so this action should be safe to do for some time yet.



    With the following configuration in place we can now install CUDA 10.0 and the machine learning libraries required for Tensorflow GPU support and all of the libraries get installed in the correct places that Tensorflow expects.

    To install, run:
    • dnf install cuda libcudnn7 libnccl

    Install Tensorflow GPU
    The final piece of the puzzle is to install Tensorflow GPU which is now as easy as:
    • pip3 install tensorflow-gpu

    Friday 23 August 2019

    Migrating to Gnome 3

    I'm a massive laggard in the move to a Gnome 3 desktop.  Colleagues and friends have been using it for years and to be honest, I've never been comfortable using it.  But, that changed recently and I've actually grown to quite like the new desktop environment I find myself working in on a daily basis.  So I've made a full-blooded leap to a modern desktop.

    Way-back when I started using Linux as a serious desktop alternative to Windows (in about 2000-2001 ish) I was running Gnome.  I migrated away from that to KDE 3 and switched to Gnome 2 when KDE 4 was released as I didn't like the changes they had made and the new KDE 4 desktop was horribly buggy and unstable in my experience.  (Maybe there's something about brand new desktops and my not taking a liking to them?)  When Gnome released Gnome 3 I absolutely hated the user experience and used XFCE for a while before settling on the MATE desktop which I've been using for quite a few years now.

    Trying out Gnome 3 again recently and I was pleasantly surprised that the desktop has progressed significantly since those first few releases I couldn't get along with.  But it's the addition of extensions that are the final straw in my move as I've found with just the right mix I can craft a desktop that gives me a nice balance between the new world and the old, much more familiar, world.

    So, the real purpose of this post is to share the extensions I've discovered.  I'll document these below in brief but would also be interested to find others that are useful:

    Applications Menu (updated 5th Feb 2021 - no longer in use, see below)
    This was right at the very top of my list of requirements for Gnome 3 usability.  It simply puts an old school applications menu in the top bar, a bit like your old fashioned Windows start menu or similar from other desktops.  I am, however, finding I use this very little now as the search hot-key in Gnome 3 does seem to be a quicker way of finding and starting programs.

    Frippery Bottom Panel
    This is another of my top requirements for Gnome 3 usability.  It gives you a panel at the bottom of the screen (D'uh) that allows you to switch easily between applications you have running.  It also has a small workspace switcher which is why I like the Frippery version of this type of extension versus some of the others that don't have a workspace switcher capability.

    Top Icons Plus (update 5th Feb 2021 - no longer in use, replaced with AppIndicator, see below)
    Either the Top Icons or the Top Icons Plus extension that I'm using here seem so ubiquitous for Gnome 3 users I wonder why on earth they're not a default option, aside from the fact the Gnome 3 developers do seem to retain their keen vision on what a modern desktop should look like and "old" system tray icons are not part of that outlook.  This extension, if you're not already using it, allows you to see system tray icons such as the ones used by Virt Manager or Slack, for example.

    GPaste (update 4th Nov 2021 - no longer in use, too difficult to configure and doesn't always work the way I expected, replaced with Clipboard Indicator, updated again 8th Mar 2023, replaced with Pano Clipboard Manager)
    A clipboard management system that has a nice integration with the Gnome 3 panel.  I was previously using apps like ClipIt or Parcelite that do pretty much the same job.

    Lock Screen (update 5th Feb 2021 - no longer in use, I wasn't using this as I just hit Win+L to lock)
    This adds a button to the gnome panel that, when clicked, locks your desktop.  This would be the same as pressing Win+L on the keyboard.  I was in the habit of using a graphical button on MATE so having this back in Gnome 3 gives me the experience I'm used to.

    No TopLeft Hot Corner (update 5th Feb 2021 - no longer in use, Gnome Tweaks as a toggle for "Activities Overview Hot Corner" from the Top Bar options.
    I find the Gnome 3 facility to show activities when you mouse to the top left corner really annoying and it detracts from my productivity when it happens automatically.  Fortunately, this extension disables that feature.  It does make it more awkward to reach activities with the mouse (I'd have to click the applications menu first then select "Activities Overview") but I more or less always use the Windows key anyway.

    Places Status Indicator (update 8th Mar 2023 - no longer in use, I wasn't using it so have stopped installing it)
    This adds the old Gnome 2 style places menu to the Gnome 3 panel.  I find I flip between using this menu to start navigating directories and just starting Gnome Files and going from there.  Any which way, having this menu back on my desktop just makes it feel a bit more familiar and comfortable.

    Remove Dropdown Arrows (update 5th Feb 2021 - no longer in use, Gnome seems to have gotten rid of most of these by default)
    The Gnome 3 panel insists on having an arrow indicator to show items that pull down a menu when clicked.  These menus seem obvious to me and the arrows look rubbish and take up space, so this extension gets rid of them completely.  Happy days.

    Suspend Button (update 5th Feb 2021 - no longer in use, Gnome now has a built-in suspend button)
    I run from a laptop most of the time and use the suspend feature every time I "shut down" my laptop.  Bizarrely, there's no graphical facility (that I can find) in Gnome to suspend my machine.  This extension adds a nice button to the status menu that immediately suspends my machine.  Perfect.

    System Monitor
    Adds little graphs to the Gnome panel that show resource usage.  The extension is pretty configurable but I have it showing CPU, memory and network utilisation.  This allows me to keep an easy eye on my machine and how loaded it is at the current time.  Extremely useful for spotting those occasional rogue apps that start eating an entire core of my CPU.

    Media Keys (update 5th Feb 2021 - no longer in use, Gnome has media controls built-in)
    I haven't decided how useful this one is going to be yet and it's currently turned off.  However, when listening to Music through services like Amazon Music from a web browser it's nice to be able to control the audio without having to revert back to the browser ever time.  This extension simply adds a few buttons to the Gnome panel to control your media.  Handy if you haven't got the physical buttons on your keyboard too.

    Do Not Disturb Button (update 5th Feb 2021 - no longer in use, Gnome has the button built-in)
    I generally leave this extension disabled but it's useful to have installed and running when presenting or screen sharing.  It saves any embarrassing situations of people being able to read your notifications while they're looking at your screen.  Basically, it simply stops notifications being displayed, they're still received so you can go read them later.


    Blog edited with more extensions added on 28th August 2019:
    Frippery Panel Favourites
    I'm not quite sure how I missed this from my original list as it's an extension I've been using more or less since day one in Gnome 3.  It takes your favourite menu and adds this as a set of icons to the top of the Gnome Panel.  Makes for extra quick access to your commonly used apps.

    Some more extensions have been brought to my attention since writing the list above.  I've tried out all of the ones mentioned to me but these additions (below) are the ones that seem to have stuck.

    Caffeine (update 5th Feb 2021 - no longer in use, using Gnome's built-in do not disturb button instead)
    This extension sits fairly well alongside the Do Not Disturb Button extension in my original list.  This one simply disables the screen saver and auto suspend.  Hence, in conjunction with Do Not Disturb, will make a good presentation or screen sharing environment.

    GTile
    This is a genius little extension that allows you to easily resize your windows in order to tile them across your display.  I love the side-snapping in Gnome 3 that allows you to size a window to half the screen size.  In my older desktops I also had corner snapping to size a window to a quarter of the screen, Gnome 3 doesn't have this by default.  However, GTile adds an icon to your Gnome Panel that, when clicked, allows you to size to any area of your screen across a pre-defined grid - you can even change the grid size.  Brilliant for usability with lots of on-screen windows at the same time.


    Blog edited to update the list of extensions I'm using on 5th February 2021:
    Applications Menu
    Just a note to say that after using Gnome 3 for quite some time now, I rarely (if ever) use the Applications Menu any longer.  I tend to start applications either by pressing the Gnome hot key (Windows Key by default) and type in the search box, or by clicking on one of the favourites in the panel via the "Panel Favourites" extension.

    While the free desktop standard continues to specify the classic "icon tray" that was supported by extensions such as TopIcons, in reality few of the modern desktops (I'm referring to Gnome and KDE) support them.  The modern take on the tray icon is an AppIndicator icon and many modern applications are written to use this standard (and perhaps fall back to a tray icon).

    Blog edited to update the list of extensions I'm using on 8th March 2023:
    It's interesting to see how much use of extensions has changed over time.  I'm using considerably fewer now than I was when I first started using Gnome 3.  I put this down to two things: (1) Gnome is better at operating the way user's expect by removing the need for extensions such as the Suspend Button in the list above; and (2) I've become more institutionalised to the way that Gnome works, I'm much more familiar with it and have grown to like much of the way it works.

    Friday 16 November 2018

    Building Tensorflow GPU on Fedora Linux

    <update on Sept 13th 2019>
    I have written another post on how to install (rather than build) Tensorflow GPU for Fedora that uses a different and much simpler method.  See Installing Tensorflow GPU on Fedora Linux.
    </update>

    First off, let's say that there are easy ways of configuring Tensorflow for GPU usage such as using one of the docker images.  However, I'm a bit old school for some things and having always done so I've recently got Tensorflow going on my machine using my GPU.  Tensorflow CPU support is quite easy to do and generally works quite nicely using the pip install method.  GPU support, I've always found, is quite a bit more difficult as there are a whole bunch of things that need to be at just the right level for everything to work i.e. it's quite brittle!

    What follows are my notes (it's in the name of the blog) for how to build Tensorflow from scratch to enable GPU support and I do this on Fedora Linux.  If you want to know why it's worth bothering going to this effort, I've tested the Keras MNIST CNN example as a bench mark.  It takes:
    • 11 minutes 7 seconds on my CPU
    • 2 minutes 55 seconds on my GPU
    That's just over 3.8 as fast on my GPU as per my CPU so for large jobs this will be huge!

    Some info on my machine and config:
    • Lenovo P50 Laptop
    • Intel Core i7-6820HQ CPU @ 2.70GHz (4 core with hyper threading)
    • 32GB RAM
    • Nvidia Quadro M1000M (CUDA compute capability 5.0)
    • Fedora 28 running kernel 4.18.18-200.fc28.x86_64
    Install Required Nvidia RPMs
    You need to get everything Nvidia and CUDA installed on your machine first.   I quite like the Negativo17 repository for Nvidia on Fedora Linux and so I use this but you could also go with RPM Fusion or even download everything directly from Nvidia.  For me, right now, I have this little lot installed:
    cuda-9.2.148.1-2.fc28.x86_64
    cuda-cli-tools-9.2.148.1-2.fc28.x86_64
    cuda-cublas-9.2.148.1-2.fc28.x86_64
    cuda-cublas-devel-9.2.148.1-2.fc28.x86_64
    cuda-cudart-9.2.148.1-2.fc28.x86_64
    cuda-cudart-devel-9.2.148.1-2.fc28.x86_64
    cuda-cudnn-7.2.1.38-1.fc28.x86_64
    cuda-cudnn-devel-7.2.1.38-1.fc28.x86_64
    cuda-cufft-9.2.148.1-2.fc28.x86_64
    cuda-cufft-devel-9.2.148.1-2.fc28.x86_64
    cuda-cupti-9.2.148.1-2.fc28.x86_64
    cuda-cupti-devel-9.2.148.1-2.fc28.x86_64
    cuda-curand-9.2.148.1-2.fc28.x86_64
    cuda-curand-devel-9.2.148.1-2.fc28.x86_64
    cuda-cusolver-9.2.148.1-2.fc28.x86_64
    cuda-cusolver-devel-9.2.148.1-2.fc28.x86_64
    cuda-cusparse-9.2.148.1-2.fc28.x86_64
    cuda-cusparse-devel-9.2.148.1-2.fc28.x86_64
    cuda-devel-9.2.148.1-2.fc28.x86_64
    cuda-docs-9.2.148.1-2.fc28.noarch
    cuda-gcc-7.3.0-1.fc28.x86_64
    cuda-gcc-c++-7.3.0-1.fc28.x86_64
    cuda-gcc-gfortran-7.3.0-1.fc28.x86_64
    cuda-libs-9.2.148.1-2.fc28.x86_64
    cuda-npp-9.2.148.1-2.fc28.x86_64
    cuda-npp-devel-9.2.148.1-2.fc28.x86_64
    cuda-nvgraph-9.2.148.1-2.fc28.x86_64
    cuda-nvgraph-devel-9.2.148.1-2.fc28.x86_64
    cuda-nvml-devel-9.2.148.1-2.fc28.x86_64
    cuda-nvrtc-9.2.148.1-2.fc28.x86_64
    cuda-nvrtc-devel-9.2.148.1-2.fc28.x86_64
    cuda-nvtx-9.2.148.1-2.fc28.x86_64
    cuda-nvtx-devel-9.2.148.1-2.fc28.x86_64
    nvidia-driver-cuda-libs-410.73-4.fc28.x86_64

    You might wonder about some of the above, particularly why you might need a back level version of GCC.  When Fedora 28 has a quite capable GCC version 8 why on earth would you want version 7?  The answer lies in my comment about things being difficult or brittle, it's quite simply that CUDA doesn't yet support GCC 8 so you do need a back level compiler for this

    Install NVidia NCCL
    This library isn't available through an RPM installation or the Negativo17 repository and so you must:
    • Go to the Nvidia NCCL home page 
    • Click the link to download NCCL (requires an Nvidia developer login account)
    • Agree to the Terms and Conditions
    • Download the NCCL zipped tar file that matches your CUDA version (9.2 for this blog post)

    At the time of writing the file required is nccl_2.3.7-1+cuda9.2_x86_64.txz

    I simply untar this file into /usr/local and create a symbolic link as follows:
    • cd /usr/local
    • sudo tar -xf /path/to/file/nccl_2.3.7-1+cuda9.2_x86_64.txz
    • sudo ln -s nccl_2.3.7-1+cuda9.2_x86_64.txz nccl


    Install the Bazel Build Tool
    You're going to need a build tool called Bazel which isn't directly available in the Fedora repositories (that I know of at least) but fortunately there's a version in a copr repository you can use as documented run the following commands:
    •  dnf copr enable vbatts/bazel
    •  dnf install bazel
    Get a Copy of Tensorflow Source
    For this it's just as easy to use git as it is anything else.  You can directly clone the 1.12 release of Tensorflow into a new directory by running:
    • git clone --single-branch -b r1.12 https://github.com/tensorflow/tensorflow tensorflow-r1.12
    • cd tensorflow-r1.12
    Simply replace r1.12 in the above commands if you want to use a different Tensorflow release.

    Run the Tensorflow Configure Script
    This step is actually quite simple but you'll need the answers to some questions to hand, simply run:
    • ./configure
    I accept all the default options with the exception of:
    • "location of python" set to /usr/bin/python3 since Fedora still uses Python 2.7 as the default version at /usr/bin/python
    • "build TensorFlow with CUDA support" set to Yes
    • "CUDA SDK version" set to 9.2 (this value should match the cuda version you have installed and at the time of writing 9.2 is the current version from the Negativo17 repository)
    • "location where CUDA 9.2 toolkit is installed" set to /usr
    • "cuDNN version" set to 7.2 (similar to the cuda version above, this value should match the cuda-cudnn package version and 7.2 is the current version from the Negativo17 repository)
    • "NCCL version" set to 2.3
    • "location where NCCL 2 library is installed" set to /usr/local/nccl
    • "Cuda compute capabilities you want to build with" set to 5.0 (but this value should match the CUDA compute capability of the GPU in the machine you're building for)
    • "which gcc" set to /usr/bin/cuda-gcc (to use the back level GCC version 7)


    Fix Bazel Config
    The above config command writes a file but the location isn't compatible with the latest version of Bazel.  Presumably this issue will be fixed at some point in the future, it's not an issue with Bazel 0.18 and below as far as I'm aware, but has just become an issue on 0.19.  Simply copy the config to the correct place:
    • cat tools/bazel.rc >> .tf_configure.bazelrc
    Build Tensorflow with GPU Support
    This took around an hour to complete on my machine:
    • bazel build --config=opt --config=cuda //tensorflow/tools/pip_package:build_pip_package
    • bazel-bin/tensorflow/tools/pip_package/build_pip_package /tmp/tensorflow_pkg
    The first step is the long one for the build, the second simply builds the python wheel file.

    Install Tensorflow with GPU Support
    You've got your wheel file so simply install and enjoy:
    • pip3 install tensorflow-1.12.0-cp36-cp36m-linux_x86_64.whl 
    Run Some Code
    The first time I attempted to run some code to test I got an error:
    • failed call to cuInit: CUDA_ERROR_UNKNOWN
    This can be solved by making sure you have the nvidia-modprobe package installed.  Alternatively, you can run the little script below the following explanation.

    This seems to be some sort of permissions issue and running the following simple script to output the GPUs available on my machine but as root seems to have fixed the above issue i.e. put the following into a script, run that script as root, then any time you want to run code as an unprivileged user the above issue is fixed and the code will work:
    from keras import backend as K
    K.tensorflow_backend._get_available_gpus()

    If the above works then you can try out the Keras MNIST CNN example code.

    Sunday 23 April 2017

    New Thinkpad P50

    It's been a while, but true to our 4 year hardware refresh cycle, I've just received my latest laptop - a Lenovo P50.  I've been installing it with Fedora 25 since Friday and configuring and copying data over this weekend ready to swap laptops first thing this week.  I'm looking forward to trying out the new machine although I'm not quite sure why as the specs are barely different from the machine I was given 4 years ago.  It's certainly the best indication yet I've personally experienced of Moore's Law coming to a complete halt as well as many of the other specifications not improving a huge amount either.  The two most noticeable differences are likely to be the more powerful graphics chip and the inclusion of an SSD.  That said, there is twice as much RAM in this machine and I had upgraded my previous machine with an SSD as well so that particular upgrade isn't going to be noticeable for me at least.

    My previous machine was a W530 and the one I had before that was a T61p (with a T41p before that) and so I'm well used to this particular line of Thinkpad laptops.

    Here's the specifications of the machine I've got, as ever there are variants of the P50 so if you have one or are thinking of getting one the specifications could be a little different but will be broadly similar to this:

    • Intel(R) Core(TM) i7-6820HQ CPU @ 2.70GHz (5433.79 bogomips in Linux)
    • 32GB DDR4 2133MHz
    • Samsung MZNLN512 (PM871) 512GB SSD
    • 15.6" 1920 x 1080 IPS (non-touch)
    • 6 Cell Battery
    • Wireless A/C
    • NVIDIA Quadro M1000M 4 GB
    • Front Facing Web Cam, Mini Display Port, HDMI Out, Headphone, 4x USB3, Smart Card Reader, GBit Ethernet, Thunderbold, Fingerprint Reader
    So looking at those and comparing in more detail to what I had before it seems my gut feeling was pretty good.  The CPU benchmarks are more-or-less exactly the same and certainly within tolerances of error as well as other performance increases that will effect the benchmarks such as the memory clock speed.  Here's the comparison between the W530 CPU and the P50 CPU:


    The same can't be said of the GPU benchmarks though so it looks like GPUs are continuing to gain in power even when CPU speed increases have run out of steam:

    The other noticeable difference I hadn't spotted before is the battery size.  That's very apparent when you pick the machine up as it's actually a little bit thinner (probably also due to the lack of DVD/combo drive) as well as not as deep i.e. it doesn't have the big battery sticking out of the back that has been common place on this line of Thinkpad machines over the past decade or so.  I'm guessing (without having done any research on the matter) that this is probably due to improvements in battery technology so I'd think Lenovo have probably moved over to Li-ion or Li-po batteries.

    In terms of running and using the machine, it does seem very nice so far as one might expect.  It's running Fedora 25 very nicely and hasn't caused me any issues at all during setup.  I'm not really expecting any either as most if not all of the hardware seems pretty well support by Linux these days.  I think, in fact, Lenovo even offer to supply this machine pre-installed with Linux if you want.  That said, there looks to be one possible sticking point in terms of hardware support at the moment but this is very minor.  That is, the build-in fingerprint reader doesn't seem to have a driver available on Linux yet.  I did some very brief research into this yesterday and it's not clear why vendor support is lacking for the device at the moment although I did find at least one effort that has gone a fairly long way towards reverse engineering it and starting to write a driver so I would guess within the next year we'll see some sort of support for the fingerprint reader too.

    All in all then it's a good machine even though it's not a huge upgrade over my 4 year old laptop!

    Thursday 19 November 2015

    Compiling the 8192eu driver for the Raspberry Pi

    I recently had the need to Wi-Fi enable a Raspberry Pi and so bought a D-Link DWA-131 Wireless USB Adapter.  I knew from something I'd read that it was a bit of a gamble in terms of whether it would be supported by the Pi under Raspian.  It turns out there are currently 3 revs of this adapter with different chipsets in each.  The one I got was the latest E1 version identified with the USB Device ID 2001:3319 that requires the realtek 8192eu driver.

    Here's how to get it working under the September 2015 Raspian Jessie running Kernel 4.1.7+ for which I found some similar instructions a helpful starter:

    1.  Get up to date and ready for compilation

    sudo apt-get update
    sudo apt-get upgrade
    sudo apt-get install build-essential git


    2. Grab the Driver Source

    git clone https://github.com/romcyncynatus/rtl8192eu.git

    or from

    http://support.dlink.com.au/download/download.aspx?product=DWA-131


    3. Patch the driver source for Kernel 4.x

    cd rtl8192eu
    Apply the following patch to rtw_android.c

    diff --git a/os_dep/linux/rtw_android.c b/os_dep/linux/rtw_android.c
    index 40ddf07..f7c496e 100755
    --- a/os_dep/linux/rtw_android.c
    +++ b/os_dep/linux/rtw_android.c
    @@ -342,7 +342,11 @@ int rtw_android_cmdstr_to_num(char *cmdstr)
     {
            int cmd_num;
            for(cmd_num=0 ; cmd_num<ANDROID_WIFI_CMD_MAX; cmd_num++)
    +#if (LINUX_VERSION_CODE >= KERNEL_VERSION(4,0,0))
    +               if(0 == strncasecmp(cmdstr , android_wifi_cmd_str[cmd_num], strlen(android_wifi_cmd_str[cmd_num])) )
    +#else
                    if(0 == strnicmp(cmdstr , android_wifi_cmd_str[cmd_num], strlen(android_wifi_cmd_str[cmd_num])) )
    +#endif
                            break;

            return cmd_num;



    4. Grab the rpi-source tool (to download the Pi kernel source)

    wget https://raw.githubusercontent.com/notro/rpi-source/master/rpi-source 
    chmod +x rpi-source
    sudo mv rpi-source   /usr/bin/
    sudo rpi-source -q --tag-update


    5. Install the Pi kernel

    sudo rpi-source --skip-gcc


    6. Build and install the driver

    make ARCH=arm
    sudo make ARCH=arm install
    sudo bash -c 'echo "options 8192eu rtw_power_mgnt=0 rtw_enusbss=0" > /etc/modprobe.d/8192eu.conf'
    modprobe 8192eu

    Saturday 9 March 2013

    New Thinkpad W530

    It's been quite a while since I got my last laptop upgrade at work, coming up to 5 years in fact.  We have a 4 year refresh programme so I'm a little overdue but have just been given a shiny new Thinkpad W530 from Lenovo.  This seems to be our current standard issue machine for "developers" which is our way of saying "power users".  I'm part of the software development business and hence get one of these.  The up side of course is the latest and most powerful technology at a reasonably high specification, the downside is they're really quite big and heavy and the power brick - well it really is a brick.  I'll spare giving a full review of the laptop itself as there are plenty of them out there already and you'll know how to find them, however, there are one or two things I wanted to say about the machine and in particular regarding my preferred use of Linux rather than the software it comes pre-installed with.

    Here's the specification highlights of the machine I've got (there is a bit of variation available with the W530):

    • Intel(R) Core(TM) i7-3720QM CPU @ 2.60GHz (5187.87 bogomips in Linux)
    • 16GB DDR3 1600MHz
    • 500GB (7200rpm) HDD
    • 15.6" 1920x1080
    • 9 Cell Battery
    • Wireless N
    • NVidia Quadro K1000M
    • Front Facing Web Cam, Mini Display Port, VGA Out, Headphone, 2x USB3, 2xUSB2.0, Smart Card Reader, Firewire,DVD Burner, GBit Ethernet
    It came with firmware version 2.07 which was only 3 months old but had already been superseded by two newer versions when I got it earlier this week (there is a firmware readme available).  The newer versions fixed a couple of well known issues with screen corruption under Linux and the fan always running at full speed (and hence being noisy).  So I downloaded and applied the updated version before I did anything else.


    The next thing I did was tweak a few settings in the BIOS to my liking and install Fedora 18 with the KDE desktop.  The installation went very smoothly using the Integrated graphics card on the Ivy Bridge CPU.  The W530 has Optimus built in for efficient switching between the integrated card and discrete NVidia card for a great combo of power/performance, it is however, designed for Windows and Linux support hasn't quite caught up yet although there is an open source option available - which I'm yet to try.  Post installation I installed the latest NVidia drivers available from the RPM Fusion repository (304.64) ready to switch to using the graphics subsystem in discrete only mode.  The advantage of this is greater graphical processing power and also the ability to use external display devices.  The integrated graphics card is only able to drive the laptop screen and doesn't output via the VGA port or display port.  The down side to the NVidia card is a greater power draw so reduced battery life.  Also, at the time of writing the Nouveau driver doesn't support the Quadro K1000M card so you're forced into using the proprietary driver.  This situation can only improve over time and hopefully Optimus support will grow in Linux too but I'm not holding my breath on that one given NVidia's attempt to put support into the Linux kernel was refuted by the kernel developers last year due to it not being GPL code.

    Away from the graphics subsystem which was always going to be the most difficult thing under Linux on this machine, the rest of  it appears to be very well supported.  There are a few bits and pieces I haven't quite got around to trying in the couple of days since I got it but my impression is generally quite good.  Speed, as you would expect is very good although nowhere near my home machine which is a similar specification but contains an SSD instead of HDD.  Consequently, I put the speed boost I see at home down to this more or less entirely.

    I've also moved away from Gnome (I don't get on with Gnome 3) and gone back to using KDE once again which I had moved away from 5 years ago when I installed my previous laptop as KDE 4 was pretty shocking at the time as well.  I've used KDE a lot more than I have Gnome in terms of years of elapsed usage but I did get on very well with Gnome 2 for the past 5 years and I'm sure I'll miss it.  That said, I can't see myself ever moving to Gnome 3 unless the developers go back on their current manifesto of treating users like idiots.  It'll be interesting to see how the Mate desktop progresses and whether XFCE picks up as well given they both have benefited from Gnome 3's unfortunate design decisions and have a much smaller community of users and developers than either Gnome or KDE.

    In general then, I'm pleased with the new machine.  It's up and running to my liking in a very short period of time.  The graphics are bound to be a pain until I get used to relying on the nvidia-settings utility once again.  However, the other benefits it brings in terms of larger memory and greater processing power over my old machine are probably worth it.

    Tuesday 5 February 2013

    Upgrading Fedora 17 to 18

    It's been a while since I talked about upgrading Fedora but back in late 2009 and early 2010 I wrote about upgrading my home PC from one version of Fedora to the latest version at the time:

    These were about the time (shortly after) the Fedora project introduced its latest piece of tooling, used for upgrading between distribution versions, called preupgrade.  Several years down the line and my PC and the more complex configuration than average that caused a few issues at the time have changed.  Preupgrade has been changed too, dropped in fact.  The Fedora project have moved away from it in favour of producing a new tool called Fedup (yes, yes, nice name).

    It really was about time that preupgrade was replaced, as far as I know it was only ever produced as a short-term solution to upgrading Fedora without the need for booting from CD/DVD/USB/PXE and going through the Anaconda upgrade process.  It was a proof of concept if you like.  It's also been openly described within the project as "just a set of hacks" and other such non-complementary terms.  So why the need for something new?  Well I think that's already been best described elsewhere buy the guys behind Fedup so I'll just point you at a little background information on Fedup instead.

    Having tried it first at work to upgrade a virtual machine from F17 to F18 I found that Fedup actually works pretty well, in fact to the user it doesn't really appear to do much differently to preupgrade.  You simply start the tool, tell it what to upgrade to, wait while it downloads the packages, then reboot to perform the upgrade, all done.  I recently tried it at home as well and it worked perfectly, no issues at all, which seems to be the experience of all the others users I've talked to about using it as well.  So far then it's a bit thumbs-up and thanks to the Fedup and Fedora teams for making it all so easy for us.

    The one pitfall is that you can't upgrade straight from F16 to F18.  Traditionally with Fedora you can jump a version so you've always been able to upgrade directly from any current Fedora version that hasn't gone end of life yet to the very latest without going through intermediate versions.  Between F16 and F18 that wasn't possible though so if you're still on F16 you'll need to preupgrade your way through F17 before doing a Fedup to F18 if that's where you want to get to.  However, from F17 onwards Fedup should support the same version jumping as preupgrade did, it's simply that Fedup isn't available until F17 that causes this particular issue.



    Tuesday 22 May 2012

    New PC Install Notes


    This post documents how I installed Linux and Windows side-by-side in a dual boot configuration.  This isn't something particularly difficult to do but I wanted to note down what I did so I remember in years to come.  Also, my new PC build contains some very up-to-date hardware (such as UEFI and an SSD drive) and with the combination of the many changes and updates to Fedora 17 (F17) and Windows 7 SP1 (Win7) it made the installation a first of a kind for me in quite a few different ways.

    This post may well be updated in the future if I do further installation tweaks and optimisations to the system.  There's also clearly a lot more you can do in terms of system set up than I've written here, installation of drivers in Win7 very much being one of those.  This is simply intended as an installation and base optimisation guide.

    Create USB Boot Sticks

    Due to a fault with the DVD writer I ordered, it's on its way back to the retailer for replacement.  Not one to let this stop an installation going ahead I wrote install images for F17 and Win7 onto USB stick.

    F17 is still in beta with the full release delayed until 29th May at the time of writing.  I tried writing and booting from the KDE Spin Beta Live image but it stopped with a kernel panic during the boot process after the grub screen.  I found using a later copy of the boot.iso (which is the same as a netinst.iso) from the distribution nightly builds solved the problem so clearly whatever the bug is on the beta image it's already been solved.

    Creating a USB stick for Fedora is pretty easy these days, no messing around on the command line, I decided to use the liveusb-creator utility.  It fires up a GUI from which you basically just select the iso image you want to write and the USB device to write to, then hit "go" and it does the magic for you.

    For me, writing the Windows stick was a little more complicated as it requires a Windows system to run the stick writing utility with the somewhat strange and long winded name of the Windows 7 USB/DVD Download Tool.  Fortunately, I had a Windows 7 VM laying around so I used that and writing the image to USB stick was similarly easy as it was for Fedora.  Simply choose the image file to write, the target device to write it on, then hit "go" and it does the magic for you.

    Install Fedora 17

    Once I worked around the kernel panic bug I mentioned above and booted with a later F17 image, the installation process was a fairly familiar affair.

    With the new PC being a UEFI box there was no need to add the GPT partition when partitioning the SSD. I simply created one large root partition and a 4GB swap partition, leaving half the disk unallocated for the Win7 install later.

    Since I didn't boot from the KDE spin image, I swapped out the default Gnome desktop (I've tried hard for a long time to Like Gnome 3 but I just don't so I'm moving back to KDE) and did a lot of package selection using the installer to save me messing around later but also to optimise the amount of data downloaded since I would be installing over my ADSL connection.

    Once tip when installing Windows after Linux these days is to ensure the os-prober RPM gets installed.  This was done by default for me.  This package allows grub to detect the presence of other operating systems and add boot entries for them in the grub menu.  It'll come in very handy later on...!

    SSD Optimisations for Linux

    Even with a distribution as current as Fedora 17, the settings chosen for SSD usage are really rather sub-standard.  There are a lot of handy tips and guides out there for which settings you should change or add to the system to enhance both the performance and longevity of your SSD.  I decided to go with the rather comprehensive information provided for the Arch Linux distribution as they have a great wiki page on SSD optimisation.


    Update /etc/fstab

    I've only got one SSD in my system at the moment, I've removed all my old hard disks with no intention to use them right now as all my data is stored on my NAS.

    Add the "noatime" and "discard" options to SSD partitions.  The discard option is the really super-important one as it turns on TRIM.

    Mount /tmp as tmpfs by adding a line similar to the following:
      tmpfs /tmp tmpfs nodev,nosuid,size=75% 0 0

    Doing this allows the system to write temporary files to RAM instead of the SSD.  This will improve performance (RAM is faster than SSD) and reduce writes to the SSD (improving the life of the SSD).  I've added an option to increase the allowable size of the tmpfs file system to 75% of RAM from the default of 50%.  This means I can run compilations or other intensive tasks in RAM without ruining the SSD and get the performance benefits too.  With 16GB main RAM, this will allocate up to 12GB for my /tmp directory.  In normal usage I wouldn't expect to use anywhere near this but it's nice to have it there for when I'm not running too many apps but doing something else such as compiling RPMs.

    Change the Scheduler

    The recommendation for an SSD is to move away from the default cfq IO scheduler and switch over to the noop scheduler.  This can be done in a variety of ways that are documented in the Arch Linux wiki page I've linked above.  Since I've only got 1 disk in my machine and it's an SSD I changed the scheduler option using grub.

    For Fedora 17 this consisted of an edit to the /etc/default/grub file and adding elevator=noop to the existing GRUB_CMDLINE_LINUX stanza.  Then rebuilding the grub configuration with the command:
    grub2-mkconfig > /boot/grub2/grub.cfg

    Optimise Kernel Parameters

    With 16GB main RAM I'm not expecting to do much in the way of swapping.  However, I did add a couple of lines to /etc/sysctl.conf to make the system less likely to do so:
      # make the system less likely to swap
      vm.swapiness=1
      vm.vfs_cache_pressure=50


    Install Windows 7

    Similarly to the F17 install, the Win7 install proceeded with little in the way of drama.  I did select the advanced install option when given the chance but that was just to ensure Win7 installed into the free space I had left on the SSD rather than rudely splat my shiny new F17 installation.

    And yes, for those of you wondering why I'm installing Win7 at all, especially dual boot rather than in a VM, it's simply for those times when only Windows will do... so gaming mostly I should think.

    There's not much else to do with Windows after installation.  Unlike current Linux distributions it's said to  detect the presence of an SSD drive and apply the appropriate optimisations automatically.  Whether this is entirely true or not I suspect I'll never be any the wiser to.

    Update the Boot Loader

    So Win7 didn't kill off my F17 installation which is always a bonus, but it does assume divine rights over the entire system so writes its boot loader all over the existing grub installation allowing you only to boot windows with no menu options for anything else - not ideal.  Now I need to re-install grub which I've always found easiest to do by booting a rescue Linux CD and using a chroot to the installed OS.  This has changed slightly with the inclusion of grub 2 so here's what I did.

    Boot the F17 USB stick once again but this time choose the "troubleshooting" boot option and select to boot the "rescue environment".  Red Hat based systems have always done a great job of rescue environments so you'll boot into a text based system that asks you if you want various things turned on in the rescue environment such as networking (although they assume you want that these days) and if you want to attempt detection of installed Linux systems (which you do).

    Drop out to the shell prompt and chroot to /mnt/sysimage.  Then rebuild the grub config (this is where os prober installed above comes in very handy) to include an entry for booting Win7.  Then re-install grub.  Job done.  Once you've booted to the rescue shell, the commands are something along the lines of:

      chroot /mnt/sysimage
      grub2-mkconfig > /boot/grub2/grub.cfg
      grub2-install /dev/sda
      exit
      exit
      reboot

    This assumes you want to install grub to /dev/sda of course.  You'll need to exit (or ctrl+d) twice, once to get out of the chroot and once more to return to the rescue interface.  Then choose to reboot from there as it'll cleanly unmount your file systems and do a better job of clearing up than if you simply rebooted the system yourself.

    Sunday 10 April 2011

    ReadyNAS Ultra 2 Plus

    I recently bought a Netgear ReadyNAS Ultra Plus 2 (RNDP200U) Network Attached Storage (NAS) device and before buying found it hard if not impossible to find out the finer technical details of the hardware specification.  In a similar way to some of my previous posts I thought I'd list out some of the key specs as found under Linux running on the device.

    It appears to be running a distribution based from Debian Etch which Netgear have modified to make what they call their Raidiator operating system.  It shipped with Raidiator version 4.2.15 and this is upgradeable when they release new versions.

    The kernel version is 2.6.33.7.RNx86_64.2.2 and (surprisingly) is x86_64 rather than the 32 bit OS I would have expected.

    The tech specs list the RAM as 1GB DDR2 SODIMM and I can happily report free sees all 1GB available, there's around 500MB of swap space too.

    They seem to carve out some sort of virtual storage on the disks you put into the box too.  I've not quite worked this out yet but df reports the following
    /dev/md0              4.0G  572M  3.3G  15% /

    The CPU is pretty beefy for this type of hardware, Linux sees one processor and two hyperthreaded cores so you get four lots of the following in /proc/cpuinfo
    processor : 0
    vendor_id : GenuineIntel
    cpu family : 6
    model : 28
    model name : Intel(R) Atom(TM) CPU D525   @ 1.80GHz
    stepping : 10
    cpu MHz : 1800.215
    cache size : 512 KB
    physical id : 0
    siblings : 4
    core id : 0
    cpu cores : 2
    apicid : 0
    initial apicid : 0
    fpu : yes
    fpu_exception : yes
    cpuid level : 10
    wp : yes
    flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good aperfmperf pni dtes64 monitor ds_cpl tm2 ssse3 cx16 xtpr pdcm movbe lahf_lm
    bogomips : 3600.43
    clflush size : 64
    cache_alignment : 64
    address sizes : 36 bits physical, 48 bits virtual
    power management:

    The other hardware in the system is pretty much covered by the output of lspci
    Host bridge: Intel Corporation Unknown device
    VGA compatible controller: Intel Corporation Unknown device
    Display controller: Intel Corporation Unknown device
    PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1
    PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 2
    PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 3
    USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #1
    USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #2
    USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #3
    USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #4
    USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller
    PCI bridge: Intel Corporation 82801 Mobile PCI Bridge
    ISA bridge: Intel Corporation Unknown device 27bc
    SATA controller: Intel Corporation 82801GR/GH (ICH7 Family) Serial ATA Storage Controller AHCI
    SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller
    Ethernet controller: Marvell Technology Group Ltd. Unknown device 4380
    USB Controller: NEC Corporation Unknown device 0194
    Ethernet controller: Marvell Technology Group Ltd. Unknown device 4380

    The hardware Specs from the ReadyNAS site are

    Physical Specifications
    Intel® Atom 1.8 GHz Dual-core CPU (Ultra 2 Plus)
    1GB DDR2 SODIMM
    Two (42) Serial ATA II channels
    Hot swappable and lockable trays
    Two (2) 10/100/1000 Ethernet ports
    One (1) USB 3.0 port
    Two (2) USB 2.0 ports
    Embedded 128 MB Flash Memory for OS
    Kensington Lock security hole
    Software controlled 80 mm chassis cooling fan
    Dimension (H x W x D): 101 x 142 x 220 mm (3.98 x 5.59 x 8.66 in)
    Weight: 2.07 kg (4.56 lb), without hard disks
    Electrical
    60W External AC power supply
    Input: 100-240V AC~ 50-60Hz 5A(Max)
    Power Consumption
    34W typical with 2 x 2TB disks
    32W idle, 19W with disk spin-down
    Environmental Compliance
    0 to 40 C (32 to 104 F)
    20% to 80% Humidity (non-condensing)
    FCC, UL, CE, RoHS, C-tick, VCCI, CCC, KCC compliance
    Available Configurations
    Diskless
    Half-populated

    Tuesday 1 June 2010

    Joggler Linux Boot Mysteries

    PCs boot first using a system known as a BIOS (basic input output system), that's the bit you might see when you very first switch on your computer and might say something like "Press F1 to enter system menu" or similar. The BIOS is responsible for knowing enough about your hardware such that it can start the computer, run your boot loader and ultimately pass on some information to your operating system which takes over control of the hardware. The Joggler doesn't boot using the mechanism most of us as PC users are familiar with, however, abandoning the BIOS in favour of EFI (extensible firmware interface). EFI is much bigger, more flexible and inevitably a lot more complicated than the older BIOS system. I'll attempt to unravel in simple terms some of the mysteries of booting your own operating system on the Joggler here.

    EFI has its roots in Intel in the same way as a BIOS has its roots in IBM.  Basically, it consists of a set of executables able to run within the simple environment EFI provides.  These executables are just little computer programs that can vary extremely widely from talking to a piece of your hardware to providing you with a shell environment in which you can interact with EFI through to booting your operating system.  This last function is quite important to us as computer users if we're to understand how EFI is used to start your machine, in this case your Joggler.  A BIOS will boot your machine by looking at the master boot record and starting the boot loader that your installed operating system has put there; your operating system is responsible for booting itself.  EFI does away with this, moving the responsibility for booting operating systems into the firmware interface itself, you no longer need a boot loader for your operating system.  Instead, the boot loader is now just another EFI program that runs within the simple EFI environment I mentioned earlier.

    You've been wondering what this FAT partition on your Joggler image is all about?  FAT is just another file system like NTFS for Windows or ext for Linux, it's very widely understood so is commonly used these days on USB sticks but not necessarily many other places.  If your disk is to be used to boot an operating system then EFI says you need a FAT file system as the first partition of that disk.  EFI actually says FAT12 or FAT16 must be used for "removable media" so for us Joggler users with USB sticks or hard disks we should be using FAT16 even though EFI can understand FAT32 as well.  You could boot any other disk from your FAT partition but all the simple Joggler cases would just involve booting an operating system somewhere else on the same disk i.e. the second partition.

    Fortunately for us, when you start your Joggler its EFI looks both at its internal disk (the one with the O2 interface on it) and removable media (your USB disk).  The FAT partition is discovered on your USB disk and by convention the file called startup.nsh is executed.  This file is simply a script which can be used to execute any EFI script commands you wish.  For Joggler USB booting it just runs a local script on your disk to start your boot loader EFI program.

    So for the Joggler we might have something like this in startup.nsh on our disk in order to call the boot.nsh:
    fs1:boot2
    fs0:boot


    And the following in the file boot.nsh to start the grub EFI boot loader program:
    fs1:
    grub


    You now know what to do in order to boot your Joggler from a USB disk but the final missing piece to the puzzle is the EFI boot loader program itself. In the example above I used grub as the boot loader program. Yes, this is the same grub you're familiar with from booting Linux on BIOS based machines. However, in this example it's an EFI program so you'd be right to be wondering how you go about getting a copy of it.  In my example here your FAT partition already has 2 files on it (startup.nsh and boot.nsh) and you'll need another 2 files (grub.efi and grub.cfg) to be able to boot your disk

    There are two versions of grub.  The old version, grub 1 or grub legacy as it's know known is not the one you want.  You're looking for the current version which is (or will become) grub 2.  At the time of writing grub 1.98 is the latest version, download the released version.  Unfortunately, it doesn't work on the Joggler without applying a patch.  So it's with thanks and reference to the guys over at Joggler Hacks I got my Joggler booting with my own grub 2.

    To compile an EFI version of grub 2, unpack the source you've downloaded, then apply the Joggler grub 2 patch (using patch -p1), run ./configure --with-platform=efi and make.  The compilation should proceed through to completion leaving you just finish off by making the grub EFI program.  You can do this with ./grub-mkimage -d . -o grub.efi part_msdos hfsplus fat ext2 normal sh chain boot configfile linux.  The file grub.efi will be created and you can copy this to your FAT partition.

    The one remaining thing to do is create the grub configuration file.  In grub 2 this is called grub.cfg and can be put in the root directory of your FAT partition with the other three files already there.  If you've got your root file system on your second partition then the following should be enough for you to boot it:
    set timeout=0
    menuentry "Linux" {
    set root=(hd0,1)
    linux /vmlinuz root=/dev/sda2 acpi=force ro idle=halt
    initrd /initrd
    }


    This configuration requires your kernel (vmlinuz) and ram disk (initramfs or initrd) to be on the FAT partition too.   The final piece to the puzzle is to copy these files from your installed version of Linux in the second partition from the /boot directory.  With all six files in place on the FAT partition you're all set to boot the OS on the second partition.  Most recent versions of Linux should at least boot on the Joggler. However, the Joggler does have some interesting hardware which may not be optimally supported.  Hence, for the quickest out of the box working system you're still better off using a pre-built image from someone else as now you've got the thing booted the hard work is only about to begin.

    You can find a lot more of my information about the Joggler at my Joggler Index post. I also have a list of Joggler Bookmarks.