I started playing around with having RPM automatically generate the
debuginfo subpackages per
Because the kernel is a continual source of exceptions, the existing
code doesn't handle the case where the debuginfo and file may have
The kernel modules are compressed at the install stage so foo.ko
becomes foo.ko.xz. The debuginfo is generated as foo.ko.debug.
The existing code to split debugfiles.list can't detect this so
those files end up as unpackaged. A similar problem happens with
the vmlinux for the main kernel.
Is this an issue that can reasonably be fixed or worked around to
support the debuginfo subpackages for the kernel? I want to make
sure I'm not digging myself into a hole before I spend more time
I compile a custom kernel locally from the Fedora src.rpm. I notice
that the most recent 4.13 kernel I compiled, 4.13.0-0.rc4.git3.1, has
different behavior for the kernel entropy pool than it used to have.
The way it used to work was that when the kernel entropy pool was kept
full, or fuller, it would bleed entropy across to the pseudo-random
generator in order to reseed it. This makes the output sequence of the
PRNG indeterminate, and thus more random, and harder to attack. It is
no longer a pseudo random number generator, except in intervals.
I notice now that there is no bleed happening. When the kernel entropy
pool gets full, if there are no calls to /dev/random, it stays full.
I don't have a hardware RNG, but I harvest entropy from a sound device,
and from an rtl2832 receiver (atmospheric). They still work, if I do
cat /dev/random | rngtest -b 10
they get fired up and run full out.
But if I do
cat /dev/urandom | rngtest -b 20000
the entropy pool just sits there, and they don't run.
The entropy pool can be looked at, as root, with
I reset the write_wakeup_threshold there to 3840 from its default 1792,
and lower the urandom_min_reseed_secs to 5 (I think the default is 60).
Can you explain why this was changed, or point me to a discussion of
the rationale for the change? It seems like it has implications for
system security, and on the surface seems to decrease security of the
I've been working on cleaning up the vboxguest drivers so that they
can be added to the mainline kernel for:
The vboxvideo driver is already upstream, atm it is in staging
because it still needs to be ported to the new atomic-kms APIs
but otherwise it is in very good state and not really of staging
quality (I've already done a lot of cleanup reducing it from
52681 in its original form to 7275 lines in staging).
Some people have expressed concerns about my plans to _temporarily_
carry patches for the vboxguest integration in the Fedora kernel pkg.
I can understand that you are reluctant to carry patches which
need to be maintained for ever and ever, but that is not the case
I've been working my ass of to get these drivers cleaned up
in time for F27, so that the _cleaned up_ version can be added
to the Fedora kernels for a kernel release or 2, see:
for all the work I've been oing on the vboxguest driver.
As mentioned on the fedora-devel list I did not contact the kernel
team before because I first wanted to have something to show and
something better then just dropping the vbox out-of-tree drivers
into the kernel as is.
The other 2 drivers needed for vboxguest integration are the vboxguest
and vboxsf drivers.
I now have the vboxguest driver ready for upstream submission,
reducing it from 100587 lines of code in /usr/src/vboxguest-5.1.24/vboxguest
to just 6324 lines for the patch I'm going to submit upstream:
I plan to also have the vboxsf driver ready coming Friday and to submit
both upstream then.
As you can see from the above link the vboxguest driver is not big and
is completely self contained, without needing changes anywhere else
in the kernel. The vboxsf driver is the same. As such carrying these
2 drivers as patches should cause very little work and I will maintain
them both while they are patched in and afterwards.
So I'm hereby asking the Fedora kernel-team for permission to add
these 2 drivers as patches to the Fedora kernel for a kernel-release
or 2 while I finish pushing them upstream.