Tuesday, 29 September 2020

Canonical have announced a new point release for Ubuntu 16.04 LTS - 16.04.7 (Xenial Xerus)

Canonical have released the sixth point release of Ubuntu 16.04 Long-Term Support (LTS) as Ubuntu 16.04.7.

I’ve respun the desktop ISO using my ‘isorespin.sh‘ script and created ISOs suitable for Intel Atom and Intel Apollo Lake devices:

Atom (-i ubuntu-16.04.7-desktop-amd64.iso --atom)
Apollo (-i ubuntu-16.04.7-desktop-amd64.iso --apollo)


Downloading Note

After downloading an ISO file it is recommended to test that the file is correct and safe to use by verifying the integrity of the downloaded file. An error during the download could result in a corrupted file and trigger random issues during the usage of the ISO.

The program 'md5sum' is designed to verify data integrity using the MD5 (Message-Digest algorithm 5) 128-bit cryptographic hash. The MD5 calculation gives a checksum (called a hash value), which must equal the MD5 value of a correct ISO.

First open a terminal and go to the correct directory to check a downloaded ISO. Then run the command 'md5sum <ISO>' for example:
md5sum linuxium-atom-ubuntu-16.04.7-desktop-amd64.iso
'md5sum' should then print out a single line after calculating the hash:

e1c5c463c3d2078f7a26d65472b59973  linuxium-atom-ubuntu-16.04.7-desktop-amd64.iso

Compare the hash (the alphanumeric string on left) from your output with the corresponding hash below. If both hashes match exactly then the downloaded file is almost certainly intact. However if the hashes do not match then there was a problem with the download and you should download the file again.


ISO 'md5sum' hashes

e1c5c463c3d2078f7a26d65472b59973  linuxium-atom-ubuntu-16.04.7-desktop-amd64.iso
ee3367e767d2c0938cc12776d5cf288d  linuxium-apollo-ubuntu-16.04.7-desktop-amd64.iso


Please donate if you find these ISOs useful.

Saturday, 26 September 2020

'BootHole' implications for 'isorespin.sh'

 

