kernel May 2015

kernel@lists.fedoraproject.org

24 participants
13 discussions

Re: [kernel/f21] Make sure acpi brightness_switch is disabled (like forever in Fedora)
by Hans de Goede 29 Jul '15

29 Jul '15

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/?h=… 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

3 7

kdbus and Fedora
by Josh Boyer 08 Jul '15

08 Jul '15

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

9 19

fedora 14 kernel performance with ip forwarding workload
by Jesse Brandeburg 04 Jun '15

04 Jun '15

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

5 9

Fwd: OSSEC Alert - annun10 - Level 13 - Non standard syslog message (size too large).
by Lance Lassetter 29 May '15

29 May '15

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

2 1

Re: Backporting vmmouse kernel support to Fedora-22 kernel ?
by Josh Boyer 27 May '15

27 May '15

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=8… > > 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

3 8

[PATCH] Drop compile-fixes and upstream-reverts patches
by Josh Boyer 26 May '15

26 May '15

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

1 0

mtime of untouched files changed?
by Reindl Harald 20 May '15

20 May '15

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

3 4

[PATCH] kernel.spec: no more files in /boot
by Harald Hoyer 18 May '15

18 May '15

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

12 24

Re: Moving joydev back into the main modules package
by Hans de Goede 12 May '15

12 May '15

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

1 0

Re: Moving joydev back into the main modules package
by Hans de Goede 12 May '15

12 May '15

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

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

kernel May 2015