Wednesday 24 January 2018

First look at Ubuntu 18.04 or Bionic

With the date for the first 'Alpha 1' releases of the upcoming Ubuntu 18.04 code named Bionic Beaver having silently slipped by I decided to respin the latest daily build of Ubuntu MATE (20180123) using my '' script with the latest Canonical built kernel (v4.15-rc9) and try it out on the MINIX NEO Z83-4.

The command I used was: -i bionic-desktop-amd64.iso --atom -u -f 4345r6nvram.txt \
"mv /usr/local/bin/4345r6nvram.txt /lib/firmware/brcm/brcmfmac43455-sdio.txt" \
-f MINIX-Z83-4_usr_share_alsa_ucm_chtrt5645_HiFi.conf \
which includes the required files to support wifi and headphone audio (see Linux on MINIX NEO Z83-4 and Z83-4 Pro) on this specific device

The following command should work for other Intel Atom devices: -i bionic-desktop-amd64.iso --atom -u 
or this command for Intel Apollo devices: -i bionic-desktop-amd64.iso --apollo -u
although do also read Resize EFI partition to prevent any installation issues on Intel Apollo devices.

The reason for trying Ubuntu MATE is due to what might be seen as somewhat provocative 'call to arms' in their blog which highlights their various 'panel' layouts which control the look of the desktop.

The panel layout 'Mutiny' creates a surprisingly similar look and feel to Unity and is certainly worth trying if you are still unsure of the direction Ubuntu is moving to in their current releases.

Simply use 'MATE Tweak' to change the default panel to 'Mutiny' and then 'pin' applications to the panel like with Unity.

Please donate if you find my scripts useful using the following link

Saturday 13 January 2018

Running and installing Fedora on Apollo Lake devices

Because some Intel Apollo Lake devices do not have an option in the BIOS that allows booting Linux based operating systems it make using any Linux on these devices too complicated for some. Previously I've provided a script '' that can respin an official Ubuntu based ISO suitable for use and installation on Apollo Lake mini PCs. Now I've created a similar script called '' for Fedora ISOs.

At this stage the script is very simple. It respins a Fedora ISO making it bootable when used to create a LiveUSB and you can also optionally add my bootloader script which when run after installing Fedora enables subsequent booting.

When installing Fedora from a respun ISO (and as mentioned for Ubuntu) it is necessary to make sure the EFI partition is large enough to store the bootable EFI file when dual booting with Windows. Some Windows installations only create a 60MB partition which after installing the Windows EFI files leaves only around 30MB. With the later Linux kernel releases the size and number of modules have increased and the available space may not be enough. If there is insufficient space the resultant installation will not boot so the solution is to increase the size of the EFI partition first by following the instructions posted here.


Running the script is simple as there are not a lot of options at this stage:
Usage: -i <ISO> [ -b Linuxium | --apollo ] [ -w <directory> ]
If you respin an official Fedora ISO just using the '-b Linuxium' option then it will only add my  'Linuxium' bootscript to make the ISO capable of booting.

If you respin with the '--apollo' option it will add my 'Linuxium' bootscript and another script called 'linuxium-update-bootloader' which can be used to add or update my 'Linuxium' bootscript used for booting. This option also installs the 'binutils' package whch is required by the script.


At this stage I've only tested it with the Fedora 27 Workstation ISO and further testing is required for other Fedora releases and ISOs.


In the following example I have downloaded the ISO 'Fedora-Workstation-Live-x86_64-27-1.6.iso' and respun it with the '--apollo' option creating the respun ISO 'linuxium-apollo-Fedora-Workstation-Live-x86_64-27-1.6.iso' which I wrote to a USB using 'dd'.

First I booted my Apollo Lake device into Windows:

and created some free space for the Fedora installation:

Then I rebooted to the LiveUSB:

Before commencing the installation I opened a 'terminal' window to see what file systems were mounted:

I then started the installation:

After the initial question for 'Installation Destination' I selected the device's eMMC as the drive with 'Automatic' storage configuration:

I also set the host name:

and then started the install:

followed by creating a user:

making sure they were an administrator:

and then waited for the installation to finish:

But instead of clicking on 'Quit' I switched back to the terminal window:

Looking at the newly mounted file systems I made a note of where Fedora had been installed ('/mnt/sysimage'):

and what kernel version had been installed ('4.13.9-300.fc27.x86_64'):

The next step is to replace the currently installed GRUB with my bootscript generated bootable EFI file. To do this I run 'linuxium-update-bootloader' with parameters of the kernel version and target destination (as it is different to '/boot') using the values I noted above:

which creates the bootable EFI file ('shimx64.efi'):

As this now completes the installation I restarted:

and having removed the LiveUSB I booted Fedora:

and logged in:

answered the setup questions:

and started using Fedora. 

This is the resultant installed file system:

Anyone wanting to try Fedora can download an ISO and respin using my '' script with the above option.

Please donate if you find the scripts useful using the following link

Tuesday 9 January 2018

Ubuntu or Fedora?

MINIX NEO Z83-4 running Fedora 27 with Rawhide kernel
(showing working WiFi, Bluetooth and audio including headphone jack)

Three recent events have made me question whether to keep using Ubuntu as my preferred Linux distribution:

  1. Six weeks have passed since v4.15-rc1 was released and the Ubuntu config for the 'unstable' kernel still hasn't been updated to reflect the patches around the Serial Device Bus managing serial devices declared as attached to an UART in ACPI table. This prevents Bluetooth working on some mini PCs.
  2. The Ubuntu 17.10 ISO is still not available following the scramble to address the corrupted BIOS due to "Intel SPI bug in kernel" arguably actually caused by incorrectly enabling the Intel SPI drivers in the config.
  3. Canonical's slow response coupled with what appears to be a justification to adhere to previously agreed timescales resulting in their inability to immediately address the 'Meltdown' exploit. This has created a 'Window of Vulnerability' for existing Ubuntu users unaware they could temporarily upgrade to a the most recent Canonical mainline build.

The core of the problem appears to lie in the architectural approach of how kernels are adopted and released as part of the overall Ubuntu release structure. Whilst implementing Ubuntu LTS enablement (known as HWE or Hardware Enablement) stacks which provide newer kernel support for existing Ubuntu LTS releases, there is no equivalent for regular releases which are only guaranteed to receive security updates for the duration of their release life (normally 9 months for desktop and server releases). As a result the Ubuntu kernel support per se is not aligned with the mainline kernel development strategy of supporting the current release together with nominated LTS kernels.

Aside from the above points there is also the somewhat emotive issue of dropping Unity in preference for the GNOME desktop. Through dressing up GNOME to look similar to Unity by including the 'dock-to-dash' extension it inadvertently shows that changing the back-end distribution might not be so visible if GNOME is to be used especially for users reliant on a GUI.

Furthermore as I run Ubuntu 17.04 on a number of devices I have to make a 'release' decision now that Ubuntu 17.04 reaches 'end of life' on 13th January. Canonical will not be providing updated kernel packages for Ubuntu 17.04 as they will not be patching the 4.10 HWE kernel to address the Meltdown and Spectre vulnerabilities resulting in a '4.10 HWE EARLY END OF LIFE'. The consequence is that the rolling HWE kernel for Ubuntu 16.04 will go to 4.13 early.

To continue using Ubuntu on those devices I will need to either:
  • upgrade to Ubuntu 17.10 and use the GNOME desktop or gamble with 'Ubuntu Unity' as the Unity desktop in the long term, or
  • replace existing Ubuntu 17.04 instances with fresh installations of Ubuntu 16.04 and continue using the Unity desktop in the short term
or, and given my initial concerns, look for an alternative to Ubuntu.

