Re: [Test Week] Fedora Linux Kernel 5.16 2022-01-23 through 2022-01-29

[Justin Forbes]

On Wed, Jan 26, 2022 at 3:38 AM Thorsten Leemhuis  wrote:
>
> Lo!
>
> On 20.01.22 09:38, Sumantro Mukherjee wrote:
> >
> > I would like to invite all of you to participate in the Kernel 5.16
> > Test week is happening from 2022-01-23 to 2022-01-29. It's
> > fairly simple, head over to the wiki [0] and read in detail about the
> > test week and simply run the test case mentioned in[1] and enter your
> > results.
> > [...]
> > [0] https://fedoraproject.org/wiki/Test_Day:2022-01-23_Kernel_5.16_Test_Week
> > [1] https://testdays.fedoraproject.org/events/126
> > [2] https://badges.fedoraproject.org/badge/science-kernel-tester-i
>
> Wouldn't it be better for everyone if stable pre-releases would be
> offered for testing in these test weeks, *if* they are available at that
> time? I was just wondering that, as according to your [0] it seems that
> 5.16.2 is still being tested currently, but 5.16.3 is up for review
> already since Monday -- with more that 1000 changes:
> https://lore.kernel.org/stable/20220124184125.121143...@linuxfoundation.org/
>
> [note, there are newer pre-releases for 5.16.3 already]
>
> These changes might fix a few bugs testers otherwise might run into
> without need -- or introduce new bugs that thus can be found and fixed
> before 5.16.y hits updates-testing.

I do create test builds for stable rc kernels usually, but they are
scratch builds and not secure boot signed. With the time it takes for
full kernel builds, and then the time to spin new ISOs, etc. I would
never get feedback in time for a stablerc before the kernel is
released. And with 5.15 and 5.16, the early stable's often have more
than 1 rc release.   For most of the 5.15 test week, we were iterating
over rcs to get 5.15.3 out because of an issue that would impact
many/most users, which was a regression from 5.15.2.  We knew about
this issue, but having it as a test week kernel would have lost a lot
of meaningful feedback because many testers would hit the known bug
and stop testing.

> I bring this up, as situations like happened a few times already, as
> Greg often merges a big bunch of changes in the first two weeks after a
> mainline rc1 is out (see https://lwn.net/Articles/863505/ ) -- and
> that's usually the time when the kernel test week happens.
>
> Ciao, Thorsten
>
> P.S.: kernel.spec until a few years had some code that made building
> stable rcs easy, but it was removed (and likely won't work well the the
> ask based kernel.spec anyway).

There are still a couple of ways to go about it.  If you just want to
deal with dist-git and the stable-queue quilt trees, it is pretty
simple to cat the patches (in series order) to a patch file and apply
that patch before the redhat patch.
For kernel ark with the source tree, there are still some issues with
the scripts that I need to fix up to handle a stable rc.  Right now,
the logic expects either an rc or a stable.  I will try to get that
done as we get further in the 5.17 cycle.  It is still possible, and
pretty easy to build  a stable rc with a caveat.

An example workflow for building the 5.16.3-rc2 stable kernel (this
expects you have local branches for both stable/linux-5.16.y and
stablerc/linux-5.16.y as linux-5.16.y-rc).
1) Update linux-5.16.y, linux-5.16.y-rc, and fedora-5.16 branches
2) In fedora-5.16 'git merge linux-5.16.y-rc' and fix any merge issues
if they appear
3) git revert Greg's latest commit which actually changes the version
to 5.16.3-rc2 (this chokes up our scripts).

From there you can build as you typically would.  The kernel  is still
versioned as 5.16.2, so I tend to specify the release to match the rc
number, but that is personal preference. Once I get the scripts fixed,
we won't need to revert the version patch, and the spec should be
versioned correctly.

Justin
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-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/test@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: [Test Week] Fedora Linux Kernel 5.13 2021-07-11 through 2021-07-18

[Justin Forbes]

On Tue, Jul 6, 2021 at 1:22 PM Brandon Nielsen  wrote:
>
> Linked test day image[0] has not been updated.
>
> [0] - https://jforbes.fedorapeople.org/testweek/

It never is until the Friday before test week, as I like to get the
newest revision. Then it tends to get updated once or twice during
test week. That is why we link to the directory instead of the
specific image.  It has been uploaded now.

Justin

