Re: [OS-BUILD PATCH 0/3] Add clang config framework
On Fri, 29 Sep 2023 19:31:19 - "Don Zickus (via Email Bridge)" wrote: > From: Don Zickus on gitlab.com > https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2654#note_1584466006 > > Resolving the thread as it appears stan agreed with Jan's reply below. I thought about responding to your email, but decided it would be unnecessary traffic / noise. Apologies, I didn't mean to disrupt your work, just clarify what was happening as it seemed it would affect me. But, it doesn't, so I am a happy camper. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [OS-BUILD PATCH 0/3] Add clang config framework
On Wed, 27 Sep 2023 19:26:25 - "Jan Stancek (via Email Bridge)" wrote: > From: Jan Stancek on gitlab.com > https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2654#note_1581215345 > > Yes, that shouldn't change. I was talking about copy of the file > created during build, which is immediately copied again to > partial-kernel-local*. SOURCE3001 still refers to "kernel-local" in > SOURCES, so for users nothing should change. Thanks for clarifying. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [OS-BUILD PATCH 3/3] Add clang config framework
On Wed, 27 Sep 2023 09:11:32 -
"Jan Stancek (via Email Bridge)" wrote:
> From: Jan Stancek on gitlab.com
> https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2654#note_1580183896
>
> kernel-local appears unused now, so maybe these 3 lines could be
> turned into: ```
> cp %{SOURCE3001} kernel-local partial-kernel-local-snip.config
> cp %{SOURCE3001} kernel-local partial-kernel-local-debug-snip.config
> ```
> ?
I build custom kernels using the rpmbuild method, and I still use the
kernel-local file to override default configuration settings with my
local settings. Would that still work with your proposed change? Is
there a workaround that *would* work with your proposed change? e.g.
instead of kernel-local, I use partial-kernel-local-snip.config,
copying my custom .config from make menuconfig to
SOURCES/partial-kernel-local-snip.config instead of
SOURCES/kernel-local.
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
kernel 6.5 and fedora 37, not a great combination
Hi, I build custom kernels from the fedora srpms. I built a couple of 6.5 kernels, rc0 and rc2, on fedora 37 and both worked, but had the same problems intermittently. Sometimes disk mounting would fail on boot, and sometimes disk unmounting, and stopping other services would fail on shutdown. I attribute this to the fact that 6.5 build requires systemd-udev > 252.1 and I was overriding it to the latest version in fedora 37, 251-13. I don't know if 6.5 is on the schedule for f37 before EOL, but if it is I think that systemd would have to be updated in order to avoid problems. Seems easier to just not put 6.5 on fedora 37. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: What is the current procedure to patch the kernel in the spec file?
On Wed, 31 May 2023 13:43:44 -0500 Justin Forbes wrote: > apply it in some manner. While we used to have a weird git routine > that set everything up as a git tree and did git am using the > manifest, that was a lot of unnecessary overhead, and of little value > when most development is done in the source tree now. I forgot to thank you for this. I built patches under that system, and I agree that it was a very involved procedure. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: What is the current procedure to patch the kernel in the spec file?
On Wed, 31 May 2023 14:51:54 -0400 Prarit Bhargava wrote: > Just curious ... Is there a reason you don't want to commit the > change and then build? If I understand what you are asking correctly, I am building from the srpm, so I don't have a git repository to commit the change to. I haven't used mock to build a kernel, but I think if I was, I could do exactly that, and of course that would be the way to go. I haven't switched because I have been building kernels this way for so long that I hardly have to think about it, and using mock would require me to go through a learning curve. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: What is the current procedure to patch the kernel in the spec file?
On Wed, 31 May 2023 13:43:44 -0500 Justin Forbes wrote: > Patch2: just adds it to the file manifest for the srpm. You have to > apply it in some manner. While we used to have a weird git routine > that set everything up as a git tree and did git am using the > manifest, that was a lot of unnecessary overhead, and of little value > when most development is done in the source tree now. > You need another line in the spec: > > ApplyOptionalPatch 0001-my_custom_change.patch Thanks, that is exactly what I was looking for. > Of note, the linux-kernel-test.patch is also meant to facilitate > people doing quick builds with a patch in dist-git. You could 'cat > 0001-my_custom_change.patch > linux-kernel-test.patch' and not have to > touch the spec at all. I eventually figured that out. :-) ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Solved: Re: What is the current procedure to patch the kernel in the spec file?
Figured it out. On Wed, 31 May 2023 11:10:01 -0700 stan via kernel wrote: > spec file directly. Can anyone point me to the current procedure? It is easy to do from the spec file. Just put the patch in the Patch99: linux-kernel-test.patch ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
What is the current procedure to patch the kernel in the spec file?
It has been ages since I wanted to patch the kernel when I built a
custom kernel. I tried putting the patch in the spec file where the
other patches were, but it doesn't apply. There is no error, or even
indication that it saw the patch, so I am obviously doing it
incorrectly.
I'm building the kernel from the srpm using rpmbuild. It builds fine
when unpatched. I can, of course, just untar the kernel tar file,
apply the patch, and tar it. But, it should be simple to do from the
spec file directly. Can anyone point me to the current procedure?
Here is what is in the spec file:
```
## Patches needed for building this package
%if !%{nopatches}
Patch1: patch-%{patchversion}-redhat.patch
Patch2: 0001-my_custom_change.patch
%endif
# empty final patch to facilitate testing of kernel patches
Patch99: linux-kernel-test.patch
```
I tried it outside the if, still didn't work:
```
## Patches needed for building this package
%if !%{nopatches}
Patch1: patch-%{patchversion}-redhat.patch
%endif
Patch2: 0001-my_custom_change.patch
# empty final patch to facilitate testing of kernel patches
Patch99: linux-kernel-test.patch
```
Here is the output with this version in the spec file.
+ ApplyOptionalPatch patch-6.4-redhat.patch
+ local patch=patch-6.4-redhat.patch
+ shift
+ '[' '!' -f /home/stan/rpmbuild/SOURCES/patch-6.4-redhat.patch ']'
++ wc -l /home/stan/rpmbuild/SOURCES/patch-6.4-redhat.patch
++ awk '{print $1}'
+ local C=2978
+ '[' 2978 -gt 9 ']'
+ ApplyPatch patch-6.4-redhat.patch
+ local patch=patch-6.4-redhat.patch
+ shift
+ '[' '!' -f /home/stan/rpmbuild/SOURCES/patch-6.4-redhat.patch ']'
+ case "$patch" in
+ git --work-tree=. apply
+ ApplyOptionalPatch linux-kernel-test.patch
+ local patch=linux-kernel-test.patch
+ shift
+ '[' '!' -f /home/stan/rpmbuild/SOURCES/linux-kernel-test.patch ']'
++ wc -l /home/stan/rpmbuild/SOURCES/linux-kernel-test.patch
It finds the Patch99 patch which is empty, and in
~/rpmbuild/SOURCE like my patch, so why isn't it finding my patch?
Thanks for any help.
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Is there a change to the way that /proc/sys works? It doesn't seem to allow updates anymore.
On Fri, 26 May 2023 13:24:04 -0700 stan via kernel wrote: > On Fri, 26 May 2023 12:36:18 -0700 > stan via kernel wrote: > > > I compile a custom kernel (currently 6.4 rc1), and I have > > CONFIG_PROC_SYSCTL=y > > set in the configuration. I run a program that gathers entropy from > > the atmosphere and feeds it into the kernel entropy pool via the > > public kernel interface. When I start the program, I want to change > > the thresholds for entropy because there is no longer any shortage > > of entropy, so I want it to be kept full (4096). I do that using > > /usr/bin/echo 3967 > /proc/sys/kernel/random/write_wakeup_threshold > > I haven't checked in a while using > > cat /proc/sys/kernel/random/entropy_avail > > It used to hover around 4030 or so. But now the > > write_wakeup_threshold is 256, and the amount of entropy is 256, and > > no changes are possible. > > > > Have there been recent changes to the kernel random generation > > process? Has this been deprecated or restricted? > > It seems that this is a known issue, and I am not the only one > affected. It is > discussed in the link > below. > https://github.com/nhorman/rng-tools/issues/173 I see this from the author of LRNG. "The following patch set provides a different approach to /dev/random which is called Linux Random Number Generator (LRNG) to collect entropy within the Linux kernel. It provides the same API and ABI and can be used as a drop-in replacement." Obviously, the last sentence is false, since it caused the user input of entropy to the kernel to fail, because it changed the process. It removed the two proc/sys values as having any relevance. I'll have to see if I can ditch this LRNG since I don't need it, and from the thread above, it doesn't seem like it will work for individuals wanting to add entropy. I completely missed any discussion of this. It's too bad the author didn't add it in a way that didn't interfere with existing functionality. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Is there a change to the way that /proc/sys works? It doesn't seem to allow updates anymore.
On Fri, 26 May 2023 12:36:18 -0700 stan via kernel wrote: > I compile a custom kernel (currently 6.4 rc1), and I have > CONFIG_PROC_SYSCTL=y > set in the configuration. I run a program that gathers entropy from > the atmosphere and feeds it into the kernel entropy pool via the > public kernel interface. When I start the program, I want to change > the thresholds for entropy because there is no longer any shortage of > entropy, so I want it to be kept full (4096). I do that using > /usr/bin/echo 3967 > /proc/sys/kernel/random/write_wakeup_threshold > I haven't checked in a while using > cat /proc/sys/kernel/random/entropy_avail > It used to hover around 4030 or so. But now the > write_wakeup_threshold is 256, and the amount of entropy is 256, and > no changes are possible. > > Have there been recent changes to the kernel random generation > process? Has this been deprecated or restricted? It seems that this is a known issue, and I am not the only one affected. It is discussed in the link below. https://github.com/nhorman/rng-tools/issues/173 ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Is there a change to the way that /proc/sys works? It doesn't seem to allow updates anymore.
I compile a custom kernel (currently 6.4 rc1), and I have CONFIG_PROC_SYSCTL=y set in the configuration. I run a program that gathers entropy from the atmosphere and feeds it into the kernel entropy pool via the public kernel interface. When I start the program, I want to change the thresholds for entropy because there is no longer any shortage of entropy, so I want it to be kept full (4096). I do that using /usr/bin/echo 3967 > /proc/sys/kernel/random/write_wakeup_threshold I haven't checked in a while using cat /proc/sys/kernel/random/entropy_avail It used to hover around 4030 or so. But now the write_wakeup_threshold is 256, and the amount of entropy is 256, and no changes are possible. Have there been recent changes to the kernel random generation process? Has this been deprecated or restricted? ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Error when trying to install local custom build of kernel 6.3 rc4. Can't find kernel-libs
On Sun, 2 Apr 2023 08:53:35 -0700
stan wrote:
> I compiled the 6.3 rc4 kernel without problems. But, when I tried to
> install the resulting rpms I got the error,
> Nothing provides kernel-libs =
> 6.3.0-0.rc4.20230331git62bad54b26db.39.20230402.fc37 needed by
> kernel-tools-libs-devel-6.3.0-0.rc4.20230331git62bad54b26db.39.20230402.fc37.x86_64
>
> I looked around in koji, and there is no kernel package that provides
> this library.
>
> Here are the rpms I was trying to install.
> kernel-6.3.0-0.rc4.20230331git62bad54b26db.39.20230402.fc37.x86_64.rpm
> kernel-modules-extra-6.3.0-0.rc4.20230331git62bad54b26db.39.20230402.fc37.x86_64.rpm
> kernel-core-6.3.0-0.rc4.20230331git62bad54b26db.39.20230402.fc37.x86_64.rpm
> kernel-tools-6.3.0-0.rc4.20230331git62bad54b26db.39.20230402.fc37.x86_64.rpm
> kernel-devel-6.3.0-0.rc4.20230331git62bad54b26db.39.20230402.fc37.x86_64.rpm
> kernel-tools-libs-6.3.0-0.rc4.20230331git62bad54b26db.39.20230402.fc37.x86_64.rpm
> kernel-devel-matched-6.3.0-0.rc4.20230331git62bad54b26db.39.20230402.fc37.x86_64.rpm
> kernel-tools-libs-devel-6.3.0-0.rc4.20230331git62bad54b26db.39.20230402.fc37.x86_64.rpm
> kernel-headers-6.3.0-0.rc4.20230331git62bad54b26db.39.20230402.fc37.x86_64.rpm
> kernel-uki-virt-6.3.0-0.rc4.20230331git62bad54b26db.39.20230402.fc37.x86_64.rpm
> kernel-modules-6.3.0-0.rc4.20230331git62bad54b26db.39.20230402.fc37.x86_64.rpm
> rtla-6.3.0-0.rc4.20230331git62bad54b26db.39.20230402.fc37.x86_64.rpm
> kernel-modules-core-6.3.0-0.rc4.20230331git62bad54b26db.39.20230402.fc37.x86_64.rpm
>
> Is it possible that the library it was looking for is
> kernel-tools-libs instead of kernel-libs? That is, there was a typo
> in the requires. I didn't find it in the kernel.spec file. Maybe the
> kernel-tools.spec file? I didn't look there.
>
>
I think I found the issue. This is in the kernel.spec file,
Requires: %{package_name}-libs = %{version}-%{release} <<<<-
Provides: %{package_name}-tools-devel
%description -n %{package_name}-tools-libs-devel
This package contains the development files for the tools/ directory
from the kernel source.
I didn't take into account that it might be a macro when I searched
before.
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Error when trying to install local custom build of kernel 6.3 rc4. Can't find kernel-libs
I compiled the 6.3 rc4 kernel without problems. But, when I tried to install the resulting rpms I got the error, Nothing provides kernel-libs = 6.3.0-0.rc4.20230331git62bad54b26db.39.20230402.fc37 needed by kernel-tools-libs-devel-6.3.0-0.rc4.20230331git62bad54b26db.39.20230402.fc37.x86_64 I looked around in koji, and there is no kernel package that provides this library. Here are the rpms I was trying to install. kernel-6.3.0-0.rc4.20230331git62bad54b26db.39.20230402.fc37.x86_64.rpm kernel-modules-extra-6.3.0-0.rc4.20230331git62bad54b26db.39.20230402.fc37.x86_64.rpm kernel-core-6.3.0-0.rc4.20230331git62bad54b26db.39.20230402.fc37.x86_64.rpm kernel-tools-6.3.0-0.rc4.20230331git62bad54b26db.39.20230402.fc37.x86_64.rpm kernel-devel-6.3.0-0.rc4.20230331git62bad54b26db.39.20230402.fc37.x86_64.rpm kernel-tools-libs-6.3.0-0.rc4.20230331git62bad54b26db.39.20230402.fc37.x86_64.rpm kernel-devel-matched-6.3.0-0.rc4.20230331git62bad54b26db.39.20230402.fc37.x86_64.rpm kernel-tools-libs-devel-6.3.0-0.rc4.20230331git62bad54b26db.39.20230402.fc37.x86_64.rpm kernel-headers-6.3.0-0.rc4.20230331git62bad54b26db.39.20230402.fc37.x86_64.rpm kernel-uki-virt-6.3.0-0.rc4.20230331git62bad54b26db.39.20230402.fc37.x86_64.rpm kernel-modules-6.3.0-0.rc4.20230331git62bad54b26db.39.20230402.fc37.x86_64.rpm rtla-6.3.0-0.rc4.20230331git62bad54b26db.39.20230402.fc37.x86_64.rpm kernel-modules-core-6.3.0-0.rc4.20230331git62bad54b26db.39.20230402.fc37.x86_64.rpm Is it possible that the library it was looking for is kernel-tools-libs instead of kernel-libs? That is, there was a typo in the requires. I didn't find it in the kernel.spec file. Maybe the kernel-tools.spec file? I didn't look there. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Building custom kernel using rpmbuild with spec file gives error on cpufreq.h Is it meaningful?
On Sun, 5 Mar 2023 21:46:41 -0600 Justin Forbes wrote: > More detail on this is in > https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1903 but > for Fedora, we ship cpufreq.h in kernel-tools, not kernel-headers. Thanks! ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Building custom kernel using rpmbuild with spec file gives error on cpufreq.h Is it meaningful?
Hi,
I just built a kernel from the 6.2.2 fc37 src.rpm. It built fine, but
at the end there was a missing file warning for cpufreq.h. I build the
header files when building the kernel, so I would think that would be
included in them.
The error:
+ exit 0
File not found:
/home/stan/rpmbuild/BUILDROOT/kernel-6.2.2-300.20230305.fc37.x86_64/usr/include/cpufreq.h
absolute symlink: /lib/modules/6.2.2-300.20230305.fc37.x86_64/build ->
/usr/src/kernels/6.2.2-300.20230305.fc37.x86_64
The second one is always there, a warning about a workaround as I
understand it.
I find this in the SPEC file:
%if %{with_headers}
%files headers
/usr/include/*
%exclude %{_includedir}/cpufreq.h
%endif
When I search the BUILD tree I find:
./linux-6.2.2-300.20230305.fc37.x86_64/include/linux/cpufreq.h
./linux-6.2.2-300.20230305.fc37.x86_64/include/linux/sched/cpufreq.h
It seems that these are there but the above stanza in the SPEC file is
excluding them. Is there a reason? Is it harmless?
There is another cpufreq.h present,
./linux-6.2.2-300.20230305.fc37.x86_64/tools/power/cpupower/lib/cpufreq.h
but I am not building tools, so it is probably being ignored. Do I
have to build tools to pick this up?
Thanks.
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: [OS-BUILD PATCH] redhat: Test tmp file before deleting
On Mon, 07 Nov 2022 17:59:40 - "Prarit Bhargava (via Email Bridge)" wrote: Thanks. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [OS-BUILD PATCH] redhat: Test tmp file before deleting
On Mon, 07 Nov 2022 18:41:00 - "Herton R. Krzesinski (via Email Bridge)" wrote: > From: Herton R. Krzesinski on gitlab.com > https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2135#note_1162936472 > > Wouldn't it be better to just use ```rm -f``` instead of adding the > if? Good point. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Possible error in the 6.1 rc3 kernel spec file
Hi, I built the 6.1 rc3 kernel over the weekend, and on the first build it failed. The error was this line in the spec file: # Remove large intermediate files we no longer need to save space # rm vmlinux.o .tmp_vmlinux.btf The error was that the [a path in tmp I don't remember]/.tmp_vmlinux.btf file did not exist. There was no complaint about the vmlinux.o file. As you can see, because of the helpful comment, I knew that it was only a space issue, so I just commented the line and everything built successfully after that. Perhaps this should be protected with if [-f .tmp_vmlinux.btf] rm .tmp_vmlinux.btf fi ? I know it won't matter to the stock fedora kernel (it has to be general), but I used the new fixed number of cpus setting, after editing the config file to change the setting (from 8 to 6), and it is working fine. Just in case anyone else wants to try it. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [PATCH 0/3] pre-generated initrd and unified kernels
On Thu, 1 Sep 2022 16:24:17 +0200 Gerd Hoffmann wrote: > Wouldn't be different than local builds today, unified kernels are not > special and the signing process will work the same way it works for > non-unified kernels. > > Essentially you have the options to either sign your custom kernel > with your own keys (and add them to the uefi/shim key database) or > turn off secure boot. Thanks. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [PATCH 0/3] pre-generated initrd and unified kernels
On Wed, 31 Aug 2022 14:46:15 +0200 Gerd Hoffmann wrote: > Here is a little patch series to kick off a discussion on > pre-generated initrd images and unified kernels. Lets start with a > description of the patches: > > Patch #1 adds a dracut config file, targeting virtual machines. > Given that most physical machines have either sata or nvme disks > these days it probably boots most physical systems too. > > Patch #2 adds a sub-package with an initrd image. > > Patch #3 adds a sub-package with an unified kernel. > > The goal is to move away from initrd images being generated on the > installed machine. They are generated while building the kernel > package instead. Main motivation for this move is to make the distro > more robust and more secure. A worthy goal. > Comments? Reviews? Suggestions? How will this impact people who build a custom kernel locally? Will it still be possible? ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Latest rawhide kernel, kernel-5.19.0-0.rc6.20220714git4a57a8400075.49.fc37.src.rpm, builds but won't boot
On Tue, 26 Jul 2022 15:27:40 -0700 stan wrote: > > https://bugzilla.redhat.com/show_bug.cgi?id=2109194 I updated this with my latest update on resolving the problem. > But I have no idea where to begin looking for such a change. The latest stock fedora kernel for rawhide, 5.19.0-65.fc37.x86_64, exhibits the same problem as I reported above, except now the library that can't be found is libsystemd-core-251-3-2.fc37.so. $ ls -nZ /usr/lib/systemd/libsystemd-core-251.3-2.fc37.so -rwxr-xr-x. 1 0 0 system_u:object_r:lib_t:s0 2126024 Jul 23 03:09 /usr/lib/systemd/libsystemd-core-251.3-2.fc37.so And the system has a panic and hangs. I have tried all sorts of ways to rebuild the initramfs, that haven't worked, mentioned in the bugzilla. Same result, a brief read of the disk and then a hang with a blank screen. I've also been trying to create a kernel that doesn't require an initramfs to boot, but the Fedora kernels have the initramfs hard coded. I moved the initramfs, thinking it would try the kernel if there was no initramfs, but it turns out that the kernel builds in a rudimentary backup initramfs, and it is invoked instead of just directly booting the kernel. Meanwhile the kernel I built and installed on 20220703 continues to boot and run flawlessly, thank goodness. All of the above with the latest updates in rawhide applied. There are still some issues with erlang* and wx*, but I don't think they would impact this problem. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Latest rawhide kernel, kernel-5.19.0-0.rc6.20220714git4a57a8400075.49.fc37.src.rpm, builds but won't boot
On Wed, 20 Jul 2022 09:00:06 -0700 stan wrote: > On Wed, 20 Jul 2022 08:19:17 -0700 > stan via kernel wrote: > > > configuration options have changed. I think I will be opening a > > bugzilla against dracut, just to get their input. > > https://bugzilla.redhat.com/show_bug.cgi?id=2109194 The mass rebuild is finished, and ~4500 packages updated on my rawhide system. I rebuilt the kernel, and reinstalled it, and the initramfs is still significantly smaller than the working versions, and it still doesn't boot with an immediate hang after trying to read the disk. I downgraded both dracut and systemd to versions that worked, and they still didn't build a valid initramfs. I think that lets them off the hook. It has to be a configuration change they are responding to. But I have no idea where to begin looking for such a change. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Error during compile of 5.19 rc7 kernel, seems to be bad name.
While compiling the latest kernel (which still wouldn't boot, working on it), I got the following warning message: Makefile.config:778: No libcrypto.h found, disables jitted code injection, please install openssl-devel or libssl-dev fatal: not a git repository (or any of the parent directories): .git ... repeats about 20 times I *do* have openssl-devel installed, but there is no libcrypto.h under /usr/include. There is a crypto.h at /usr/include/openssl/crypto.h I am thinking that this is an error in the makefile, the name changed out from under it. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Latest rawhide kernel, kernel-5.19.0-0.rc6.20220714git4a57a8400075.49.fc37.src.rpm, builds but won't boot
On Wed, 20 Jul 2022 08:19:17 -0700 stan via kernel wrote: > configuration options have changed. I think I will be opening a > bugzilla against dracut, just to get their input. https://bugzilla.redhat.com/show_bug.cgi?id=2109194 ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Latest rawhide kernel, kernel-5.19.0-0.rc6.20220714git4a57a8400075.49.fc37.src.rpm, builds but won't boot
On Tue, 19 Jul 2022 15:36:09 -0700 stan via kernel wrote: > I downgraded dracut to a version (56) before the problem, and rebuilt > the initramfs for the local rc7 build. It still failed to boot with > the same symptom. So, I think that lets dracut off the hook. > Something else has changed that is causing the problem. A > configuration setting? A library it is using? > > Hundreds of packages have changed in the last few weeks. I unpacked the rc4 initramfs that works, and the rc7 initramfs that doesn't work, and there are a few differences in permissions. As you can see from this sample, the group and world readable permissions have been removed from several items in the newer dracut. These are from dracut version 57, but they were also there when using the dracut version 56 to create a new initramfs. It looks like some configuration options have changed. I think I will be opening a bugzilla against dracut, just to get their input. d 1c1 < Image: /boot/initramfs-5.19.0-0.rc4.20220701gita175eca0f3d7.36.20220703.fc37.x86_64.img: 48M --- > Image: /boot/initramfs-5.19.0-0.rc7.53.20220719.fc37.x86_64.img: 32M 3c3 < Version: dracut-056-2.fc37 --- > Version: dracut-057-1.fc37 37,57c37,57 < drwxr-xr-x 12 root root0 Apr 19 16:17 . < crw-r--r-- 1 root root 5, 1 Apr 19 16:17 dev/console < crw-r--r-- 1 root root 1, 11 Apr 19 16:17 dev/kmsg < crw-r--r-- 1 root root 1, 3 Apr 19 16:17 dev/null < crw-r--r-- 1 root root 1, 8 Apr 19 16:17 dev/random < crw-r--r-- 1 root root 1, 9 Apr 19 16:17 dev/urandom < lrwxrwxrwx 1 root root7 Apr 19 16:17 bin -> usr/bin < drwxr-xr-x 2 root root0 Apr 19 16:17 dev < drwxr-xr-x 13 root root0 Apr 19 16:17 etc < drwxr-xr-x 2 root root0 Apr 19 16:17 etc/authselect < -rw-r--r-- 1 root root 703 Apr 19 16:17 etc/authselect/nsswitch.conf < drwxr-xr-x 2 root root0 Apr 19 16:17 etc/cmdline.d < drwxr-xr-x 2 root root0 Apr 19 16:17 etc/conf.d < -rw-r--r-- 1 root root 124 Apr 19 16:17 etc/conf.d/systemd.conf < drwxr-xr-x 7 root root0 Apr 19 16:17 etc/dbus-1 < drwxr-xr-x 2 root root0 Apr 19 16:17 etc/dbus-1/interfaces < drwxr-xr-x 2 root root0 Apr 19 16:17 etc/dbus-1/services < -rw-r--r-- 1 root root 838 Mar 10 02:47 etc/dbus-1/session.conf < drwxr-xr-x 2 root root0 Apr 19 16:17 etc/dbus-1/session.d < -rw-r--r-- 1 root root 833 Mar 10 02:47 etc/dbus-1/system.conf < drwxr-xr-x 2 root root0 Apr 19 16:17 etc/dbus-1/system.d --- > drwxr-xr-x 12 root root0 Jul 18 04:21 . > crw--- 1 root root 5, 1 Jul 18 04:21 dev/console > crw--- 1 root root 1, 11 Jul 18 04:21 dev/kmsg > crw--- 1 root root 1, 3 Jul 18 04:21 dev/null > crw--- 1 root root 1, 8 Jul 18 04:21 dev/random > crw--- 1 root root 1, 9 Jul 18 04:21 dev/urandom > lrwxrwxrwx 1 root root7 Jul 18 04:21 bin -> usr/bin > drwxr-xr-x 2 root root0 Jul 18 04:21 dev > drwxr-xr-x 13 root root0 Jul 18 04:21 etc > drwxr-xr-x 2 root root0 Jul 18 04:21 etc/authselect > -rw-r--r-- 1 root root 703 Jul 18 04:21 > etc/authselect/nsswitch.conf > drwx-- 2 root root0 Jul 18 04:21 etc/cmdline.d > drwx-- 2 root root0 Jul 18 04:21 etc/conf.d > -rw--- 1 root root 124 Jul 18 04:21 etc/conf.d/systemd.conf > drwxr-xr-x 7 root root0 Jul 18 04:21 etc/dbus-1 > drwxr-xr-x 2 root root0 Jul 18 04:21 etc/dbus-1/interfaces > drwxr-xr-x 2 root root0 Jul 18 04:21 etc/dbus-1/services > -rw-r--r-- 1 root root 838 Jul 12 09:59 etc/dbus-1/session.conf > drwxr-xr-x 2 root root0 Jul 18 04:21 etc/dbus-1/session.d > -rw-r--r-- 1 root root 833 Jul 12 09:59 etc/dbus-1/system.conf > drwxr-xr-x 2 root root0 Jul 18 04:21 etc/dbus-1/system.d ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Latest rawhide kernel, kernel-5.19.0-0.rc6.20220714git4a57a8400075.49.fc37.src.rpm, builds but won't boot
On Tue, 19 Jul 2022 15:06:38 -0700 stan via kernel wrote: > You are right. I took an older kernel, regenerated the initramfs, and > it failed. The size of the initramfs was drastically smaller (~ 1/2) > than the original, as it is for the latest rc7 kernels that fail as > well (~ 3/4 of older 5.19 kernels). > > What is my next step? Open a bugzilla against dracut? Or is there a > setting I can pass to dracut that will fix this? I downgraded dracut to a version (56) before the problem, and rebuilt the initramfs for the local rc7 build. It still failed to boot with the same symptom. So, I think that lets dracut off the hook. Something else has changed that is causing the problem. A configuration setting? A library it is using? Hundreds of packages have changed in the last few weeks. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fw: Latest rawhide kernel, kernel-5.19.0-0.rc6.20220714git4a57a8400075.49.fc37.src.rpm, builds but won't boot
Forgot to copy the list. I think I am going to downgrade dracut to an older version that doesn't have problems. I have the latest release, installed today, and it exhibited the problem. Begin forwarded message: Date: Tue, 19 Jul 2022 14:56:56 -0700 From: stan To: Justin Forbes Subject: Re: Latest rawhide kernel, kernel-5.19.0-0.rc6.20220714git4a57a8400075.49.fc37.src.rpm, builds but won't boot On Tue, 19 Jul 2022 16:01:55 -0500 Justin Forbes wrote: > It sounds like you are not so far off. This doesn't seem to be a > kernel issue at all though. To verify, take a known good kernel, save > a copy of the initramfs for that one somewhere, and then regenerate > the initramfs and try to boot it. I am guessing it will fail in the > same way with a new initramfs. You are right. I took an older kernel, regenerated the initramfs, and it failed. The size of the initramfs was drastically smaller (~ 1/2) than the original, as it is for the latest rc7 kernels that fail as well (~ 3/4 of older 5.19 kernels). What is my next step? Open a bugzilla against dracut? Or is there a setting I can pass to dracut that will fix this? ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Latest rawhide kernel, kernel-5.19.0-0.rc6.20220714git4a57a8400075.49.fc37.src.rpm, builds but won't boot
On Tue, 19 Jul 2022 13:43:37 -0700 stan wrote: > Both the fedora stock 5.19 rc7 kernel and the locally built version > still fail in the same way. The error message from the stock kernel > is the same, except the text of the message is corrected to have a > period instead of a dash. The problem could be in something the > libsystemd-core library is calling, but I don't know how to get to > that. Or maybe the original error is completely unrelated, and the > error message is for a subsequent problem caused by the original > error. A further thought. Could this be caused by inconsistencies in the packages on the system? At the last dnf update today, there were 115 package conflicts preventing updates. Maybe an update after the mass rebuild will fix this issue, as everything should then be in sync. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Latest rawhide kernel, kernel-5.19.0-0.rc6.20220714git4a57a8400075.49.fc37.src.rpm, builds but won't boot
On Mon, 18 Jul 2022 11:57:08 -0700 stan via kernel wrote: > Found the problem. There is a mismatch in the file name. > The kernel should be looking for > /usr/lib/systemd/libsystemd-core-251.3-1.fc37.so > not > /usr/lib/systemd/libsystemd-core-251-3-1.fc37.so > Note the dash instead of a period in front of the 3 in the library > name the kernel is searching for. Typo! Both the fedora stock 5.19 rc7 kernel and the locally built version still fail in the same way. The error message from the stock kernel is the same, except the text of the message is corrected to have a period instead of a dash. The problem could be in something the libsystemd-core library is calling, but I don't know how to get to that. Or maybe the original error is completely unrelated, and the error message is for a subsequent problem caused by the original error. What would be the way to get more information? > Resolving this will probably resolve all my issues. It seems I was foolishly optimistic. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Latest rawhide kernel, kernel-5.19.0-0.rc6.20220714git4a57a8400075.49.fc37.src.rpm, builds but won't boot
On Mon, 18 Jul 2022 08:45:07 -0500 Justin Forbes wrote: > There were unfortunately some corner cases with retbleed mitigation > that simply did not work. Most of those should have been worked out > over the past week, but due to the way the embargo was done, there was > a whole lot of testing that just couldn't happen before the code was > merged. As this is your rebuild, the first thing I would do is see if > the proper fedora build boots on this system, and I would not work > with anything pre rc7 at this point. Doing so ensures that you are > missing valid fixes. If the fedora build boots and your build does > not, that is an interesting case to investigate. If the fedora build > does not, that should be filed as a bug and figured out as 5.19 will > be the F37 kernel. The issue started with the rc5 kernels. I installed and tried to boot the stock fedora 5.19 fc6 kernel, and it also failed, but fortunately it panicked and wrote messages to the console. The error is strange. All of the following was on one line, wrapped here /init error while loading shared libraries libsystemd-core-251-3-1.fc37.so cannot open shared object file: no such file or directory. But I have systemd-251.3-1.fc37.x86_64 installed, and the file /usr/lib/systemd/libsystemd-core-251.3-1.fc37.so exists. Found the problem. There is a mismatch in the file name. The kernel should be looking for /usr/lib/systemd/libsystemd-core-251.3-1.fc37.so not /usr/lib/systemd/libsystemd-core-251-3-1.fc37.so Note the dash instead of a period in front of the 3 in the library name the kernel is searching for. Typo! Resolving this will probably resolve all my issues. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Latest rawhide kernel, kernel-5.19.0-0.rc6.20220714git4a57a8400075.49.fc37.src.rpm, builds but won't boot
On Sun, 17 Jul 2022 11:40:14 -0700 stan wrote: > Hi, > > When I built the > kernel-5.19.0-0.rc6.20220714git4a57a8400075.49.fc37.src.rpm > using rpmbuild, it builds without any error, but fails to boot. The > rc4 kernel with the same configuration with one exception runs fine. > > The exception is the new automatic timing mitigation configuration > option. I turned it off, single user, no internet facing services, > amd cpu (as i understand it, has vulnerabilities, but fewer). So, no > complaints from the build process, but the kernel looks like it is > going to boot (the drive light comes on), and then it just stops with > a blank screen. Nothing in the journal since it fails at the start. > > I'll be building the rc6 kernel with the new option enabled to see if > that fixes things, but the kernel should still run even if the > automatic mitigation is turned off. Should I open a bugzilla for > this? kernel-5.19.0-0.rc5.20220708gite8a4e1c1bb69.44.fc37.src.rpm also fails with the same symptoms. Doesn't have the automatic mitigation option, so that isn't the cause of the failure. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Latest rawhide kernel, kernel-5.19.0-0.rc6.20220714git4a57a8400075.49.fc37.src.rpm, builds but won't boot
On Sun, 17 Jul 2022 11:40:14 -0700 stan wrote: > I'll be building the rc6 kernel with the new option enabled to see if > that fixes things, but the kernel should still run even if the > automatic mitigation is turned off. Should I open a bugzilla for > this? I built a kernel with the automatic mitigation turned on, same behavior. I then commented out all the rtla related code in the spec file, and turned off the mitigation, and still the same behavior. The only other change I see is removing cpufreq.h from the headers, but I don't think that would cause an error. So, stumped. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Latest rawhide kernel, kernel-5.19.0-0.rc6.20220714git4a57a8400075.49.fc37.src.rpm, builds but won't boot
On Sun, 17 Jul 2022 11:40:14 -0700
stan wrote:
> Hi,
>
> When I built the
> kernel-5.19.0-0.rc6.20220714git4a57a8400075.49.fc37.src.rpm
> using rpmbuild, it builds without any error, but fails to boot. The
> rc4 kernel with the same configuration with one exception runs fine.
>
> The exception is the new automatic timing mitigation configuration
> option. I turned it off, single user, no internet facing services,
> amd cpu (as i understand it, has vulnerabilities, but fewer). So, no
> complaints from the build process, but the kernel looks like it is
> going to boot (the drive light comes on), and then it just stops with
> a blank screen. Nothing in the journal since it fails at the start.
>
> I'll be building the rc6 kernel with the new option enabled to see if
> that fixes things, but the kernel should still run even if the
> automatic mitigation is turned off. Should I open a bugzilla for
> this?
I checked the difference in the spec files, and I see that the
following has been added. Perhaps it is the issue?
> BuildRequires: libtracefs-devel
1035a1037,1045
> %package -n rtla
> Summary: RTLA: Real-Time Linux Analysis tools
> %description -n rtla
> The rtla tool is a meta-tool that includes a set of commands that
> aims to analyze the real-time properties of Linux. But, instead of
> testing Linux as a black box, rtla leverages kernel tracing
> capabilities to provide precise information about the properties
> and root causes of unexpected results.
>
2313a2324,2326
> pushd tools/tracing/rtla
> %{tools_make}
> popd
2587a2601,2610
> pushd tools/tracing/rtla/
> %{tools_make} DESTDIR=%{buildroot} install
> rm -f %{buildroot}%{_bindir}/osnoise
> rm -f %{buildroot}%{_bindir}/timerlat
> (cd %{buildroot}
>
> ln -sf rtla ./%{_bindir}/osnoise
> ln -sf rtla ./%{_bindir}/timerlat
> )
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Latest rawhide kernel, kernel-5.19.0-0.rc6.20220714git4a57a8400075.49.fc37.src.rpm, builds but won't boot
Hi, When I built the kernel-5.19.0-0.rc6.20220714git4a57a8400075.49.fc37.src.rpm using rpmbuild, it builds without any error, but fails to boot. The rc4 kernel with the same configuration with one exception runs fine. The exception is the new automatic timing mitigation configuration option. I turned it off, single user, no internet facing services, amd cpu (as i understand it, has vulnerabilities, but fewer). So, no complaints from the build process, but the kernel looks like it is going to boot (the drive light comes on), and then it just stops with a blank screen. Nothing in the journal since it fails at the start. I'll be building the rc6 kernel with the new option enabled to see if that fixes things, but the kernel should still run even if the automatic mitigation is turned off. Should I open a bugzilla for this? ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Getting 'modpost: "cc_mkenc" [...] undefined!' when compiling out of tree kernel module
> On Thu, Jun 9, 2022 at 3:39 AM Mauro Moltrasio > wrote: > > Does anyone know if this is something I'm only getting? Is there a > > work around to get these builds working again? An involved workaround would be to build the kernel locally patched to include the module you want to build, I think. My reasoning is that the cc_mkenc would be available because it is being used to build the existing kernel modules. Justin will be able to validate whether this is true. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: kernel-5.18.0-0.rc1.20220408git1831fed559732b1.20.fc37.src.rpm fails to build locally
On Wed, 13 Apr 2022 13:25:44 -0500 Justin Forbes wrote: > There is no change in the build process, this is just a thing that > pops up from time to time during the merge window, not incredibly > often. Basically the problem is a merge comes in for kernel tools > which both adds something to a uapi header, and adds code in > kernel-tools which uses that new thing. Because tools are using the > userspace headers installed on the system, you are trying to build the > 5.18 kernel tools using 5.17 kernel headers. In this case, it was > upstream commit a1a5cfe70cd29 but this is not the first time it has > happened. When building kernel-headers as a separate package, it > becomes easy to build the new headers, which can then be installed to > build kernel-tools. If you are building everything all together, you > need to edit the spec to skip that failing tool, or turn off > kernel-tools all together. Then you will get a kernel-headers package > that you can install and build. That makes sense, thanks. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: kernel-5.18.0-0.rc1.20220408git1831fed559732b1.20.fc37.src.rpm fails to build locally
On Tue, 12 Apr 2022 15:23:47 -0500 Justin Forbes wrote: > And now you see why kernel-headers is a separate package for Fedora, > you can't build the tools without installed kernel headers from the > same kernel. For a quick work around, install > kernel-headers-5.18.0-0.rc2.git0.1.fc37 I'm also building the header package for the kernel at the same time as the tools, and this has worked without issue before 5.18. That is, when a new kernel version came out, I just built kernel, tools, and headers as usual, and never had a problem. There must have been some change in the build process with the introduction of 5.18. Thanks for the workaround. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: kernel-5.18.0-0.rc1.20220408git1831fed559732b1.20.fc37.src.rpm fails to build locally
On Mon, 11 Apr 2022 10:53:54 -0500
Justin Forbes wrote:
> Coming soon to the kernel-ark repo, but the fix is easy in the spec:
>
> diff --git a/kernel.spec b/kernel.spec
> index fb67ab956..515942496 100755
> --- a/kernel.spec
> +++ b/kernel.spec
> @@ -2249,7 +2249,7 @@ chmod +x
> tools/power/cpupower/utils/version-gen.sh %{make}
> CFLAGS+="-D_GNU_SOURCE -Iinclude -I/usr/include/libnl3" popd
> pushd tools/arch/x86/intel_sdsi
> - %{make}
> + %{tools_make}
> popd
> %endif
> %endif
Thanks. That got me further, but I then hit another error.
+ popd
+ pushd tools/iio/
+ /usr/bin/make V=1 'HOSTCFLAGS=-O2 -fexceptions -g
-grecord-gcc-switches -pipe -Wall -Werror=format-security
-Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
-fstack-protector-strong
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
-fasynchronous-unwind-tables -fstack-clash-protection
-fcf-protection' 'HOSTLDFLAGS=-Wl,-z,relro -Wl,--as-needed
-Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -Wl,--build-id=sha1
-Wl,-dT,/home/stan/rpmbuild/BUILD/kernel-5.18-rc1-184-g1831fed559732b1/.package_note-kernel-5.18.0-0.rc1.20220408git1831fed559732b1.20.20220410.fc37.x86_64.ld'
'CFLAGS=-O2 -fexceptions -g -grecord-gcc-switches -pipe -Wall
-Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
-Wp,-D_GLIBCXX_ASSERTIONS
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
-fstack-protector-strong
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
-fasynchronous-unwind-tables -fstack-clash-protection
-fcf-protection' 'LDFLAGS=-Wl,-z,relro -Wl,--as-needed -Wl,-z,now
-specs=/usr/lib/rpm/redhat/redhat-hardened-ld
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -Wl,--build-id=sha1
-Wl,-dT,/home/stan/rpmbuild/BUILD/kernel-5.18-rc1-184-g1831fed559732b1/.package_note-kernel-5.18.0-0.rc1.20220408git1831fed559732b1.20.20220410.fc37.x86_64.ld'
V=1
iio_utils.c: In function 'iioutils_break_up_name':
iio_utils.c:65:15: warning: implicit declaration of function 'asprintf'; did
you mean 'vsprintf'? [-Wimplicit-function-declaration]
65 | ret = asprintf(generic_name, "%s_%s", prefix, working);
| ^~~~
| vsprintf
iio_event_monitor.c:71:10: error: 'IIO_EV_TYPE_MAG_REFERENCED' undeclared here
(not in a function); did you mean 'IIO_EV_TYPE_MAG_ADAPTIVE'?
71 | [IIO_EV_TYPE_MAG_REFERENCED] = "mag_referenced",
| ^~
| IIO_EV_TYPE_MAG_ADAPTIVE
iio_event_monitor.c:71:10: error: array index in initializer not of integer type
iio_event_monitor.c:71:10: note: (near initialization for 'iio_ev_type_text')
iio_event_monitor.c: In function 'main':
iio_event_monitor.c:353:23: warning: implicit declaration of function
'asprintf'; did you mean 'vsprintf'? [-Wimplicit-function-declaration]
353 | ret = asprintf(&chrdev_name, "/dev/iio:device%d",
dev_num);
| ^~~~
| vsprintf
make[1]: ***
[/home/stan/rpmbuild/BUILD/kernel-5.18-rc1-184-g1831fed559732b1/linux-5.18.0-0.rc1.20220408git1831fed559732b1.20.20220410.fc37.x86_64/tools/build/Makefile.build:97:
iio_event_monitor.o] Error 1
make: *** [Makefile:48: iio_event_monitor-in.o] Error 2
error: Bad exit status from /var/tmp/rpm-tmp.X2X12m (%build)
Bad exit status from /var/tmp/rpm-tmp.X2X12m (%build)
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: kernel-5.18.0-0.rc1.20220408git1831fed559732b1.20.fc37.src.rpm fails to build locally
On Mon, 11 Apr 2022 07:23:39 -0500 Justin Forbes wrote: > I am guessing this is because you turned on a build of kernel-tools > with it? libnl3 is only needed for kernel tools (the intel_sdsi build > is also kernel-tools only). Yeah, I build kernel-tools so that everything is aligned. But I have been building with kernel-tools all along without issue. Must be something new in 5.18 (this is my first build of a 5.18 kernel). > As to the issues with intel_sdsi, Today > would be the first fedora build, so I have not looked at what the > issues might be. It looks like it failed Friday for the same reason > in the ELN build though. I had not even checked, as the 5.17.2 builds > and the 5.16.19 builds and resulting activities kept me busy. Perhaps > Prarit might have some insight? I look forward to the analysis, and a fix. :-) Thanks. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fw: kernel-5.18.0-0.rc1.20220408git1831fed559732b1.20.fc37.src.rpm fails to build locally
So, I responded and forgot to forward to the list. Fixing. Begin forwarded message: Date: Sun, 10 Apr 2022 18:59:24 -0700 From: stan To: Sérgio Basto Subject: Re: kernel-5.18.0-0.rc1.20220408git1831fed559732b1.20.fc37.src.rpm fails to build locally On Sun, 10 Apr 2022 23:06:24 +0100 Sérgio Basto wrote: > On Sun, 2022-04-10 at 13:35 -0700, stan via kernel wrote: > > /usr/bin/ld: /tmp/cc6wxoxI.o: relocation R_X86_64_32 against > > `.rodata.str1.1' can not be used when making a PIE object; recompile > > with -fPIE > > Relocation R_X86_64_PC32 against undefined symbol , usually happens > when LDFLAGS are set with hardening and CFLAGS not . An usually > happens when configure.ac override all system flags with > CFLAGS="something" you need change it to CFLAGS+="something" > https://stackoverflow.com/a/69005262/778517 Thanks. I would never have figured that out. Or, at least it would have taken a long time. > maybe is an effect of > https://fedoraproject.org/wiki/Changes/SetBuildFlagsBuildCheck have > you tried %undefine _auto_set_build_flags ? > I'm using the default in the kernel spec, as far as I know. Which should be the rh flags with all hardening. + CFLAGS='-O2 -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection' + LDFLAGS='-Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -Wl,--build-id=sha1 -Wl,-dT,/home/stan/rpmbuild/BUILD/kernel-5.18-rc1-184-g1831fed559732b1/.package_note-kernel-5.18.0-0.rc1.20220408git1831fed559732b1.20.20220410.fc37.x86_64.ld' This is a typical compilation stanza from the build: gcc -Wp,-MMD,arch/x86/realmode/.init.o.d -nostdinc -I./arch/x86/include -I./arch/x86/include/generated -I./include -I./arch/x86/include/uapi -I./arch/x86/include/generated/uapi -I./include/uapi -I./include/generated/uapi -include ./include/linux/compiler-version.h -include ./include/linux/kconfig.h -include ./include/linux/compiler_types.h -D__KERNEL__ -fmacro-prefix-map=./= -Wall -Wundef -Werror=strict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -fshort-wchar -fno-PIE <--- -Werror=implicit-function-declaration -Werror=implicit-int -Werror=return-type -Wno-format-security -std=gnu11 -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -mno-avx -fcf-protection=none -m64 -falign-jumps=1 -falign-loops=1 -mno-80387 -mno-fp-ret-in-387 -mpreferred-stack-boundary=3 -mskip-rax-setup -mtune=generic -mno-red-zone -mcmodel=kernel -Wno-sign-compare -fno-asynchronous-unwind-tables -fno-delete-null-pointer-checks -Wno-frame-address -Wno-format-truncation -Wno-format-overflow -Wno-address-of-packed-member -O2 -fno-allow-store-data-races -Wframe-larger-than=2048 -fstack-protector-strong -Wimplicit-fallthrough=5 -Wno-main -Wno-unused-but-set-variable -Wno-unused-const-variable -fomit-frame-pointer -ftrivial-auto-var-init=zero -fno-stack-clash-protection -fzero-call-used-regs=used-gpr -fno-inline-functions-called-once -Wdeclaration-after-statement -Wvla -Wno-pointer-sign -Wcast-function-type -Wno-stringop-truncation -Wno-stringop-overflow -Wno-restrict -Wno-maybe-uninitialized -Wno-alloc-size-larger-than -fno-strict-overflow -fno-stack-check -fconserve-stack -Werror=date-time -Werror=incompatible-pointer-types -Werror=designated-init -Wno-packed-not-aligned -fplugin=./scripts/gcc-plugins/randomize_layout_plugin.so -fplugin=./scripts/gcc-plugins/stackleak_plugin.so -DRANDSTRUCT_PLUGIN -DSTACKLEAK_PLUGIN -fplugin-arg-stackleak_plugin-track-min-size=100 -fplugin-arg-stackleak_plugin-arch=x86 -DKBUILD_MODFILE='"arch/x86/realmode/init"' -DKBUILD_BASENAME='"init"' -DKBUILD_MODNAME='"init"' -D__KBUILD_MODNAME=kmod_init -c -o arch/x86/realmode/init.o arch/x86/realmode/init.c Could the -fno-PIE be the culprit? ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
kernel-5.18.0-0.rc1.20220408git1831fed559732b1.20.fc37.src.rpm fails to build locally
Information. I'm building a custom kernel from the src.rpm tuned to my system. The last 5.17 kernel built just fine. However, this 5.18 kernel fails with the following error. + popd + pushd tools/arch/x86/intel_sdsi + /usr/bin/make V=1 'HOSTCFLAGS=-O2 -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection' 'HOSTLDFLAGS=-Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -Wl,--build-id=sha1 -Wl,-dT,/home/stan/rpmbuild/BUILD/kernel-5.18-rc1-184-g1831fed559732b1/.package_note-kernel-5.18.0-0.rc1.20220408git1831fed559732b1.20.20220410.fc37.x86_64.ld' /usr/bin/ld: /tmp/cc6wxoxI.o: relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a PIE object; recompile with -fPIE /usr/bin/ld: failed to set dynamic section sizes: bad value collect2: error: ld returned 1 exit status make: *** [Makefile:13: intel_sdsi] Error 1 error: Bad exit status from /var/tmp/rpm-tmp.cIdvtt (%build) Bad exit status from /var/tmp/rpm-tmp.cIdvtt (%build) I have the new option CONFIG_X64_X32_ABI disabled, and I am wondering if it is related to that. I'm not sure why intel_sdsi is even being processed, since I don't have an intel CPU, and have intel related CONFIG options disabled in the kernel-local file. Is this an error in the SPEC file? And a note. The rpmbuild -bp kernel.spec command ran without error, but after I had configured the kernel-local file, and ran rpmbuild -bb kernel.spec it complained about a missing package, libnl3-devel. I would have thought that would be picked up by the -bp command when it expanded the source. Am I wrong, and this is normal behavior? ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora kernel emails: too much or just right?
On Tue, 8 Feb 2022 14:24:22 -0500 Donald Zickus wrote: > Hi, > > It has been awhile since we changed how this mailing list is used. As > folks have noticed, we have increased traffic significantly over the > past couple of years to reflect the activity Red Hat developers are > performing on the Fedora kernel. > > My question to this list is around the thoughts of this activity: > * Is there too much noise? Should we throttle back? > * is the volume ok? Folks have good filters? > * Other suggestions on how we use this list? > > Trying to continue to make this mailing list useful. > > Thanks for any feedback! I don't really have a dog in the fight, but I like reading the subject lines to see what is coming down the pipe for the kernel. The thing that I find annoying about the messages is how succinct they are. If someone is involved with the change, they probably just need the slight reminder. But for everyone else it would be good to have a little more flesh on the bones. Even in the body of the message there is no explanation of the purpose of the change other than the brief note. I see the same thing in rpm package descriptions (sometimes). e.g. the package description for libfoo says "this is a library for package foo." And in the kernel help messages during configuration (sometimes). e.g. the latest 5.17 kernel has something called straight line synchronization. But the description doesn't really explain what that is. I haven't got around to looking it up online yet. Should you change? Maybe not, maybe the time developers would spend upgrading the messages just isn't worth the hit to their productivity for the few consumers who aren't involved that read the messages. Anyhow, I'm fine with the level of messages in the kernel list. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Compiling a kernel from kernel-5.17.0-0.rc2.20220204gitdcb85f85fa6f.86.fc36.src.rpm fails if warnings as errors is turned on
On Mon, 7 Feb 2022 15:40:54 -0700 stan via kernel wrote: > On Mon, 7 Feb 2022 07:42:54 -0600 > Justin Forbes wrote: > > > Oh, no, the patches are in the src rpm and dist-git, they just are > > not in the os-build branch of kernel-ark yet, which is what most > > people building custom kernels are working with. Apologies, I did > > not know you were working from the srpm. > > I just tried with the latest 5.17, the rc3 src.rpm. And it had all > the same errors as the rc2 src.rpm. If the patches are applied, why > is the build still showing infinite recursion errors? And it still > complains that libperf-jvmti.so is missing when it wants to install it > into an rpm. I don't think the patches are in the source. Is there > something else I need to do? gcc was updated to gcc-12.0.1-0.6.fc36.x86_64 and the 5.17 rc3 kernel src.rpm now builds and creates packages. This is with warnings as errors turned off, and the ssl and infinite recursion warnings are still there. However, the kernel is running fine, as far as I can tell. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Compiling a kernel from kernel-5.17.0-0.rc2.20220204gitdcb85f85fa6f.86.fc36.src.rpm fails if warnings as errors is turned on
On Mon, 7 Feb 2022 07:42:54 -0600 Justin Forbes wrote: > Oh, no, the patches are in the src rpm and dist-git, they just are not > in the os-build branch of kernel-ark yet, which is what most people > building custom kernels are working with. Apologies, I did not know > you were working from the srpm. I just tried with the latest 5.17, the rc3 src.rpm. And it had all the same errors as the rc2 src.rpm. If the patches are applied, why is the build still showing infinite recursion errors? And it still complains that libperf-jvmti.so is missing when it wants to install it into an rpm. I don't think the patches are in the source. Is there something else I need to do? ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Compiling a kernel from kernel-5.17.0-0.rc2.20220204gitdcb85f85fa6f.86.fc36.src.rpm fails if warnings as errors is turned on
On Sun, 6 Feb 2022 15:25:28 -0600 Justin Forbes wrote: > Always best to check kernel-ark's "include in releases" tag to find > out if anything is required for it to build that haven't been merged > yet because review was not finished: > > https://gitlab.com/cki-project/kernel-ark/-/merge_requests?scope=all&state=opened&label_name[]=Include%20in%20Releases > > There are 2 patches required to properly build with gcc 12, both have > been submitted upstream. Thanks for both the information and the link. I'm not completely clear on what is happening, but I think you added the patches manually to build the 5.17 rc2 Fedora kernel so they are not in the src.rpm. I would have to add them to the spec myself for the kernel 5.17 rc2 to build properly with gcc 12. And once they are accepted upstream, they will be included in the src.rpm. Is that correct? ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Compiling a kernel from kernel-5.17.0-0.rc2.20220204gitdcb85f85fa6f.86.fc36.src.rpm fails if warnings as errors is turned on
On Sun, 6 Feb 2022 11:53:28 -0700 stan via kernel wrote: > When I turned off warnings as errors, the kernel compiled > successfully. This is not a problem in the 5.16 series, they compile > cleanly with warnings as errors turned on. The kernel compiled cleanly with all the warnings, but when it was writing the rpm packages it failed with File not found: /home/stan/rpmbuild/BUILDROOT/kernel-5.17.0-0.rc2.20220204gitdcb85f85fa6f.86.20220206.fc36.x86_64/usr/lib64/libperf-jvmti.so I can't find any reason why this would be true. When I compare a spec file that worked to the latest spec file, they appear to be identical in dealing with libperf-jvmti.so. And the source for the library is there under ./tools/perf/jvmti/libjvmti.c I did find that there was a switch, NO_JVMTI that would turn building this off. Has that been enabled in 5.17 kernels? I'm building tools and perf and headers as part of the custom kernel so everything is in sync when I install. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Compiling a kernel from kernel-5.17.0-0.rc2.20220204gitdcb85f85fa6f.86.fc36.src.rpm fails if warnings as errors is turned on
Hi, I'm on rawhide with latest updates, except for some that have package version conflicts. But, the latest gcc and glibc packages. First, when I was configuring, (make menuconfig), even though it said that sysfb and sysfb-simplefb were in /drivers/firmware, they weren't there. They took the setting from the last 5.16 kernel config that I used as a template. Then, when I tried to compile the 5.17 kernel from kernel-5.17.0-0.rc2.20220204gitdcb85f85fa6f.86.fc36.src.rpm it failed because I had warnings as errors, and the kernel warned about ssh version being deprecated for openssl 3. e.g. scripts/sign-file.c: In function 'read_private_key': scripts/sign-file.c:142:17: warning: 'ENGINE_load_builtin_engines' is deprecated: Since OpenSSL 3.0 [-Wdeprecated-declarations] 142 | ENGINE_load_builtin_engines(); | ^~~ There were also warnings about an infinite recursion error on the header files because of memcmp, memcpy and memset. This is puzzling to me since the kernel compiled just fine in koji. Did it use different header files? And aren't all header files protected from being read more than once? Or are Fedora kernels compiled with warnings as errors turned off? e.g. ./include/linux/fortify-string.h:269:16: note: in expansion of macro '__underlying_memcmp' 269 | return __underlying_memcmp(p, q, size); |^~~ In file included from ./include/linux/string.h:253, from ./include/linux/bitmap.h:11, from ./include/linux/cpumask.h:12, from ./arch/x86/include/asm/cpumask.h:5, from ./arch/x86/include/asm/msr.h:11, from ./arch/x86/include/asm/processor.h:22, from ./arch/x86/include/asm/timex.h:5, from ./include/linux/timex.h:65, from ./include/linux/time32.h:13, from ./include/linux/time.h:60, from ./include/linux/stat.h:19, from ./include/linux/module.h:13, from init/do_mounts.c:2: ./include/linux/fortify-string.h: In function 'strncpy': ./include/linux/fortify-string.h:51:24: warning: infinite recursion detected [-Winfinite-recursion] 51 | __FORTIFY_INLINE char *strncpy(char *p, const char *q, __kernel_size_t size) |^~~ When I turned off warnings as errors, the kernel compiled successfully. This is not a problem in the 5.16 series, they compile cleanly with warnings as errors turned on. Anyway, I am attaching the error output from the attempt with warnings as errors. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Can you point me to documentation of the kernel spec file?
On Sun, 08 Aug 2021 14:13:08 +0200 Benjamin Kircher wrote: [lots of good information snipped] Thanks for taking the time to do this. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: fedpkg clone -a kernel failed
On Thu, 05 Aug 2021 02:33:57 -
"Sampson Fung" wrote:
> rpm -qa and dnf list installed return the same result.
Thanks for the info, looks like you are in business.
> Regarding the kernel.spec issue, I reported it as
> https://bugzilla.redhat.com/show_bug.cgi?id=1990129
>
> Change the below from 1 to 0 allow rpmbuild to finish building the
> kernel RPM packages.
>
> diff kernel.spec.dist kernel.spec.works
> 202c202
> < %define with_configchecks %{?_without_configchecks:0}
> %{?!_without_configchecks:1} ---
> > %define with_configchecks %{?_without_configchecks:0}
> > %{?!_without_configchecks:0}
It might get accepted, though the policy of the fedora kernel team has
been that anyone who builds their own kernels is on their own. It
makes sense because there are so many combinatorial possibilities.
But maybe it has changed.
> If I want to learn how to read kernel.spec, where should I start?
Well, the first thing is to understand the spec file organization.
https://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html/Packagers_Guide/sect-Packagers_Guide-Creating_a_Basic_Spec_File.html
I'm not aware of any spec file documentation specific to the kernel. I
think it is institutional awareness within the fedora kernel team. You
can create a new thread here on the kernel list with something like
"can you point me to documentation of the kernel spec file" as the
subject, and maybe someone with more knowledge than me will give you
links to such documentation, if it exists.
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: fedpkg clone -a kernel failed
On Wed, 04 Aug 2021 19:35:20 - "Sampson Fung" wrote: > Finally! [snip] > I got: > $ ls -lsh > total 97M > 68K -rw-rw-r--. 1 fcc fcc 66K Aug 5 03:00 > kernel-5.13.6-200.0805.fc34.x86_64.rpm 38M -rw-rw-r--. 1 fcc fcc 38M > Aug 5 03:00 kernel-core-5.13.6-200.0805.fc34.x86_64.rpm 15M > -rw-rw-r--. 1 fcc fcc 15M Aug 5 03:00 > kernel-devel-5.13.6-200.0805.fc34.x86_64.rpm 42M -rw-rw-r--. 1 fcc > fcc 42M Aug 5 03:00 kernel-modules-5.13.6-200.0805.fc34.x86_64.rpm > 2.3M -rw-rw-r--. 1 fcc fcc 2.3M Aug 5 03:00 > kernel-modules-extra-5.13.6-200.0805.fc34.x86_64.rpm 272K -rw-rw-r--. > 1 fcc fcc 272K Aug 5 03:00 > kernel-modules-internal-5.13.6-200.0805.fc34.x86_64.rpm > > After doing `rpm -ivh kernel-5* kernel-core-5* kernel-modules-5* > kernel-devel-5*`, it booted OK. Good job. I think it would be better to use dnf -C install so that the package manager knows about the packages in its database. It is possible that it will refresh its database from the rpm database, though it didn't in the past. If you do a dnf list installed kernel\* , are your new packages in the list. Anyway, all's well that ends well. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: fedpkg clone -a kernel failed
On Wed, 04 Aug 2021 02:18:55 - "Sampson Fung" wrote: > The second run is much faster. > > build_output: > http://cwillu.com:8080/112.119.240.206/7 > > error_output: > http://cwillu.com:8080/112.119.240.206/8 > > kernel.spec: > http://cwillu.com:8080/112.119.240.206/9 My builds choke if I have this uncommented, but yours obviously need it. #config(noreplace) /etc/modprobe.d/*-blacklist.conf\ Change it to: %config(noreplace) /etc/modprobe.d/*-blacklist.conf\ On the plus side, you are almost there. The file checking only occurs as the rpms are being created. The compile successfully completed. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: fedpkg clone -a kernel failed
On Tue, 03 Aug 2021 17:02:34 - "Sampson Fung" wrote: > After installation of the reported dependency issues, building can > proceed without the previous error. Excellent! > A million thanks! You're welcome. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: fedpkg clone -a kernel failed
On Tue, 03 Aug 2021 07:00:56 -
"Sampson Fung" wrote:
This all looks OK.
Here is my relevant error output from the configuration step.
+ cp /home/stan/rpmbuild/SOURCES/generate_all_configs.sh .
+ cp /home/stan/rpmbuild/SOURCES/merge.pl .
+ cp /home/stan/rpmbuild/SOURCES/kernel-local .
+ VERSION=5.14.0
+ ./generate_all_configs.sh fedora 0
+ for i in kernel-5.14.0-x86_64*.config
+ mv kernel-5.14.0-x86_64.config kernel-5.14.0-x86_64.config.tmp
+ ./merge.pl /home/stan/rpmbuild/SOURCES/kernel-local
kernel-5.14.0-x86_64.config.tmp
+ rm kernel-5.14.0-x86_64.config.tmp
+ cp /home/stan/rpmbuild/SOURCES/process_configs.sh .
+ OPTS=
+ ./process_configs.sh kernel 5.14.0
/home/stan/rpmbuild/BUILD/kernel-5.14-rc3-38-g4010a528219e/linux-5.14.0-0.rc3.20210728git4010a528219e.32.20210731.fc35.x86_64/configs/kernel-5.14.0-x86_64.config.orig:4950:warning:
override: PSTORE_LZ4HC_COMPRESS_DEFAULT changes choice state
+ cp /home/stan/rpmbuild/SOURCES/update_scripts.sh .
+ RPM_SOURCE_DIR=/home/stan/rpmbuild/SOURCES
+ ./update_scripts.sh fedora
+ cd ..
+ find . '(' -name '*.orig' -o -name '*~' ')' -delete
Here is your error output, as you also posted, but here unwrapped
because replying wrapped it.
+ cp /home/fcc/rpmbuild/SOURCES/generate_all_configs.sh .
+ cp /home/fcc/rpmbuild/SOURCES/merge.pl .
+ cp /home/fcc/rpmbuild/SOURCES/kernel-local .
+ VERSION=5.14.0
+ ./generate_all_configs.sh fedora 1
+ for i in kernel-5.14.0-x86_64*.config
+ mv kernel-5.14.0-x86_64-debug.config kernel-5.14.0-x86_64-debug.config.tmp
+ ./merge.pl /home/fcc/rpmbuild/SOURCES/kernel-local
kernel-5.14.0-x86_64-debug.config.tmp
+ rm kernel-5.14.0-x86_64-debug.config.tmp
+ for i in kernel-5.14.0-x86_64*.config
+ mv kernel-5.14.0-x86_64.config kernel-5.14.0-x86_64.config.tmp
+ ./merge.pl /home/fcc/rpmbuild/SOURCES/kernel-local
kernel-5.14.0-x86_64.config.tmp
+ rm kernel-5.14.0-x86_64.config.tmp
+ cp /home/fcc/rpmbuild/SOURCES/process_configs.sh .
+ OPTS=
+ OPTS=' -w -n -c'
+ ./process_configs.sh -w -n -c kernel 5.14.0
error: Bad exit status from /var/tmp/rpm-tmp.yeTFEV (%prep)
Your output has an extra for loop. I'm not sure where that comes from.
The OPTS line is also different when you run process_configs.sh
I ran a diff between your spec file and mine, and I found that there
were setting changes that I have that you do not have. That first one
looks like the culprit.
%define with_configchecks %{?_without_configchecks:0}
%{?!_without_configchecks:0}
%define with_headers 1
%define with_perf 1
%define with_tools 1
# bpftool btf dump file vmlinux format c >
$RPM_BUILD_ROOT/$DevelDir/vmlinux.h
#config(noreplace) /etc/modprobe.d/*-blacklist.conf\
Try these, and see if they work for you. If they don't, I can post the
spec file and the kernel-local I use. The kernel-local is tuned to my
hardware, so won't build a system you want, but they can show if what
works here works there. I don't think it will be necessary, I think it
is the configchecks setting above that is causing the problem. I
should have thought of it, but I have been setting it for years, so
it's on autopilot.
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: fedpkg clone -a kernel failed
On Fri, 30 Jul 2021 12:07:19 -0700 stan wrote: > On Thu, 29 Jul 2021 14:55:25 - > "Sampson Fung" wrote: > > > both reads like 11.1.1 to me. I did cp .config as kernel-local > > after make menuconfig. After rm -rf ~/rpmbuild and start over, exit > > with same error. > If I get time I'll try to reproduce the issue. It has to be something > simple, a switch or configuration option, I *think*. > I looked at the output from a successful kernel build (under ~/rpmbuild/BUILD/kernel []/linux []) here using rpmbuild. I checked for the error message you received. This is the output. configs/kernel-5.14.0-x86_64.config:CONFIG_GCC_VERSION=20 configs/kernel-local:CONFIG_GCC_VERSION=110101 configs/kernel-5.14.0-armv7hl-lpae.config:CONFIG_GCC_VERSION=20 configs/kernel-5.14.0-aarch64.config:CONFIG_GCC_VERSION=20 configs/kernel-5.14.0-ppc64le.config:CONFIG_GCC_VERSION=20 configs/kernel-5.14.0-i686.config:CONFIG_GCC_VERSION=20 configs/kernel-5.14.0-armv7hl.config:CONFIG_GCC_VERSION=20 configs/kernel-5.14.0-s390x.config:CONFIG_GCC_VERSION=20 include/config/auto.conf:CONFIG_GCC_VERSION=110101 include/generated/autoconf.h:#define CONFIG_GCC_VERSION 110101 kernel/config_data:CONFIG_GCC_VERSION=110101 So the compiler version set in the kernel-local is overriding the default. Can you do a grep on your kernel-local to be sure it has the version set as above. It should be in ~/rpmbuild/SOURCES/ grep -i -e 'config_gcc_version' ~/rpmbuild/SOURCES/kernel-local You could also run the grep I did to see what it shows, in ~/rpmbuild/BUILD/kernel []/linux [] grep -i -r -e 'config_gcc_version' * | less ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: fedpkg clone -a kernel failed
On Thu, 29 Jul 2021 14:55:25 -
"Sampson Fung" wrote:
> both reads like 11.1.1 to me. I did cp .config as kernel-local
> after make menuconfig. After rm -rf ~/rpmbuild and start over, exit
> with same error.
I agree, the gcc version isn't the problem. I suggest you turn on
verbose in the spec file,
# verbose build, i.e. no silent rules and V=1
%define with_verbose %{?_with_verbose:1} %{?!_with_verbose: 1}
It is set to 0 as default.
You might as well make the other changes to the spec file at the same
time.
Then run the rpmbuild as
rpmbuild -bb kernel.spec > build_output 2> error_output
If they aren't too large, could you attach them to an email (< 30k?).
If they are too large, could you put them on fedora paste (Fedora
Pastebin at http://paste.fedoraproject.org) and provide a link. I think
fedora has fpaste to do that easily, you might have to install it.
There can be errors further back, or at least warnings, so they may
point to the problem.
If I get time I'll try to reproduce the issue. It has to be something
simple, a switch or configuration option, I *think*.
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: fedpkg clone -a kernel failed
On Wed, 28 Jul 2021 00:25:42 -
I see you got the other method working, so you really don't need this,
but I'll comment just in case someone else reads this in the far
future. :-)
"Sampson Fung" wrote:
> I got "user mockbuild does not exist - using root"
>
> $ rpm -ivh kernel-5.13.5-200.fc34.src.rpm
> Updating / installing...
>1:kernel-5.13.5-200.fc34 warning: user mockbuild does
> not exist - using root warning: user mockbuild does not exist - using
> root warning: user mockbuild does not exist - using root
Harmless.
> > Edit the kernel.spec
> file and uncomment the #define line and add something like 20210727 to
> distinguish this kernel from repository kernel.
>
> I find at line 107: # define .local, after un-comment it:
> $ rpmbuild -bp kernel.spec
> error: line 107: Unknown tag: define buildid .local
> Thus I undo and continue.
It has to be
%define buildid .local
Note the % sign in front of the define, it matters.
> > rpmbuild -bb kernel.spec
> Exit with error:
>
> Processing
> /home/fcc/rpmbuild/BUILD/kernel-5.13.5/linux-5.13.5-200.fc34.x86_64/configs/kernel-5.13.5-s390x.config
> ... done Processing
> /home/fcc/rpmbuild/BUILD/kernel-5.13.5/linux-5.13.5-200.fc34.x86_64/configs/kernel-5.13.5-x86_64-debug.config
> ... Error: Mismatches found in configuration files Found
> CONFIG_CC_VERSION_TEXT="gcc (scripts/dummy-tools/gcc)" after
> generation, had CONFIG_CC_VERSION_TEXT="gcc (GCC) 11.1.1 20210531
> (Red Hat 11.1.1-3)" in Source tree Found CONFIG_GCC_VERSION=20
> after generation, had CONFIG_GCC_VERSION=110101 in Source tree Found
> CONFIG_AS_VERSION=25000 after generation, had CONFIG_AS_VERSION=23501
> in Source tree Found CONFIG_LD_VERSION=25000 after generation, had
> CONFIG_LD_VERSION=23501 in Source tree error: Bad exit status from
> /var/tmp/rpm-tmp.wCoe4b (%prep)
>
>
> RPM build errors:
> Bad exit status from /var/tmp/rpm-tmp.wCoe4b (%prep)
You can try the below. It will show whether the installed gcc on your
system is the same as the config files are expecting.
What is the output of rpm -q gcc?
What is the output of grep -i cc_version
/home/fcc/rpmbuild/BUILD/kernel-5.13.5/linux-5.13.5-200.fc34.x86_64/configs/kernel-5.13.5-x86_64-debug.confiG
?
Are they different? I think that creating the
~/rpmbuild/SOURCES/kernel-local file will fix this.
You can turn off debug config in the kernel.spec file. Set the switch
to 0 as it is set below.
# kernel-debug
%define with_debug %{?_without_debug: 0} %{?!_without_debug: 0}
# kernel-debuginfo
%define with_debuginfo %{?_without_debuginfo: 0} %{?!_without_debuginfo: 0}
You might as well turn off PAE as well as you don't need it.
# kernel PAE (only valid for ARM (lpae))
%define with_pae %{?_without_pae: 0} %{?!_without_pae: 0}
You can also turn off the build of architectures that you are not
interested in. Add the last line to your spec (it won't be there).
%define nobuildarches i386 i686 %{arm}
%endif
%define nobuildarches i386 i686 ppc64 s390x %{arm} %{power64} aarch64 ppc64le
That should get you a little further, if the other method doesn't work
out. It is more user friendly than this technique, which is a lot more
manual. Probably why it was replaced.
I recommend you put your effort into getting the other method working.
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: fedpkg clone -a kernel failed
On Tue, 27 Jul 2021 01:41:58 - "Sampson Fung" wrote: > I am trying to build custom kernel on Fedora-34 following this > quick-doc > https://docs.fedoraproject.org/en-US/quick-docs/kernel/build-custom-kernel/ > > I got error: > # fedpkg clone -a kernel > Cloning into 'kernel'... > remote: Enumerating objects: 2656, done. > remote: Counting objects: 100% (2656/2656), done. > remote: Compressing objects: 100% (926/926), done. > fetch-pack: unexpected disconnect while reading sideband packet > fatal: early EOF > fatal: fetch-pack: invalid index-pack output > Could not execute clone: Failed to execute command. This is an old and deprecated way to do this. You can also build using the src.rpm from here https://koji.fedoraproject.org/koji/packageinfo?packageID=8 run in /home/[your home] rpmdev-setuptree to create the rpmbuild heirarchy. Then run, as *user* (important) rpm -ivh [kernel*src.rpm] to install the src.rpm in the rpmbuild heirarchy. Edit the kernel.spec file and uncomment the #define line and add something like 20210727 to distinguish this kernel from repository kernel. Run rpmbuild -bp kernel.spec in the SPECS directory of the rpmbuild heirarchy to expand the src.rpm Switch to ~/rpmbuild/BUILD/kernel[]/linux[] Then cp a /boot/config-[] of a kernel to ./.config and run make oldconfig Then run makemenuconfig and make the changes to the kernel configuration that you want in your custom kernel. Save them. Then cp the .config file to a local config to override the defaults. cp ./.config ~/rpmbuild/SOURCES/kernel-local Switch back to ~/rpmbuild/SPECS and run rpmbuild -bb kernel.spec The output rpms will be in ~/rpmbuild/RPMS/x86_64. Run dnf -C install $(ls *.rpm) in that directory to install them. Seems complicated, but really isn't. If you are going to do this a lot, you could set up a screen instance to have access to all the directories needed just by using Ctrl-A [#] to make it easier. This does not sign the kernel so it can be booted via UEFI secure boot. So, you either have to turn that off in the BIOS when running it, or create your own signing key and sign it using pesign. I recommed the former for a one off. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
SOLVED: 5.14 stable in rc1 and edid problem fixed Re: The 5.14 kernel in rawhide seems to be unstable, having lockups and failed boots, didn't occur with 5.13
The rc1 series of 5.14 kernels do not have the lockups and failed boots. On Thu, 15 Jul 2021 12:03:10 -0700 stan via test wrote: > This is a custom kernel boot message series: > > Jul 15 11:44:57 fedora kernel: [drm] Loading CAICOS > Microcode Jul 15 11:44:57 fedora kernel: radeon :01:00.0: Direct > firmware load for radeon/CAICOS_pfp.bin failed with error -2 Jul 15 > 11:44:57 fedora kernel: ni_cp: Failed to load firmware > "radeon/CAICOS_pfp.bin" Jul 15 11:44:57 fedora kernel: > [drm:evergreen_init [radeon]] *ERROR* Failed to load firmware! Jul 15 > 11:44:57 fedora kernel: radeon :01:00.0: Fatal error during GPU > init Jul 15 11:44:57 fedora kernel: [drm] radeon: finishing device. > Jul 15 11:44:57 fedora kernel: [drm] radeon: ttm finalized Jul 15 > 11:44:57 fedora kernel: radeon: probe of :01:00.0 failed with > error -2 The problem was that firmware is now compressed, and there is a configuration option to allow that so it is decoded before being sent to the device. I didn't have that option set, so the compressed firmware failed to load because it was compressed when the device was expecting valid binary. No gpu device, no scan of the EDID. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: The 5.14 kernel in rawhide seems to be unstable, having lockups and failed boots, didn't occur with 5.13
On Sun, 11 Jul 2021 12:46:28 -0700 stan wrote: > Unfortunately, it doesn't boot correctly because it fails to get the > edid from the monitor. The rest of boot goes off without a hitch, I > can login (without seeing anything) and run commands. When I get to > X, it is in some sort of vga mode with large text and flaky colors > and it is very fragile and hangs after a short time. But I can > switch from there to a virtual console, login as root, and shutdown > normally. > > The Fedora rawhide kernels do not have this issue. I can see them > probe the EDID in the messages, whereas the custom kernel doesn't. > The custom kernel built with this config file had no problem booting > into this same hardware configuration with a 5.10 kernel, so > something has changed in the settings for getting edid between then > and 5.14. > > Anyone have a suggestion for where the problem might be? I think I have found the problem. After many failed attempts to set configuration options. :-) It seems that the custom kernel fails to load microcode that is required. Has this mechanism changed in recent kernels? Is there a way to fix this? I never had to worry about microcode in the past. This is a fedora stock kernel boot message series: Jul 15 11:48:34 fedora kernel: [drm] radeon kernel modesetting enabled. Jul 15 11:48:34 fedora kernel: radeon :01:00.0: vgaarb: deactivate vga console Jul 15 11:48:34 fedora kernel: Console: switching to colour dummy device 80x25 Jul 15 11:48:34 fedora kernel: [drm] initializing kernel modesetting (CAICOS 0x1002:0x6779 0x174B:0xE164 0x00). Jul 15 11:48:34 fedora kernel: ATOM BIOS: C26401 Jul 15 11:48:34 fedora kernel: radeon :01:00.0: VRAM: 1024M 0x - 0x3FFF (1024M used) Jul 15 11:48:34 fedora kernel: radeon :01:00.0: GTT: 1024M 0x4000 - 0x7FFF Jul 15 11:48:34 fedora kernel: [drm] Detected VRAM RAM=1024M, BAR=256M Jul 15 11:48:34 fedora kernel: [drm] RAM width 64bits DDR Jul 15 11:48:34 fedora kernel: [drm] radeon: 1024M of VRAM memory ready Jul 15 11:48:34 fedora kernel: [drm] radeon: 1024M of GTT memory ready. Jul 15 11:48:34 fedora kernel: [drm] Loading CAICOS Microcode Jul 15 11:48:34 fedora kernel: [drm] Internal thermal controller without fan control Jul 15 11:48:34 fedora kernel: [drm] radeon: dpm initialized This is a custom kernel boot message series: Jul 15 11:44:57 fedora kernel: [drm] radeon kernel modesetting enabled. Jul 15 11:44:57 fedora kernel: radeon :01:00.0: vgaarb: deactivate vga console Jul 15 11:44:57 fedora kernel: Console: switching to colour dummy device 240x68 Jul 15 11:44:57 fedora kernel: [drm] initializing kernel modesetting (CAICOS 0x1002:0x6779 0x174B:0xE164 0x00). Jul 15 11:44:57 fedora kernel: ATOM BIOS: C26401 Jul 15 11:44:57 fedora kernel: radeon :01:00.0: VRAM: 1024M 0x - 0x3FFF (1024M used) Jul 15 11:44:57 fedora kernel: radeon :01:00.0: GTT: 1024M 0x4000 - 0x7FFF Jul 15 11:44:57 fedora kernel: [drm] Detected VRAM RAM=1024M, BAR=256M Jul 15 11:44:57 fedora kernel: [drm] RAM width 64bits DDR Jul 15 11:44:57 fedora kernel: [drm] radeon: 1024M of VRAM memory ready Jul 15 11:44:57 fedora kernel: [drm] radeon: 1024M of GTT memory ready. Jul 15 11:44:57 fedora kernel: [drm] Loading CAICOS Microcode Jul 15 11:44:57 fedora kernel: radeon :01:00.0: Direct firmware load for radeon/CAICOS_pfp.bin failed with error -2 Jul 15 11:44:57 fedora kernel: ni_cp: Failed to load firmware "radeon/CAICOS_pfp.bin" Jul 15 11:44:57 fedora kernel: [drm:evergreen_init [radeon]] *ERROR* Failed to load firmware! Jul 15 11:44:57 fedora kernel: radeon :01:00.0: Fatal error during GPU init Jul 15 11:44:57 fedora kernel: [drm] radeon: finishing device. Jul 15 11:44:57 fedora kernel: [drm] radeon: ttm finalized Jul 15 11:44:57 fedora kernel: radeon: probe of :01:00.0 failed with error -2 Thanks. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: The 5.14 kernel in rawhide seems to be unstable, having lockups and failed boots, didn't occur with 5.13
On Mon, 12 Jul 2021 01:11:42 -0600 Chris Murphy wrote: > You might ask in #fedora-kernel but my two cents is I generally don't > file bugs on rawhide kernels in the RHBZ. Instead I try to figure out > what part of the kernels is blowing up, and use a current version of > the MAINTAINERS file [1] to figure out where to send an email: I'm > expecting X, I'm seeing Y, here's a dmesg. In short. > > There's a ton of changes happening in the rc0 kernels, they aren't > release candidates yet. The merge window just closed, and it's 7-8 > weeks of stabilization. You can expect to be asked to bisect if it > sounds like a regression; and to test a patch. If you can't, just say > so. > > Branch is in about 4 weeks [2]. We will see current rawhide become > Fedora 35, which looks like it'll be kernel 4.14-rc5 by then. Any sort > of show stopper type bugs I'll file in RHBZ with a URL pointing to the > email I started with the upstream maintainers of the problem driver or > kernel component. That's because these bugs are potentially release > blocking bugs that'll need to get fixed before either the beta or > final milestone. And for that I use the blockerbugs app [3] to propose > it. > > > > [1] > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/MAINTAINERS?h=v5.14-rc1 > > [2] > https://fedorapeople.org/groups/schedule/f-35/f-35-key-tasks.html > > [3] > https://qa.fedoraproject.org/blockerbugs/propose_bug Thanks! ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: The 5.14 kernel in rawhide seems to be unstable, having lockups and failed boots, didn't occur with 5.13
On Sun, 11 Jul 2021 06:22:51 -0700 stan via test wrote: > I normally run custom compiled rawhide kernels tuned to my hardware. > In those I turn debugging off. I haven't been able to build one for > 5.14 yet because of a problem in the build process. I will try again > with the 20210709 kernel because it seems the fix for the error is in > that package. I was able to compile a custom kernel with the 20200709 kernel src.rpm package. So the perf fix is working; the link that used to cause an error now causes a warning, warning: absolute symlink: /lib/modules/5.14.0-0.rc0.20210709gitf55966571d5e.14.20210711.fc35.x86_64/build -> /usr/src/kernels/5.14.0-0.rc0.20210709gitf55966571d5e.14.20210711.fc35.x86_64 Unfortunately, it doesn't boot correctly because it fails to get the edid from the monitor. The rest of boot goes off without a hitch, I can login (without seeing anything) and run commands. When I get to X, it is in some sort of vga mode with large text and flaky colors and it is very fragile and hangs after a short time. But I can switch from there to a virtual console, login as root, and shutdown normally. The Fedora rawhide kernels do not have this issue. I can see them probe the EDID in the messages, whereas the custom kernel doesn't. The custom kernel built with this config file had no problem booting into this same hardware configuration with a 5.10 kernel, so something has changed in the settings for getting edid between then and 5.14. Anyone have a suggestion for where the problem might be? ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: The 5.14 kernel in rawhide seems to be unstable, having lockups and failed boots, didn't occur with 5.13
On Fri, 9 Jul 2021 06:38:08 -0700 stan via kernel wrote: > I have an install of rawhide. It is updated to latest packages in > rawhide. One of those packages is the new 5.14 kernel. It mostly > works, but I have seen three freezes during boot. Two of them just > stopped after a screen update from systemd, but one of them (the > latest) said something about a deadlock involving console and cpu. I > had to reboot, and the journal was corrupted, so I lost the message. > > I have also had several (less than 5) freezes while going about normal > business. No consistency, they just happen. > > It is early in the development cycle for 5.14, so these will probably > go away, but I wanted the issue to be raised and noted. I installed the latest kernel today, Name: kernel Version : 5.14.0 Release : 0.rc0.20210708gite9f1cbc0c411.13.fc35 and it has issues. It boots successfully to multiuser, but when I try to start X, it freezes the machine. I've attached oops from journalctl during boot. I don't know if they are the problem, but they probably shouldn't be happening. Should I open a bug for this? Trace from successful boot, but starting X froze the system. Jul 10 17:30:02 fedora kernel: ---[ end trace 13973a84f8ee267e ]--- Jul 10 17:30:02 fedora kernel: softirqs last disabled at (869): [] __irq_exit_rcu+0xec/0x110 Jul 10 17:30:02 fedora kernel: softirqs last enabled at (1102): [] __irq_exit_rcu+0xec/0x110 Jul 10 17:30:02 fedora kernel: hardirqs last disabled at (1172): [] console_unlock+0x40c/0x5e0 Jul 10 17:30:02 fedora kernel: hardirqs last enabled at (1167): [] console_unlock+0x4c1/0x5e0 Jul 10 17:30:02 fedora kernel: irq event stamp: 1161 Jul 10 17:30:02 fedora kernel: ret_from_fork+0x22/0x30 Jul 10 17:30:02 fedora kernel: ? set_kthread_struct+0x40/0x40 Jul 10 17:30:02 fedora kernel: kthread+0x149/0x170 Jul 10 17:30:02 fedora kernel: rtThreadNativeMain+0x1b/0x20 [vboxdrv] Jul 10 17:30:02 fedora kernel: rtThreadMain+0x3e/0x90 [vboxdrv] Jul 10 17:30:02 fedora kernel: ? VBoxHost_RTThreadSleepNoLog+0x40/0x40 [vboxdrv] Jul 10 17:30:02 fedora kernel: supdrvTscDeltaThread+0x3ad/0x5e0 [vboxdrv] Jul 10 17:30:02 fedora kernel: ? destroy_timer_on_stack+0x20/0x20 Jul 10 17:30:02 fedora kernel: supdrvTscMeasureDeltaOne+0x3b6/0x450 [vboxdrv] Jul 10 17:30:02 fedora kernel: ? supdrvTscMeasureDeltaCallbackUnwrapped.isra.0+0xa70/0xa70 [vboxdrv] Jul 10 17:30:02 fedora kernel: VBoxHost_RTMpOnPair+0x147/0x230 [vboxdrv] Jul 10 17:30:02 fedora kernel: ? supdrvTscMeasureDeltaCallbackUnwrapped.isra.0+0xa70/0xa70 [vboxdrv] Jul 10 17:30:02 fedora kernel: ? rtmpLinuxWrapper+0x30/0x30 [vboxdrv] Jul 10 17:30:02 fedora kernel: Call Trace: Jul 10 17:30:02 fedora kernel: CR2: 55b95932b000 CR3: 000110c9a000 CR4: 000406e0 Jul 10 17:30:02 fedora kernel: CS: 0010 DS: ES: CR0: 80050033 Jul 10 17:30:02 fedora kernel: FS: () GS:99c12ea0() knlGS: Jul 10 17:30:02 fedora kernel: R13: a8e881ef3db0 R14: 0004 R15: Jul 10 17:30:02 fedora kernel: R10: 9476db5b R11: R12: Jul 10 17:30:02 fedora kernel: RBP: a8e881ef3e08 R08: R09: 99be335cea10 Jul 10 17:30:02 fedora kernel: RDX: a8e881ef3db0 RSI: 0001 RDI: 99be335cea10 Jul 10 17:30:02 fedora kernel: RAX: 0001 RBX: c0c4c9b0 RCX: 0001 Jul 10 17:30:02 fedora kernel: RSP: 0018:a8e881ef3d28 EFLAGS: 00010202 Jul 10 17:30:02 fedora kernel: Code: ff ff 0f 0b e9 c8 fe ff ff 65 8b 05 63 fe e5 6b a9 ff ff ff 7f 0f 85 8e fe ff ff 65 8b 05 dd 0a e6 6b 85 c0 0f 84 7f fe ff ff <0f> 0b 44 3b 35 74 f2 0b 02 0f 82 7d fe ff ff 0f 0b e9 76 fe ff ff Jul 10 17:30:02 fedora kernel: RIP: 0010:smp_call_function_many_cond+0x1c7/0x3c0 Jul 10 17:30:02 fedora kernel: Hardware name: To be filled by O.E.M. To be filled by O.E.M./M5A97 LE R2.0, BIOS 2501 04/09/2014 Jul 10 17:30:02 fedora kernel: CPU: 4 PID: 5905 Comm: iprt-VBoxTscThr Tainted: G OE- --- 5.14.0-0.rc0.20210708gite9f1cbc0c411.13.fc35.x86_64 #1 Jul 10 17:30:02 fedora kernel: acpi_cpufreq binfmt_misc zram ip_tables crct10dif_pclmul crc32_pclmul radeon crc32c_intel ghash_clmulni_intel i2c_algo_bit serio_raw drm_ttm_helper ttm sp5100_tco hid_microsoft ff_memless drm_kms_helper cec hid_microsoft ff_memless drm r8169 wmi fuse ecryptfs i2c_dev [last unloaded: ipmi_msghandler] Jul 10 17:30:02 fedora kernel: Modules linked in: vboxdrv(OE) xt_CHECKSUM xt_MASQUERADE xt_conntrack ipt_REJECT nft_compat nf_nat_tftp nft_objref nf_conntrack_tftp nft_counter bridge stp llc nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables nfnetlink sunrpc
The 5.14 kernel in rawhide seems to be unstable, having lockups and failed boots, didn't occur with 5.13
I have an install of rawhide. It is updated to latest packages in rawhide. One of those packages is the new 5.14 kernel. It mostly works, but I have seen three freezes during boot. Two of them just stopped after a screen update from systemd, but one of them (the latest) said something about a deadlock involving console and cpu. I had to reboot, and the journal was corrupted, so I lost the message. I have also had several (less than 5) freezes while going about normal business. No consistency, they just happen. It is early in the development cycle for 5.14, so these will probably go away, but I wanted the issue to be raised and noted. I had no issues whatsoever with the 5.13 kernels. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: kernel 5.14 spec file problems, one solved, one unresolved, help
On Wed, 7 Jul 2021 15:55:15 -0500 Justin Forbes wrote: > No, BTF debuginfo is set on regular kernels as well. Are you building > this on a rawhide system? My build/test system here is F34, but with > bpftool-5.13.0-1.fc35.x86_64 (rebuilt against F34) it seems to pass > fine on this. I got the same error that you did when I was running an > older version of kernel-tools. In your particular user case though, > you can comment out that line. The vmlinux.h created there is only > used in 2 instances, where kernel-tools is built separately from the > kernel, and when cross compiling the kernel (because tools have to be > built native). Yes, on rawhide, running under the Fedora 5.14 kernel I am trying to custom build. Great, that is simple and straightforward. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: kernel 5.14 spec file problems, one solved, one unresolved, help
On Wed, 7 Jul 2021 10:04:07 -0700 stan via kernel wrote: > On Wed, 7 Jul 2021 10:21:01 -0500 > Justin Forbes wrote: > > > > > bpftool is a builreq, the failure there has to do with where you are > > building it. You need bpftool from 5.13 to build a 5.14 snapshot. > > The error is unclear, but that is the solution. This is actually a > > very useful bit in that we will use that vmlinux.h to build > > kernel-tools for Fedora. It is built in kernel for ELN. As I > > rebase stable Fedora to 5.13, it will require a prebuild of > > kernel-tools for 5.13 followed by the kernel build. > > I have bpftool-5.13.0-1.fc35.x86_64 installed, and that seems to have > satisfied the buildrequire. I am also building perf, tools, > headers, and devel, so that everything is in sync with the custom > kernel. That used to work fine as late as 5.10 kernels. So, my > takeaway is that this has changed, and I now need to enable the build > of vmlinux.h. > > The error message I received was that bpftool could not find BFT. I > infer from your response that turning on the build of bpf will remedy > that. It doesn't. Here is the output of a compile with bpf turned on everywhere. It shows the creation of the link that causes the problem of an upackaged file being packaged, and then the failure to build vmlinux.h using bpftool. + cp certs/signing_key.pem certs/signing_key.pem.sign + cp certs/signing_key.x509 certs/signing_key.x509.sign + mkdir -p /home/stan/rpmbuild/BUILDROOT/kernel-5.14.0-0.rc0.20210706git79160a603bdb.11.20210706.fc35.x86_64/usr/src/kernels + mv /home/stan/rpmbuild/BUILDROOT/kernel-5.14.0-0.rc0.20210706git79160a603bdb.11.20210706.fc35.x86_64/lib/modules/5.14.0-0.rc0.20210706git79160a603bdb.11.20210706.fc35.x86_64/build /home/stan/rpmbuild/BUILDROOT/kernel-5.14.0-0.rc0.20210706git79160a603bdb.11.20210706.fc35.x86_64//usr/src/kernels/5.14.0-0.rc0.20210706git79160a603bdb.11.20210706.fc35.x86_64 + ln -sf /usr/src/kernels/5.14.0-0.rc0.20210706git79160a603bdb.11.20210706.fc35.x86_64 /home/stan/rpmbuild/BUILDROOT/kernel-5.14.0-0.rc0.20210706git79160a603bdb.11.20210706.fc35.x86_64/lib/modules/5.14.0-0.rc0.20210706git79160a603bdb.11.20210706.fc35.x86_64/build + bpftool btf dump file vmlinux format c Error: failed to load BTF from vmlinux: No such file or directory error: Bad exit status from /var/tmp/rpm-tmp.Zt6DVC (%build) Bad exit status from /var/tmp/rpm-tmp.Zt6DVC (%build) I have debug builds turned off. Are they required for bpftool to work? ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: kernel 5.14 spec file problems, one solved, one unresolved, help
On Wed, 7 Jul 2021 10:21:01 -0500 Justin Forbes wrote: > > bpftool is a builreq, the failure there has to do with where you are > building it. You need bpftool from 5.13 to build a 5.14 snapshot. The > error is unclear, but that is the solution. This is actually a very > useful bit in that we will use that vmlinux.h to build kernel-tools > for Fedora. It is built in kernel for ELN. As I rebase stable Fedora > to 5.13, it will require a prebuild of kernel-tools for 5.13 followed > by the kernel build. I have bpftool-5.13.0-1.fc35.x86_64 installed, and that seems to have satisfied the buildrequire. I am also building perf, tools, headers, and devel, so that everything is in sync with the custom kernel. That used to work fine as late as 5.10 kernels. So, my takeaway is that this has changed, and I now need to enable the build of vmlinux.h. The error message I received was that bpftool could not find BFT. I infer from your response that turning on the build of bpf will remedy that. > Would need to know what link this is. I know perf messed up the > makefile and created a link in the wrong place. We don't package this > link, but our command to remove it wasn't looking in the right place. > Rather than fix this in spec, I sent a fix upstream which is applied > and waiting for the next Linus perf pull. > https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1237 but > you shouldn't be hitting that at all if you are doing a fedora build > which doesn't build perf. If it isn't that, let me know what it > actually is, since I am not seeing it in rawhide builds. But as I say above, I *am* building perf. So, this solves the second problem. I can wait for a fedora kernel that has the fix, or I can try to apply that patch manually. The main reason I'm doing this is that the Fedora kernel has the configuration option for the rtl2832 module turned on. That is to use it for its intended purpose, as a tuner, and that is reasonable. But, I use an rtl2832 as a source of atmospheric entropy. My daemon can't acquire it unless the rtl2832 is free, which it isn't with a stock Fedora kernel. The slimmed down size and reduced attack surface are just bonuses of building the custom kernel. Thanks for your help. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
kernel 5.14 spec file problems, one solved, one unresolved, help
Hi, I'm building the 5.14 kernel from kernel-5.14.0-0.rc0.20210706git79160a603bdb.11.fc35.src.rpm I've run into two issues. The first is to do with bpftool. I see in the comments that it is supposed to be disabled in Fedora. But, it still has a buildrequires:, and there is a segment of code that is not protected even if bpftool is turned off. %ifnarch armv7hl # Generate vmlinux.h and put it to kernel-devel path bpftool btf dump file vmlinux format c > $RPM_BUILD_ROOT/$DevelDir/vmlinux.h %endif Because bpftool is turned off, this chokes. The second is to do with a symbolic link. # Move the devel headers out of the root file system mkdir -p $RPM_BUILD_ROOT/usr/src/kernels mv $RPM_BUILD_ROOT/lib/modules/$KernelVer/build $RPM_BUILD_ROOT/$DevelDir # This is going to create a broken link during the build, but we don't use # it after this point. We need the link to actually point to something # when kernel-devel is installed, and a relative link doesn't work across # the F17 UsrMove feature. ln -sf $DevelDir $RPM_BUILD_ROOT/lib/modules/$KernelVer/build The comment says that symbolic link should not matter, but rpmbuild complains that files are being packaged that are not registered (?, from memory). Building something else right now, but if you need the exact error message, I can regenerate it later. This code is in prior kernel spec files without problems. It seems that something is being more assiduous now. I've tried various things to work around this, but they haven't worked. I guess that is because I don't really understand why this symbolic link is being created. What is your suggestion for how to fix this? Finally, I've built the kernel successfully several times while testing my fixes. I've noticed that ccache is not being used; it is rebuilding everything every time. Since I'm building a kernel customized to my hardware, that isn't so onerous. But, how would I enable ccache so that rebuilds are basically copy operations? Thanks for any help. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [OS-BUILD PATCHv2] [redhat] spec: package decompressor vmlinux for s390
On Tue, 9 Feb 2021 17:49:50 +0100 Patrick Talbert wrote: > On Tue, Feb 9, 2021 at 5:11 PM stan via kernel > wrote: > > > > On Tue, 09 Feb 2021 05:57:45 - > > cki-git...@redhat.com wrote: > > > > > From: CKI KWF Bot on gitlab.com > > > https://gitlab.com/cki-project/kernel-ark/-/merge_requests/883#note_504695499 > > > > > > Acked-by: Justin Forbes > > > (via approve button) > > > > """ > > From: CKI KWF Bot on gitlab.com > > https://gitlab.com/cki-project/kernel-ark/-/merge_requests/883#note_504694117 > > > > Acked-by: Don Zickus > > (via approve button) > > """ > > > > Why am I seeing hundreds of the same messages like above from the > > cki bot? They are identical except for the timestamp. Could > > someone please fix this. > > It should no longer be occurring. I apologize for the spam. > > One of the gitlab api endpoints used by our webhooks was returning an > unexpected error and it was not being handled appropriately. > > As soon as I realized it I stopped the webhook and have since pushed a > fix so the exception is handled. We've also opened an issue with > Gitlab to understand why the error was being returned by the API at > all.. > > https://gitlab.com/cki-project/kernel-webhooks/-/issues/79 Thanks, both for your *very* fast fix, and for your response. It sounds like my response was noise also, since you had already fixed things. :-) ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: [OS-BUILD PATCHv2] [redhat] spec: package decompressor vmlinux for s390
On Tue, 09 Feb 2021 05:57:45 - cki-git...@redhat.com wrote: > From: CKI KWF Bot on gitlab.com > https://gitlab.com/cki-project/kernel-ark/-/merge_requests/883#note_504695499 > > Acked-by: Justin Forbes > (via approve button) """ From: CKI KWF Bot on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/883#note_504694117 Acked-by: Don Zickus (via approve button) """ Why am I seeing hundreds of the same messages like above from the cki bot? They are identical except for the timestamp. Could someone please fix this. Date: Tue, 09 Feb 2021 05:47:38 - Date: Tue, 09 Feb 2021 05:57:45 - Date: Tue, 09 Feb 2021 06:07:49 - Date: Tue, 09 Feb 2021 06:17:55 - etc. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
kernel 5.10.11 overwrote my private UEFI key
Hi, I compile a custom kernel from the Fedora src.rpm. When I compiled the 5.10.11 kernel, it overwrote my private key when I installed it. The last 5.10 kernel I compiled and installed, 5.10.4, did not. I don't expect any kind of fix since it is a custom compile, just putting this out there as a data point in case anyone else runs into this and is scratching their head. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: virtual console scroll back isn't working anymore, I think it started with 5.10
On Fri, 11 Dec 2020 14:09:40 -0500 Chuck Anderson wrote: > On Fri, Dec 11, 2020 at 11:44:54AM -0700, stan via kernel wrote: > > The scrollback in the virtual consoles has stopped working for me. > > I think, but am not sure, that this started with the 5.10 series of > > kernels. Is this a regression, or did the kernel developers disable > > this deliberately for some reason? > > https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.9-Drops-Soft-Scrollback Thanks! ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
virtual console scroll back isn't working anymore, I think it started with 5.10
Hi, The scrollback in the virtual consoles has stopped working for me. I think, but am not sure, that this started with the 5.10 series of kernels. Is this a regression, or did the kernel developers disable this deliberately for some reason? Thanks. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: enrollment to the mailing list
On Tue, 17 Nov 2020 15:55:29 +0200 "Claudio @ Gmail" wrote: > Please add my email (cchin...@gmail.com) to your mailing list. I don't think this will work without some manual intervention. The usual way to do this is to go to https://lists.fedoraproject.org/admin/lists/kernel.lists.fedoraproject.org/ and use the signup form at the bottom. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: kernel 5.9.300 spec file has missing executable gpio-watch in tools file section
On Mon, 26 Oct 2020 14:01:31 -0500 Justin Forbes wrote: > Right, the 5.9 development kernel was built from rawhide, which does > include these things because ELN needs them. The 5.9.0-300 is in a > stable branch where all of that is stripped. I don't just copy the > spec back to old releases, I only move bring back patches, configs, > and filter changes generally. Thanks for the explanation. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: kernel 5.9.300 spec file has missing executable gpio-watch in tools file section
On Mon, 26 Oct 2020 10:54:12 -0500 Justin Forbes wrote: > It shouldn't be a merge request anyway, kernel-5.9.0-300 has > nothing to do > with ark. It is based on the F32 spec, with most of the RHELisms > stripped out. Anything relating to the build of kernel-tools is > bitrot because Fedora doesn't build kernel-tools from the kernel srpm > or kernel.spec. This will likely change with the 5.10 rebases as we > move to a src-git model, though still entirely possible that stable > updates will fail on tools because we just don't build it. > kernel-tools.spec is the appropriate place to build gpio-watch in > Fedora. OK, I only mentioned it because the last 5.9 development kernel didn't have the issue. From what you say above I think that is because development kernels and stable kernels use different spec files, right? I like to update everything in synch, kernel, headers, tools, etc. whether they need it or not. I guess I'll have to start building them separately from the src.rpms if the kernel spec gets too out of date. Thanks. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: kernel 5.9.300 spec file has missing executable gpio-watch in tools file section
On Mon, 26 Oct 2020 11:49:48 -0400
Brian Masney wrote:
> Hi Stan,
>
> I don't see a patch attached. There is also no [PATCH] subject prefix
> so the patch wasn't automatically converted to a merge request.
When I look at the list mail, neither do I. But when I look at the
mail in my sent folder, the patch is attached. So, either my mail
server dropped it, or the mailing list did. I suspect the mail server,
zoho, though I think I've successfully sent attachments in the past.
Here it is:
--- kernel.spec 2020-10-25 14:40:29.715787846 -0700
+++ kernel.spec 2020-10-25 14:06:16.766496187 -0700
@@ -2795,10 +2795,11 @@ fi
%{_bindir}/iio_generic_buffer
%{_bindir}/lsiio
%{_bindir}/lsgpio
%{_bindir}/gpio-hammer
%{_bindir}/gpio-event-mon
+%{_bindir}/gpio-watch
%{_mandir}/man1/kvm_stat*
%{_bindir}/kvm_stat
%if %{with_debuginfo}
%files -f kernel-tools-debuginfo.list -n kernel-tools-debuginfo
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
kernel 5.9.300 spec file has missing executable gpio-watch in tools file section
The src.rpm for kernel 5.9.300 failed to build rpms because gpio-watch was not included in the files section of the spec file. Putting it there allowed the kernel rpms to build. I've attached a patch file. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Solved? Re: System no longer distributes load to multiple cores for long running task
On Mon, 21 Sep 2020 12:06:27 -0700 stan wrote: > It's been a while (6 months?) since I ran a python program that uses a > 100% cpu core for hours. The last time I ran it, the task would > migrate from core to core to core, every second or so. I could see > it doing so in the various tops. > > Now, it runs on only one core, and doesn't move. > > This is more efficient from a computing perspective because there > aren't as many task switches, but it means that the core that is > running gets very hot. Since the rest of the cores are idle, I would > like to switch back to the previous behavior for this reason. Can > someone tell me how? A quick follow-up: I am running kernel 5.9 rc8 and this seems to be working again. I see the single python task switching cores approximately every 5 - 10 seconds; perfect! ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
header mismatch between tools and kernel in 5.9 rc8
Hi,
Just a heads up that there is a header file mismatch between the tools
and kernel includes in 5.9 rc8. Building from the src.rpm I get this
error.
Warning: Kernel ABI header at 'tools/include/uapi/linux/perf_event.h'
differs from latest version at 'include/uapi/linux/perf_event.h'
The difference between the two files is a single line:
< #define PERF_MEM_SNOOPX_SHIFT 38
---
> #define PERF_MEM_SNOOPX_SHIFT 37
$ diff -U5 -p tools/include/uapi/linux/perf_event.h
include/uapi/linux/perf_event.h
--- tools/include/uapi/linux/perf_event.h 2020-10-05 11:54:20.0
-0700
+++ include/uapi/linux/perf_event.h 2020-10-05 11:54:20.0 -0700
@@ -1194,11 +1194,11 @@ union perf_mem_data_src {
#define PERF_MEM_SNOOP_HITM0x10 /* snoop hit modified */
#define PERF_MEM_SNOOP_SHIFT 19
#define PERF_MEM_SNOOPX_FWD0x01 /* forward */
/* 1 free */
-#define PERF_MEM_SNOOPX_SHIFT 38
+#define PERF_MEM_SNOOPX_SHIFT 37
/* locked instruction */
#define PERF_MEM_LOCK_NA 0x01 /* not available */
#define PERF_MEM_LOCK_LOCKED 0x02 /* locked transaction */
#define PERF_MEM_LOCK_SHIFT24
I'm not sure which is the correct version, but once I know I can fix
this with a patch (the above will work), but is there a better way? I
realize that the Fedora kernel no longer builds tools directly, but
could you make this change there?
Thanks.
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: Problem building kernel 5.9 rc6 from src.rpm when perf enabled, looks to be a script error, a typo
On Tue, 29 Sep 2020 06:57:07 -0500 Justin Forbes wrote: > This is a copy paste error. Building tools is broken in F33/rawhide > due to LTO. That should fix it, though I don't always add it to test > and see where we are. You happened to catch a time when I copied too > much. Sorry about that. I never noticed it because we don't build > tools as part of the kernel.spec for Fedora, and you can't find it > because it went away the next day automatically. The spec is generated > without that line at all. Thanks for the explanation. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Problem building kernel 5.9 rc6 from src.rpm when perf enabled, looks to be a script error, a typo
I sent part of this to the devel list by mistake, correcting and
sending to the kernel list.
Hi,
When building the kernel with perf enabled from the src.rpm
kernel-5.9.0-0.rc6.20200925git171d4ff79f96.17.fc34.src.rpm
I get an error. There seems to be an error in one of the build
scripts. This was not a problem in src.rpm for
kernel-5.9.0-0.rc4.20200911git581cb3a26baf.8.fc34.src.rpm
The error seems to be in a script, and looks like a typo,
+ +# perf
/var/tmp/rpm-tmp.bbuLwN: line 499: +#: command not found
error: Bad exit status from /var/tmp/rpm-tmp.bbuLwN (%build)
Bad exit status from /var/tmp/rpm-tmp.bbuLwN (%build)
When I look in that temporary file, I find this, with the error line
marked by << error:
###
# DO it...
###
# prepare directories
rm -rf $RPM_BUILD_ROOT
mkdir -p $RPM_BUILD_ROOT/boot
mkdir -p $RPM_BUILD_ROOT/usr/libexec
cd linux-5.9.0-0.rc6.20200925git171d4ff79f96.17.20200927.fc31.x86_64
BuildKernel bzImage arch/x86/boot/bzImage 1
+# perf error
# make sure check-headers.sh is executable
chmod +x tools/perf/check-headers.sh
/usr/bin/make -s EXTRA_CFLAGS="${RPM_OPT_FLAGS}"
LDFLAGS="-Wl,-z,relro -Wl,--as-needed -Wl,-z,now
-specs=/usr/lib/rpm/redhat/redhat-hardened-ld" -C tools/perf V=1
NO_PERF_READ_VDSO32=1 NO_PERF_READ_VDSOX32=1 WERROR=0 NO_LIBUNWIND=1
HAVE_CPLUS_DEMANGLE=1 NO_GTK2=1 NO_STRLCPY=1 NO_BIONIC=1 prefix=/usr
PYTHON=/usr/bin/python3 DESTDIR=$RPM_BUILD_ROOT all
That is in the spec file, but the error isn't in the spec file.
It doesn't have the + in front of the # in the spec file.
###
# DO it...
###
# prepare directories
rm -rf $RPM_BUILD_ROOT
mkdir -p $RPM_BUILD_ROOT/boot
mkdir -p $RPM_BUILD_ROOT%{_libexecdir}
cd linux-%{KVERREL}
%if %{with_debug}
BuildKernel %make_target %kernel_image %{_use_vdso} debug
%endif
%if %{with_zfcpdump}
BuildKernel %make_target %kernel_image %{_use_vdso} zfcpdump
%endif
%if %{with_pae}
BuildKernel %make_target %kernel_image %{use_vdso} lpae
%endif
%if %{with_up}
BuildKernel %make_target %kernel_image %{_use_vdso}
%endif
%global perf_make \
%{__make} -s EXTRA_CFLAGS="${RPM_OPT_FLAGS}" LDFLAGS="%{__global_ldflags}"
%{?cross_opts} -C tools/perf V=1 NO_PERF_READ_VDSO32=1 NO_PERF_READ_VDSOX32=1
WERROR=0 NO_LIBUNWIND=1 HAVE_CPLUS_DEMANGLE=1 NO_GTK2=1 NO_STRLCPY=1
NO_BIONIC=1 prefix=%{_prefix} PYTHON=%{__python3}
%if %{with_perf}
+%global _lto_cflags %{nil}
# perf
# make sure check-headers.sh is executable
chmod +x tools/perf/check-headers.sh
%{perf_make} DESTDIR=$RPM_BUILD_ROOT all
%endif
%global tools_make \
%{make} CFLAGS="${RPM_OPT_FLAGS}" LDFLAGS="%{__global_ldflags}" V=1
Thanks for any insight.
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: System no longer distributes load to multiple cores for long running task
On Thu, 24 Sep 2020 06:42:00 -0500 Justin Forbes wrote: > On Thu, Sep 24, 2020 at 6:35 AM Florian Weimer > wrote: > > > > * Justin Forbes: > > > > > On Thu, Sep 24, 2020 at 4:34 AM Florian Weimer > > > wrote: > > >> > > >> * Chris Murphy: > > >> > > >> > On Wed, Sep 23, 2020 at 1:44 PM stan wrote: > > >> > > > >> > For what it's worth, gmail puts your emails into spam because > > >> > of the your domain's DMARC policy: > > >> > > > >> > > > >> > Authentication-Results: mx.google.com; > > >> >arc=fail (body hash mismatch); > > >> > > >> That's a Fedora mailing list configuration issue. It alters the > > >> body. > > >> > > >> These days, mailing lists need to be configured in such a way > > >> that they do not add such footers (adding headers is generally > > >> fine). > > > > > > I don't see any option to change that in the list settings. > > > > As a user/subscriber? Yes, I think it's a list administrator > > setting. > > No, as an admin. I am the admin. There are options for modifying > headers, nothing for the footer/body. I am able to post to the users and devel list with the same email address, so it must be possible. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: System no longer distributes load to multiple cores for long running task
On Wed, 23 Sep 2020 22:20:14 -0600 Chris Murphy wrote: > On Wed, Sep 23, 2020 at 1:44 PM stan wrote: > > For what it's worth, gmail puts your emails into spam because of the > your domain's DMARC policy: > > > Authentication-Results: mx.google.com; >arc=fail (body hash mismatch); >spf=pass (google.com: domain of > kernel-boun...@lists.fedoraproject.org designates 38.145.60.11 as > permitted sender) > smtp.mailfrom=kernel-boun...@lists.fedoraproject.org; >dmarc=fail (p=REJECT sp=REJECT dis=QUARANTINE) > header.from=zoho.com Thanks for the explanation! ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: Test reply Re: System no longer distributes load to multiple cores for long running task
On Thu, 24 Sep 2020 09:17:22 -0700 stan via kernel wrote: > This is a test reply to see if the setting change worked. Will post > whether I receive the email or not. I am assuming that 1 hr is enough > time to propagate the change. I received the message, so it worked, but I see by Jiri's response that this causes problems for other list members. Maybe there is the better way he suggested? ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Test reply Re: System no longer distributes load to multiple cores for long running task
On Thu, 24 Sep 2020 10:51:25 -0500 Justin Forbes wrote: > On Thu, Sep 24, 2020 at 9:47 AM Kevin Fenzi wrote: > > You may be looking for the DMARC Mitigations section under > > 'settings' in the admin interface? > > > > Both devel and users have that set to: > > > > "Replace From with list address" > > > > Just enabled that setting for kernel. We will see how it goes. > > Thanks! This is a test reply to see if the setting change worked. Will post whether I receive the email or not. I am assuming that 1 hr is enough time to propagate the change. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: System no longer distributes load to multiple cores for long running task
On Wed, 23 Sep 2020 12:44:45 -0700 stan wrote: > On Wed, 23 Sep 2020 12:08:22 + > "Gregorio ." wrote: > > > You can manually set the CPU affinity (see taskset utility) to > > decide the core(s) where to run your process, even if it is already > > running. The plot thickens. I am running a background compile using clang / rust restricted to 2 cores, and I see that it in fact behaves exactly as I remember. The tasks switch between cores regularly. Perhaps I am remembering incorrectly what happens with python scripts, and they have always remained locked on a single core. But I don't think so. I'll keep following up with my plan. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: System no longer distributes load to multiple cores for long running task
On Wed, 23 Sep 2020 12:08:22 + "Gregorio ." wrote: > You can manually set the CPU affinity (see taskset utility) to decide > the core(s) where to run your process, even if it is already running. I can see how that would work as a manual intervention. But this used to happen automatically as the default for the system. I've been trying to research this but most of the web articles available are about sharing a single core, and ensuring a fair allocation of that core's resources to several tasks. This kind of task migration to random cores while the task is running when there isn't resource contention does not seem to get much mention. The kernel documentation has the same bias. My plan right now is to compile an older kernel, say 5.5 or 5.6 where this was working by default, and see if it is still working. If it is, then it is a kernel change. If it isn't, then something changed in the Fedora configuration. That will narrow down where I have to look. I'm probably not searching correctly because I have only a vague understanding of the terminology used for scheduling tasks. And the interaction of the scheduler and NUMA. When I search the kernel mailing list, the problem isn't a lack of matches, but an overwhelming number of matches. This seems to be a very active area of development. In the end, I might just have to live with it, and use your suggestion to manually shift the task when I am present and think about it. Maybe it isn't really an issue, but it seems to me that for the CPU core in question, it is a lot like over-clocking it. Thanks for your reply. It gave me another thread to pull. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
System no longer distributes load to multiple cores for long running task
Hi, It's been a while (6 months?) since I ran a python program that uses a 100% cpu core for hours. The last time I ran it, the task would migrate from core to core to core, every second or so. I could see it doing so in the various tops. Now, it runs on only one core, and doesn't move. This is more efficient from a computing perspective because there aren't as many task switches, but it means that the core that is running gets very hot. Since the rest of the cores are idle, I would like to switch back to the previous behavior for this reason. Can someone tell me how? Thanks. PS I'm copying devel in case this isn't a kernel issue, and also because my posts to the kernel list just seem to disappear into the ether. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: Who knows how to configure mock to build the kernel locally?
On Wed, 15 Jul 2020 17:01:07 - "Mikhail Gavrilov" wrote: > Who knows how to configure mock to build the kernel locally? > I need to test some upstream patches, but I discovered that > currently, I could not build kernel locally because of pesign not > working in the mock environment. I do not want to use koji because I > have enough power PC at home with Ryzen 3950X. Here I filled bug > report https://bugzilla.redhat.com/show_bug.cgi?id=1855836 but no one > answers me. I build a custom kernel, and sign it using pesign with a locally generated key, but using rpmbuild, not mock. However, what isn't clear from your description, and my unfamiliarity with the mock build process, is whether you have a local signing key installed in your EFI public key database. If you don't, I don't think it can work. The private key that kernels are signed with when they are official Fedora kernels resides on the Fedora infrastructure. It is *not* going to be transferred to your local machine as that would be a severe security breach (it would no longer be a valid private key). So, I think you need to create a key pair on your local machine, and install the public key in the EFI database on your local machine. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: Building a custom kernel with 5.8 rc2 fails with error
On Fri, 26 Jun 2020 21:34:27 +0200 Ondrej Mosnacek wrote: > Apparently you are not the only one hitting this problem: > https://lore.kernel.org/lkml/20200609202134.GA1105@sol.localdomain/ > Seems you need to turn off CONFIG_GCC_PLUGIN_RANDSTRUCT to work around > it (but hopefully the guys will fix it in a better way eventually). > > It wasn't really hard to find the thread: > 1. `git blame kernel/smp.c` to find which commit introduced the lines > that throw the error. > 2. The commit message has a helpful link to the original patch > submission in the LKML archives. > 3. Clicked the third reply (longest subthread) to the patch itself and > read the rest of the replies in the thread. > 4. Bingo ;-) And like others in the above thread, when I turn off CONFIG_GCC_PLUGIN_RANDSTRUCT, compilation succeeds. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: Building a custom kernel with 5.8 rc2 fails with error
On Fri, 26 Jun 2020 21:34:27 +0200 Ondrej Mosnacek wrote: > Apparently you are not the only one hitting this problem: > https://lore.kernel.org/lkml/20200609202134.GA1105@sol.localdomain/ > Seems you need to turn off CONFIG_GCC_PLUGIN_RANDSTRUCT to work around > it (but hopefully the guys will fix it in a better way eventually). > > It wasn't really hard to find the thread: > 1. `git blame kernel/smp.c` to find which commit introduced the lines > that throw the error. > 2. The commit message has a helpful link to the original patch > submission in the LKML archives. > 3. Clicked the third reply (longest subthread) to the patch itself and > read the rest of the replies in the thread. > 4. Bingo ;-) Thank you! I never even thought to do a search. I just presumed it was something I had done, especially since the rawhide builds were succeeding (which in fact I had, just a long time ago). They must have that CONFIG_GCC_PLUGIN_RANDSTRUCT turned off. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: Building a custom kernel with 5.8 rc2 fails with error
On Fri, 26 Jun 2020 13:36:26 -0500 Justin Forbes wrote: > I am not sure, I haven't tried building on f31, but it does build fine > on f32. Given that the kernels gcc targets are much lower than what > we are shipping anywhere in Fedora, I would not expect that to be the > case, but it could be a bug. Thanks, a bug after all this time, while possible, seems unlikely; I'll just keep plugging away at it, trying with newer kernel packages, and by changing the new configuration options in various patterns. Maybe I'll do some diffs of the 5.7 and 5.8 files that are implicated to see if anything has changed. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: Building a custom kernel with 5.8 rc2 fails with error
On Fri, 26 Jun 2020 12:17:29 -0500 Justin Forbes wrote: > What changes are you making to your custom build? This is not > something we are hitting in rawhide. Extensive. It is tuned for my hardware, and turns off anything that isn't necessary. But I didn't change any options from what worked with 5.7. There were new configuration options with 5.8 that I left turned off; maybe it was one of them, though none of them had anything to do with smp that I could determine. I was afraid it might be something like this, but was hoping that you would be aware of some obvious change to the kernel that would cause this. Could it be related to the switch to the later version of gcc in rawhide? i.e. new flags not recognized by my older version of gcc are causing the problem. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Building a custom kernel with 5.8 rc2 fails with error
I sent the message below to the kernel list on Wednesday, and have not seen it on the list yet. So I am copying Justin, who I expect would be the person that would answer this question if possible, and resending it in case it somehow got lost in the data center move. Hi, I am trying to build a custom kernel from the src.rpm for 5.8.0.0.rc2 (kernel-5.8.0-0.rc2.20200623gitdd0d718152e4.1.fc33.src.rpm) on FC31, and it fails with the following error. I've tried two candidates so far, and both failed (0622, 0623). The same configuration works on 5.7 kernels. Can you provide any insight, or a workaround? In file included from ./arch/x86/include/asm/atomic.h:5, from ./include/linux/atomic.h:7, from ./include/linux/llist.h:51, from ./include/linux/irq_work.h:5, from kernel/smp.c:10: kernel/smp.c: In function 'smp_init': ./include/linux/compiler.h:392:38: error: call to '__compiletime_assert_156' declared with attribute error: BUILD_BUG_ON failed: offsetof(struct task_struct, wake_entry_type) - offsetof(struct task_struct, wake_entry) != offsetof(struct __call_single_data, flags) - offsetof(struct __call_single_data, llist) 392 | _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) | ^ ./include/linux/compiler.h:373:4: note: in definition of macro '__compiletime_assert' 373 |prefix ## suffix();\ |^~ ./include/linux/compiler.h:392:2: note: in expansion of macro '_compiletime_assert' 392 | _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) | ^~~ ./include/linux/build_bug.h:39:37: note: in expansion of macro 'compiletime_assert' 39 | #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg) | ^~ ./include/linux/build_bug.h:50:2: note: in expansion of macro 'BUILD_BUG_ON_MSG' 50 | BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition) | ^~~~ kernel/smp.c:687:2: note: in expansion of macro 'BUILD_BUG_ON' 687 | BUILD_BUG_ON(offsetof(struct task_struct, wake_entry_type) - offsetof(struct task_struct, wake_entry) != | ^~~~ make[1]: *** [scripts/Makefile.build:281: kernel/smp.o] Error 1 make[1]: *** Waiting for unfinished jobs ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Building a custom kernel with 5.8 rc2 fails with error
Hi, I am trying to build a custom kernel from the src.rpm for 5.8.0.0.rc2 (kernel-5.8.0-0.rc2.20200623gitdd0d718152e4.1.fc33.src.rpm) on FC31, and it fails with the following error. I've tried two candidates so far, and both failed (0622, 0623). The same configuration works on 5.7 kernels. Can you provide any insight, or a workaround? In file included from ./arch/x86/include/asm/atomic.h:5, from ./include/linux/atomic.h:7, from ./include/linux/llist.h:51, from ./include/linux/irq_work.h:5, from kernel/smp.c:10: kernel/smp.c: In function 'smp_init': ./include/linux/compiler.h:392:38: error: call to '__compiletime_assert_156' declared with attribute error: BUILD_BUG_ON failed: offsetof(struct task_struct, wake_entry_type) - offsetof(struct task_struct, wake_entry) != offsetof(struct __call_single_data, flags) - offsetof(struct __call_single_data, llist) 392 | _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) | ^ ./include/linux/compiler.h:373:4: note: in definition of macro '__compiletime_assert' 373 |prefix ## suffix();\ |^~ ./include/linux/compiler.h:392:2: note: in expansion of macro '_compiletime_assert' 392 | _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) | ^~~ ./include/linux/build_bug.h:39:37: note: in expansion of macro 'compiletime_assert' 39 | #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg) | ^~ ./include/linux/build_bug.h:50:2: note: in expansion of macro 'BUILD_BUG_ON_MSG' 50 | BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition) | ^~~~ kernel/smp.c:687:2: note: in expansion of macro 'BUILD_BUG_ON' 687 | BUILD_BUG_ON(offsetof(struct task_struct, wake_entry_type) - offsetof(struct task_struct, wake_entry) != | ^~~~ make[1]: *** [scripts/Makefile.build:281: kernel/smp.o] Error 1 make[1]: *** Waiting for unfinished jobs ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: [ARK PATCH 2/2] x86, hypervisor: Update hypervisor macro for rh_check_supported
On Thu, 14 May 2020 20:20:52 - GitLab Bridge on behalf of dzickusrh wrote: > From: Don Zickus > > Upstream status: RHEL only > > The variable x86_hyper_type is hidden behind a macro and not available > when guest mode is not config'd enabled. > > Update to use hypervisor_is_type() macro, available since Thanks for fixing this. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: RHEL-specific patches in Fedora (non ELN) (was: Re: Building custom kernel from src.rpm fails for kernel 5.7)
On Tue, 12 May 2020 11:21:59 -0500 Justin Forbes wrote: > The ELN kernel does build with them enabled. The original build > failure here was due to one not being wrapped, and it should be fixed. After I saw this, I pulled the latest src.rpm from koji, rc7, and tried building it. I still had to patch it for the original error, though after that it built successfully, and is now running. Is that because the fix is still in the pipeline and hadn't yet made it into rc7? Thanks. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: Building custom kernel from src.rpm fails for kernel 5.7
On Mon, 11 May 2020 14:20:35 -0400 Don Zickus wrote: > Odd, the ELN build didn't fail for that reason. > > You should able to wrap rh_check_supported() with > > #ifdef CONFIG_RHEL_DIFFERENCES > ... > #endif > > (as I am pretty sure your config has the disabled) It does. > OR > > s/x86_hyper_type != > X86_HYPER_NATIVE/!hypervisor_is_type(X86_HYPER_NATIVE)/ I saw that, but I wasn't familiar enough with what is going on to know if that would only take me down the rabbit hole because something else was missing because of the failed extern definition of x86_hyper_native. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: Building custom kernel from src.rpm fails for kernel 5.7
On Mon, 11 May 2020 09:44:54 -0700 stan wrote: > On Mon, 11 May 2020 11:30:26 -0500 > Justin Forbes wrote: > > > when building the kernel with multiple threads, it is entirely > > possible that the failure happens in one thread, but the remaining > > threads make noise while they continue their current task. The error > > can end up a good bit higher in the build log. It is best to look > > through the entire log. The current 5.7 kernels do have some > > changes to support GCC 10, but they should continue to build fine > > on F31 as well, and the ELN builds of these kernels are doing > > headers and tools as well, so the spec should be working with that > > now. > > Thank you, I'll look into that. This is the actual error. arch/x86/kernel/setup.c: In function 'rh_check_supported': arch/x86/kernel/setup.c:824:11: error: 'x86_hyper_type' undeclared (first use in this function); did you mean 'x86_hyper_init'? 824 | guest = (x86_hyper_type != X86_HYPER_NATIVE || boot_cpu_has(X86_FEATURE_HYPERVISOR)); | ^~ | x86_hyper_init arch/x86/kernel/setup.c:824:11: note: each undeclared identifier is reported only once for each function it appears in At top level: arch/x86/kernel/setup.c:820:13: warning: 'rh_check_supported' defined but not used [-Wunused-function] 820 | static void rh_check_supported(void) | ^~ make[2]: *** [scripts/Makefile.build:267: arch/x86/kernel/setup.o] Error 1 make[1]: *** [scripts/Makefile.build:488: arch/x86/kernel] Error 2 make: *** [Makefile:1732: arch/x86] Error 2 make: *** Waiting for unfinished jobs ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
