the kernel version is quite irrelevant because it occurs with any custom
kernel that does not have "modules" built outside the kernel. So it
happens for 3.14, 3.15 and 3.16 kernels that don't have any
/lib/modules/<kernel version> paths needed for them.
The problem is dramatic because I would be using such a particular
kernel build and not any other available kernel and the user is "stuck"
if they ever wish to install a packaged kernel later.
Simply the custom kernel booted only has it's kernel image being booted
from and nothing else. For some reason the workaround of commenting out
a line in a policy driver file seems to do the trick.
The name of the kernel in the quotation is actually
/boot/3.16.1-xxxx-std-ipv6-64-vps and it doesn't have any modules
external of it(this is by intention to minimize surface attacks on a server)
The scripts are definitely failing when a module path doesn't exists for
the current runinng kernel and I was hoping it is not something that is
mandatory by debian policy, if it is then feel free to close this bug
report.
thanks
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