Choosing a distributions is somewhat complex and ultimately personal however one candidate does immediately comes to mind: Fedora. Arguably not so user-friendly it is focused on leading-edge software. The principle difference between Ubuntu and Fedora is package management due to the origins of each namely Debian vs Red Hat respectively.

Becuase the ISO for Ubuntu 17.10 is unavailable and installing Ubuntu 16.04 is effectively downgrading I have made the decision to look at transitioning to Fedora. I'll start by using Fedora as a desktop for everyday use and gradually increase usage. There will be challenges ahead as Fedora 'OOTB' doesn't work on a number of mini PCs both old and new. For inspiration I've combined several well know quotes:
If things don’t change
    they’ll stay the way they are,
and if they stay the way they are
    they won't get any better,
but the more things change
    the more they stay the same.
as making things better need not necessarily make everything different. We shall see.


The target release date for respun Ubuntu 17.10 ISOs for all flavors is Thursday, January 11. These will include a kernel which fixes the "Intel SPI bug in kernel" (point 2 above).

However "Note that these images are being prepared in advance of the release of fixes for Spectre and Meltdown.  As a rule, we do not re-release install media for security bugs, even those as severe as this" [1].

Currently these respun ISOs include the Ubuntu 4.13.0-21.24 kernel rather than the Ubuntu 4.13.0-25.29 kernel which is version that includes the 'Meltdown' fix which was released yesterday Tuesday, January 9 [2].

It is difficult to understand why Canonical would respin ISOs to fix a 'bug' using a kernel that includes a highly publicized and well-known 'vulnerability' when they have released a fixed kernel.

Given the rationale is to make the Ubuntu 17.10 images available again due to the impending 17.04 EOL then maybe extend the life of 17.04 by a day or two as it is not like security matters or so it seems.

If you want an Ubuntu 17.10 ISO I believe you would be safer using respinning the current official Ubuntu 17.10 ISO [3] with: -i ubuntu-17.10-desktop-amd64.iso --upgrade \
-e "linux-image-4.13.0-16-generic linux-headers-4.13.0-16" \
-p "linux-generic linux-signed-generic" \
-p "gir1.2-gmenu-3.0 libgnome-menu-3-0"
as you would get Ubuntu 17.10 similar to the proposed respin ISO [4] together with the 'Meltdown' fixed kernel:
$ 7z x linuxium-ubuntu-17.10-desktop-amd64.iso casper/filesystem.manifest -so > \
$ wget -q \ -O - | \
  sed 's/:amd64//' | \
  diff -w linuxium-ubuntu-17.10-desktop-amd64.iso_filesystem.manifest -
< libpoppler-glib8 0.57.0-2ubuntu4.2
< libpoppler68 0.57.0-2ubuntu4.2
> libpoppler-glib8 0.57.0-2ubuntu4.1
> libpoppler68 0.57.0-2ubuntu4.1
< linux-generic
< linux-headers-4.13.0-25 4.13.0-25.29
< linux-headers-4.13.0-25-generic 4.13.0-25.29
< linux-headers-generic
< linux-image-4.13.0-25-generic 4.13.0-25.29
< linux-image-extra-4.13.0-25-generic 4.13.0-25.29
< linux-image-generic
< linux-signed-generic
< linux-signed-image-4.13.0-25-generic 4.13.0-25.29
< linux-signed-image-generic
> linux-generic
> linux-headers-4.13.0-21 4.13.0-21.24
> linux-headers-4.13.0-21-generic 4.13.0-21.24
> linux-headers-generic
> linux-image-4.13.0-21-generic 4.13.0-21.24
> linux-image-extra-4.13.0-21-generic 4.13.0-21.24
> linux-image-generic
> linux-signed-generic
> linux-signed-image-4.13.0-21-generic 4.13.0-21.24
> linux-signed-image-generic
< poppler-utils 0.57.0-2ubuntu4.2
> poppler-utils 0.57.0-2ubuntu4.1
< ubuntu-desktop 1.404
> ubuntu-desktop 1.404.1
Please donate if you find my work useful using the following link