(Credit: https://eclypsium.com/2020/07/29/theres-a-hole-in-the-boot)

When it was discovered that GRUB2 contained various vulnerabilities that would allow UEFI Secure Boot to be bypassed and which became known as the “BootHole” vulnerability (CVE-2020-10713), the recommendation was that all operating systems using GRUB2 with Secure Boot must release new installers and bootloaders. 

I reviewed 'isorespin.sh' at that time as one of it's key features is the option to add a GRUB2 bootloader to allow ISOs to boot on the many Intel devices limited by their BIOS requiring a 32-bit bootloader to boot a 64-bit OS.

My initial 'fix' was based around Ubuntu's response by recompiling and adding the latest fixed GRUB2 bootloader from 'groovy' (Ubuntu 20.10) and let the Ubuntu package manager 'apt' install the appropriate GRUB2 binaries to the ISO whilst being respun.

This initially worked, however after receiving what can only be described as some abusive 'hate' email from a user complaining that 'isorespin.sh' fails when installing the 32-bit binaries, I investigated and found that Canonical had effectively removed the earlier 32-bit GRUB2 packages with vulnerabilities.

The original 'isorespin.sh' process was to download the 32-bit GRUB2 packages whose version matched the 64-bit GRUB2 packages in the ISO and update the relevant package file with the details of these packages. However in Canonical's process when a package is replaced by a newer version at some point older versions get archived so the 'isorespin.sh' download process needs to perform the download from the archive location. At this point the package information is still typically available in the package manager's cache so it is still possible to update the relevant package file.

But in order to add the other functionality in 'isorespin.sh' such as updating the kernel or installing a package as part of respinning an ISO it is also necessary to update the package manager's cache. The issue that "BootHole" subsequently created for 'isorespin.sh' was that because the cache was now updated, the earlier versions of the GRUB2 packages with the vulnerabilities were (obviously) no longer included to prevent them from being selected and installed. The consequence was that because the downloaded earlier versioned 32-bit GRUB2 packages were no longer supported, when they were further processed either by 'isorespin.sh' or as part of ISO installation, errors occurred.

Part of the problem in fixing these errors was wanting to mimic the original ISO's ability to be installed either with or without a network connection and also address the "BootHole" vulnerability as part of respinning the ISO. A new issue was encountered because by simply downloading the latest and therefore fixed 32-bit GRUB2 packages left their package dependencies untouched. This leads to package incompatibility when trying to install these later versioned packages.  

To address this I've made the decision to continue to download the 32-bit GRUB2 packages whose version matches that of the ISO thereby keeping the integrity of the ISO. However in recognising that any package in the ISO's pool structure could be superseded by security updates I also then ensure that all of the pool packages are updated to their respective current version at time of respinning the ISO. This also means that their versions are reflected in the ISO's package manager's cache. Finally to correct the GRUB2 package dependencies I also update any GRUB2 packages currently installed in the ISO's filesystem.

Whilst this addresses the vulnerabilities caused by "BootHole" it does mean that if the Ubiquity installer installs other packages from the pool structure it may still result in package dependency issues. The workaround if this occurs is to either individually update the affected packages when respinning the ISO or use the '--dist-upgrade' option to upgrade all installed packages.

This newest version (8.6.4) is now available from 'isorespin.sh'. 

Please donate if you find the script useful using the following link http://goo.gl/nXWSGf as everything helps with development costs.


Friday, 4 September 2020

Canonical announces new point releases - Ubuntu 20.04.1 and 18.04.5


Canonical have released both the first point release of Ubuntu 20.04 Long-Term Support (LTS) as Ubuntu 20.04.1 and the fifth point release of Ubuntu 18.04 Long-Term Support (LTS) as Ubuntu 18.04.5.

I’ve respun the desktop ISOs using my ‘isorespin.sh‘ script and created ISOs suitable for Intel Atom and Intel Apollo Lake devices:

Atom (-i ubuntu-20.04.1-desktop-amd64.iso --atom)
Apollo (-i ubuntu-20.04.1-desktop-amd64.iso --apollo)
Atom (-i ubuntu-18.04.5-desktop-amd64.iso --atom)
Apollo (-i ubuntu-18.04.5-desktop-amd64.iso --apollo)

I've also respun the 'Focal Fossa' desktop ISO with the '--server' option to create a pseudo server ISO suitable for Intel devices with a 32-bit bootloader:

Server (-i ubuntu-20.04.1-desktop-amd64.iso --server)

Also announced are the official 20.04.1 flavours of Ubuntu including Lubuntu which I've also respun to created an ISO suitable for Intel Atom devices:

Atom (-i lubuntu-20.04.1-desktop-amd64.iso --atom)


Downloading Note

After downloading an ISO file it is recommended to test that the file is correct and safe to use by verifying the integrity of the downloaded file. An error during the download could result in a corrupted file and trigger random issues during the usage of the ISO.

The program 'md5sum' is designed to verify data integrity using the MD5 (Message-Digest algorithm 5) 128-bit cryptographic hash. The MD5 calculation gives a checksum (called a hash value), which must equal the MD5 value of a correct ISO.

First open a terminal and go to the correct directory to check a downloaded ISO. Then run the command 'md5sum <ISO>' for example:
md5sum linuxium-atom-ubuntu-20.04.1-desktop-amd64.iso
'md5sum' should then print out a single line after calculating the hash:

5157b92b64ac5a9a0b69c8d27888c739  linuxium-atom-ubuntu-20.04.1-desktop-amd64.iso

Compare the hash (the alphanumeric string on left) from your output with the corresponding hash below. If both hashes match exactly then the downloaded file is almost certainly intact. However if the hashes do not match then there was a problem with the download and you should download the file again.


ISO 'md5sum' hashes

5157b92b64ac5a9a0b69c8d27888c739  linuxium-atom-ubuntu-20.04.1-desktop-amd64.iso
58b349bc95ac9f545a9480eda410b9f1  linuxium-apollo-ubuntu-20.04.1-desktop-amd64.iso
9b460cbc70020f117217bf96385d7a3f  linuxium-atom-ubuntu-18.04.5-desktop-amd64.iso
8231e6792cc3c8eed61dbe9b47563dc4  linuxium-apollo-ubuntu-18.04.5-desktop-amd64.iso
58b65aca1795562cf16471a45cdf35c8  linuxium-ubuntu-20.04.1-server-amd64.iso
d7fb5c40db10b100b2ad0428a1ff0dcf  linuxium-atom-lubuntu-20.04.1-desktop-amd64.iso


Please donate if you find these ISOs useful.

Saturday, 27 June 2020

Demonstrating the usage of 'ISO' tools with a real-life example

This is the final of three posts about my 'ISO' tools that include 'isorespin.sh', 'isocomparepkgs.sh' and 'isomimicpkgs.sh' scripts and in it I will demonstrates their usage with a worked example.

The example is about a testing PC that is currently running Ubuntu 18.04 LTS and now that Ubuntu 20.04 LTS has been released I'm considering how to upgrade it.

Normally Ubuntu does not prompt you to upgrade until the first point release becomes available (in this case 20.04.1) so in theory I could use the interim to plan however I want to upgrade now.

I'm considered two approaches to perform the upgrade. The first is the accepted way of upgrading where you simply run a command or use the Ubuntu update manager and upgrade the currently installed Ubuntu (i.e. 18.04 to 20.04). The second approach is arguably more of a migration where you backup your data then install a clean Ubuntu 20.04 and then restore your data which despite semantics is still effectively upgrading from 18.04 to 20.04.

Canonical provide good documentation on how to perform upgrades (e.g. How to upgrade from Ubuntu 18.04 LTS to 20.04 LTS today) however one point that must not be overlooked is whether your upgraded system will still have the same functionality of your existing one.

Like most users besides the applications or packages provided by the base installation I've also added packages and an upgrade will likely affect them. Unfortunately some packages are tied to a release version so maybe unavailable in a new releases or unsupported at best.

When you perform a upgrade traditionally you would remove obsolete packages in order to get a clean system and in part that is why planning for an upgrade is necessary.

The alternative approach of restoring your data after a fresh install also isn't just that simple as besides restoring your data you then need to install all the packages you added to the previous release albeit bearing in mind that not all packages may be available.

One key issue you face with the second approach is knowing what packages you have currently installed and of them which were manually installed subsequent to the initial base installation.

Looking at the second approach first, lets start by identifying the packages that will be required to be additionally installed.

On Debian and other dpkg-based distributions which includes Ubuntu you could try running the following command to gather this information:

grep " install" /var/log/dpkg.log

However this only works if the log file hasn't been rotation in which case you need:

grep " install" /var/log/dpkg.log /var/log/dpkg.log.1

But again this isn't that simple as older log files get compressed and worse still eventually deleted by log rotation (take a look at your '/etc/logrotate.d/dpkg' file) so it can't be used as a way to give you the entire history of your system.

As a simple alternative you can use my 'isocomparepkgs.sh' to compare the packages currently installed with those included in the installation ISO.

First I need to find out which ISO was used for the initial install as looking at '/etc/os-release' will only show the current version (in my case 18.04.4). Looking at '/var/log/installer/media-info' shows the release version (mine was 18.04) and release date (20180426). This indicates that the installation was done from the 'ubuntu-18.04-desktop-amd64.iso' ISO and this can be confirmed by comparing with the ISO's '.disk/info':

if [ "$(cat /var/log/installer/media-info)" == \
     "$(7z x -so ubuntu-18.04-desktop-amd64.iso .disk/info)" ]; then \
        echo is the ISO
else
        echo not the ISO
fi

However since its installation multiple 'apt upgrade' commands have upgraded my system from 18.04 to 18.04.4 so to ensure I make a true comparison I should first use 'isorespin.sh' to upgrade an 18.04 ISO the same way (as remember that point releases also introduce the HWE stack so an upgraded 18.04.4 is not exactly the same as a release 18.04.4 ISO).

Therefore I need to first simulate the elapsed upgrades with:

isorespin.sh -i ubuntu-18.04-desktop-amd64.iso -b GRUB-64 --dist-upgrade


after which I renamed the resultant ISO as 'dist-upgraded-ubuntu-18.04-desktop-amd64.iso' and then compare with my existing system:

isocomparepkgs.sh dist-upgraded-ubuntu-18.04-desktop-amd64.iso

The resultant 'isocomparepkgs.log' contains a list of packages that are only locally installed:


Even now it is not that simple as the list of packages is very long as it includes package dependencies including libraries but at least I have a list which could be used for the second approach.

This is where 'isomimicpkgs.sh' comes in useful. It will take that long list of packages and try and identify which core packages would achieve the same result if installed using 'apt' from Ubuntu sources as well as identifying those which require manual installation. So it is just a simple question of running:

isocomparepkgs.sh dist-upgraded-ubuntu-18.04-desktop-amd64.iso

and the log file shows:


A point to note here is that at some stage during using Ubuntu 18.04 I installed the 'lxde' package and later purged 'youtube-dl'. It also looks like a package dependency changed with respect to PHP as if I follow the suggested purge command exactly then I will also remove a package I want to keep ('phoronix-test-suite') again because of package dependencies (see my documentation on 'isomimicpkg.sh' for more details).

Another observation to make here is that three packages were identified as requiring manually installation.

So after verifying and running the appropriate 'apt install' and 'apt purge' commands I then renamed the resultant ISO as 'localised_18.04.iso' which is an ISO that effectively reflects my current environment (less chome, megasync and xnview).

Therefore if I was to adopt the second approach to upgrading from 18.04 to 20.04 I could use these two 'apt' commands as a basis of what to install over a clean 20.04 installation. Obviously some packages like 'linux-headers-4.15.0-99-generic' are not required whereas others like 'edid-decode' I may decide I no longer require and some packages like 'phoronix-test-suite' are just not available. But at least it is a starting point.

However the first approach was to upgrade 18.04 using the command line. Now that I have an ISO that mimics my current environment I can install this on a separate test box, run the upgrade and observe what happens without the need of lengthy data backups or restores. This way I can see what happens during the upgrade.

Or I can manually upgrade this ISO. However because of 'snaps' not working in an 'chroot' environment the upgrade is slightly more convoluted.

First I need to replace the 'bionic' repositories with the 'focal' ones:

isorespin.sh -i localised_18.04.iso -b GRUB-64 -r "--remove deb http://archive.ubuntu.com/ubuntu/ bionic main restricted" -r "--remove deb http://security.ubuntu.com/ubuntu/ bionic-security main restricted" -r "--remove deb http://archive.ubuntu.com/ubuntu/ bionic-updates main restricted" -r "deb http://archive.ubuntu.com/ubuntu/ focal main restricted" -r "deb http://security.ubuntu.com/ubuntu/ focal-security main restricted" -r "deb http://archive.ubuntu.com/ubuntu/ focal-updates main restricted"

after which I rename the resultant ISO as 'interim_first_localised_pseudo_20.04.iso'. Then in theory I could perform a 'dist-upgrade' on this ISO however this fails due to a problem with the 'texlive-binaries' package. So instead I purge that package and then perform the upgrade:

isorespin.sh -i interim_first_localised_pseudo_20.04.iso -b GRUB-64 -e texlive-binaries --dist-upgrade

creating a new ISO I call 'interim_second_localised_pseudo_20.04.iso' and renaming the log file as 'interim_second_localised_pseudo_20.04.iso.isorespin.log'. I then add back in packages removed as a result of '-e texlive-binaries' with:

isorespin.sh -i interim_second_localised_pseudo_20.04.iso -b GRUB-64 -p '"'$(sed -n '/The following packages will be REMOVED/,/The following NEW packages will be installed/p;/The following NEW packages will be installed/q' interim_second_localised_pseudo_20.04.iso.isorespin.log | sed '1d;$d;s/\*//g' | xargs | sed 's/libsynctex1 //' | sed 's/libtexlua52 //')'"' --debug

which is a command derived through trial and error as a couple of the packages must be excluded in order to successfully add back the packages. I rename the final ISO as 'localised_pseudo_20.04.iso'.

At this point I can now mimic a standard Ubuntu 20.04 ISO from this localised pseudo 20.04:

isomimicpkgs.sh localised_pseudo_20.04.iso ubuntu-20.04-desktop-amd64.iso

to give me the 'apt' commands to create a localised Ubuntu 20.04 ISO from the localised pseudo Ubuntu 20.04 ISO:

$(grep "^isorespin.sh" isomimicpkgs.log | head -1) --debug
isorespin.sh -i linuxium-ubuntu-20.04-desktop-amd64.iso -b GRUB-64 -e "libxfce4util-bin python3-pyxattr rtmpdump youtube-dl"

which I triumphantly name 'localised_20.04_from_pseudo_20.04.iso'.

Finally I can compare this 'localised_20.04_from_pseudo_20.04.iso' with the earlier 'localised_pseudo_20.04.iso' to shows me the new packages installed as part of Ubuntu 20.04 and the packages I loose as part of the upgrade:


and importantly for me this includes loosing 'phoronix-test-suite'.

This still leaves me the option of manually installing my mimic'ed Ubuntu 18.04 testing environment and performing the upgrade the official Ubuntu way.  However before doing this I want to make sure that I create the most similar environment as possible prior to the upgrade so first I capture the full list of installed packages on Ubuntu 18.04 with:

dpkg-query -Wf '${db:Status-Abbrev}${Package}\n' | grep '^ii' | awk '{print $2}' | sort > source_locally_installed_packages.18.04

Now I can install my 'localised_18.04.iso' on the separate test box. Once installed I need to examine the installation log as 'ubiquity' (Ubuntu's installer) removes some packages it believes are not required:

grep -i removed /var/log/installer/syslog

and I need to re-install them with:

sudo apt install apt-clone cifs-utils dmeventd dpkg-repack gparted grub-efi-amd64 kpartx lvm2 python-crypto python-ldb python-samba python-tdb qt5-gtk-platformtheme qttranslations5-l10n samba-common samba-common-bin

I also need to remove any packages added by 'ubiquity' so I compare the output of running a 'dpkg-query' with the previous 'source_locally_installed_packages.18.04' output and see that I need to:

sudo apt purge grub-pc-bin

As a check I can then compare the 'localised_18.04.iso' with newly locally installed packages using:

isocomparepkgs.sh localised_18.04.iso

which confirms that I have successfully replicated the environment:



Now I can perform the upgrade with

(Alt+F2) update-manager -c -d



As I perform the upgrade I am given the opportunity to monitor what will happen:



and make important decisions:



Once complete I can then mimic the resultant environment to a standard Ubuntu 20.04 ISO with:

isomimicpkgs.sh ubuntu-20.04-desktop-amd64.iso

creating a final 'localised_20.04.iso'.

I can then compare this ISO with the ones created earlier (i.e. 'localised_pseudo_20.04.iso' and 'localised_20.04_from_pseudo_20.04.iso') and see more implications and effects of upgrading for use in my final planning of which approach to use and what information I need to successfully upgrade my testing PC from Ubuntu 18.04 to 20.04.

Hopefully this worked example show the usefulness of my 'ISO' tools and how they can be applied to everyday problems rather than just being used to boot Ubuntu on a 32-bit device.

Please donate if you find the scripts useful using the following link http://goo.gl/nXWSGf as everything helps with development costs.

Friday, 15 May 2020

How to create an ISO that mimics the installed packages from an ISO or those locally installed using 'isomimicpkgs.sh'

This is the second of three posts introducing a couple of new 'ISO' tools that I've developed to complement my 'isorespin.sh' script.

The second tool is 'isomimicpkgs.sh' which is a script to compare installed packages in two Ubuntu (or Ubuntu flavour), Linux Mint, neon, elementary, BackBox or Peppermint desktop ISOs or Ubuntu live server ISOs, or one such ISO with locally installed packages and identify which packages need to be added to the second ISO to mimic the first ISO or added to the first ISO to mimic those locally installed. In otherwords it will show how to update an ISO with either the packages found in another ISO or with those locally installed.

For example, say you want to create a test enviroment with the same packages as those locally installed. Normally you would install the same Ubuntu release ISO and then install the packages one by one in order to replicate the enviroment. However this is not so simple when you have a lot of packages installed.

You can start by finding the ISO that was used for the initial install by looking at the contents of the file '/var/log/installer/media-info':

linuxium@LINUXIUM:~$ cat /var/log/installer/media-info 
Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426)linuxium@LINUXIUM:~$ 
linuxium@LINUXIUM:~$

Next you can search through the 'apt' history files looking for entries showing an application installation:


See how the highlighted entry shows the package installed together with the dependent packages that were automatically installed at the same time.

However this will not show any packages that were installed using 'dpkg' or by a tool like 'gdebi'. To see all the packages we can look at '/var/log/dpkg.log' however the 'package -> dependent package' relationship is somewhat lost:


Finally these logs do not last for ever as they are rotated to save space as defined by their respective configuration files:


So one solution to the problem of creating a duplicate test environment would be to use 'isocomparepkgs.sh' to establish which packages were locally installed and not part of the original ISO and then respin the original ISO adding these packages. Except that in a more complex environment this can become a somewhat unrealistic alternative :


Which finally leads me to my other tool: 'isomimicpkgs.sh'.

        linuxium@LINUXIUM:~$ isomimicpkgs.sh
        Usage: isomimicpkgs.sh <target ISO>
   
        or: isomimicpkgs.sh <source ISO> <target ISO>
        linuxium@LINUXIUM:~$

The usage syntax is straightforward: you either run the script against two ISOs to see how to mimic the package of those installed in the source ISO to the target ISO or you run the script against an ISO to see how to mimic the locally installed packages to that ISO.

In the example we have been using so far you would run the command:
isomimicpkgs.sh ubuntu-18.04-desktop-amd64.iso
The resultant output looks like this:


The tool first identifies those local packages that need to be installed manually as they are not Canonical packages (e.g. 'google-chrome-stable', 'megasync' and 'xnview').

The tool has then simplified the number of packages that were needed to be installed down from 698 to 102 by attemting to reverse engineer the package dependencies and determine a minimum set of packages that obtains the same result.

However as a result it has highlighted some packages that then also need to be removed (or purged), either because they had been previously removed since original installation (for example 'youtube-dl') or due to a dependency issue (in this case it is actually 'php7.2-gd'). Therefore rather than simply removing all the identified additional packages as there could be consequencies because of package dependencies it is advisable to check each one individually first. This is best achieved by respinning the intermediate ISO using the '--interactive' option. For example:


The resultant ISO can then be compared with the locally installed packages to verify that we have successfully mimicked the local environment:


In the final post of this series I will demonstrate the usage of my 'ISO' tools in a real-life example.

The initial release of 'isomimicpkgs.sh' can be downloaded from here.

Please donate if you find the script useful using the following link http://goo.gl/nXWSGf as everything helps with development costs.


Saturday, 9 May 2020

Comparing packages between ISOs or between an ISO and those locally installed using 'isocomparepkgs.sh'



This is the first of three posts introducing a couple of new 'ISO' tools that I've developed to complement my 'isorespin.sh' script.

The first tool is 'isocomparepkgs.sh' which is a script to compare installed packages between two Ubuntu (or Ubuntu flavour), Linux Mint, neon, elementary, BackBox or Peppermint desktop ISOs or Ubuntu live server ISOs or between one such ISO and the locally installed packages on the system where the script is run.
linuxium@LINUXIUM:~$ isocomparepkgs.sh
Usage: isocomparepkgs.sh <ISO> [<ISO>]
linuxium@LINUXIUM:~$
The usage syntax is straightforward: you either run the script against two ISOs to get a package comparison of those installed in each or you run the script against one ISO to get a comparison of packages in the ISO verses those locally installed.

For example, say you want to see the package difference between the original Ubuntu 18.04 ISO and the latest point release of 18.04.4. Simply enter the command:

isocomparepkgs.sh ubuntu-18.04-desktop-amd64.iso ubuntu-18.04.4-desktop-amd64.iso

The resultant output looks like this:



with the logfile 'isocomparepkgs.log' also including a side-by-side comparison:


It is important to note that the script only shows the difference between installed packages based on their name and not their version or release. Also it only shows packages and not userspace file differences. 

So the difference between a respun Ubuntu 18.04.4 ISO using the 'atom' option and the original ISO only shows the additional bluetooth package and not the wifi and ALSA UCM files which were also added as a result of respinning:


When comparing packages in an ISO with those locally installed it is important to remember than an ISO also includes several packages used only as part of the installation process:


and that the list of locally installed packages also includes all the dependent packages which can make it difficult to determine the actual packages used in the install commands:


which is a why the second post in this series may be of interest.

The initial release of 'isocomparepkgs.sh' can be downloaded from here.

Please donate if you find the script useful using the following link http://goo.gl/nXWSGf as everything helps with development costs.