>
> On 7/6/21 9:30 AM, Sumantro Mukherjee wrote:
> > Hey All,
> >
> > I would like to invite all of you to participate in the Kernel 5.13
> > Test week, which is happening from 2021-07-11 to 2021-07-18. It's
> > fairly simple, head over to the wiki [0] and read in detail about the
> > test week and simply run the test case mentioned in[1] and enter your
> > results.
> >
> > As usual, the Fedora QA team will hang out at #fedora-test-...@libera.chat
> > for question and discussion.
> >
> >
> > [0] https://fedoraproject.org/wiki/Test_Day:2021-07-11_Kernel_5.13_Test_Week
> > [1] https://testdays.fedoraproject.org/events/115
> >
> >
> ___
> test mailing list -- test@lists.fedoraproject.org
> To unsubscribe send an email to test-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/test@lists.fedoraproject.org
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-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/test@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: A question about upgrading kernels, again

[Justin Forbes]

On Mon, May 10, 2021 at 12:51 PM stan via test
 wrote:
>
> On Mon, 10 May 2021 03:49:33 -0400
> Francisco Tissera  wrote:
>
> > When trying to install fedora 34's repository packages, I get across
> > errors that I have to fix by adding the --allowerasing flag, or the
> > --skipbroken one.
> >
> > Is that advisable, or does that mean that repositories of different
> > versions of Fedora are not instalable in parallel?
>
> Without seeing the actual error messages, I assume that they are not
> parallel installable.  They probably use the same path and package name
> for something, and so cannot be installed at the same time.
>
> Since it is only a single kernel that you will have to do the manual
> procedure for, that is probably the path you should take.  Even if you
> install the f34 repos only to get the kernel, and then reinstall the
> rawhide repos, the latest kernel in f34 is now 5.12, so you will have
> to specify the version of kernel you want during the kernel update.

The 5.12 kernels are no tin the f34 repos, they are being built as
"official" F34 kernels so that they are secure boot signed for test
week, but 5.11 kernels are still being updated and pushed through
bodhi.  I expect 5.12 rebases to happen next week.
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-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/test@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: In Fedora 34, cannot install "C Development Tools and Libraries"

[Justin Forbes]

On Sun, Feb 14, 2021 at 7:00 AM Qiyu Yan  wrote:

> 王 臣  于 2021年2月14日周日 下午8:02写道：
>
>> In Fedora 34  Fedora nightlies ,
>> dnf -y groupinstall "C Development Tools and Libraries" "Development
>> Tools"
>> notice an error.
>>
> I guess it is due to unannounced sobump, that means kernel-tools package
> should be rebuilt.
>

kernel-tools gets rebuilt weekly with rcX builds. It will be rebuilt on
Monday with 5.11.0.

Justin

>
>> ___
>> test mailing list -- test@lists.fedoraproject.org
>> To unsubscribe send an email to test-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/test@lists.fedoraproject.org
>> Do not reply to spam on the list, report it:
>> https://pagure.io/fedora-infrastructure
>>
>
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-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/test@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: some basic Rawhide kernel questions

[Justin Forbes]

On Wed, Apr 1, 2020 at 5:25 PM David  wrote:

> As of today, my install still uses the version below
> for the kernel
>
>  5.6.0-0.rc7.git1.1.fc33.x86_64
>
> ( and is running great, in my opinion )
>
> But in today's Rawhide compose announcement of upgraded
> packages, the kernel was listed as
> upgrading to the newer
>
>  kernel-5.7.0-0.rc0.git2.1.fc33
>
> So I have several questions
>
> 1 )   Yesterday, I think I only got the kernel-header package. Is that
> the way this normally works.
>

The kernel upgrades pretty much daily, though sometimes it can take a day
or 2 to get out to mirrors. Between what you are running and what has been
built, we did 5.6.0-1,  kernel-5.7.0-0.rc0.git1.1,
and kernel-5.7.0-0.rc0.git2.1  Kernel-headers is typically built only once
a week, or once per rc.


> 2 )Does Rawhide never run on the stable version of the kernel ?
>

Generally not for more than 24 hours. As 5.6.0 was released on a Sunday, it
gets built on Monday morning. We will either start doing builds of the
merge window Monday afternoon, or Tuesday morning at the latest.  This
week, it was Monday afternoon.  Kernels are built with a snapshot of
Linus tree most weekdays.  The first rc build each week and the final
stable build of a kernel are built as release kernels with debug options
turned off, and git snapshots in between have additional debugging options
turned on. These do have some impact on performance, but not too drastic.
Of course we also offer regular snapshot builds in a rawhide nodebug
repository for people who really want them.  A side effect of this is they
are not secureboot signed while the official rawhide builds are.


>
>
3 )What all goes into repackaging the kernel by the people tasked with
> doing that ?
>

Taking a snapshot of the current upstream tree, setting all of the new
config options appropriately, building/testing/pushing.  Stable updates
tend to require much less work, config doesn't change.  Even with rc
kernels after rc1 the config is fairly set until the next merge window
opens up.


