Re: [kernel/f21] Make sure acpi brightness_switch is disabled (like forever in Fedora)
by Hans de Goede
Hi Josh,
On 07/28/2014 07:04 PM, Josh Boyer wrote:
> commit e6fe382d1d53d4cdf9b544729dc823d4eab0217c
> Author: Josh Boyer <jwboyer(a)fedoraproject.org>
> Date: Mon Jul 28 13:03:01 2014 -0400
>
> Make sure acpi brightness_switch is disabled (like forever in Fedora)
>
> Upstream reverted the change to turn the ACPI brightness_switch_enabled
> parameter off by default. Revert the revert so we go back to the state
> Fedora has traditionally been in.
Ack, I was planning on doing this myself but you beat me to it, thanks for
taking care of this.
Note that 3.17 will have this patch:
https://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/commit/?...
Which fixes the 2 steps being taken for one keypress problem while
keeping the acpi brightness_switch behavior enabled, so that people who
have an acpi-video controlled backlight and a userspace which does not
do backlight control (e.g. windowmaker).
So for 3.17 we should IMHO drop the revert-revert and stick with
upstream behavior.
Alternatively we could apply that patch now instead of the revert-revert.
Regards,
Hans
7 years, 10 months
kdbus and Fedora
by Josh Boyer
Hi All,
Harald and I were recently talking about kdbus and how it plays into
Fedora. Right now, the kernel-playground COPR is carrying the kdbus
patches, but that isn't widely used and isn't included in a broad test
base. Obviously our distribution is heavily entwined with D-Bus and we
were looking to see if it was possible to help kdbus testing and
development by doing some kind of integration within Fedora itself. I
promised Harald I would talk it over with the other Fedora kernel
maintainers and after a brief discussion we came up with the following
possible proposal.
If Fedora were to carry kdbus in any form, the following things would
be required:
1) There would be a single canonical location to track kdbus
development. After talking with Harald, that should be the upstream
tree that gregkh is using to submit patches.
2) Harald's team (systemd, etc) would commit to testing the system
both with and without kdbus active. Obviously we do not want to
enforce reliance on something as core critical as kdbus while it is
still being actively developed upstream. That could cause a lot of
deviation down the road and it isn't the aim here.
3) kdbus would only be carried in the rawhide branch until it is
merged upstream. As a concrete example, if kdbus was not merged in
the upstream kernel at the time rel-eng creates the F23 branches, then
Fedora 23 will never get kdbus. It will be carried in rawhide and
rawhide only until it's accepted upstream. The maintainers actually
hope this does get merged but we want to make sure we are prepared to
drop this without causing too much trouble if needed.
4) After discussing a bit with the rest of the Fedora kernel
maintainers, we would carry an additional patch that would require
'kdbus-enabled' to be specified before the kernel would allow kdbus to
be loaded (or similar mechanism). This would focus the main testing
effort for all the default images to remain as they are today, while
easily allowing the plumbing layer developers access to kdbus for
their enablement testing.
These conditions would hopefully help the Fedora kernel maintainers
avoid some of the pitfalls of carrying a large chunk of out of tree
code and if they're all met we feel fairly comfortable with doing
this. We wanted to send this out for a bit wider discussion and
review before proceeding with it, and I agreed to start this thread so
here we are.
Harald, does the above look like what you were envisioning when we
talked earlier?
josh
7 years, 11 months
fedora 14 kernel performance with ip forwarding workload
by Jesse Brandeburg
The other day I was running the stock fedora kernel on my ip
forwarding setup, to see what the performance was, and the performance
wasn't very good.
system is S5520HC dual socket 2.93GHz Xeon 5570 (Nehalem) with 3 quad
port 82580 adapters (12 ports). Traffic is bidirectional 64 byte
packets being forwarded and received on each port, basically port to
port routing. I am only using 12 flows currently.
The driver is igb, and I am using an affinity script that lines up
each pair of ports that are forwarding traffic into optimal
configurations for cache locality. I am also disabling
remote_node_defrag_ratio to stop cross node traffic.
With the fedora default kernel from F14 it appears that
CONFIG_NETFILTER=y means that I cannot unload all of netfilter even if
I stop iptables service.
perf showed netfilter being prominent, and removing it gives me much
higher throughput. Is there a reason CONFIG_NETFILTER=y ? Isn't it a
good thing to be able to disable netfilter if you want to?
Jesse
8 years
Fwd: OSSEC Alert - annun10 - Level 13 - Non standard syslog message (size too large).
by Lance Lassetter
Just upgraded to FC22. And spamd crashes alot.
-------- Original Message --------
From: OSSEC HIDS <ossecm(a)annun10.lan>
Sent: May 29, 2015 10:05:08 AM CDT
To: root@localhost
Subject: OSSEC Alert - annun10 - Level 13 - Non standard syslog message (size too large).
OSSEC HIDS Notification.
2015 May 29 10:04:34
Received From: annun10->/var/log/messages
Rule: 1003 fired (level 13) -> "Non standard syslog message (size too large)."
Portion of the log(s):
May 29 10:04:32 annun10 systemd-coredump: Process 8264 (spamd) of user 0 dumped core.#012#012Stack trace of thread 8264:#012#0 0x00007fd515e6526e boot_MIME__Base64 (Base64.so)#012#1 0x00007fd51f67867b Perl_pp_entersub (libperl.so.5.20)#012#2 0x00007fd51f670f06 Perl_runops_standard (libperl.so.5.20)#012#3 0x00007fd51f5f9286 Perl_call_sv (libperl.so.5.20)#012#4 0x00007fd51f5fb533 Perl_call_list (libperl.so.5.20)#012#5 0x00007fd51f5def61 S_process_special_blocks (libperl.so.5.20)#012#6 0x00007fd51f5f2907 Perl_newATTRSUB_x (libperl.so.5.20)#012#7 0x00007fd51f5f5967 Perl_utilize (libperl.so.5.20)#012#8 0x00007fd51f628cad Perl_yyparse (libperl.so.5.20)#012#9 0x00007fd51f6ab4dd S_doeval (libperl.so.5.20)#012#10 0x00007fd51f6b6962 Perl_pp_require (libperl.so.5.20)#012#11 0x00007fd51f670f06 Perl_runops_standard (libperl.so.5.20)#012#12 0x00007fd51f5f9286 Perl_call_sv (libperl.so.5.20)#012#13 0x00007fd51f5fb533 Perl_call_list (libperl.so.5.20)#012#14 0x00007fd51f5def61
S_process_spec
ial_blocks (libperl.so.5.20)#012#15 0x00007fd51f5f2907 Perl_newATTRSUB_x (libperl.so.5.20)#012#16 0x00007fd51f5f5967 Perl_utilize (libperl.so.5.20)#012#17 0x00007fd51f628cad Perl_yyparse (libperl.so.5.20)#012#18 0x00007fd51f6ab4dd S_doeval (libperl.so.5.20)#
--END OF NOTIFICATION
OSSEC HIDS Notification.
2015 May 29 10:04:38
Received From: annun10->/var/log/messages
Rule: 1003 fired (level 13) -> "Non standard syslog message (size too large)."
Portion of the log(s):
May 29 10:04:36 annun10 systemd-coredump: Process 8267 (spamd) of user 0 dumped core.#012#012Stack trace of thread 8267:#012#0 0x00007f1d5ff7a26e boot_MIME__Base64 (Base64.so)#012#1 0x00007f1d6978d67b Perl_pp_entersub (libperl.so.5.20)#012#2 0x00007f1d69785f06 Perl_runops_standard (libperl.so.5.20)#012#3 0x00007f1d6970e286 Perl_call_sv (libperl.so.5.20)#012#4 0x00007f1d69710533 Perl_call_list (libperl.so.5.20)#012#5 0x00007f1d696f3f61 S_process_special_blocks (libperl.so.5.20)#012#6 0x00007f1d69707907 Perl_newATTRSUB_x (libperl.so.5.20)#012#7 0x00007f1d6970a967 Perl_utilize (libperl.so.5.20)#012#8 0x00007f1d6973dcad Perl_yyparse (libperl.so.5.20)#012#9 0x00007f1d697c04dd S_doeval (libperl.so.5.20)#012#10 0x00007f1d697cb962 Perl_pp_require (libperl.so.5.20)#012#11 0x00007f1d69785f06 Perl_runops_standard (libperl.so.5.20)#012#12 0x00007f1d6970e286 Perl_call_sv (libperl.so.5.20)#012#13 0x00007f1d69710533 Perl_call_list (libperl.so.5.20)#012#14 0x00007f1d696f3f61
S_process_spec
ial_blocks (libperl.so.5.20)#012#15 0x00007f1d69707907 Perl_newATTRSUB_x (libperl.so.5.20)#012#16 0x00007f1d6970a967 Perl_utilize (libperl.so.5.20)#012#17 0x00007f1d6973dcad Perl_yyparse (libperl.so.5.20)#012#18 0x00007f1d697c04dd S_doeval (libperl.so.5.20)#
--END OF NOTIFICATION
OSSEC HIDS Notification.
2015 May 29 10:04:42
Received From: annun10->/var/log/messages
Rule: 1003 fired (level 13) -> "Non standard syslog message (size too large)."
Portion of the log(s):
May 29 10:04:41 annun10 systemd-coredump: Process 8270 (spamd) of user 0 dumped core.#012#012Stack trace of thread 8270:#012#0 0x00007f9840b8b26e boot_MIME__Base64 (Base64.so)#012#1 0x00007f984a39e67b Perl_pp_entersub (libperl.so.5.20)#012#2 0x00007f984a396f06 Perl_runops_standard (libperl.so.5.20)#012#3 0x00007f984a31f286 Perl_call_sv (libperl.so.5.20)#012#4 0x00007f984a321533 Perl_call_list (libperl.so.5.20)#012#5 0x00007f984a304f61 S_process_special_blocks (libperl.so.5.20)#012#6 0x00007f984a318907 Perl_newATTRSUB_x (libperl.so.5.20)#012#7 0x00007f984a31b967 Perl_utilize (libperl.so.5.20)#012#8 0x00007f984a34ecad Perl_yyparse (libperl.so.5.20)#012#9 0x00007f984a3d14dd S_doeval (libperl.so.5.20)#012#10 0x00007f984a3dc962 Perl_pp_require (libperl.so.5.20)#012#11 0x00007f984a396f06 Perl_runops_standard (libperl.so.5.20)#012#12 0x00007f984a31f286 Perl_call_sv (libperl.so.5.20)#012#13 0x00007f984a321533 Perl_call_list (libperl.so.5.20)#012#14 0x00007f984a304f61
S_process_spec
ial_blocks (libperl.so.5.20)#012#15 0x00007f984a318907 Perl_newATTRSUB_x (libperl.so.5.20)#012#16 0x00007f984a31b967 Perl_utilize (libperl.so.5.20)#012#17 0x00007f984a34ecad Perl_yyparse (libperl.so.5.20)#012#18 0x00007f984a3d14dd S_doeval (libperl.so.5.20)#
--END OF NOTIFICATION
OSSEC HIDS Notification.
2015 May 29 10:04:46
Received From: annun10->/var/log/messages
Rule: 1003 fired (level 13) -> "Non standard syslog message (size too large)."
Portion of the log(s):
May 29 10:04:45 annun10 systemd-coredump: Process 8301 (spamd) of user 0 dumped core.#012#012Stack trace of thread 8301:#012#0 0x00007f9d7513d26e boot_MIME__Base64 (Base64.so)#012#1 0x00007f9d7e95067b Perl_pp_entersub (libperl.so.5.20)#012#2 0x00007f9d7e948f06 Perl_runops_standard (libperl.so.5.20)#012#3 0x00007f9d7e8d1286 Perl_call_sv (libperl.so.5.20)#012#4 0x00007f9d7e8d3533 Perl_call_list (libperl.so.5.20)#012#5 0x00007f9d7e8b6f61 S_process_special_blocks (libperl.so.5.20)#012#6 0x00007f9d7e8ca907 Perl_newATTRSUB_x (libperl.so.5.20)#012#7 0x00007f9d7e8cd967 Perl_utilize (libperl.so.5.20)#012#8 0x00007f9d7e900cad Perl_yyparse (libperl.so.5.20)#012#9 0x00007f9d7e9834dd S_doeval (libperl.so.5.20)#012#10 0x00007f9d7e98e962 Perl_pp_require (libperl.so.5.20)#012#11 0x00007f9d7e948f06 Perl_runops_standard (libperl.so.5.20)#012#12 0x00007f9d7e8d1286 Perl_call_sv (libperl.so.5.20)#012#13 0x00007f9d7e8d3533 Perl_call_list (libperl.so.5.20)#012#14 0x00007f9d7e8b6f61
S_process_spec
ial_blocks (libperl.so.5.20)#012#15 0x00007f9d7e8ca907 Perl_newATTRSUB_x (libperl.so.5.20)#012#16 0x00007f9d7e8cd967 Perl_utilize (libperl.so.5.20)#012#17 0x00007f9d7e900cad Perl_yyparse (libperl.so.5.20)#012#18 0x00007f9d7e9834dd S_doeval (libperl.so.5.20)#
--END OF NOTIFICATION
OSSEC HIDS Notification.
2015 May 29 10:04:50
Received From: annun10->/var/log/messages
Rule: 1003 fired (level 13) -> "Non standard syslog message (size too large)."
Portion of the log(s):
May 29 10:04:49 annun10 systemd-coredump: Process 8304 (spamd) of user 0 dumped core.#012#012Stack trace of thread 8304:#012#0 0x00007f48a536126e boot_MIME__Base64 (Base64.so)#012#1 0x00007f48aeb7467b Perl_pp_entersub (libperl.so.5.20)#012#2 0x00007f48aeb6cf06 Perl_runops_standard (libperl.so.5.20)#012#3 0x00007f48aeaf5286 Perl_call_sv (libperl.so.5.20)#012#4 0x00007f48aeaf7533 Perl_call_list (libperl.so.5.20)#012#5 0x00007f48aeadaf61 S_process_special_blocks (libperl.so.5.20)#012#6 0x00007f48aeaee907 Perl_newATTRSUB_x (libperl.so.5.20)#012#7 0x00007f48aeaf1967 Perl_utilize (libperl.so.5.20)#012#8 0x00007f48aeb24cad Perl_yyparse (libperl.so.5.20)#012#9 0x00007f48aeba74dd S_doeval (libperl.so.5.20)#012#10 0x00007f48aebb2962 Perl_pp_require (libperl.so.5.20)#012#11 0x00007f48aeb6cf06 Perl_runops_standard (libperl.so.5.20)#012#12 0x00007f48aeaf5286 Perl_call_sv (libperl.so.5.20)#012#13 0x00007f48aeaf7533 Perl_call_list (libperl.so.5.20)#012#14 0x00007f48aeadaf61
S_process_spec
ial_blocks (libperl.so.5.20)#012#15 0x00007f48aeaee907 Perl_newATTRSUB_x (libperl.so.5.20)#012#16 0x00007f48aeaf1967 Perl_utilize (libperl.so.5.20)#012#17 0x00007f48aeb24cad Perl_yyparse (libperl.so.5.20)#012#18 0x00007f48aeba74dd S_doeval (libperl.so.5.20)#
--END OF NOTIFICATION
OSSEC HIDS Notification.
2015 May 29 10:04:54
Received From: annun10->/var/log/messages
Rule: 1003 fired (level 13) -> "Non standard syslog message (size too large)."
Portion of the log(s):
May 29 10:04:53 annun10 systemd-coredump: Process 8307 (spamd) of user 0 dumped core.#012#012Stack trace of thread 8307:#012#0 0x00007fc60b53326e boot_MIME__Base64 (Base64.so)#012#1 0x00007fc614d4667b Perl_pp_entersub (libperl.so.5.20)#012#2 0x00007fc614d3ef06 Perl_runops_standard (libperl.so.5.20)#012#3 0x00007fc614cc7286 Perl_call_sv (libperl.so.5.20)#012#4 0x00007fc614cc9533 Perl_call_list (libperl.so.5.20)#012#5 0x00007fc614cacf61 S_process_special_blocks (libperl.so.5.20)#012#6 0x00007fc614cc0907 Perl_newATTRSUB_x (libperl.so.5.20)#012#7 0x00007fc614cc3967 Perl_utilize (libperl.so.5.20)#012#8 0x00007fc614cf6cad Perl_yyparse (libperl.so.5.20)#012#9 0x00007fc614d794dd S_doeval (libperl.so.5.20)#012#10 0x00007fc614d84962 Perl_pp_require (libperl.so.5.20)#012#11 0x00007fc614d3ef06 Perl_runops_standard (libperl.so.5.20)#012#12 0x00007fc614cc7286 Perl_call_sv (libperl.so.5.20)#012#13 0x00007fc614cc9533 Perl_call_list (libperl.so.5.20)#012#14 0x00007fc614cacf61
S_process_spec
ial_blocks (libperl.so.5.20)#012#15 0x00007fc614cc0907 Perl_newATTRSUB_x (libperl.so.5.20)#012#16 0x00007fc614cc3967 Perl_utilize (libperl.so.5.20)#012#17 0x00007fc614cf6cad Perl_yyparse (libperl.so.5.20)#012#18 0x00007fc614d794dd S_doeval (libperl.so.5.20)#
--END OF NOTIFICATION
OSSEC HIDS Notification.
2015 May 29 10:04:58
Received From: annun10->/var/log/messages
Rule: 1003 fired (level 13) -> "Non standard syslog message (size too large)."
Portion of the log(s):
May 29 10:04:58 annun10 systemd-coredump: Process 8310 (spamd) of user 0 dumped core.#012#012Stack trace of thread 8310:#012#0 0x00007f93c1f5126e boot_MIME__Base64 (Base64.so)#012#1 0x00007f93cb76467b Perl_pp_entersub (libperl.so.5.20)#012#2 0x00007f93cb75cf06 Perl_runops_standard (libperl.so.5.20)#012#3 0x00007f93cb6e5286 Perl_call_sv (libperl.so.5.20)#012#4 0x00007f93cb6e7533 Perl_call_list (libperl.so.5.20)#012#5 0x00007f93cb6caf61 S_process_special_blocks (libperl.so.5.20)#012#6 0x00007f93cb6de907 Perl_newATTRSUB_x (libperl.so.5.20)#012#7 0x00007f93cb6e1967 Perl_utilize (libperl.so.5.20)#012#8 0x00007f93cb714cad Perl_yyparse (libperl.so.5.20)#012#9 0x00007f93cb7974dd S_doeval (libperl.so.5.20)#012#10 0x00007f93cb7a2962 Perl_pp_require (libperl.so.5.20)#012#11 0x00007f93cb75cf06 Perl_runops_standard (libperl.so.5.20)#012#12 0x00007f93cb6e5286 Perl_call_sv (libperl.so.5.20)#012#13 0x00007f93cb6e7533 Perl_call_list (libperl.so.5.20)#012#14 0x00007f93cb6caf61
S_process_spec
ial_blocks (libperl.so.5.20)#012#15 0x00007f93cb6de907 Perl_newATTRSUB_x (libperl.so.5.20)#012#16 0x00007f93cb6e1967 Perl_utilize (libperl.so.5.20)#012#17 0x00007f93cb714cad Perl_yyparse (libperl.so.5.20)#012#18 0x00007f93cb7974dd S_doeval (libperl.so.5.20)#
--END OF NOTIFICATION
8 years
Re: Backporting vmmouse kernel support to Fedora-22 kernel ?
by Josh Boyer
On Fri, May 15, 2015 at 5:04 AM, Hans de Goede <hdegoede(a)redhat.com> wrote:
> Hi Josh,
Throwing kernel@ on CC.
> I'm mailing you because of:
> https://bugzilla.redhat.com/show_bug.cgi?id=1214474
>
> Rather then hacking around the problem discussed there
> (and then at one point in time needing to remove the hack).
>
> I would rather see us go straight to the final solution and
> backport the new vmmouse kernel driver (vs the old crufty lets
> bitbang from userspace driver still used today) to the F-22
> kernel, this would involve cherry-picking this single commit:
>
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit?id...
>
> This is not something which we should do for F-22 GA, but
> it would be good to do this for one of the first kernel
> updates after GA IMHO.
I saw this driver come in during the 4.1 merge window, but it's
disabled even in rawhide at the moment. The Kconfig help text clearly
says we need the 13.0.1 version of the userspace driver, and rawhide
is only at 13.0.99. F22 is at 13.0.0.
Additionally, I'm not sure we want to add a full Requires: in
kernel.spec for that version, because it will force the xorg driver to
be installed on all systems when most won't need it. We could add an
Obsoletes if the userspace driver is truly no longer needed when the
in-kernel driver is present, but I'd need to know if that was actually
true. Is there really no way for this to be backwards compatible?
I'm not opposed to backporting this eventually, but I think there's
some work to do on the xorg side as well?
josh
8 years
[PATCH] Drop compile-fixes and upstream-reverts patches
by Josh Boyer
We very very rarely use these. The last time compile-fixes.patch was
used was over 3 years ago. The upstream-reverts.patch has literally
never been used since Fedora switched to git. We tend to apply the
reverts as stand-alone patches anyway, and compile fixes are generally
better as stand-alone patches that get sent upstream ASAP.
---
compile-fixes.patch | 6 ------
kernel.spec | 12 ------------
upstream-reverts.patch | 1 -
3 files changed, 19 deletions(-)
delete mode 100644 compile-fixes.patch
delete mode 100644 upstream-reverts.patch
diff --git a/compile-fixes.patch b/compile-fixes.patch
deleted file mode 100644
index 34c08ce..0000000
--- a/compile-fixes.patch
+++ /dev/null
@@ -1,6 +0,0 @@
-#
-# Small compile fixes (For more involved fixes, please use a separate patch).
-#
-# Please add the errors from gcc before the diffs to save others having
-# to do a compile to figure out what your diff is fixing. Thanks.
-#
diff --git a/kernel.spec b/kernel.spec
index bd1a394..38a6eae 100644
--- a/kernel.spec
+++ b/kernel.spec
@@ -481,17 +481,12 @@ Patch00: patch-4.%{base_sublevel}-git%{gitrev}.xz
%endif
%endif
-# we also need compile fixes for -vanilla
-Patch04: compile-fixes.patch
-
# build tweak for build ID magic, even for -vanilla
Patch05: kbuild-AFTER_LINK.patch
%if !%{nopatches}
-# revert upstream patches we get via other methods
-Patch09: upstream-reverts.patch
# Git trees.
# Standalone patches
@@ -1175,16 +1170,9 @@ done
ApplyPatch kbuild-AFTER_LINK.patch
-#
-# misc small stuff to make things compile
-#
-ApplyOptionalPatch compile-fixes.patch
%if !%{nopatches}
-# revert patches from upstream that conflict or that we get via other means
-ApplyOptionalPatch upstream-reverts.patch -R
-
# Architecture patches
# x86(-64)
ApplyPatch lib-cpumask-Make-CPUMASK_OFFSTACK-usable-without-deb.patch
diff --git a/upstream-reverts.patch b/upstream-reverts.patch
deleted file mode 100644
index 607602c..0000000
--- a/upstream-reverts.patch
+++ /dev/null
@@ -1 +0,0 @@
-nil
--
2.4.0
8 years
mtime of untouched files changed?
by Reindl Harald
i switched from "noatime,nodiratime" to "relatime,nodiratime,lazytime"
which seems to lead in unexpected mtime changes for a lot of files
leading in rkhunter alerts and likely rsync problems
May 15 13:35:51 Installed: kernel-core-4.0.3-201.fc21.x86_64
May 15 13:35:54 Installed: kernel-modules-4.0.3-201.fc21.x86_64
May 15 13:35:55 Updated: kernel-headers-4.0.3-201.fc21.x86_64
Warning: Package manager verification has failed:
File: /usr/bin/vmstat
The file modification time has changed
Warning: Package manager verification has failed:
File: /usr/sbin/fsck
The file modification time has changed
Warning: Package manager verification has failed:
File: /usr/sbin/nologin
The file modification time has changed
[root@rh:~]$ stat /usr/sbin/fsck
File: '/usr/sbin/fsck'
Size: 37168 Blocks: 80 IO Block: 4096 regular file
Device: 901h/2305d Inode: 1309455 Links: 1
Access: (0755/-rwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2015-05-18 11:30:07.909951123 +0200
Modify: 2015-05-15 13:34:47.037194874 +0200
Change: 2015-05-15 13:34:47.037194874 +0200
8 years
[PATCH] kernel.spec: no more files in /boot
by Harald Hoyer
From: Harald Hoyer <harald(a)redhat.com>
This patch is to install everything to /lib/modules/$KERNEL_VERSION
and only have %ghost files for /boot files.
Installation in %posttrans with kernel-install should work already.
F20: systemd >= 208-31
F21: systemd >= 216-21
F >= 22: systemd >= 215-12
The main target is to have all rpms install only to /usr, so in the end
we would have a self contained installation in /usr.
As of now, we still have to cope with /var and /etc, but you have to
start somewhere.
---
kernel.spec | 39 +++++++++++++++++++++++++--------------
1 file changed, 25 insertions(+), 14 deletions(-)
diff --git a/kernel.spec b/kernel.spec
index 74e27fb..a7ae323 100644
--- a/kernel.spec
+++ b/kernel.spec
@@ -1538,19 +1538,24 @@ BuildKernel() {
%{make} -s ARCH=$Arch V=1 %{?_smp_mflags} $MakeTarget %{?sparse_mflags} %{?kernel_mflags}
%{make} -s ARCH=$Arch V=1 %{?_smp_mflags} modules %{?sparse_mflags} || exit 1
+ mkdir -p $RPM_BUILD_ROOT/%{image_install_path}
+ mkdir -p $RPM_BUILD_ROOT/lib/modules/$KernelVer
+%if %{with_debuginfo}
+ mkdir -p $RPM_BUILD_ROOT%{debuginfodir}/boot
+ mkdir -p $RPM_BUILD_ROOT%{debuginfodir}/%{image_install_path}
+%endif
+
%ifarch %{arm} aarch64
%{make} -s ARCH=$Arch V=1 dtbs dtbs_install INSTALL_DTBS_PATH=$RPM_BUILD_ROOT/%{image_install_path}/dtb-$KernelVer
+ cp $RPM_BUILD_ROOT/%{image_install_path}/dtb-$KernelVer
find arch/$Arch/boot/dts -name '*.dtb' -type f | xargs rm -f
%endif
# Start installing the results
-%if %{with_debuginfo}
- mkdir -p $RPM_BUILD_ROOT%{debuginfodir}/boot
- mkdir -p $RPM_BUILD_ROOT%{debuginfodir}/%{image_install_path}
-%endif
- mkdir -p $RPM_BUILD_ROOT/%{image_install_path}
install -m 644 .config $RPM_BUILD_ROOT/boot/config-$KernelVer
+ install -m 644 .config $RPM_BUILD_ROOT/lib/modules/$KernelVer/config
install -m 644 System.map $RPM_BUILD_ROOT/boot/System.map-$KernelVer
+ install -m 644 System.map $RPM_BUILD_ROOT/lib/modules/$KernelVer/System.map
# We estimate the size of the initramfs because rpm needs to take this size
# into consideration when performing disk space calculations. (See bz #530778)
@@ -1558,6 +1563,7 @@ BuildKernel() {
if [ -f arch/$Arch/boot/zImage.stub ]; then
cp arch/$Arch/boot/zImage.stub $RPM_BUILD_ROOT/%{image_install_path}/zImage.stub-$KernelVer || :
+ cp arch/$Arch/boot/zImage.stub $RPM_BUILD_ROOT/lib/modules/$KernelVer/zImage.stub-$KernelVer || :
fi
%if %{signmodules}
# Sign the image if we're using EFI
@@ -1571,13 +1577,14 @@ BuildKernel() {
$CopyKernel $KernelImage \
$RPM_BUILD_ROOT/%{image_install_path}/$InstallName-$KernelVer
chmod 755 $RPM_BUILD_ROOT/%{image_install_path}/$InstallName-$KernelVer
+ cp $RPM_BUILD_ROOT/%{image_install_path}/$InstallName-$KernelVer $RPM_BUILD_ROOT/lib/modules/$KernelVer/$InstallName
# hmac sign the kernel for FIPS
echo "Creating hmac file: $RPM_BUILD_ROOT/%{image_install_path}/.vmlinuz-$KernelVer.hmac"
ls -l $RPM_BUILD_ROOT/%{image_install_path}/$InstallName-$KernelVer
sha512hmac $RPM_BUILD_ROOT/%{image_install_path}/$InstallName-$KernelVer | sed -e "s,$RPM_BUILD_ROOT,," > $RPM_BUILD_ROOT/%{image_install_path}/.vmlinuz-$KernelVer.hmac;
+ cp $RPM_BUILD_ROOT/%{image_install_path}/.vmlinuz-$KernelVer.hmac $RPM_BUILD_ROOT/lib/modules/$KernelVer/.vmlinuz.hmac
- mkdir -p $RPM_BUILD_ROOT/lib/modules/$KernelVer
# Override $(mod-fw) because we don't want it to install any firmware
# we'll get it from the linux-firmware package and we don't want conflicts
%{make} -s ARCH=$Arch INSTALL_MOD_PATH=$RPM_BUILD_ROOT modules_install KERNELRELEASE=$KernelVer mod-fw=
@@ -1990,7 +1997,6 @@ popd
make DESTDIR=$RPM_BUILD_ROOT bootwrapper_install WRAPPER_OBJDIR=%{_libdir}/kernel-wrapper WRAPPER_DTSDIR=%{_libdir}/kernel-wrapper/dts
%endif
-
###
### clean
###
@@ -2061,7 +2067,7 @@ fi\
#
%define kernel_variant_posttrans() \
%{expand:%%posttrans %{?1:%{1}-}core}\
-/bin/kernel-install add %{KVERREL}%{?1:+%{1}} /%{image_install_path}/vmlinuz-%{KVERREL}%{?1:+%{1}} || exit $?\
+/bin/kernel-install add %{KVERREL}%{?1:+%{1}} /lib/modules/%{KVERREL}%{?1:+%{1}}/vmlinuz || exit $?\
%{nil}
#
@@ -2088,7 +2094,7 @@ fi}\
#
%define kernel_variant_preun() \
%{expand:%%preun %{?1:%{1}-}core}\
-/bin/kernel-install remove %{KVERREL}%{?1:+%{1}} /%{image_install_path}/vmlinuz-%{KVERREL}%{?1:+%{1}} || exit $?\
+/bin/kernel-install remove %{KVERREL}%{?1:+%{1}} /lib/modules/%{KVERREL}%{?1:+%{1}}/vmlinuz || exit $?\
%{nil}
%kernel_variant_preun
@@ -2206,13 +2212,18 @@ fi
%defattr(-,root,root)\
%{!?_licensedir:%global license %%doc}\
%license linux-%{KVERREL}/COPYING\
-/%{image_install_path}/%{?-k:%{-k*}}%{!?-k:vmlinuz}-%{KVERREL}%{?2:+%{2}}\
-/%{image_install_path}/.vmlinuz-%{KVERREL}%{?2:+%{2}}.hmac \
+/lib/modules/%{KVERREL}%{?2:+%{2}}/%{?-k:%{-k*}}%{!?-k:vmlinuz}\
+%ghost /%{image_install_path}/%{?-k:%{-k*}}%{!?-k:vmlinuz}-%{KVERREL}%{?2:+%{2}}\
+/lib/modules/%{KVERREL}%{?2:+%{2}}/.vmlinuz.hmac \
+%ghost /%{image_install_path}/.vmlinuz-%{KVERREL}%{?2:+%{2}}.hmac \
%ifarch %{arm} aarch64\
-/%{image_install_path}/dtb-%{KVERREL}%{?2:+%{2}} \
+/lib/modules/%{KVERREL}%{?2:+%{2}}/dtb \
+%ghost /%{image_install_path}/dtb-%{KVERREL}%{?2:+%{2}} \
%endif\
-%attr(600,root,root) /boot/System.map-%{KVERREL}%{?2:+%{2}}\
-/boot/config-%{KVERREL}%{?2:+%{2}}\
+%attr(600,root,root) /lib/modules/%{KVERREL}%{?2:+%{2}}/System.map\
+%ghost /boot/System.map-%{KVERREL}%{?2:+%{2}}\
+/lib/modules/%{KVERREL}%{?2:+%{2}}/config\
+%ghost /boot/config-%{KVERREL}%{?2:+%{2}}\
%ghost /boot/initramfs-%{KVERREL}%{?2:+%{2}}.img\
%dir /lib/modules\
%dir /lib/modules/%{KVERREL}%{?2:+%{2}}\
--
2.3.7
8 years
Re: Moving joydev back into the main modules package
by Hans de Goede
Hi,
On 05/12/2015 05:07 PM, poma wrote:
> On 12.05.2015 13:55, Hans de Goede wrote:
>> Hi,
>>
>> On 12-05-15 13:48, poma wrote:
>>> On 12.05.2015 09:00, Hans de Goede wrote:
>>>> Hi,
>>>>
>>>> On 12-05-15 03:22, poma wrote:
>>>>> On 11.05.2015 20:05, Hans de Goede wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On 11-05-15 18:50, Peter Robinson wrote:
>>>>>>> On Mon, May 11, 2015 at 4:53 PM, Hans de Goede <hdegoede(a)redhat.com> wrote:
>>>>>>>> Hi All,
>>>>>>>>
>>>>>>>> This weekend I lost 2 hours figuring out why supertuxkart would not
>>>>>>>> recognize a standard logitech usb gamepad.
>>>>>>>>
>>>>>>>> After 2 hours I found out that the problem is that some games
>>>>>>>> need to joydev module to interact with usb-hid devices as
>>>>>>>> the use the /dev/js interface rather then the /dev/input/event#
>>>>>>>> interface, once I had installed kernel-modules-extras everything
>>>>>>>> just worked, the module auto loaded stk recognized the gamepad
>>>>>>>> and things just worked (tm) which is what I believe is the
>>>>>>>> experience we want to offer ootb.
>>>>>>>>
>>>>>>>> Therefor I would like to request for the joydev module to be
>>>>>>>> moved from kernel-modules-extras into the main kernel-modules
>>>>>>>> package.
>>>>>>>
>>>>>>> A bunch of games use the means we now have to specify a "Requires:
>>>>>>> kernel-module(joydev)" style syntax so it doesn't matter where the
>>>>>>> module resides (sorry, don't know the exact syntax offhand).
>>>>>>
>>>>>> I do not think that sprinkling "Requires: kernel-module(joydev)"
>>>>>> all over the place for something which is really just core functionality
>>>>>> which apps should be able to rely on is a good idea. Esp. not when
>>>>>> we are talking about a module which is 6784 bytes on the filesystem.
>>>>>>
>>>>>> Also these requires have funny side effects, they cause dnf to
>>>>>> install kernel-debug rather then kernel-modules-extra when the
>>>>>> module is not already present on the system which sorta defeats the
>>>>>> purpose.
>>>>>>
>>>>>
>>>>> What rhbz is it?
>>>>
>>>> The one which you are going to create for it ?
>>>>
>>>
>>> No problemos, all for your love.
>>>
>>>> Just do: "dnf install joystick-support" on an F-22 system without
>>>> kernel-modules-extra installed to reproduce.
>>>>
>>>
>>> What component, strange thing called dnf, stick of joy, or kernel?
>>
>> Lets start with filing a bug against dnf for this and then see from
>> there.
>>
>> Regards,
>>
>> Hans
>>
>
> dnf - joystick-support - kernel-[debug]
> https://bugzilla.redhat.com/show_bug.cgi?id=1220821
Thanks!
Regards,
Hans
8 years
Re: Moving joydev back into the main modules package
by Hans de Goede
Hi,
On 12-05-15 13:48, poma wrote:
> On 12.05.2015 09:00, Hans de Goede wrote:
>> Hi,
>>
>> On 12-05-15 03:22, poma wrote:
>>> On 11.05.2015 20:05, Hans de Goede wrote:
>>>> Hi,
>>>>
>>>> On 11-05-15 18:50, Peter Robinson wrote:
>>>>> On Mon, May 11, 2015 at 4:53 PM, Hans de Goede <hdegoede(a)redhat.com> wrote:
>>>>>> Hi All,
>>>>>>
>>>>>> This weekend I lost 2 hours figuring out why supertuxkart would not
>>>>>> recognize a standard logitech usb gamepad.
>>>>>>
>>>>>> After 2 hours I found out that the problem is that some games
>>>>>> need to joydev module to interact with usb-hid devices as
>>>>>> the use the /dev/js interface rather then the /dev/input/event#
>>>>>> interface, once I had installed kernel-modules-extras everything
>>>>>> just worked, the module auto loaded stk recognized the gamepad
>>>>>> and things just worked (tm) which is what I believe is the
>>>>>> experience we want to offer ootb.
>>>>>>
>>>>>> Therefor I would like to request for the joydev module to be
>>>>>> moved from kernel-modules-extras into the main kernel-modules
>>>>>> package.
>>>>>
>>>>> A bunch of games use the means we now have to specify a "Requires:
>>>>> kernel-module(joydev)" style syntax so it doesn't matter where the
>>>>> module resides (sorry, don't know the exact syntax offhand).
>>>>
>>>> I do not think that sprinkling "Requires: kernel-module(joydev)"
>>>> all over the place for something which is really just core functionality
>>>> which apps should be able to rely on is a good idea. Esp. not when
>>>> we are talking about a module which is 6784 bytes on the filesystem.
>>>>
>>>> Also these requires have funny side effects, they cause dnf to
>>>> install kernel-debug rather then kernel-modules-extra when the
>>>> module is not already present on the system which sorta defeats the
>>>> purpose.
>>>>
>>>
>>> What rhbz is it?
>>
>> The one which you are going to create for it ?
>>
>
> No problemos, all for your love.
>
>> Just do: "dnf install joystick-support" on an F-22 system without
>> kernel-modules-extra installed to reproduce.
>>
>
> What component, strange thing called dnf, stick of joy, or kernel?
Lets start with filing a bug against dnf for this and then see from
there.
Regards,
Hans
8 years