Enabling vboxsf in Fedora 5.4+ kernels
by Hans de Goede
Hi all,
So vboxsf has finally landed upstream. I gave up getting it merged
directly under fs/vboxsf since despite some fs-devel folks saying
that it was as good as it is going to get (given the limitations
of the API exposed by the host) it seems that the fs subsys maintainers
did not have the time to take a look at it.
So I've send it to GKH for merging under drivers/staging instead
and somewhat to my surprise (not complaining) he send it in for
this cycle.
Since this upstream now; and despite being in staging has alread seen
multiple reviews, I would like to get this enabled for the Fedora 5.4
kernels so that shared-folders will just work for users running Fedora
as a VirtualBox guest.
So unless there are any objections I'm going to flip the
configs/fedora/generic/CONFIG_VBOXSF_FS file to m and enable this in rawhide
soon.
Regards,
Hans
3 years, 10 months
bringing back tools/perf into the kernel.spec file
by Laura Abbott
Hi,
Continuing on the theme of bringing things into Fedora, one other
task I'm currently looking at is bringing the tools building back
into the kernel.spec file for testing purposes only.
Fedora split the kernel-tools and userspace packages out into
a separate repository at least two years ago. From my perspective,
this has been a success since we've been able to avoid issues with
tools breaking kernel builds and let the userspace tools build in
a more standard way since we don't need to do all the weird hacks
to build the kernel.
This change has encountered some resistance downstream since their
workflow involves more process and splitting out into a separate
repository could potentially have more impact. I'm still working
to resolve this but as an intermediate step I'd like to bring
back the build commands into the kernel.spec file. We'd still
keep building the tools in a separate repository but this would
at least let us work towards the goal of having a common tree.
If we decide to go with the split downstream, we will remove it
again. If we decide to not go with the split downstream, I
expect Fedora will want to follow and we'll need to bring the
code back in anyway.
I don't know exactly when I'll be getting to this but this is
just a heads up that this work will be coming.
Thanks,
Laura
4 years
cleaning out some scripts from the kernel dist-git
by Laura Abbott
The kernel dist-git has a number of scripts in the script directory.
Some are used for regular work (stable-update.sh, rawhide-rc.sh,
rawhide-snapshot.sh) but some of them haven't been used in a
long time. I'd like to delete the following:
- check-patchlist.sh
- check-TODO.sh
- combine.sh
- grab-logs.sh
- newpatch.sh
Does anyone have an issue with removing these scripts?
Thanks,
Laura
4 years
Building custom kernel using rpmbuild method fails with config
conflicts between kernel-local and x86_64.config
by stan
I use the src.rpm from rawhide kernels to build a kernel custom
configured for my hardware in F31, and with a local patch, using the
old rpmbuild method. For rc5 this worked, when I tried rc7 it didn't.
And rc8 is failing with the same error. The error message is this:
scripts/gen_compile_commands.py: updating
Processing /home/stan/rpmbuild/BUILD/kernel-5.3.fc31/linux-5.4.0-0.rc8.git1.2.20191124.fc31.x86_64/configs/kernel-5.4.0-aarch64.config ... done
Processing /home/stan/rpmbuild/BUILD/kernel-5.3.fc31/linux-5.4.0-0.rc8.git1.2.20191124.fc31.x86_64/configs/kernel-5.4.0-armv7hl-lpae.config ... done
Processing /home/stan/rpmbuild/BUILD/kernel-5.3.fc31/linux-5.4.0-0.rc8.git1.2.20191124.fc31.x86_64/configs/kernel-5.4.0-armv7hl.config ... done
Processing /home/stan/rpmbuild/BUILD/kernel-5.3.fc31/linux-5.4.0-0.rc8.git1.2.20191124.fc31.x86_64/configs/kernel-5.4.0-i686.config ... done
Processing /home/stan/rpmbuild/BUILD/kernel-5.3.fc31/linux-5.4.0-0.rc8.git1.2.20191124.fc31.x86_64/configs/kernel-5.4.0-ppc64le.config ... done
Processing /home/stan/rpmbuild/BUILD/kernel-5.3.fc31/linux-5.4.0-0.rc8.git1.2.20191124.fc31.x86_64/configs/kernel-5.4.0-s390x.config ... done
Processing /home/stan/rpmbuild/BUILD/kernel-5.3.fc31/linux-5.4.0-0.rc8.git1.2.20191124.fc31.x86_64/configs/kernel-5.4.0-x86_64.config ... Found misconfigured config items, please set them to an appropriate value
/home/stan/rpmbuild/BUILD/kernel-5.3.fc31/linux-5.4.0-0.rc8.git1.2.20191124.fc31.x86_64/configs/kernel-5.4.0-x86_64.config.orig:4359:warning: override: PSTORE_LZ4HC_COMPRESS_DEFAULT changes choice state
So, kernel-local is not overriding the default kernel configuration. I
think it should; so whatever is checking the configuration consistency
has a bug, I think.
Here is where it happens in the build process:
+ ./process_configs.sh -w -n -c kernel 5.4.0
error: Bad exit status from /var/tmp/rpm-tmp.sEsDIh (%prep)
extra tokens at the end of %else directive in line 618: %else # released_kernel
extra tokens at the end of %endif directive in line 627: %endif # released_kernel
Macro expanded in comment on line 701: %{rpmversion}-%{distro_build}.tar.bz2
Macro expanded in comment on line 702: %{rpmversion}-%{distro_build}.tar.bz2
Macro expanded in comment on line 710: %{rpmversion}-redhat.patch
Bad exit status from /var/tmp/rpm-tmp.sEsDIh (%prep)
Should I open a bugzilla for this?
Thanks.
4 years
Even though I have nobuild set for architectures, rpmbuild is
processing their configs. Is this correct?
by stan
I build a custom local kernel using the rawhide kernel src.rpm here on
F31. I change the spec file to build only for my arch, x86_64, and not
to build cross headers. But I notice that the config files for all the
nobuild archs are still processed. This seems like an error to me. Is
it?
In the kernel.spec file.
%define nobuildarches i386 i686 ppc64 s390x %{arm} %{power64} aarch64 ppc64le
Output from rpmbuild -bb kernel.spec.
Processing /home/stan/rpmbuild/BUILD/kernel-5.3.fc31/linux-5.4.0-0.rc8.git1.2.20191124.fc31.x86_64/configs/kernel-5.4.0-aarch64.config ... done
Processing /home/stan/rpmbuild/BUILD/kernel-5.3.fc31/linux-5.4.0-0.rc8.git1.2.20191124.fc31.x86_64/configs/kernel-5.4.0-armv7hl-lpae.config ... done
Processing /home/stan/rpmbuild/BUILD/kernel-5.3.fc31/linux-5.4.0-0.rc8.git1.2.20191124.fc31.x86_64/configs/kernel-5.4.0-armv7hl.config ... done
Processing /home/stan/rpmbuild/BUILD/kernel-5.3.fc31/linux-5.4.0-0.rc8.git1.2.20191124.fc31.x86_64/configs/kernel-5.4.0-i686.config ... done
Processing /home/stan/rpmbuild/BUILD/kernel-5.3.fc31/linux-5.4.0-0.rc8.git1.2.20191124.fc31.x86_64/configs/kernel-5.4.0-ppc64le.config ... done
Processing /home/stan/rpmbuild/BUILD/kernel-5.3.fc31/linux-5.4.0-0.rc8.git1.2.20191124.fc31.x86_64/configs/kernel-5.4.0-s390x.config ... done
4 years
I see this statement a lot in the kernel spec file. What is its
interpretation? %if 0%{?fedora}
by stan
As the subject says, I see the %if 0%{?fedora} statement in the spec
file, and I thought I knew what it meant, but the latest additions to
the spec file have caused me to question that.
My interpretation is that without the 0, it is checking whether it is
running on fedora. With the zero, it is ignoring the branch and either
skipping the guarded statements or taking the else. Is this correct?
4 years
Updated kernel to 5.3.11, now /dev/null does not return any data
by Juha Nikkanen
Ladies and gentlemen,
I have curious problem after booting into 5.3.11. I can't read a stream of
zeroes from /dev/null anymore:
$ dd if=/dev/null of=zero.dat bs=2048 count=1
0+0 records in
0+0 records out
0 bytes copied, 0.00036764 s, 0.0 kB/s
and:
$ file /dev/null
/dev/null: character special (1/3)
$ ls -l /dev/null
crw-rw-rw-. 1 root root 1, 3 Nov 14 20:28 /dev/null
No matter if I try this as a root or as a ordinary user. Results are
exactly same. I did not test this with kernels 5.3.7 and 5.3.8, I jumped to
5.3.11 from 5.3.6 and I think 5.3.6 did provide a stream of zero data. No
strace gives anything special, just ordinary read() after dup2() and read
returns zero length for 2048 requested. Now is this a problem of kernel or
is it within dd and how it opens a /dev/null or how it flags read()
function?
Sincerely,
Juha
4 years
Some more upcoming Fedora kernel changes
by Laura Abbott
Hi,
I'm looking to bring in another piece of downstream work into Fedora
sometime next week. The short summary is that Fedora will be bringing
in some files to build against a RHEL buildroot but Fedora will still
be the same.
The longer answer:
The goal with this work is bring Fedora and RHEL closer together and
reduce work between the kernels. What we'd like to happen is that
if we build against a Fedora buildroot we bring in the Fedora kernel
configuration options and if we're building against a RHEL buildroot
we bring in the RHEL kernel configuration. What this will do is let
us test and verify configuration options easily in both RHEL and
Fedora configuration without having to do redundant work.
As a step towards this goal, I'll be bringing in some changes to
the build scripts and moving some files around. You'll see a number
of empty files brought in for the RHEL side just as a place holder.
Part of this work also involves bringing in a few certificates for
RHEL secureboot signing on powerpc and s390x.
A big part of this goal is to let Fedora do most of its work
from a src-git tree. The reason I'm working to bring parts of these
commits in now is so when it comes time to start using the src-git
tree the diff doesn't look so scary. Small changes help make sure
things aren't getting broken (I've already found a few things that
need to be fixed during the course of this work)
My goal is to still keep Fedora stable and let Fedora be Fedora.
I expect to keep tweaking the scripts to make the process easier.
If you have feedback, feel free to let me know.
You can see the tree with some other changes at
https://pagure.io/fedora-kernel-labbott/tree/ark_sync_nov8
Thanks,
Laura
4 years