>
>
4 )   How much different are the two kernels listed above ?
>

 The diff between rc7-git1 and 5.7 git snapshot 2 is roughly 300k lines.
The merge window is when the majority of new features for a given version
come in, so the diff from day to day can be huge. For instance snapshot 2
is almost 280k lines smaller than snapshot 3, and that covers a roughly 24
hour period.  After rc1 comes out, this slows down drastically.

5 )   Does Rawhide use every tiny update on the git for the kernel, or does
> it
> sometimes skip one or two ?
>
> We tend to take a snapshot every weekday, provided upstream has pulled in
commits.


> 6 ) Are there any other interesting insights related to this procedure ?
>
>
It is fairly straightforward, build and test the upstream tree as often as
possible.  This lets us hopefully catch bugs before they make it to a
stable release, and gives us a much smaller window for tracking down bugs
that are found... If you have a problem with 5.6-rc5-git2, but rc5.git1
works for you, it has been narrowed down to just a few dozen possible
issues.  From there it is easier to fix, or report the issue to upstream
for a fix, and hopefully get that fix in before 5.6.0 final releases. Once
a Fedora version hits beta (as F32 has, it only gets a snapshot once per
week with the rcX releases until the stable it out, so FC32 is on 5.6.0
right now, with 5.6.1 building. It will remain on stable kernels. The week
after next is a 5.6.0 test week where we will get users testing the 5.6
series on stable Fedora versions (F31 and F30), and based on the feedback
from that, we will get 5.6.x onto those branches as the supported kernel
shortly after.

I am just curious, and I am certain that the answers may be above my IQ, so
> please try to explain it all as simple as possible.
>
> I have used other developmental versions of distros, but this process does
> not
> take place in some of those.For example, even in the most unstable of
> the
> KDE Neon "Unstable Developer's Edition," the kernel never changes ( except
> maybe some kind of security update ?? ).  I do not recall the kernel
> getting so
> many updates in Tumbleweed either.( Tumbleweed, is my second favorite
> way
> to use Linux, by the way. )
>
>
I can understand from a KDE development platform, they are more concerned
with KDE changes than kernel changes.  Somewhat surprised that Tumbleweed
isn't updating the kernel at least weekly.  We tend to be more aggressive
than most in updating the kernel across the board, but particularly in
rawhide, we have found the feedback loop that we get from this to be
valuable.

Thank you.
>
> David Locklear
> Novice Rawhide user
>
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List 

Re: Discussion: what would not blocking on btrfs look like?

[Justin Forbes]

On Fri, Aug 23, 2019 at 8:00 PM Chris Murphy  wrote:
>
> On Fri, Aug 23, 2019 at 1:17 PM Adam Williamson
>  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?

From my standpoint, ext4 and xfs are the primary supported root
filesystems. I don't think that anything else should be release
blocking. As for whether the installer exposes other options, it is
really more of an installer and QA question. We are certainly not even
discussing turning them off in the kernel at this point, and I don't
think that we should.

> --
> Chris Murphy
> ___
> kernel mailing list -- ker...@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/ker...@lists.fedoraproject.org
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-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/test@lists.fedoraproject.org

Re: Discussion: what would not blocking on btrfs look like?

[Justin Forbes]

On Fri, Aug 23, 2019 at 2:17 PM Adam Williamson
 wrote:
>
> Hey folks!
>
> 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
>
> The bug was fixed, so that's fine, but along the way, Laura said this:
>
> "I'm strongly against anything with btrfs being a blocker. If that's in
> the criteria I think we should see about removing btrfs simply because
> we don't have the resources to actually deal with btrfs besides
> reporting bugs upstream."
>
> and Justin followed up with:
>
> "Agreed, btrfs has been a gamble pretty much always. See previous
> discussion around proposals to make btrfs default. Ext4 and xfs should
> be the only release blocking."
>
> So, that's the whole kernel team 'strongly against' blocking on btrfs.
> Which means we should talk about not doing that any more!
>
> This is a bit complicated, though, because of how the Final criteria
> are phrased. Basic does not include btrfs at all, and Beta includes a
> laundry list we can just remove btrfs from:
>
> "When using both the installer-native and the blivet-gui-based custom
> partitioning flow, the installer must be able to:
>
> * Correctly interpret, and modify as described below, any disk with a
> valid ms-dos or gpt disk label and partition table containing ext4
> partitions, LVM and/or btrfs volumes, and/or software RAID arrays at
> RAID levels 0, 1 and 5 containing ext4 partitions
> * Create mount points backed by ext4 partitions, LVM volumes or btrfs
> volumes, or software RAID arrays at RAID levels 0, 1 and 5 containing
> ext4 partitions
> ..."
>
> so those two are easy. However, the Final criterion is not laundry
> list-style. The relevant Final criterion is this:
>
> "The installer must be able to create and install to any workable
> partition layout using any file system and/or container format
> combination offered in a default installer configuration."
>
> with a somewhat apologetic explanatory footnote:
>
> "Wait, what?
> Yeah, we know. This is a huge catch-all criterion and it's subject to a
> lot of on-the-fly interpretation. Broadly what it's 'meant to mean' is
> that you should be able to do anything sane that the Installation
> Destination spoke attempts to let you do, without the installer
> exploding or failing. We are trying to write more specific criteria
> covering this area, but it's not easy. Patches welcome, as the kids
> say..."
>
> so as the footnote says, the rule is basically "if the installer lets
> you do it, it ought to work". It seems a bit awkward to craft an
> exception for btrfs from that. I mean, technically it's easy:
>
> "The installer must be able to create and install to any workable
> partition layout using any file system and/or container format
> combination offered in a default installer configuration, except
> btrfs."
>
> but that's odd. Why is btrfs, alone, an exception? It kinda goes
> against the fundamental idea of the criterion: that we stand behind
> everything the UI offers.

All of this, the criteria, and the UI support for btrfs are from the
many years old proposal to make btrfs the default filesystem.  In the
beginning, it was not ready, but did show promise. This proposal came
up for several releases in a row, and at the end of it, even the
upstream developers recommended against it.  At this point, it is safe
to say that btrfs will not be the default.  Since that time, things
have not gotten better.   Yes, there is active btrfs development
upstream.  It is fairly narrowly focused, and not something we can
rely upon for a supported default among the Fedora use cases.  While
Fedora does enable it in the kernel, and plans to continue doing so,
it is enabled in the "if you break it, you get to keep the pieces"
method of many other options. Sure, we will be happy to bring in a
patch that is headed upstream if it fixes a bug, and someone points us
to it.  No, we aren't going to spend time debugging issues with it
ourselves.  There is no shortage of issues in more "core" kernel
pieces that require attention.

> 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 would opt for 4 or 5, and would be in full support of 5.  I do not
think that it can (or should) be dropped from the kernel, because we
don't want to cut off existing users, and it can still be a useful
filesystem for specific cases.

> I'm bringing this to anaconda, kernel and test teams initially to kick
> around; if we agree on an approach we should then probably loop in
> devel@ for wider review, unless the choice is 1).
>
> Thanks for any thoughts, folks!
> --
> Adam Williamson
> Fedora 

