[PATCH 0/9] Clean up some old patches post F31
by Laura Abbott
I'd like to drop a bunch of patches Fedora has been carrying since
forever. Most of these are fairly minor tweaks most people forgot
we had and nobody cares about. My motivation is both in the spirit
of cleaning up and also to better align Fedora + RHEL (I had a talk
about this at Flock, video should be up soon).
If someone wants to make an effort at upstreaming any of these, feel
free to do so but I really think most of these are cruft.
Thanks,
Laura
Laura Abbott (9):
Drop namespaces config tweak
Drop cpumask auto select patch
Drop scsi warning patch
Remove ancient ath9k workaround
Drop old lis3 patch
Remove some old modalias adjustments
Remove old keyboard logging patch
Remove patch for GCC VTA
Remove crash driver
Kbuild-Add-an-option-to-enable-GCC-VTA.patch | 94 ---
ath9k-rx-dma-stop-check.patch | 38 -
.../fedora/generic/x86/x86_64/CONFIG_NR_CPUS | 2 +-
crash-driver.patch | 722 ------------------
die-floppy-die.patch | 29 -
input-kill-stupid-messages.patch | 30 -
kernel.spec | 20 -
...-CPUMASK_OFFSTACK-usable-without-deb.patch | 34 -
lis3-improve-handling-of-null-rate.patch | 75 --
namespaces-no-expert.patch | 27 -
no-pcspkr-modalias.patch | 22 -
...validate_disk-prevent-NULL-ptr-deref.patch | 39 -
12 files changed, 1 insertion(+), 1131 deletions(-)
delete mode 100644 Kbuild-Add-an-option-to-enable-GCC-VTA.patch
delete mode 100644 ath9k-rx-dma-stop-check.patch
delete mode 100644 crash-driver.patch
delete mode 100644 die-floppy-die.patch
delete mode 100644 input-kill-stupid-messages.patch
delete mode 100644 lib-cpumask-Make-CPUMASK_OFFSTACK-usable-without-deb.patch
delete mode 100644 lis3-improve-handling-of-null-rate.patch
delete mode 100644 namespaces-no-expert.patch
delete mode 100644 no-pcspkr-modalias.patch
delete mode 100644 scsi-sd_revalidate_disk-prevent-NULL-ptr-deref.patch
--
2.21.0
4 years, 1 month
Support buildid in kernel-headers
by Paul Moore
Hello,
Last year there was a change to how the kernel-headers package is
built, and unfortunately that change made it so that changes to the
kernel's buildid variable do not carryover to the the kernel-header's
build. While I recognize that this is problem that only affects a
small number of people, it would be nice to see this fixed.
I'm attaching a small patch which fixes this for my use case, and
while I think it is a generic solution, I can't say I've spent enough
time looking at it to say for certain. I'm putting it out here as a
way to help describe the problem as well as one possible solution. If
you have a different/better approach that's fine with me, I just want
to see the buildid reflected in the kernel-header package build so I
can drop this patch from my build process :)
--
paul moore
www.paul-moore.com
4 years, 2 months
Re: Discussion: what would not blocking on btrfs look like?
by Chris Murphy
On Fri, Aug 23, 2019 at 1:17 PM Adam Williamson
<adamwill(a)fedoraproject.org> wrote:
> So, there was recently a Thing where btrfs installs were broken, and
> this got accepted as a release blocker:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1733388
Summary: This bug was introduced and discovered in linux-next, it
started to affect Fedora 5.3.0-rc0 kernels in openqa tests, patch
appeared during rc1, and the patch was merged into 5.3.0-rc2. The bug
resulted in a somewhat transient deadlock which caused installs to
hang, but no corruption. The fix, 2 files changed, 12 insertions, 8
deletions (1/2 the insertions are comments).
How remarkable or interesting is this bug? And in particular, exactly
how much faster should it have been fixed in order to avoid worrying
about it being a blocker bug?
7/25 14:27 utc bug patch was submitted to linux-btrfs@
7/25 22:33 utc bug was first reported in Fedora bugzilla
7/26 19:20 utc I confirmed upstream's patch related to this bug with
upstream and updated the Fedora bug
7/26 22:50 utc I confirmed it was merged into rc2, and updated the Fedora bug
So in the context of status quo, where Btrfs is presented as an option
in the installer and if there are bugs they Beta blocking, how could
or should this have been fixed sooner? What about the handling should
have been different?
I note here that ext2 and ext3 are offered as file systems in
Custom/Advanced partitioning and in this sense have parity with Btrfs.
If this same bug occurred in ext2 or ext3 would or should that cause
discussion to drop them from the installer, even if the bug were fixed
within 24 hours of discovery and patch? What about vfat? That's
literally the only truly required filesystem that must work, for the
most commonly supported hardware so it can't be dropped, we'd just be
stuck until it got fixed. That work would have to be done upstream,
yes?
--
Chris Murphy
4 years, 3 months
Re: Discussion: what would not blocking on btrfs look like?
by Neal Gompa
On Tue, Aug 27, 2019 at 1:30 PM Laura Abbott <labbott(a)fedoraproject.org> wrote:
>
>
> > I also think there are other perspectives that might at least
> > potentially be useful here. Right now we've mainly heard from a couple
> > of community folks who are very passionate about btrfs, and Red Hat
> > folks from anaconda/kernel development and RHEL management who
> > essentially see it as a burden that is not aligned with their
> > priorities. Is that all the perspectives we have to make a decision
> > with? I think we should at least talk to the Facebook team that
> > apparently uses btrfs on Fedora extensively about whether they'd be sad
> > to see installer btrfs support die and, if so, whether they'd perhaps
> > be interested in helping support it. And more broadly, community folks
> > on all the lists this is going to: are there more people who actually
> > are interested in this functionality and would be sad to see it go? If
> > btrfs isn't a part of Red Hat's product roadmaps but is important to
> > lots of folks in the wider Fedora community, maybe that's another
> > indicator we can use....or indeed, if it turns out not many folks
> > actually care.
>
> As an on the record btrfs skeptic, I think it would help to have an end-to-end picture of what's missing or needs to be added across all packages. If someone comes to me today and says "I want to help btrfs be successful in Fedora", I'd like to know where to point them besides just suggesting they get added on the btrfs kernel alias.
Forgive me, but I had missed this in the sea of other messages (this
thread is long and crazy now!).
The Fedora Btrfs folks over the past few years have implemented the following:
* Developed a DNF plugin to invoke snapper correctly for full system snapshots
* Ported over the change set from SUSE to the Fedora grub2 package to
support btrfs boot to snapshot
* Fixed grubby to handle snapshot menu items for grub (this is kind of
deprecated with BLS, though)
The things that I'm looking to do:
* Develop a libdnf plugin to replace the existing DNF snapper plugin
(so that PackageKit is also covered)
* Adapt the boot to snapshot stuff to use BLS (with boom, presumably?)
The things I've been pushing off (for obvious reasons):
* Enable Anaconda to allow /boot to be a btrfs subvolume (PR is in limbo...)
* Ensure Anaconda configures snapper automatically when btrfs rootfs is selected
* Design a sensible default btrfs layout (perhaps based on the current
openSUSE one?)
The mid-/long-term things I'm thinking of:
* Consideration of moving the rpmdb to /usr/lib/sysimage/rpm (unifying
standard Fedora and OSTree Fedora...)
* A libdnf plugin to implement atomic package management using btrfs
snapshots (like transactional-update, except done properly...)
That's basically the full scope of the Btrfs enablement work I've
planned right now.
--
真実はいつも一つ！/ Always, there's only one truth!
4 years, 3 months
Re: Discussion: what would not blocking on btrfs look like?
by Chris Murphy
On Tue, Aug 27, 2019 at 1:02 PM David Cantrell <dcantrell(a)redhat.com> wrote:
>
> On 8/27/19 2:00 PM, Chris Murphy wrote:
> > The Fedora working group's technical specification states Btrfs is to
> > be the default. Yet the working group has said it's uncomfortable
> > taking action on this decision expressly because the Federal kernel
> > team's official recommendation is to not recommend Btrfs. And I agree.
> > I trust the Fedora kernel team as they've clearly stated limited
> > resources and interest in Btrfs, the expectations and parameters for
> > properly supporting Btrfs either as bug blocker worthy, and as a
> > default file system from a user advocacy point of view.
>
> OK, so 8 years has gone by and the landscape around btrfs looks
> different in Fedora. Given the kernel team's position, is it worth
> still having the FESCo decision and kernel team's recommendation at odds?
They aren't at odds.
8 years ago FESCo decision on Btrfs
5 years ago Workstation working group decision on Btrfs (their
requirements and specs docs were signed off by FESCo)
3 years ago kernel team said while they don't recommend it, they
acknowledged it was ultimately up to the working group to decide, and
noted they were sick of having this conversation every release
The Workstation working group has, correctly in my view, put their own
decision in abeyance, as a result of the kernel team's official
recommendation. How does the Btrfs landscape in Fedora look different
to you in three years?
The way the landscape looks different to me:
One, the possibility of getting a kernel engineer who works on Btrfs
to join the Fedora kernel team, so that the team has the capacity to
support and recommend (at least as a team, not that any individual
needs to give up one tiny bit of their Btrfs scepticism) is an
important development.
Two, that in the interim, Red Hat is where the landscape has really
changed has occurred with respect to Btrfs, and I see indications of
this bias being injected back into Fedora: suggesting that a Red Hat
shift away from Btrfs somehow is actually a Fedora shift away from
Btrfs, suggesting a do over vote in the Workstation working group, or
even an undo vote by FESCo to set aside the Workstation working group
vote.
And to what end? All that's needed is for the Anaconda team to
provided the same courtesy of clear expectations and parameters, as
the kernel team has done.
>
> >> If it's a best effort thing, then that makes it easier for
> >> projects and contributors. Going back to Adam's original list, I would
> >> suggest a FESCo decision like this should require explicit opt-in by the
> >> user to enable btrfs functionality in the application in question. For
> >> example, in the installer that could be enabled via a boot parameter (we
> >> did this initially when btrfs functionality was first enabled in anaconda).
> >
> > That can only be considered to be a remarkable regression, not just in
> > the context of Fedora, but in the context of the top 10 linux
> > distributions all of which have visible Btrfs support in their GUI
> > installers. Fedora's installer being the first to make Btrfs invisible
> > by default would be a remarkable first indeed.
>
> I'm merely offering an example scenario.
>
> This does illustrate a problem with expectations among users. It's
> visible now, but not a priority, which leads to frustration.
Just like today's kernel team, Anaconda today are not obligated to
make it a priority. But qualifying what "not a priority" actually
means is necessary. The question is what are the preconditions for
others who will make it a priority? And whether Anaconda is going to
slow walk every PR that tries to improve Btrfs support? What about
simplifying the Btrfs support in Anaconda to make it easier to
maintain with priority parity with other file systems? Gut all the
multiple device stuff, perhaps? Btrfs can easily do quite a lot of
adjustments post-install, it's one of it's most central features. Few
options are mkfs only.
> >> I'm not advocating one way or another for btrfs. But it seems we as a
> >> project need a larger decision and policy around btrfs in general so we
> >> can set expectations for users and developers.
> >
> > That decision and policy has already been made. Do you want it reverted?
>
> I guess I meant to say "FESCo needs to revisit this decision for a
> potential change".
I can't parse this. Which decision, and what potential change?
--
Chris Murphy
4 years, 3 months
Re: Discussion: what would not blocking on btrfs look like?
by Chris Murphy
On Tue, Aug 27, 2019 at 11:25 AM David Cantrell <dcantrell(a)redhat.com> wrote:
>
> The installer team rejecting btrfs patches is going to be based on their
> resources to support the functionality. I would say "btrfs in Fedora"
> needs a FESCo decision to set expectations and policy for the project.
> Is it something that Fedora wants to offer and if so, what does that
> look like?
FESCo already voted 8 years ago to make Btrfs the default file system,
and then allowed that to wither and become moot rather than revert the
decision. Then later when the editions were created, part of
Fedora.next, the decision of default file systems was handed to the
working groups to decide. And the Fedora kernel team has also said
this is a working group decision.
The Fedora working group's technical specification states Btrfs is to
be the default. Yet the working group has said it's uncomfortable
taking action on this decision expressly because the Federal kernel
team's official recommendation is to not recommend Btrfs. And I agree.
I trust the Fedora kernel team as they've clearly stated limited
resources and interest in Btrfs, the expectations and parameters for
properly supporting Btrfs either as bug blocker worthy, and as a
default file system from a user advocacy point of view.
> If it's a best effort thing, then that makes it easier for
> projects and contributors. Going back to Adam's original list, I would
> suggest a FESCo decision like this should require explicit opt-in by the
> user to enable btrfs functionality in the application in question. For
> example, in the installer that could be enabled via a boot parameter (we
> did this initially when btrfs functionality was first enabled in anaconda).
That can only be considered to be a remarkable regression, not just in
the context of Fedora, but in the context of the top 10 linux
distributions all of which have visible Btrfs support in their GUI
installers. Fedora's installer being the first to make Btrfs invisible
by default would be a remarkable first indeed.
> I'm not advocating one way or another for btrfs. But it seems we as a
> project need a larger decision and policy around btrfs in general so we
> can set expectations for users and developers.
That decision and policy has already been made. Do you want it reverted?
--
Chris Murphy
4 years, 3 months
Re: Discussion: what would not blocking on btrfs look like?
by Chris Murphy
On Tue, Aug 27, 2019 at 7:49 AM Samantha Bueno <sbueno(a)redhat.com> wrote:
>
> On Fri, Aug 23, 2019 at 9:17 PM Adam Williamson
> <adamwill(a)fedoraproject.org> wrote:
> > So...what should we do? Here are the options as I see 'em:
> >
> > 1. Keep supporting btrfs
> > 2. Just modify the criterion with a btrfs exception, even if it's weird
> > 3. Rewrite the criterion entirely
> > 4. Keep btrfs support in the installer (and blivet-gui) but hide it as
> > we used to - require a special boot argument for it to be visible
> > 5. Drop btrfs support from the installer
> This thread has diverged wildly into a lot of delightful
> invective-slinging at my team. In the interest of getting back to the
> original topic at hand: I would be in support of three -- five.
This clearly means Btrfs related bugs in Fedora's Anaconda will not
block release, and by extension Btrfs could not be the default file
system either.
"Btrfs is not a priority" does not at all answer the central question
of what level of support and resources are expected to exist in the
Fedora community to maintain Btrfs in both the bug blocking, and
default file system contexts. I think Laura Abbott's emails on the
kernel side are quite clear ground rules for serious Btrfs bugs to
remain blocker worthy, along with a path to discuss any additional
expectations for Btrfs to be a default file system in some capacity.
Unqualified statements like "it is safe to say btrfs will not be the
default" and "Btrfs is not a priority" and this 'zero chance Btrfs'
comment [1] are completely compatible with assuming that no matter how
much work is done by others, those things will not appear in Anaconda
because the decision has been made, it is a fait accompli.
It is very important to have clarity exactly to what degree Btrfs is
not a priority. If the Anaconda team cannot state the terms and
expectations for the #1 option in Adam's list, that's troubling.
Again, I think it's completely fine if Red Hat Anaconda folks are
disinterested in Btrfs, but it's a very different thing if there's
resistance to it, and I'm getting a lot of language that is compatible
with resisting Btrfs no matter what.
[1]
https://bugzilla.redhat.com/show_bug.cgi?id=1717728#c10
--
Chris Murphy
4 years, 3 months
Simple Firmware Interface being deprecated
by Laura Abbott
https://lore.kernel.org/lkml/20190826181956.6918-1-lukas.bulwahn@gmail.com/
menuconfig SFI
bool "SFI (Simple Firmware Interface) Support"
---help---
The Simple Firmware Interface (SFI) provides a lightweight method
for platform firmware to pass information to the operating system
via static tables in memory. Kernel SFI support is required to
boot on SFI-only platforms. Currently, all SFI-only platforms are
based on the 2nd generation Intel Atom processor platform,
code-named Moorestown.
For more information, see http://simplefirmware.org
Say 'Y' here to enable the kernel to boot on SFI-only platforms.
I have no idea how common this is but Fedora does enable this option.
If you are interested in salvaging this, please speak up!
Thanks,
Laura
4 years, 3 months
Re: Discussion: what would not blocking on btrfs look like?
by Neal Gompa
On Tue, Aug 27, 2019 at 5:55 AM <jkonecny(a)redhat.com> wrote:
>
> On Mon, 2019-08-26 at 23:54 -0400, Neal Gompa wrote:
> > On Mon, Aug 26, 2019 at 7:16 AM <jkonecny(a)redhat.com> wrote:
> > >
> > > I understand them. The point is, for them and even us (the
> > > installer)
> > > is work on BTRFS not a priority. It's something we can't benefit on
> > > RHEL and it could be almost completely replaced by LVM + xfs
> > > solution.
> > > However, it still giving us bugs and making our test surface
> > > bigger.
> > >
> > > > From the Anaconda team PoV it would make our lives easier to not
> > > support BTRFS at all. I'm not saying that we should drop BTRFS in
> > > Fedora, only that it would be easier for Anaconda team to be
> > > without
> > > that on Fedora.
> >
> > This is flat-out a trap. This is what makes Anaconda such a failure
> > as
> > a community project. Why does the past (RHEL) affect the present and
> > future (Fedora)? There's basically no way whatsoever to make anything
> > better with this logic. The Anaconda releases that any improvements
> > would be going into aren't even landing into the RHEL 8 branch that
> > governs the latest iteration of Fedora's past. From any reasonable
> > person's perspective, this answer makes no sense unless you're using
> > RHEL as an excuse to not support Fedora.
> >
>
> RHEL is not the past. Everything we do we have to think that it will go
> to RHEL and if it is Fedora specific we have to create a way to disable
> the functionality for another RHEL branching. And yes, we have a few
> things (not only a BTRFS) specific to Fedora the same way as a few
> things specific to RHEL which are disabled on Fedora.
>
> And as I wrote before, I'm not saying that we will remove the BTRFS
> support from Fedora. The point is that making the list specific to
> releases smaller will make our live easier.
>
By definition, RHEL *is* the past from a Fedora context. It's forked
from an old version of Fedora that's not supported anymore. It is the
result of decisions that aren't supposed to apply to Fedora. And it is
the result of a different bias that should never apply to Fedora if
the RH ecosystem is supposed to be able to evolve.
From the way you describe it, Fedora is just something occasionally
give lip service to while your main focus is RHEL. That's fine, but
that is a problem for the Fedora context.
--
真実はいつも一つ！/ Always, there's only one truth!
4 years, 3 months
Re: Discussion: what would not blocking on btrfs look like?
by Chris Murphy
On Mon, Aug 26, 2019 at 5:16 AM <jkonecny(a)redhat.com> wrote:
> I understand them. The point is, for them and even us (the installer)
> is work on BTRFS not a priority. It's something we can't benefit on
> RHEL and it could be almost completely replaced by LVM + xfs solution.
> However, it still giving us bugs and making our test surface bigger.
>
> >From the Anaconda team PoV it would make our lives easier to not
> support BTRFS at all. I'm not saying that we should drop BTRFS in
> Fedora, only that it would be easier for Anaconda team to be without
> that on Fedora.
It would also be easier if Custom and Advanced partitioning UIs were
dropped entirely.
Most Linux distros now support Btrfs. All the top 10 do. One,
currently ranked #7 Solus, supports it via a point and shoot
installer, deferring to Gparted to actually set it up. All the others
have a custom interface that supports Btrfs directly.
Meanwhile, #23 Parrot uses Btrfs by default for home and root. And so
does openSUSE for a while now.
And the idea being floated, is that Fedora shouldn't have a sense of
adventure, but to maybe drop Btrfs from the installer. Fedora would be
the first, if it did.
It is completely reasonable for Red Hat to have maintainability
concerns about Btrfs for RHEL, and it's entirely fair for Red Hat to
have a bias against it. If it were true that Red Hat is, however
unintentionally, injecting its Btrfs bias into Fedora, that would be
troubling.
--
Chris Murphy
4 years, 3 months
