[PATCH] configs: Correct four non-standard filenames
by Paul Bolle
These non-standard filenames have no effect on the build, but should
still be fixed since they could be confusing (to people and scripts).
Signed-off-by: Paul Bolle <pebolle(a)tiscali.nl>
---
...FIG_ALTERA_PR_IP_CORE_PLAT=n => CONFIG_ALTERA_PR_IP_CORE_PLAT} | 0
configs/fedora/generic/{CONFIG_B53_SERDES=n => CONFIG_B53_SERDES} | 0
.../{CONFIG_FPGA_MGR_ZYNQ_FPGA=n => CONFIG_FPGA_MGR_ZYNQ_FPGA} | 0
.../x86/{CONFIG_SENSORS_APPLESMC=m => CONFIG_SENSORS_APPLESMC} | 0
4 files changed, 0 insertions(+), 0 deletions(-)
rename configs/fedora/generic/{CONFIG_ALTERA_PR_IP_CORE_PLAT=n => CONFIG_ALTERA_PR_IP_CORE_PLAT} (100%)
rename configs/fedora/generic/{CONFIG_B53_SERDES=n => CONFIG_B53_SERDES} (100%)
rename configs/fedora/generic/{CONFIG_FPGA_MGR_ZYNQ_FPGA=n => CONFIG_FPGA_MGR_ZYNQ_FPGA} (100%)
rename configs/fedora/generic/x86/{CONFIG_SENSORS_APPLESMC=m => CONFIG_SENSORS_APPLESMC} (100%)
diff --git a/configs/fedora/generic/CONFIG_ALTERA_PR_IP_CORE_PLAT=n b/configs/fedora/generic/CONFIG_ALTERA_PR_IP_CORE_PLAT
similarity index 100%
rename from configs/fedora/generic/CONFIG_ALTERA_PR_IP_CORE_PLAT=n
rename to configs/fedora/generic/CONFIG_ALTERA_PR_IP_CORE_PLAT
diff --git a/configs/fedora/generic/CONFIG_B53_SERDES=n b/configs/fedora/generic/CONFIG_B53_SERDES
similarity index 100%
rename from configs/fedora/generic/CONFIG_B53_SERDES=n
rename to configs/fedora/generic/CONFIG_B53_SERDES
diff --git a/configs/fedora/generic/CONFIG_FPGA_MGR_ZYNQ_FPGA=n b/configs/fedora/generic/CONFIG_FPGA_MGR_ZYNQ_FPGA
similarity index 100%
rename from configs/fedora/generic/CONFIG_FPGA_MGR_ZYNQ_FPGA=n
rename to configs/fedora/generic/CONFIG_FPGA_MGR_ZYNQ_FPGA
diff --git a/configs/fedora/generic/x86/CONFIG_SENSORS_APPLESMC=m b/configs/fedora/generic/x86/CONFIG_SENSORS_APPLESMC
similarity index 100%
rename from configs/fedora/generic/x86/CONFIG_SENSORS_APPLESMC=m
rename to configs/fedora/generic/x86/CONFIG_SENSORS_APPLESMC
--
2.17.2
5 years, 2 months
[PATCH] configs: add arm file for CONFIG_PCI_MESON
by Paul Bolle
Commit c9c254b74995 ("minor Arm config tweaks") set CONFIG_PCI_MESON to
'y' for all shipped arm and aarch64 .config files. It didn't add the
corrresponding change to the configuration generation directory. Do so
now.
Signed-off-by: Paul Bolle <pebolle(a)tiscali.nl>
---
configs/fedora/generic/arm/CONFIG_PCI_MESON | 1 +
1 file changed, 1 insertion(+)
create mode 100644 configs/fedora/generic/arm/CONFIG_PCI_MESON
diff --git a/configs/fedora/generic/arm/CONFIG_PCI_MESON b/configs/fedora/generic/arm/CONFIG_PCI_MESON
new file mode 100644
index 000000000000..2c5ba5ddf5f8
--- /dev/null
+++ b/configs/fedora/generic/arm/CONFIG_PCI_MESON
@@ -0,0 +1 @@
+CONFIG_PCI_MESON=y
--
2.17.2
5 years, 2 months
Re: Signing Kernel Module with the Private Key
by Chris Murphy
On Thu, Jan 10, 2019 at 12:03 AM Samuel Sieb <samuel(a)sieb.net> wrote:
>
> On 1/9/19 10:03 PM, Chris Murphy wrote:
> > I'm not finding an updated version of this documentation:
> > https://docs.fedoraproject.org/en-US/Fedora/26/html/System_Administrators...
> >
> > And when I follow that, copy/pasting the perl script is stomping on my
> > kernel modules, making them zero length files. I also can't tell from
> > the documentation if this perl script should work on xz compressed
> > kernel modules, which they are by default on Fedora. I've tried it
> > both ways and still get zero length files, so I'm guessing the
> > documentation has gone stale or maybe the signing script has - not
> > sure how to troubleshoot it.
>
> That script is a badly formatted copy from a terminal window. The "\ >"
> parts are supposed to be the end of the line and the continuation marker
> of the next. The script should be
>
> perl /usr/src/kernels/$(uname -r)/scripts/sign-file sha256
> my_signing_key.priv my_signing_key_pub.der my_module.ko
>
> all on one line (in case email processing breaks it). I would assume
> the kernel module can't be compressed for the signing.
OK that fixes the zero length file problem. But I still get this
unrecognized character error, whether compressed or not.
[root@fnuc extra]# perl
/usr/src/kernels/4.19.14-300.fc29.x86_64/scripts/sign-file sha256
/home/chris/MOK.priv /home/chris/MOK.der icp.ko
Unrecognized character \x7F; marked by <-- HERE after <-- HERE near
column 1 at /usr/src/kernels/4.19.14-300.fc29.x86_64/scripts/sign-file
line 1.
[root@fnuc extra]# perl
/usr/src/kernels/4.19.14-300.fc29.x86_64/scripts/sign-file sha256
/home/chris/MOK.priv /home/chris/MOK.der splat.ko
Unrecognized character \x7F; marked by <-- HERE after <-- HERE near
column 1 at /usr/src/kernels/4.19.14-300.fc29.x86_64/scripts/sign-file
line 1.
File size and time stamp haven't changed so I'm assuming it's not signed.
--
Chris Murphy
5 years, 2 months
Signing Kernel Module with the Private Key
by Chris Murphy
crossposting devel@ and kernel@ since it's both kernel and documentation related
I'm not finding an updated version of this documentation:
https://docs.fedoraproject.org/en-US/Fedora/26/html/System_Administrators...
And when I follow that, copy/pasting the perl script is stomping on my
kernel modules, making them zero length files. I also can't tell from
the documentation if this perl script should work on xz compressed
kernel modules, which they are by default on Fedora. I've tried it
both ways and still get zero length files, so I'm guessing the
documentation has gone stale or maybe the signing script has - not
sure how to troubleshoot it.
--
Chris Murphy
5 years, 2 months
Re: Kernel 4.20 rebase plans
by Reindl Harald
Am 08.01.19 um 23:54 schrieb Joseph D. Wagner:
> IIRC, there is major performance degradation (anti-Spectre) in 4.20 that
> will be turned off by default 4.21.
>
> Will it be turned off by default in the 4.20 rebase?
that is mostly reduced with 4.20 to begin with
not even talking that 4.19.x was the badest release in the last 6 years
at all while iptables conntrack is still broken in 4.20.0 and hoepfully
will be fixed with the next updates
franly there where weeks where 3 upstream kernel updates where release
withina wekk and the bullshit of 4.19.x i still not usebale in
production after *13* point releases
> On 2019-01-08 14:31, Justin Forbes wrote:
>
>> The 4.20 kernel was released just before the end of the year, but the
>> first stable update should be dropping in the next day or two. We
>> have a 4.20 test day scheduled for Tuesday, January 15th. Depending
>> on the results of that test day, Fedora 29 will be rebased very
>> shortly afterwards, followed by F28 approximately a week later. Of
>> course the results of the test day could end up changing this, but it
>> is the current plan.
>>
>> Thanks,
>> Justin
5 years, 2 months
Kernel 4.20 rebase plans
by Justin Forbes
The 4.20 kernel was released just before the end of the year, but the
first stable update should be dropping in the next day or two. We
have a 4.20 test day scheduled for Tuesday, January 15th. Depending
on the results of that test day, Fedora 29 will be rebased very
shortly afterwards, followed by F28 approximately a week later. Of
course the results of the test day could end up changing this, but it
is the current plan.
Thanks,
Justin
5 years, 2 months