Re: Fedora 31 Beta blocker status email #3

[Justin Forbes]

On Fri, Aug 16, 2019 at 12:04 PM Ben Cotton  wrote:
>
> Action summary
> 
>
> Accepted blockers
> -
> 1. dracut-modules-olpc — Cannot be installed due to unsatisfied
> 'bitfrost' dependency — NEW
> ACTION: dracut-modules-olpc to resolve dependency on desired bitfrost package.
>
> Proposed blockers
> -
> 1. gnome-initial-setup —
> https://bugzilla.redhat.com/show_bug.cgi?id=1734198 — NEW
> ACTION: gnome-initiail-setup maintainers to fix crash when timedatex
> service is unavailable.
>
> 2. kernel — https://bugzilla.redhat.com/show_bug.cgi?id=1733388 — NEW
> ACTION: QA team to determine if btrfs should be excluded from blocker
> criteria and perhaps propose dropping it from the installer
>
> 3. selinux-policy-targeted —
> https://bugzilla.redhat.com/show_bug.cgi?id=1734197 — POST
> ACTION: QA team to verify new build (3.14.4-31.fc31) fixes issue
>
>
> Bug-by-bug detail
> =
>
> Accepted blockers
> -
> 1. dracut-modules-olpc — Cannot be installed due to unsatisfied
> 'bitfrost' depndency — NEW
> Cannot be installed due to unsatisfied 'bitfrost' dependency
>
> bitfrost package was retired, which prevents dractu-modules-olpc from
> building. However there is some discussion as to whether it's
> reasonable for that package to be added to the
> Server DVD. Currently, "dracut*" is added to Server, Workstation, and
> Everything builds:
> https://pagure.io/pungi-fedora/blob/master/f/fedora.conf#_130
>
> Proposed blockers
> -
> 1. gnome-initial-setup —
> https://bugzilla.redhat.com/show_bug.cgi?id=1734198 — NEW
> g-i-s crashes if timedatex.service isn't running
>
> Crash caused by the SELinux denial in BZ 1734197. gnome-initial-setup
> should handle that failure case gracefully. Note that systemd
> maintainers are looking to obsolete timedatex:
> https://bugzilla.redhat.com/show_bug.cgi?id=1735584
>
> 2. kernel — https://bugzilla.redhat.com/show_bug.cgi?id=1733388 — NEW
> Circular locking often causes btrfs installs to hang with
> kernel-5.3.0-0.rc0.git7.1.fc31 and later
>
> Installations since kernel-5.3.0-0.rc0.git7.1.fc31 often fail during
> package installation. The the QA team will consider excluding btrfs
> from any blocker criteria. The bug appears
> to be fixed upstream:
> https://lore.kernel.org/linux-btrfs/35b5e6a8-8e9b-037d-b248-36fee9da8...@suse.com/

