Posts

Showing posts with the label fedora

Managing NVidia on Fedora

Linus Torvalds has previously had some very choice words to say about NVidia with regards their interaction with open source and Linux.  I've spent much of my career using (and battling with) the NVidia drivers on my Linux laptop and these are my notes that make life a little easier and better.  For me, NVidia drivers at home on a PC work pretty well.  They work less well on a laptop where things are a bit more complicated with external screens, hot plugging of screens, suspend, etc.  I've tried the open source alternatives and they really just don't work as well in terms of stability (not that I find the NVidia proprietary Linux drivers especially stable, especially on a modern desktop under Wayland) but also in terms of power management and graphical performance.  Hence, I've always concluded I'm better off running the proprietary drivers.  If it weren't for the fact that the Lenovo Laptops I use at work have their external monitor connections hard wired to the NVidia card then I would probably just turn off the GPU entirely and rely on the embedded Intel GPU.

Installation

Thankfully, this is pretty simple on Fedora due to the packaging at RPM Fusion.   Hence, I think the best way to install the NVidia driver on Fedora is to use the RPM Fusion repository, as follows:

  1. Follow the guide at https://rpmfusion.org/Configuration to install both the free and non-free RPM Fusion repositories
  2. Install the NVidia drivers (see https://rpmfusion.org/Howto/NVIDIA)

It is also best to set your GPU to "discrete only" mode in your UEFI/BIOS.

Note: there is a highly viable alternative repository that also I've run very successfully at Negativo17 and you can, of course, grab the drivers directly from NVidia via their unix downloads page.

Re-Build the NVidia Kernel Module

There are instances where manually kicking off the re-building of the NVidia kernel module can be useful. This can be done very easily as follows:

$ akmodsbuild --kernels $(uname -r) /usr/src/akmods/nvidia-kmod.latest 
$ sudo dnf reinstall <name-of-the-output-rpm-from-above>

Note that the above will rebuild the NVidia kernel module for the current running kernel. You can swap out the $(uname -r) piece of the command for the version string of any of your installed kernel modules to build for a different kernel that you have.

Suspend/Resume Stability

Create a file /etc/modprobe.d/nvidia.conf with the following content:

options nvidia NVreg_PreserveVideoMemoryAllocations=1
options nvidia NVreg_TemporaryFilePath=/var/tmp
options nvidia_drm modeset=1

These should already be on your system after installation but just in case, make sure you have the following RPMs installed by running:

$ sudo dnf install xorg-x11-drv-nvidia-power nvidia-modprobe

Ensure the nvidia suspend/resume services are enabled:

$ sudo systemctl enable nvidia-suspend.service nvidia-hibernate.service nvidia-resume.service

Note: do not enable the nvidia-persistenced.service as this can cause issues on a single GPU machine such as a laptop

Fixing graphical LUKS password prompt

Often, the installation of the NVidia driver can cause the LUKS password prompt to drop back to text mode. This isn't a problem from a functional point of view but it's not so nice to look at as the graphical prompt. If you want to restore the graphical prompt you need to ensure that the NVidia driver is built into your ram disk image. This can be achieved fairly simply, as follows:

Create a file /etc/dracut.conf.d/nvidia.conf and add these lines (note the spaces are required in the quoted strings so that's not a mistake):

add_drivers+=" nvidia nvidia_modeset nvidia_uvm nvidia_drm "
install_items+=" /etc/modprobe.d/nvidia.conf "

With that file in place, you can re-generate your ram disk image by running:

$ sudo dracut -f
Larger console font

Not strictly an NVidia related thing but while I'm on the topic of displays, on HiDPI/4k laptop screens, the console font (seen during the boot process if things go wrong) can be nearly impossible to read as it's far too small. You can resolve this issue by switching your console font to a larger font size.

First, make sure you have the relevant console font(s) installed:

$ sudo dnf install kbd-misc

Next, edit the file /etc/vconsole.conf and change the "FONT=" line to a larger font e.g.

FONT="latarcyrheb-sun32"


Post a Comment
Read more

Gnome Extensions

With the current release of Fedora Linux being updated to version 40 this week, I find myself upgrading to it on the first day of release (rare for me, I usually wait a couple of months) and getting up-to-speed with the changes in Gnome 46.  My previous post about Gnome focused on my migration to Gnome 3 and the extensions I was using at the time.  During the course of the previous (nearly) 5 years, these have changed quite significantly as the Gnome desktop has grown and as my usage of it has moved on.  Hence, rather than update my old post as I have done in previous years, I thought it time to write a whole new post focusing on how I set up my Gnome desktop today.

So without further ado, this is the list of extensions I'm using right now as I write this post (in alphabetical order):

AppIndicator and KStatusNotifierItem Support

This is one of the few extensions that has stood the test of time with my particular usage of Gnome.  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). 

Dash to Panel

This is a more recent discovery for me.  I've previously evaluated Dash to Dock several times and never liked the user experience.  However, the similarly named and with somewhat similar functionality, Dash to Dock has replaced my use of the Window List extension.  It provides a more modern alternative to showing which windows I have open with window previews and suchlike.  It can do considerably more than the way I've configured it, but I have it set just how I like to work with my Gnome top bar still in tact and a minimal bottom bar used for navigating between my open applications.  If you want to try it out with my configuration, I've exported my settings into this GitHub Gist that you can import.

Frippery Panel Favourites

It takes your favourited applications and adds them as a set of icons to the Gnome top panel, making for extra quick access to your commonly used apps.  I tend to flip between using this and just searching for apps via the Super button (windows key).

GTile
This great little extension 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.  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.  It strikes a great balance for me as someone that generally prefers to tile windows but doesn't like a tiling window manager.

Hide Activities Button

This is almost a little bit superfluous for my usage but I found myself never using the activities button (top left) in the Gnome Panel.  The Dash to Panel configuration I have created maintains an activities button (bottom right) which is the place I've grown familiar with in order to use my GUI to switch between desktops (although I generally switch between desktops using keyboard shortcuts).

Pano Clipboard Manager

This is a really great modern take on the clipboard.  Press shift+windows+v and you get a pop up at the bottom of the screen with a graphical representation of your clipboard history.  The extension is clever enough to be aware of various types of clipboard content such as text, images or hyperlinks.  You also get a button on the top panel that allows access to the clipboard, incogneto mode (stops copying stuff to the extension) and settings.

System Monitor Next

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.

Post a Comment
Read more

New Thinkpad P15


This post continues a long running tradition and series of posts when I'm issued a new laptop at work.  I generally get quite a powerful and interesting machine as I'm a member of the IBM Hursley development laboratory and thus am issued a fairly beefy specification for a majority of desktop use rather than being a more mobile laptop.  I'm issued a new machine approximately every four years so my previous posts are about my:

It's interesting to see how the specification of machine has changed over time.  With the slowing (or disappearance) of Moore's Law, the speed advantage of more recent machines has come from other innovations (such as an SSD and an increased number of cores) rather than raw clock speed.  The highlight specifications for the P15 Gen 1 I have are...

  • Intel(R) Core(TM) i7-10750H CPU @ 2.60GHz (5199.98 bogomips in Linux)
  • 32GB DDR4 2933MHz
  • Toshiba 512GB SSD XG6 M.2 2280
  • 15.6" 3840 x 2160 IPS (non touch)
  • Integrated Li-Po 94Wh battery
  • Wi-Fi 6
  • NVidia Quadro T1000M 4GB
  • Front Facing Web Cam, HDMI Out, Headphone, 2x USB3.2, 2x USB-C3.2 Gen 2, GBit Ethernet, Fingerprint Reader, SD card reader

There we have it, the top level specs aren't all that different to the 4 year old P50 machine I had previously.  In fact the CPU speeds have dropped slightly although the P15 does have 12 cores to the P50's 8. RAM and GPU memory have both stayed the same and I still have a 512GB SSD.  Interestingly, the battery is now integrated which has moved away from the long standing removable battery on these top line Thinkpad machines.  There's a huge increase in the screen resolution and I dare say the screen would also have been improved in areas such as peak brightness (600 nits for the P15) and support for Dolby Vision HDR (there's also support for Dolby Atmos sound which will be a bit lost on me for a business machine).  While sounding good, if you put a 4k resolution onto a 15" laptop screen you pretty much need a magnifying glass to see anything so it's more or less useless unless you're consuming 4k video content.  No wonder then that the Gnome desktop defaulted to running in 4k mode but at 200% scale (which I think takes it back down to HD size unless I'm mistaken).

