Comment 13 for bug 1829805

After many hours diving down rabbit holes it turns out this is due to a major change in the behaviour of update-initramfs introduced by Debian in July 2018 which made its way into the Ubuntu archive end of april 2019.

01:02 <TJ-> Right! initramfs-tools had a MAJOR import from Debian with "initramfs-tools (0.133ubuntu1)" April 29th; I've worked back through the changes by Debian to "initramfs-tools (0.132) unstable" of 26th July 2018, which contains "[f39625a] update-initramfs: Make "-k all" take over other initramfs images" and looking at that commit seems to indicate it is the cause

https://salsa.debian.org/kernel-team/initramfs-tools/commit/f39625afd6ba6c1aa2027286dc3ef1c933da14e0

Running the script with shell logging shows that when Calamares initramfs module calls with:

# update-initramfs -k all -c -t

We get:

...
+ break
+ [ 0 -ne 0 ]
+ [ -z c ]
+ [ all = all ]
+ get_sorted_versions
+ linux-version list
+ linux-version sort --reverse
+ read -r version
+ test -e /boot/initrd.img-5.0.0-17-generic
+ read -r version
+ version_list=
+ verbose Available versions:
+ [ 0 = 1 ]
+ [ -z ]
+ verbose Nothing to do, exiting.
+ [ 0 = 1 ]
+ exit 0

Because there is currently no /boot/initrd.img-$VERSION the version_list is empty.

This shouldn't be a concern when we're using the "-c" create option so it looks to be a bug in the logic.

The workaround for Lubuntu calamares installer configuration is to make the file exist before calling it:

 touch /boot/initrd.img-$(uname -r)

Until initramfs-tools is fixed.