This patch is included in current F31/rawhide, so it should be fixed,
though I would still like the question of excluding btrfs from blocker
criteria to be evaluated. It was added when there was some discussion
of making btrfs the default many years ago. I do not see that
happening any more.

Justin

> 3. selinux-policy-targeted —
> https://bugzilla.redhat.com/show_bug.cgi?id=1734197 — POST
> SELinux denial "denied { send_msg } for
> scontext=system_u:system_r:timedatex_t:s0
> tcontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 tclass=dbus"
> prevents timedatex.service
> from starting in current Rawhide
>
> Original attempt to fix the issue did not. A new fix was committed and
> built (selinux-policy 3.14.4-31.fc31).
>
>
> --
> Ben Cotton
> He / Him / His
> Fedora Program Manager
> Red Hat
> TZ=America/Indiana/Indianapolis
> ___
> devel mailing list -- de...@lists.fedoraproject.org
> To unsubscribe send an email to devel-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/de...@lists.fedoraproject.org
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-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/test@lists.fedoraproject.org

[Test-Announce] Re: Call for testing: updates to address today's CPU/kernel vulnerability

[Justin Forbes]

tl;dr:
We are fixing things as quickly as we can safely do so. The fixes will
be ongoing, keep testing and installing new kernels as they appear!

On Sat, Jan 6, 2018 at 1:32 PM, Chris Adams  wrote:
> Once upon a time, Adam Williamson  said:
>> * If the fix does cause problems on your hardware, you can disable it
>> by booting with the kernel parameter 'nopti'.
>
> So, on RHEL/CentOS kernels, there are three new entries in
> /sys/kernel/debug/x86; ibpb_enabled, ibrs_enabled, and pti_enabled.  I
> don't see these on the Fedora kernel.
>
> Are these variables something added by Red Hat to their kernel,
> something that will be added to Fedora, etc.?  They are useful to see
> exactly what fix(es) are being applied, as well as to have a runtime way
> to enable/disable them.

These do not exist in Fedora yet. For KPTI, the feature is
implemented, but there isn't a debugfs entry.  Variant 2 Spectre
mitigation has a couple of proposed solutions. IBRS and retpoline are
both being discussed upstream, and the end result will likely be a
combination of the 2.  Unfortunately both have external requirements.
Retpoline requires GCC patches, and microcode updates for some CPUs.
IBRS requires microcode updates. While RHEL has done quite a bit of
testing with IBRS in their kernels, Fedora moves a lot quicker and
current Fedora kernels are substantially different from the current
RHEL kernels. Additionally, while RHEL was given microcode to ship
with these updates, Intel has not released them upstream  (soon I am
told). It is entirely possible that the patches floating around
upstream have not been tested with the microcode that RHEL shipped.
Given that variant 2 is difficult (not impossible) to attack, we have
been waiting to see what we can ship, when microcode is available and
GCC updates are available.  I can assure you that I have spending
pretty much all of my time tracking upstream, testing patch sets, and
doing what I can to make sure we have mitigations for all 3 variants
in place as quickly as possible.
Today's build of rawhide contains mitigation for variant 1 of spectre
and variant 3 (meltdown) for x86_64. Current stable Fedora kernels
contain mitigation for meltdown on x86_64 as well. Wednesday should
see a new kernel pushed to updates-testing with some bug fixes for the
meltdown mitigation (KPTI), and some mitigation for variant 1. I am
hoping to also get some meltdown coverage for other architectures in
that update. While I would love to see some variant 2 coverage as
well, it is unlikely in the Wednesday time frame.  If it is possible,
I will include those as well, but even then, it will not be the final
solution.  As soon as a solution is deemed ready, it will be pushed to
Fedora.

Justin
___
test-announce mailing list -- test-announce@lists.fedoraproject.org
To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org