A recent commit (2f3a215) changed the parsing of /proc/cmdline to use a
shell array. Unfortunately, this introduced a bug: "read -ar line"
populates the shell variable $r, not $line. This breaks installation of
new loader entries:
# kernel-install add 3.17.1-304.fc21.x86_64 \
/boot/vmlinuz-3.17.1-304.fc21.x86_64
Could not determine the kernel command line parameters.
Please specify the kernel command line in /etc/kernel/cmdline!
This commit alters the read command to correctly populate the $line
array instead.
If /etc/kernel/cmdline is missing or empty, we read /proc/cmdline and
want to filter out the initrd line. Due to a bug, the whole contents was
filtered out.
The file should have been in /usr/lib/ in the first place, since it
describes the OS container in /usr (and not the configuration in /etc),
hence, let's support os-release files in /usr/lib as fallback if no
version in /etc exists, following the usual override logic.
A prior commit already enabled tmpfiles to create /etc/os-release as a
symlink to /usr/lib/os-release should it be missing, thus providing nice
compatibility with applications only checking in /etc.
While it's probably a good idea if all apps check both locations via a
fallback logic, it is only necessary in the early boot process, as long
as the /etc/os-release symlink has not been restored, in case we boot
with an empty /etc.
Do the depmod in the kernel-install hooks, so hooks can produce/install
kernel modules and be part of the depmod.
Also move the basic boot loader entry creation and removal to a
plugin script.
If PRETTY_NAME is not defined in /etc/os-release, fallback to
PRETTY_NAME="Linux $KERNEL_VERSION".
Add documentation for everything in the man page.
