custom kernel build with patch
by Damian Ivanov
Hello,
I am trying to build the fedora kernel with the muqss patch and the
patches for the surface devices.
To start I tried to build it only with the muqss patch. So tried as
well with fedpkg as well as a plain rpmbuild but both hang at the same
stage.
I enpacked the kernel.src.rpm, fetched the latest muqss patch and
added it in the kernel.spec.
Also I did set %define with_baseonly 1 to build only non-debug x86_64
Trying to build the kernel with rpmbuild -ba kernel.spec will fail at
the stage of
process_configs.sh that compains about config options being unset
(and
.git/rebase-apply/patch:7590: space before tab in indent.
cpu = i;
.)
So I try to add them to all config's but when building I get:
Error: Mismatches found in configuration files
Found CONFIG_RQ_ALL=is not set after generation, had CONFIG_RQ_ALL=n
in Source tree
Found CONFIG_RQ_SMP=is not set after generation, had CONFIG_RQ_SMP=n
in Source tree
Found CONFIG_RQ_SMT=is not set after generation, had CONFIG_RQ_SMT=n
in Source tree
Found CONFIG_RQ_NONE=is not set after generation, had CONFIG_RQ_NONE=n
in Source tree
What is the correct way to build the fedora kernel with a custom patch added?
* tried this as well https://fedoramagazine.org/building-fedora-kernel/
Thanks in advance.
Damian
4 years, 7 months
Re: Discussion: what would not blocking on btrfs look like?
by Josef Bacik
On Mon, Sep 09, 2019 at 01:43:00PM -0400, David Lehman wrote:
> On Thu, 2019-09-05 at 18:01 -0700, Adam Williamson wrote:
> > On Tue, 2019-09-03 at 13:38 -0400, David Lehman wrote:
> > > On Fri, 2019-08-23 at 12:16 -0700, Adam Williamson wrote:
> > > > Hey folks!
> > >
> > > Hi Adam! Thanks for bringing this up again.
> > >
> > > > 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
> > >
> > > I like option 3 most. The current criteria have always seemed, to
> > > me,
> > > too vague. I'd be happy to help hash out the details if/when it
> > > happens.
> >
> > Thanks for the offer.
> >
> > So aside from the 'fun' of drafting very specific rules, my concern
> > with #3 is we would then potentially be shipping an installer that
> > presents things as roughly equal choices which are not in fact
> > equally
> > supported. You can pick 'btrfs' or 'ext4' from the dropdown...but one
> > of those we commit to making sure is working, one of them we don't.
>
> > That to me is concerning; in this scenario I'd prefer we indicate
> > somehow, somewhere, that all the choices are not equally guaranteed
> > to
> > be reliable. WDYT?
>
>
> Two off-the-cuff ideas:
>
> 1. every fs (and device?) type in the combo/dropdown has "(Supported)"
> or "(Unsupported)" postfix, eg: "xfs (Supported)" or "BTRFS
> (Unsupported)"
> 2. every unsupported fs type has a corresponding kernel arg, eg:
> "inst.btrfs" or "inst.fs.btrfs" which is required to get that
> unsupported fs type in the GUI list
>
> I could live with either, personally.
>
Why bother hiding it at all? I get that there's no btrfs expertise at Red Hat,
but there's not any reason to indicate that it's bad for the user to choose it.
Suse ships it, all of Facebook is on it, it's not like we're talking about hfs+
here or anything. I get the discussions around wether it's a release blocker, I
don't really understand why the installer needs to be changed? Thanks,
Josef
4 years, 7 months
[PATCH] enable driver for accessing HMC CD/DVD drive
by Dan Horák
---
configs/fedora/generic/s390x/CONFIG_HMC_DRV | 1 +
kernel-s390x-debug.config | 2 +-
kernel-s390x.config | 2 +-
3 files changed, 3 insertions(+), 2 deletions(-)
create mode 100644 configs/fedora/generic/s390x/CONFIG_HMC_DRV
diff --git a/configs/fedora/generic/s390x/CONFIG_HMC_DRV b/configs/fedora/generic/s390x/CONFIG_HMC_DRV
new file mode 100644
index 000000000..fc68dc34b
--- /dev/null
+++ b/configs/fedora/generic/s390x/CONFIG_HMC_DRV
@@ -0,0 +1 @@
+CONFIG_HMC_DRV=m
diff --git a/kernel-s390x-debug.config b/kernel-s390x-debug.config
index 61d06297a..eb0cd3526 100644
--- a/kernel-s390x-debug.config
+++ b/kernel-s390x-debug.config
@@ -1758,7 +1758,7 @@ CONFIG_HIGH_RES_TIMERS=y
# CONFIG_HIPPI is not set
CONFIG_HIST_TRIGGERS=y
# CONFIG_HMC6352 is not set
-# CONFIG_HMC_DRV is not set
+CONFIG_HMC_DRV=m
CONFIG_HOLTEK_FF=y
# CONFIG_HOSTAP is not set
CONFIG_HOTPLUG_CPU=y
diff --git a/kernel-s390x.config b/kernel-s390x.config
index 696652ba9..0d3be1ed5 100644
--- a/kernel-s390x.config
+++ b/kernel-s390x.config
@@ -1741,7 +1741,7 @@ CONFIG_HIGH_RES_TIMERS=y
# CONFIG_HIPPI is not set
CONFIG_HIST_TRIGGERS=y
# CONFIG_HMC6352 is not set
-# CONFIG_HMC_DRV is not set
+CONFIG_HMC_DRV=m
CONFIG_HOLTEK_FF=y
# CONFIG_HOSTAP is not set
CONFIG_HOTPLUG_CPU=y
--
2.21.0
4 years, 7 months
Re: Discussion: what would not blocking on btrfs look like?
by Neal Gompa
On Thu, Aug 29, 2019 at 4:23 AM <jkonecny(a)redhat.com> wrote:
>
> On Tue, 2019-08-27 at 14:59 -0700, Adam Williamson wrote:
> > On Tue, 2019-08-27 at 13:25 -0400, David Cantrell wrote:
> > > > Josh, to be fair, I can see Neal's point here. In a way you seem
> > > > to be
> > > > kinda sending him in circles here: "anaconda team doesn't have
> > > > the
> > > > time/resources to invest in btrfs development, but you can help
> > > > by
> > > > sending them pull requests. Oh, you sent them a pull request and
> > > > they
> > > > rejected it? Well, it's because they don't have time/resources
> > > > for
> > > > btrfs development..." You're right that one rejected PR doesn't
> > > > necessarily indicate a contribution model problem, but putting
> > > > the
> > > > wider issue aside, a very simple one-liner with a major impact on
> > > > btrfs
> > > > functionality being rejected *does* seem to say a lot about the
> > > > prospects of any btrfs-related work being accepted.
> > > >
> > > > Putting myself in Neal's shoes, given my experience with that PR
> > > > and
> > > > other attempts to help out with btrfs in anaconda, why would I
> > > > invest
> > > > my time and effort to write another one when it seems extremely
> > > > likely
> > > > it would be rejected?
> > >
> > > There's an assumption here that when someone is asked to send a PR,
> > > it
> > > will always be accepted.
> >
> > No, that's not what I'm assuming, but if we (Red Hat) tell people
> > that
> > it would be a good idea to send PRs, we should at least be
> > *potentially* willing to accept them. We should not be saying 'send
> > PRs' if there is no chance of them being accepted. And it would be
> > nicest if we gave people a roadmap: here are the specific things you
> > can do that would be acceptable to us as a way to continue including
> > btrfs handling in the installer.
>
> Sorry but I have to react on this. It's killing me how many of you
> people here are telling Anaconda does not accept patches. That is
> really not true. We have smaller amount of contributions from community
> that is partially our fault because of a lack of documentation but
> mainly it's really hard to develop & test Anaconda and most users see
> it just once in a few years so it's not bothering them so much. I guess
> most of the installers are in the same situation.
>
I sat on this for a few days, as I wanted to cool down and think about
how to reply to this. As of this moment, I have directly and
indirectly contributed to both the Red Hat and SUSE installers, and
yes it's definitely true that both installers have some of the worst
interaction models for contributors I've ever seen.
YaST's contribution model and process seems to be somewhat better,
because their team has components being used by other people. Their
libyui components are used by Fedora and Mageia for dnfdragora, and
the rest of ManaTools in Mageia uses it too. The YaST control center
is a cornerstone in the user experience in SUSE distributions, so
there are contributors from their community who do work on the main
YaST components.
The Calamares installer stack has a pretty healthy community, but our
community has an interesting aversion to all things Qt/KDE even though
the installer works fine on Fedora...
But the point I'm trying to make is there is no reason for Anaconda to
be so difficult. Unfortunately, it is.
> Please before any of you will tell again that Anaconda team is not
> accepting patches, please look on the last few years history. How many
> patches were "rejected" and how many were accepted. There are just a
> few patches which weren't accepted and basically only a few PR (I would
> even say the only one) for BTRFS. That is unfortunate but it's not all
> our contributions.
>
I also took the opportunity look back at over the last 400 merged pull
requests by paging through GitHub. Now I don't exactly have firm
numbers, but in the past 400 pull requests, I saw less than a dozen
pull requests merged from non-RHers. Half of them were from Pat from
the Scientific Linux team. One of them was a documentation fix from
some person I don't recognize with no clear affiliation. If I page
back *slightly more* then the next PR from a non Red Hatter that was
merged was *mine* fixing Anaconda's package exclusion feature for
kickstarts (which was nearly two years old when it was merged).
Of the 42 currently open pull requests, 4 are from people I could
clearly identify as not from Red Hatters. Of the ones that are from
Red Hatters, 7 appear to not be from members of the Red Hat Installer
team or the Red Hat Bootloader team as I know of them.
The lag time to response *is* improving. It's gone down from years to
months, with the most recent pull request getting a comment within a
week, and then stalling out after that. So it may even improve to
weeks!
As Adam pointed out, there's literally no reason for me to attempt
more sophisticated changes to Anaconda if a simple one-liner can't get
merged. And I didn't even make that fix, I've just been trying to
shepherd it in for over a year! I only gave up trying and focusing on
other things when it became clear I'd be dogged with non-answers
forever.
> Please stop saying all the time that Anaconda is not accepting
> contributions or that users doesn't have a chance to get the
> contributions in.
>
You guys brought it upon yourselves by having terrible documentation
and contribution policies, unclear ownership or responsibilities of
projects that are clearly related (pykickstart, which by the way guys,
changed hands *again* and now is basically in a brand new black
hole!), oh, and lets not forget the oh-so-joyous aspect of the CI that
is forbidden to be accessed by non-Red Hatters.
Honestly, I shouldn't have expected better. When I noticed that the
Anaconda mailing lists never moved from the Red Hat lists to
lists.fedorahosted.org, I should have realized that Red Hat wasn't
treating it like a community project. Every dysfunctional RH/Fedora
ecosystem project seems to have that as a common property. It's
emblematic of the deeper problem that it's not treated as a project
where the community is valued. OpenShift, Spacewalk, and Anaconda are
all projects where I've suffered these problems. That's not to say RH
projects not hosted on the Red Hat lists can't be dysfunctional too,
but people seem to try to be better when they aren't. Maybe it's an
attitude difference? A different approach to the project? I don't
know.
But something is wrong and it needs to be fixed.
--
真実はいつも一つ！/ Always, there's only one truth!
4 years, 7 months