Netboot install fails due to linux-image-4.4.0-143-generic.postinst linux-update-symlinks not found

Status changed to 'Confirmed' because the bug affects multiple users.

I can confirm I'm seeing this as well with a fresh install from the latest 16.04 netboot

I have a same problem too.

It seems to be problem of linux-base package version.
linux-image-4.4.0-143-generic require linux-base 4.5ubuntu1
but netboot installer use a linux-base 4.0ubuntu1 which does not contain below tools.

/usr/bin/linux-update-symlinks
/usr/bin/linux-version
/usr/bin/linux-check-removal

As a temporary measure, the installation failure error was avoided by putting 4.4.0-142 kernel on preseed.cfg

d-i base-installer/kernel/image string linux-image-4.4.0-142-generic

After installing this version 4.04-142, we update the linux-base to 4.5ubuntu1 version at POST stage and upgrade it to 4.4.0-143.

Same problem here.

"d-i base-installer/kernel/image string linux-image-4.4.0-142-generic"
did not work for us. The installer continued to fetch 4.4.0-143.

@ Lunatine (lunatine-lunatine)

The suggested work around does work for us. This helps relieve some pressure until the package can be fixed. Thanks.

I can confirm adding d-i base-installer/kernel/image string linux-image-4.4.0-142-generic does not work the install will ignore this option and proceed with the install of 143

fresh netinstall of 16.04

Specifying the kernel with d-i base-installer/kernel/image string linux-image-4.4.0-142-generic, after the disk layout and prior to the root user configuration, allowed the install process to continue for us.

We were able to workaround this by adding

d-i base-installer/kernel/image string linux-image-4.4.0-142-generic
d-i base-installer/kernel/override-image string linux-image-4.4.0-142-generic

to the preseed file.

To enable networking we also had to add

d-i pkgsel/include string linux-image-extra-4.4.0-142-generic

Thanks for the tip, dpfankuchen!

We use kickstarts with a few preseed options. Your suggestion helped but installs still die.

"Helped" == deployments now fetch a bunch of 4.4.0-142 packages, but ultimately still fetch linux-image-4.4.0-143* which causes them to die with the same errors quoted above.

Hi,

We are also affected by this bug.

Adding linux-meta in the loop because a simple solution could be to now add a tighter dependency on the linux-image-4.4.0-*-generic package, that means linux-base (>= 4.5ubuntu1~16.04.1).

Status changed to 'Confirmed' because the bug affects multiple users.

We are also experience this bug. All automated provisioning is not possible at the moment on our platform. Tried the above workarounds but non of them worked.

The missing linux-update-symlinks script seems like it's supposed to come from linux-base, which appears to exist with the same version number (4.5ubuntu1~16.04.1), yet different contents, in xenial (no linux-update-symlinks) and xenial-updates. It appears that this is because 4.5ubuntu1 is getting picked up from xenial-security, but the packages.ubuntu.com filelist isn't showing this; xenial actually seems to debootstrap 4.0, not 4.5ubuntu1~16.04.1.

https://packages.ubuntu.com/xenial/all/linux-base/filelist
https://packages.ubuntu.com/xenial-updates/all/linux-base/filelist
https://launchpad.net/ubuntu/xenial/+source/linux-base

So I *think* (just from first bit of this research, not from actually trying a fix) it might as simple as the linux-base dependency in linux-image-4.4.0-143 needing a version constraint >= 4.5, to force apt to upgrade linux-base first. That certainly seems appropriate in any case, as the script it's planning to call isn't in 4.0 package. The upgraded package is seemingly available (from security or from xenial-updates), but there's no constraint telling apt it must seek it out, and what it already has meets the stated dependency so it's just proceeding with it.

As far as workarounds this theory might suggest, I'm not sure if there's a way to get d-i to include xenial-updates in the debootstrap sources so it would just get it the newer one in the first place (which would also avoid the redundancy of downloading/installing old versions and then immediately upgrading it). I had hoped that using `d-i pkgsel/upgrade safe-upgrade` might be another way to get it to install the upgraded linux-base before proceeding to the kernel, but it doesn't happen early enough.

Some more info: from http://changelogs.ubuntu.com/changelogs/pool/main/l/linux-base/linux-base_4.5ubuntu1~16.04.1/changelog, it looks like the actual cutoff would be Depends: linux-base (>= 4.1)

On the question of workarounds, that confirms why pkgsel/upgrade didn't work, it's all in the base-installer udeb. The only hook point between apt-get update (where the new linux-base would be discovered) and the kernel (which currently assumes it's already installed) is the post_install_hooks call at https://salsa.debian.org/installer-team/base-installer/blob/master/debian/bootstrap-base.postinst#L188, which invokes scripts in /usr/lib/post-base-installer.d: https://salsa.debian.org/installer-team/base-installer/blob/master/library.sh#L265. And I find nothing in those hooks that would preseed can control.

So I'm not finding any way around it except a fixed kernel package with the right (versioned) Depends on linux-base.

I finally came up with a workaround that can be done in a preseed.cfg (until this can be fixed properly in the kernel image)

d-i preseed/early_command string echo -e "#!/bin/sh\napt-install linux-base" > /usr/lib/post-base-installer.d/99-bug1820755; chmod +x /usr/lib/post-base-installer.d/99-bug1820755

In other words, have the early command (which runs before base-installer) set up another post-base-installer callback hook, to upgrade linux-base. Since base-installer runs its post_install_hooks between apt_update and install_kernel, this can pick up the linux-base from xenial-updates, which will let the kernel install succeed.

Seems to work for me and ends up with everything at the right versions in the end. That seems better than trying to hold back the linux-image-4.4.0-143-generic, which would leave you vulnerable to USN-3910-1 .

I just found https://bugs.launchpad.net/ubuntu/xenial/+source/linux/+bug/1820419 - seems like the same root cause and linux-image-4.4.0-145-generic mentioned there (in -proposed) worked as I had hoped above (it has a version check on the Depends: linux-base, which pulls in the needed script from xenial-updates