Targeted release: Fedora 30
Last updated: 2022-04-08
This standard was introduced at Fedora 30 and the page is up to date as
of 2022-04-08 (set as up to date by the maintainer).
Formally, it is the standard of the Fedora editions (including
Workstation), and the Spins tend to adopt it.
Anyway, the users shall use the line that contains “rhgb quiet”, and
append the blacklisting to the end of that line. But they would be welcome
to share if they have an option line or not - now I am curious
Also, we might shift continuing the grub-entry-content discussion to a dedicated topic. It would be indeed interesting to identify that out of curiosity, but it does not belong to this topic. Feel free to ping me if you open something.
But we are comparing apples to oranges.
My images are from the edit screen opened by pressing the “e” key at the grub boot menu.
Your text seems from the .conf file for that kernel located in /boot/loader/entries.
One can be edited during boot the other cannot (and should not be manually edited).
Those are 2 completely differing topics, though the .conf file is the source for the entry in the grub menu. Try it for yourself – boot to the grub menu then press the “e” and verify that the “options” line does not appear.
I agree this is a diverging subject, but really cannot see where to split the posts without removing at least some that is pertinent to the original topic as well as this part.
No, my text in the “grub editor” when opened with “e” in the grub menu looks equal: it just shows the entry files (even including their formatting), while changes in the grub editor are (as you said) not permanent and thus not added to the file. I had to exploit the options line there many times in the recent days when we tried to identify the ath11k bug by testing many different kernel parameters in different kernels at bootup When the entry files are changed, the changes also appear in the grub editor. So it is just opening the respective file read-only and then using the outcome “one time”.
I agree, I didn’t mean to split the topic. Just to open a new one if we want to continue that. Maybe just reference the posts here and write that this (new topic) is the split follow-up or so. Maybe the topic headline attracts someone who knows off the cuff
I was able to boot without the KVM for kernel 6.3.6 and was able to get video display for the Plymouth screen. I need to use the KVM for work so I reattached it and booted back into kernel 6.2.15. I’ll go update the Bugzilla bug but the last time I had an issue related to the KVM (I linked it in my original post) I needed to raise a bug with AMD.
I tried this and I still had the same problem, no video output for kernel 6.3.6
Yeah mine started with linux as well and basically looked like the photo in Jeff V’s post.
If I got you right, everything works fine without the KVM. A bug is possible - indeed keep the bug report updated (including with model data of the KVM). But another possibility is that the KVM does not support some technology that is currently directed through it. The first thing I have in mind (since it is related to open issues) is PSR: can you try to boot with the kernel parameter amdgpu.dcdebugmask=0x10 [1][2] ? Does that make a difference? I think there were some changes in PSR in the recent time, could have been in 6.3.
Also, have you checked with your preferred search engine if that very KVM model is known to cause issues (and if maybe somewhere on the Internet mitigations are known)?
I found the fallacy, and it’s on my side. So in the place where you were, the line actually starts with linux I’ve been mixing things up with another issue I’ve had a lot to work on recently
Yes correct, sorry I may have explained that poorly. Video output works fine without the KVM on all 6.3.x kernels that I tried. But with the KVM I get no video output on all 6.3.x kernels that I’ve tried. I only get video output with the KVM with 6.2.x kernels.
I tried this with kernel 6.3.7 (upgraded this morning) and still no video with the KVM
You might add a short note to the bug report that this issue upstream could be linked to yours.
I mentioned your issue in the devel mailing list with regards to potentially wider issues around ACPI, although I assume atm that yours is not related to ACPI. However, since it cannot be excluded at this point, and since we have several open issues with the 6.3.X kernels atm, it might be worth to keep them connected in case some relations are indicated at some point.
Unfortunately, I cannot do much more atm. Keep watching the report, provide information if you are asked for, and also keep watching the kernel topics in case solutions come up in other topics that could be helpful for your issue as well. If you find something but are unsure how/if to implement it, feel free to ask here within this topic.
Also, feel free to check from time to time in your preferred search engine for identified issues (and solutions) with Linux 6.3 kernels in conjunction with KVM.
I am using Display Port but the issue with that HDMI bug sounded semi-similar to mine. The KVM I have is https://www.lindy.com.au/2-port-dp-1-2-usb-2-0-audio-cable-kvm-switch which is Display Port 1.2 and my video card is Display Port 1.4 (PowerColor Red Devil AMD Radeon RX 6800 XT). I am using the cable that came with the video card so I assume that is Display Port 1.4 as well. As far as I know Display Port 1.4 is backwards compatible with Display Port 1.2. My monitor (https://www.lg.com/us/support/product/lg-27GP850-B.AUS) is currently set to DisplayPort 1.4 I guess I could set it to DisplayPort 1.2 since the KVM is running that anyway.
The question is more if working with 1.2 uses/calls modules/functions
that are not used/called with 1.4. A lot is involved from “creating
graphics” until “shown on display”, some might be shared among DP and
HDMI (and their versions), some not. Without logs it is hard to
determine where to search/what to test.
I don’t know yet if there is any relation to that, or in between these
topics. But I would like to keep it in mind and gather some information,
just in case. E.g., perfect would be if we could identify a common
module, which we could then test by blacklisting.
It seems there has happened an accident: your bugzilla ticket is CLOSED
ERRATA, which means that the bug has been fixed → the linked updates
are FEDORA-2023-0d0eb153c9 and FEDORA-2023-0ea5b492c7 (6.3.8 for F37 and
F38). I can reopen it if you want BUT:
I am not sure if that makes a difference at this time: it is possible
that your issue will take some time to get fixed even if someone picks
it up, and F37 is close to its end of life (contributors have already to
focus on F38 and F39 when it comes to time-intensive activities).
Also, we do not know if the kernel contains the bug or if it only calls
the bug (in terms of the actual bug being outside the kernel). Thus, …
The first question at this point is: can upgrading to F38 solve your
issue? I am not sure why you still work with F37, but the two major
reasons of users are to update only once per year or to have the most
deeply tested Fedora. If it is the first, I have to say that focusing on
fixing the bug is likely to need more time and issues than upgrading
once more (and more likely to be successful). If it is the latter: be
aware that F38 is already released very long and has reached the same
level of testing than F37 when you installed it (I mean, we are close to
the release of F39).
Just to be on the same page: You have tested the current kernel release
6.4.11 ? And it does not work as well?
Unfortunately, my capabilities to support here are currently a little
limited, so if the issue persists with 6.4.11, my advice is to upgrade
to F38. If this does not solve the issue, open a new bugzilla report,
and let us know here so that I can also add a comment about the
accidental close of the old one (I guess the issue occurred because we
had to tackle two comparable issues back then while the other was fixed
by ucsi_acpi blacklisting, and given the comments, I assume your ticket
was accidentally closed without further review with the assumption that
it is the bugzilla ticket that relates to the other ask.Fedora topic
where lots of people confirmed the blacklisting to solve their issues).
Maybe your ticket at /drm/amd makes a difference, but be aware that it
can end up the same way because on one hand, F37 is end of life soon,
and on the other hand, it is not yet clear if that is an upstream issue.
I don’t think that is necessary, I get the feeling it is an AMD regression not a Fedora one.
Yeah that is my concern, I’d like to get this sorted before Fedora 37 is EOL.
Yeah that is true, I am trying to follow Bisecting Fedora kernel – Kparal's Fedora Blog and I’ve found kernel-6.2.15-200.fc37 | Build Info | koji is kernel-6.2.15-200.fc37 which I am currently using and the next successful build that is available is kernel-6.3.3-100.fc37 | Build Info | koji for kernel kernel-6.3.3-100.fc37. I built that and booted into it and it has the issue I am talking about. I did a kernel bisect on the Fedora kernel code base on the f37 branch and it pointed to kernel-6.2.16-200.fc37 | Build Info | koji kernel kernel-6.2.16-200.fc37 but that build was deleted. What I am trying to work out is how to find the generic Linux kernel code base (git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git) commit hashes for kernel-6.2.15-200.fc37, kernel-6.2.16-200.fc37, and kernel-6.3.3-100.fc37 so I can do the kernel bisect on that.
Yeah I like to be n-1 so it is more tested and less bugs. I used to always stay up to date but then I found a lot of Gnome extensions that I use got broken for a few weeks so I decided to go n-1.
Correct, no kernel above 6.2.15 and my KVM gives any video output after BIOS and GRUB. If I remove the KVM I get video output, but I need that connected to make working from home easy.
Thank you for your time and help so far. I could do the upgrade and then downgrade to the working kernel. Worst case scenario I have to unplug my DisplayPort cable from the KVM and plug it in directly. But switching the cable between my desktop and work laptop will be annoying.
Yeah that is why I am trying to do the kernel bisect to see if it is an AMD issue, which at this point I suspect it is since it hasn’t been fixed in any 6.3 or 6.4 kernel. I’ve tried all of them with and got the same result, no video output after BIOS and GRUB.
A possibility for testing F38 that does not risk your F37 installation:
if you have a usb storage available, put the F38 ISO on it (download the
ISO and put it on the device with dd, or do it with the Fedora Media
Writer that can be installed like any other package → e.g., dnf install mediawriter.x86_64 and then open it).
You can then boot the F38 live system from the USB device (which will
not touch your hard disk unless you intentionally do that yourself) just
to see if F38 makes a difference because the default kernel of the
normal F38 live system is already a 6.3.X kernel. If this F38 live
system works out, you can use a second storage (USB or any other
compatible storage) to install a F38 on it without risking your existing
production installation (don’t forget during installing F38 to unselect
the disk on which your production F37 is installed). Once installed,
check this separated F38, and then update it, and check if it remains
working.
This is also valuable information for finding & fixing the issue even if
you choose to remain with F37 after that.
If your preferred hardware/software configuration does not work also
with F38, you can still check the (officially unsupported & externally
provided) 6.1 long term support kernel: I think this was mentioned
earlier (but maybe that was in another topic), but there is a Fedora
contributor who keeps providing the long term supported Linux kernels
for Fedora. This is not officially supported, and we cannot guarantee
for anything this contributor is providing, but since you are still
working with the obsoleted 6.2 series, you might consider to switch to
one of this contributor’s long term kernels, such as 6.1 → 6.1 is a
long term supported kernel that is currently at 6.1.46 (see https://kernel.org ) → https://copr.fedorainfracloud.org/coprs/kwizart/kernel-longterm-6.1/
This kernel could work since it is from before the 6.2 series whereas
6.1 remains supported from the kernel community (unlike any 6.2 kernel).
At the latest at the end of the F37 life cycle, relying on this
contributor for long term kernels could be considered less problematic
than relying on the soon-unsupported F37 which will then no longer
receive any further package updates. Be aware: this contributor provides
the long term supported 6.1 kernel also for F38 and F39. This solution
is everything but perfect as well, but maybe the testing with the
separated F38 installation will reveal that F38 does no longer
experience the issue.
If you get your “testing F38” working with one of the possibilities, you
might consider to use it at least as interim solution instead of
remaining with F37. Otherwise, you will have still gathered valuable
information for identifying the bug origin.
Oh this is good to know, I didn’t know this was an option.
This is good, at least I have an upgrade pathway to F38 now.
I will try the F38 upgrade on USB storage and see if that fixes it. If not I will unplug the KVM and upgrade to F38 and switch to the LTS 6.1 kernel rather than using the unsupported 6.2.15 kernel. I was planning on upgrading to F38 as soon as F39 came out.
Ok so I installed F38 to a LUKS encrypted external portable hard drive and booting into it with the KVM worked as expected. But I didn’t realise that F38 fresh installs kernel 6.2.9 by default which is already working with the KVM. I then did a distribution upgrade from F37 to F38, following Upgrading Fedora to a New Release :: Fedora Docs. The latest kernel 6.4.11 is installed and with the KVM it is still broken. I still didn’t realise 6.2.9 was the default kernel after the fresh install so I thought maybe my previous install was corrupted so I reformatted / and reinstalled a fresh F38. I did because because the external HDD install worked. That is when I realised 6.2.9 is the default after a fresh install and that is why the external HDD install was working, not the upgrade to F38. Oh well, fortunately I have Ansible to reinstall and reconfigure everything automatically plus a separate /home partition so it was no big deal to recover.
I then manually installed 6.2.15 inside of F38 and booted it with the KVM and it works as expected. I then manually installed 6.3.3 inside of F38 and booted it with the KVM and it doesn’t work as expected. I then installed the 6.1 long term support kernel and booted it with the KVM and it worked as expected. There seems to be an issue with my KVM between kernel 6.2.15 and 6.3.3 in both F37 and F38. This is what I will focus on with the AMD bug ticket.
I was convinced F39 comes with 6.3.9 and not 6.2.9. However, that doesn’t change the remaining plan. Sad that F38 doesn’t solve the issue.
Generally, it is possible in such situations that developer will ask you to check if the newest versions solve an issue (to avoid double work), and so I suggest that you keep an additional F39 installation on an USB drive or so (in order to always keep testing also the newest Fedora).
Hopefully, the long term supported kernel works properly in order to get rid of 6.2.15, but keep testing the new Fedora kernels to see if any solves the issue (including testing on the separated F39 installation).
I have added a comment to your bug ticket BZ#2213179 at Fedora to re-open it (it seems I cannot re-open tickets once they are CLOSED ERRATA by someone else but I added a flag that someone with more privileges needs to do something). You might read it and you can already add related information to the ticket if you want. As mentioned above, it would be nice if you create a F39 installation for testing purposes on a USB drive or such so that we can ensure that no “double work” occurs.
At the best, once a patch that solves your problem is developed (may it be solved in the upstream ticket at freedesktop/AMD or in the Fedora ticket), the patch gets backported to the then-current Fedora kernel so that you are as soon as possible back to an “officially supported Fedora”.
Supplement: your Fedora-sided ticket was reopened Thanks @jwrdegoede
Yeah I will install F39 onto the external HDD when it is released and see how it goes. But won’t F38 and F39 have the same kernel versions, just different packages? e.g. Gnome version will be different.
So far the 6.1 LTS kernel is working fine. But yeah of course I will keep installing new kernels and try them out. The last time I had an issue similar to this it was on F35 and upgrading to F36 and a new kernel fixed it.
Thank you for doing that, I will update it with what I have done so far. Which is basically what is in this ticket plus the git bisecting that I am trying to do with the other upstream developer.
Yes that would be the ideal solution, I’d like to stay with officially supported Fedora where possible.
EDIT: 6.2 to 6.3 is better due to a cleaner git history. I’ll install 6.2 later and verify it is working (I am expecting it to work since 6.2.15 does) and do the git bisect between v6.2 and v6.3.
When the entry files are changed, the changes also appear in the grub editor. So it is just opening the respective file read-only and then using the outcome “one time”.
. When I have some time I check out where the misunderstanding/fallacy lies.
but I added a flag that someone with more privileges needs to do something). You might read it and you can already add related information to the ticket if you want. As mentioned above, it would be nice if you create a F39 installation for testing purposes on a USB drive or such so that we can ensure that no “double work” occurs.