* kernel-install: fix initrd when called as installkernel
Running make install from the kernel runs e.g.:
installkernel 4.20.5 arch/x86/boot/bzImage System.map "/boot"
Since 0912c0b80e this would
cal 90-loaderentry.install with those arguments:
add 4.20.5 /boot/... arch/x86/boot/bzImage System.map "/boot"
The two last arguments would then be handled as the initrd files.
As System.map exists in current directory but not in /boot/...
it would get copied there, and used as initrd intead of the initrd
which has been generated by dracut.
With this change, nothing changes when kernel-install is called
directly, but when it's called as installkernel, we now pass
thos arguments to 90-loaderentry.install:
add 4.20.5 /boot/... arch/x86/boot/bzImage initrd
initrd is thus detected as the file to use for the initrd, and as it
exists, nothing is copied over and the initrd line generated is
consistent with what one would expect
* kernel-install: fix dracut initrd detection when called directly
This brings back the systemd 240 behaviour when called directly too
* kernel-install: unify initrd fallback
* kernel-install: move initrd fallback handling to 90-loaderentry.install
* kernel-install: move initrd fallback just before creating loader entry
Of course, this should never happen, but let's better be safe than
sorry, and abort rather than continue when a too large memory block is
allocated, simply asa safety precaution.
An early abort is better than continuing with a likely memory corruption
later.
The problem was introduced in a37422045f:
we have a unit which has a fragment, and when we'd update it based on
/proc/self/mountinfo, we'd say that e.g. What=/dev/loop8 has origin-fragment.
This commit changes two things:
- origin-fragment is changed to origin-mountinfo-implicit
- when we stop a unit, mountinfo information is flushed and all deps based
on it are dropped.
The second step is important, because when we restart the unit, we want to
notice that we have "fresh" mountinfo information. We could keep the old info
around and solve this in a different way, but keeping stale information seems
inelegant.
Fixes#11342.
In normal use, this allow us to drop dead entries from the cache and reduces
the cache size so that we don't evict entries unnecessarily. The time limit is
there mostly to serve as a guard against malicious logging from many different
PIDs.
This is far from perfect, but should give mostly reasonable values. My
assumption is that if somebody has a few hundred MB of memory, they are
unlikely to have thousands of processes logging. A hundred would already be a
lot. So let's scale the cache size propritionally to the total memory size,
with clamping on both ends.
The formula gives 64 cache entries for each GB of RAM.
First of all let's always log where the errors happen, and not in an
upper stackframe, in all cases. Previously we'd do this somethis one way
and sometimes another, which resulted in sometimes duplicate logging and
sometimes none.
When we cannot activate something due to bad password the kernel gives
us EPERM. Let's uniformly return this EAGAIN, so tha the next password
is tried. (previously this was done in most cases but not in all)
When we get EPERM let's also explicitly indicate that this probably
means the password is simply wrong.
Fixes: #11498