The day-to-day running of the new machine has been pretty good.  Not noticeably different to that of the old machine. This goes to show the lack of improvement in specifications of these new machines in general.  It's something I've noticed with my ageing home machine as well (which is nearly 10 years old) where the processor benchmarks are very similar to today's processors on a core-for-core comparison and I still have things like a decent PCI 3 bus.  It's always nice to have a bit of a refresh though and the thing I'm liking most about the new machine is the addition of the built-in fingerprint reader.  This particular piece of hardware is now fully supported on Linux and very easy to configure using the Gnome settings tool.  It makes logging in with a massive password much less painful.  I hope more apps (such as 1password) will eventually find ways of integrating biometric security on Linux as well.  It's worth noting that this functionality hasn't come at all by accident and has been a lot of hard work and a long road between both Red Hat and Lenovo to ensure that all new Lenovo laptop machines are fully certified to have a hardware configuration that contains drivers and firmware compatible with Linux.

There are, of course, teething troubles with the new machine.  These are mostly related to graphical issues and NVidia.  More recently, I'd taken for granted my old machine just working in these respects.  My old machine had similar teething issues when it was new of course and these were gradually ironed out with driver updates as time progressed.  So right now it's weird to be back in the dark days of having to use the NVidia settings panel to configure the screen resolutions I want as for some reason the binary driver is only showing up the full 4k resolution to xrandr under Linux (yes I'm still using Xorg, not Wayland, yet).  It's also a bit fragile in terms of going into sleep mode and resuming from sleep, it all works but there can be graphical glitches (sometimes and sometimes not) which I may need to restart the gnome shell to cure (Alt+F2 then type r and hit Enter).  While this is frustrating for now, I'm fully expecting driver updates to catch up and this machine will gradually settle down into the same level of graphical performance I was used to on my old machine i.e. no problems at all and no need to open up NVidia settings.  Perhaps the thing that surprises me most about all this though is the very fact that all of this has regressed.  I'm no expert in the graphical stack on Linux but it's rather unfortunate that I seem to experience the same pains and teething problems upon the issue of every new laptop.  It'll all get there.  One day!

Post a Comment
Read more

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
    8 comments
    Read more

    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.
    10 comments
    Read more

    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!
    Post a Comment
    Read more

    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.
    3 comments
    Read more

    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.



    Post a Comment
    Read more

    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.
    Post a Comment
    Read more

    Upgrading Fedora 12 to 13

    I'm pleased to report that after problems upgrading from Fedora 10 to 11 and minor issues upgrading Fedora 11 to 12 that I've finally had a no problem upgrade from Fedora 12 to 13 on my home machine.

    I have only a very slightly unusual setup in that I've got Fedora running on top of a hardware RAID environment which has caused some issues with preupgrade in the past. Upgrades I have tried on other equipment such as my work laptop have always been flawless and now it seems the issues with RAID installs have gone away too.

    So this brings to an end my blog trilogy about upgrading Fedora, short and sweet, it just works! Now onwards to enjoy using a great new distribution that's pushing the boundaries in pretty much every area of Linux usage. Thanks to the Fedora team, Goddard looks fab.
    Post a Comment
    Read more

    Upgrading Fedora 11 to 12

    After writing recently about my previous upgrade experience, it seems fair to report my latest upgrade experience going from F11 to F12 using pre-upgrade on the same machine at home.

    Everything progressed very smoothly, even more so than last time as I'm pleased to report the bug I had written about is now fixed. Fedora now detects hardware raid devices and employs the correct work-around solution to ensure the upgrade proceeds unhindered. So far so good then and I thought I would be sailing through to another smooth upgrade. However, it appears even at Fedora 12 level there are still some small issues as it proved later in the upgrade process.

    This time the upgrade was smooth right through to the end of the upgrade process, after all the packages had been installed. Just as the bootloader config was being adjusted I was presented with a rather user-unfriendly Python stack trace with an "unhandled exception" error. By switching to another console I was able to work out the upgrade had in fact completed successfully all except for the final adjustments to the grub menu and removing the pre-upgrade cache. I reported this behaviour in a new Red Hat bugzilla bug report and have been informed this bug has already been fixed upstream in Fedora development and should not occur in pre-upgrade F12 to F13, lets wait and see.

    So it seems the pre-upgrade path for slightly more complicated configurations such as the one I have at home is finally starting to look good. I'm slightly disappointed it's still not quite there yet though but all things considered this was another smooth upgrade and one which someone less informed about Linux might be successful.
    Post a Comment
    Read more

    Upgrading Fedora 10 to 11

    Writing on the day of the scheduled release of Fedora 12 it might seem strange to be talking about two previous versions. However, I thought I would take stock briefly looking over my shoulder before moving forward with the very latest and greatest.

    I upgraded both my home machines shortly after F11 was eventually released in early June after I had been tweeting about it for some time. Aside from a small problem with my main machine at home, both upgrades progressed seamlessly with the Fedora pre-upgrade tool. I'm a bit more conservative with my main work laptop usually staying 3 months behind the latest release, after eventually finding time to upgrade I've been running F11 on my laptop very smoothly for over a month now.

    The issue I had upgrading my home machine was related to the fact my boot partition is on a (hardware) RAID device. It appears there is a bug in pre-upgrade in this area which I found out after a rare question to the fedora forums. In my experience pre-upgrade is pretty decent these days but beware that it still has some pitfalls such as this!

    After pre-upgrade finishes your box reboots, in this case taking you from your F10 desktop to F11. All in all I've noticed very little difference between the two versions which raises some interesting questions for me, basically summarised by "What's the point in upgrading?". Having noticed very little difference after the upgrade this may well be a question many less experienced users ask too. On F10 my laptop worked flawlessly, I had compatibility with all the apps I need, accelerated 3d graphics with RandR 1.2 support (for easily switching between display devices), printing and some of the more traditionally contentious Linux functionality worked perfectly, namely wireless and suspend. F11 was exactly the same after my first boot into the system, flawless.

    So what, indeed, is the point in an upgrade such as this? For me, I like to stay near (but in the case of my main machine not on) the bleeding edge of development. The upgrade for me was all about getting a few little extras in the Kernel (namely support for hard disk parking which I've not yet played with, and better web cam support) as well as all the little feature additions and bug fixes you get with every library and app you use on your box. The main point though, and the clincher, is that the upgrade process SHOULD be this smooth; these things SHOULD happen without causing any new problems while fixing as many old problems as possible. I'm glad to say F10 to F11 did work like this, it was a breeze, Fedora are getting this right and long may it continue.
    Post a Comment
    Read more

    Byebye Ubuntu, Hello Fedora

    My recent experiments with installing Ubuntu on my little home server came to an end this weekend. I'm working hard to debug problems with my media streamer software, SqueezeCenter. After finding tons of forum posts and various problems with installing SqueezeCenter on Hardy Heron I decided to try another approach so I'm now running Fedora 9 at home instead. Both Hardy and Fedora 9 are supposed to be supported by Slim Devices for their Squeeze-stuff. However, it appears neither of these work but I'll save that rant for another day once I've worked out what's wrong (I have my suspicions about Slim Devices testing against Perl 5.10).

    I'm actually quite relieved to be back in my comfort zone with Fedora at home again. I really enjoyed the experience of playing with Ubuntu but it's just not for me for various reasons...

    I've met quite a few Canonical guys in my professional role and they've all been great; helpful, very approachable and in the case of some, such as Jono Bacon very decent techies too. That's not my experience with non-Canonical Ubuntu contributors though. I found if the Ubuntu documentation (which is excellent for pretty much everything before Hardy Heron right now) failed me, then talking to the community was not a good experience. I found I was met with an abrupt RTFM attitude in most instances, where the assumption of the community is that people asking questions are dumb. Personally, I blame this on the typical Ubuntu user being non-technical where Linux is concerned so I guess the community receive lots of silly questions which must get annoying at times. All that said, I still believe Ubuntu is really important and plays an extremely valuable role in trying to bring Linux to a more mass audience.

    I also found Hardy to be down level in various instances compared with the packages available in Fedora 9. The big one for me here, on my little server, is the OpenChrome drivers for the graphics chipset. Fedora have the version that supports my chipset, but when I asked about inclusion in Ubuntu there was no interest in updating the down level version in their repositories. I also enquired about the broken Via proprietary driver in Ubuntu which resulted in the Via driver being marked for removal! So rather than update the open drivers or fix the package for the proprietary drivers, the response was to remove the proprietary one and not update the open driver which left me in a position of manually maintaining my own graphics driver until the next major Ubuntu release.

    I've used RPM and yum way more than I have deb and apt so I sway towards the former simply through familiarity. Having the chance to play with debs again recently has been great too, there's some nice additional touches you don't get with RPM such as the suggested packages and the ability to remove dependencies installed with a certain package, etc. Ubuntu have done a nice job of packaging this all up with Synaptic too. Aside from those few nice-to-haves I don't really see any other advantages to the Ubuntu system, yum and RPM would do exactly the same job when fronted by Synaptic but as ever in the world of open source having choice and competition is good.

    Hiding root from the general user is a decent idea too, no need for that confusion in a simple desktop environment, and makes it feel a little closer to what people expect from a Windows box.

    Gnome is the desktop of choice for both mainstream Ubuntu and for Fedora so I've been going with that recently instead of my usual choice of KDE. I've been really impressed with Gnome too, for a simple desktop environment it's fantastic but I know if I were to use it every day there would be some features and tools I use regularly under KDE that I would dearly miss. However, I think I've been converted for home use over to Gnome, particularly as KDE is going through turbulent times with their version 4 releases right now. Having everything written in one toolkit is really nice, you can't avoid running GTK and QT apps under KDE but at least under Gnome you have the option of not running QT and sticking with the same look and feel everywhere.

    I hope I managed to stabalise on one distribution soon so SqueezeCenter actually works, I get the feeling that will likely be Fedora 8 in the short term until Slim Devices get their act together for Perl 5.10 if my current thoughts are correct. So for now at least it's goodbye to Ubuntu until the next time I give it a run somewhere.
    2 comments
    Read more