Doing a rawhide install where I needed to pass bootargs for the system to work correctly resulted in an installed system that did not retain the bootargs requiring them to be manually added on the first boot and then the system to be updated so that they persist. Reproducible: Always Steps to Reproduce: 1. add bootargs when booting the livecd 2. install the system 3. Actual Results: no bootargs added to the installed system Expected Results: bootargs from booting the installer media be retained in the installed system
what argument, specifically, did you need? not all arguments are carried over by the installer, there is an allowlist. it contains: # Arguments preserved from the installation system. preserved_arguments = cio_ignore zfcp.allow_lun_scan speakup_synth apic noapic apm ide noht acpi video pci nodmraid nompath nomodeset noiswmd fips selinux biosdevname ipv6.disable net.ifnames net.ifnames.prefix nosmt vga
"arm64.nopauth clk_ignore_unused pd_ignore_unused rd.driver.blacklist=msm" is required for the Lenovo x13s to boot correctly
Fun. So, it's kinda expected that it doesn't work, but of course problematic. Not sure if the best fix is to add all of that alphabet soup to the allowlist in the installer, or...something else. Are kernel side fixes in progress?
My understanding is that the issues are not likely to be fixed. There is a different workaround for the issue needing rd.driver.blacklist=msm and that is to have dracut pull in some extra firmware files and kernel modules so that msm initialises fully in the initramfs. and then plymouth will show the password prompt for decrypting the disk. delaying MSM from being loaded uses simpledrm and everything works, doing nothing you get a blank screen and have to blindly enter the password.
CCing Mark Pearson, since this affects a Lenovo system. anaconda devs, what do you want to do here? Add the relevant args to the allowlist?
Oh cool - getting Fedora running on the X13s would be fantastic :) As a side note, the x13s isn't officially Linux supported - but it would be nice to have Fedora booting on it easily (there are projects for ubuntu and debian that are doing that, but I've not had enough time to really get involved and do similar for Fedora) For the bootargs: The nopauth is likely to be needed for a time - I've not had any joy getting fixes for that from Qualcomm and our FW team unfortunately. There isn't a kernel fix for that one. The others - I'll have to do some research, but I know there was still work ongoing for the rtc and the power control - which I assume is what those are for? As an aside, if there's anything sensible I can help with (testing etc) let me know. I do have a system, and connections into some of the folk who worked on this at Linaro & ARM (and a couple of people to talk to in Qualcomm). I just don't have any levers to get work done - but they've been very supportive on pushing the project of seeing how much of Linux we could get running. Mark
Hi, I have a bad feeling about preserving `rd.driver.blacklist` specifically. There might be situations where you want to blacklist drivers during installation but not after. Specifically, it's used in combination with `inst.dd`. As you can see here: https://issues.redhat.com/browse/RHEL-4762?focusedId=23052383&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-23052383
After a brief discussion in the team. We think that if Fedora (kernel or something else) is not able to resolve this, which is preferred way. It might be a specific workaround implemented for this specific HW into Anaconda so it could be removed in the future when it's not needed anymore. Ideally Fedora should try other ways first but if necessary, Anaconda can detect given HW and add these boot parameters to the installed system. It's more robust solution then using the filed mentioned above. Adding new persistent options could break some workflows. In any case, Anaconda team don't have resources right now to work on this. However, this change should be straightforward to implement, so if community wants to contribute, we are happy about sanity checking (don't have HW to test the patch).
(In reply to Mark Pearson from comment #6) > Oh cool - getting Fedora running on the X13s would be fantastic :) > As a side note, the x13s isn't officially Linux supported - but it would be > nice to have Fedora booting on it easily (there are projects for ubuntu and > debian that are doing that, but I've not had enough time to really get > involved and do similar for Fedora) > > For the bootargs: > The nopauth is likely to be needed for a time - I've not had any joy getting > fixes for that from Qualcomm and our FW team unfortunately. There isn't a > kernel fix for that one. > The others - I'll have to do some research, but I know there was still work > ongoing for the rtc and the power control - which I assume is what those are > for? > > As an aside, if there's anything sensible I can help with (testing etc) let > me know. I do have a system, and connections into some of the folk who > worked on this at Linaro & ARM (and a couple of people to talk to in > Qualcomm). I just don't have any levers to get work done - but they've been > very supportive on pushing the project of seeing how much of Linux we could > get running. > > Mark https://fedoraproject.org/wiki/Thinkpad_X13s documents getting things going. There are some fixes needed still. The x13s package in the copr deals with pulling in pd-mapper for power/battery etc, and cleaning up the blacklist needed to boot from USB but not for booting from NVMe. The system also does not suspend. But rawhide mostly works with a few corner cases that are rougher than need be. rd.driver.blacklist=msm can be removed by adding about 6 modules and some firmware to the initrd which may be a better fix as there is a timeer on a clock that gets turned off that causes the screen to turn off after 30 seconds and not come back on until further in the boot that is held up if you need to decrypt the disk. you can blindly decrypt if the clock is turned off, you just need to know that is what is going on
-3 in https://pagure.io/fedora-qa/blocker-review/issue/1445 , marking as rejected blocker. Seems like a good commonbugs candidate, though.
This message is a reminder that Fedora Linux 40 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 40 on 2025-05-13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '40'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 40 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.