System: Fedora Workstation 43 Hardware: Lenovo Thinkpad X1 2-in-1 Gen 10 Lunar Lake 258v After installing updates on 2026-03-13 (kernel 6.19.7 and associated firmwares+etc), tablet mode was no longer working. Screen would not detect when it was folded back, and would not auto-rotate between portrait/landscape. Confirmed with my backup install on a different SSD that it still worked on kernel 6.19.6. The 2026-03-13 update to kernel 6.19.7 and associated packages broke something. Testing accelerometer with $ monitor-sensor –accel returned “Waiting for iio-sensor-proxy to appear” Testing iio-sensor-proxy.service with $ systemctl status iio-sensor-proxy.service showed the service as “Inactive (dead)” Manually starting the process with $ systemctl start iio-sensor-proxy.service did not return an error but process still showed inactive. Diagnostic step one: boot into kernel 6.19.6. But simply booting into kernel 6.19.6 did not fix it. Something else was afoot; additional packages had been updated and were causing the issue. Using dnf history, I determined linux-firmware and its ~25 associated packages were also updated alongside kernel-6.19.7 and thus were the next suspect. Testing with my other SSD again, I determined tablet mode worked in linux-firmware version 20260221, but did not in version 20260309. I downgraded firmware with $ sudo dnf downgrade https://riscv-kojipkgs.fedoraproject.org//packages/linux-firmware/20260221/1.fc43/noarch/linux-firmware-20260221-1.fc43.noarch.rpm ~25 packages were downgraded in total. After downgrading to linux-firmware-20260221 AND kernel-6.19.6, tablet mode works again. iio-sensor-proxy.service is active and screen fold/rotation are detected properly. Simply downgrading one or the other did not solve the issue, but both together did. TLDR: linux-firmware-20260309 AND kernel-6.19.6 broke iio-sensor-proxy.service and thus tablet mode would not work. Downgrading to linux-firmware-20260221 AND kernel-6.19.6 fixed the issue. Kernel/firmware downgrades alone didn't work, kernel+firmware downgrade together did. Reproducible: Always Steps to Reproduce: 1. Use tablet mode on a device running linux-firmware-20260221 and kernel-6.19.6 2. Update system to linux-firmware-20260309 and kernel-6.19.7 3. Observe that iio-sensor-proxy.service no longer runs and tablet mode doesn't work Actual Results: After updating to linux-firmware-20260309 and kernel-6.19.7, iio-sensor-proxy.service no longer runs and tablet mode doesn't work Testing iio-sensor-proxy.service with $ systemctl status iio-sensor-proxy.service shows the service as “Inactive (dead)” and $ systemctl start iio-sensor-proxy.service does not change service status to active. Expected Results: $ systemctl status iio-sensor-proxy.service should show process as active and tablet mode should work
It's unlikely to be firmware as we don't ship any FW for sensors, nor the HW buses they would use (SPI/i2c etc) so it's likely to be specifically the kernel that causes the issue. If you downgrade the kernel but leave firmware in place make sure you regenerate the initrd.
(In reply to Peter Robinson from comment #1) > It's unlikely to be firmware as we don't ship any FW for sensors, nor the HW > buses they would use (SPI/i2c etc) so it's likely to be specifically the > kernel that causes the issue. If you downgrade the kernel but leave firmware > in place make sure you regenerate the initrd. Assuming $ sudo dracut -f --regenerate-all is the right way to regenerate initrd (I'm a Linux noob so correct me if that's wrong), kernel-6.19.6 with linux-firmware-20260309 still doesn't work. I can only get iio-sensor-proxy.service to start when both kernel 6.19.6 and linux-firmware-20260221 are in use.
Confirmed that it is a linux-firmware issue. If I boot kernel-6.19.7 and run $ sudo dracut -f --regenerate-all and reboot, then iio-sensor-proxy.service WILL START using linux-firmware-20260221
Kernel 6.19.8 did not solve. Downgrade of linux-firmware to 20260221 still required to get iio-sensor-proxy.service to run.
I am not aware of any sensors that ship firmware in linux-firmware, I am assuming if it really is firmware it must be GPU firmware, can you upgrade just the intel-gpu-firmware and see if it breaks. Adding Mark @ Lenovo: Mark does anyone of your team know what might be coming into play here.
Curious - I'm using the X1 2-in-1 G10 as my note taking device (almost exclusively in tablet mode) and I updated it yesterday (F43) and it's working fine - 6.19.7 kernel and linux-firmware-20260309 We have made some changes recently to support the ISH firmware on the X1 2-in-1 G11 - particularly this commit: https://gitlab.com/kernel-firmware/linux-firmware/-/commit/0882248d05045565bfefe1f07cbfc22276c9f058 (there's a follow up to remove duplicate FW) Checking my kernel logs, it's not loading that file - I suspect because I have a prototype system but I'll dig into that and ask the experts on the Japan team Could you: - Send me the kernel log so I can compare against my system and see if it gives me any clues (mpearson-lenovo at squebb dot ca is best). Check for ISH loader messages in particular - be interesting to see if it's loading the Lenovo FW - See if removing the /lib/firmware/LENOVO/ish/ fixes it - that should confirm root cause. - Let me know the BIOS and EC version please? - Send me the output to 'sudo dmidecode -t system' that would be useful too (don't post that publicly - it has your serial number in it) I've created internal ticket LO-4321 for tracking. Mark
Thanks Mark, sent you an email.
Just an update that we think we know what is going on. I'll share more details later, once it's confirmed 100% on the root cause (brief summary is it looks like some filename changes made to reduce the number of files needed on linux-firmware also need a kernel patch to go along with them which I need to backport into 6.19). Once we're confident on the fix I'll share some workaround steps. For now recommended to stay on the older linux-firmware please Mark
Merge request submitted: https://gitlab.com/cki-project/kernel-ark/-/merge_requests/4419 (I think it will do updates here once it gets reviewed and approved)
FEDORA-2026-d4572d6000 (kernel-6.19.10-200.fc43) has been submitted as an update to Fedora 43. https://bodhi.fedoraproject.org/updates/FEDORA-2026-d4572d6000
FEDORA-2026-e976c4f5fa (kernel-6.19.10-300.fc44) has been submitted as an update to Fedora 44. https://bodhi.fedoraproject.org/updates/FEDORA-2026-e976c4f5fa
FEDORA-2026-d85f7a71f0 (kernel-6.19.10-100.fc42) has been submitted as an update to Fedora 42. https://bodhi.fedoraproject.org/updates/FEDORA-2026-d85f7a71f0
Bodhi you weren't tagged in this bug yet!
FEDORA-2026-e976c4f5fa has been pushed to the Fedora 44 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-e976c4f5fa` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-e976c4f5fa See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2026-d4572d6000 has been pushed to the Fedora 43 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-d4572d6000` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-d4572d6000 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2026-d85f7a71f0 has been pushed to the Fedora 42 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-d85f7a71f0` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-d85f7a71f0 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2026-e976c4f5fa (kernel-6.19.10-300.fc44) has been pushed to the Fedora 44 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2026-d4572d6000 (kernel-6.19.10-200.fc43) has been pushed to the Fedora 43 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2026-d85f7a71f0 (kernel-6.19.10-100.fc42) has been pushed to the Fedora 42 stable repository. If problem still persists, please make note of it in this bug report.
Hi, this exact same issue happens for me on another Lunar Lake laptop HP Omnibook Ultra Flip 14 - Ultra 9 288V Downgrading to linux-firmware-20260221 like the other user fixed the issue, and it used to work when i first installed fedora. The fix you made in 6.19.10 and the firmware associated with it did not resolve the issue for me and the regression still remains.
(In reply to helpmepls477 from comment #20) > Hi, this exact same issue happens for me on another Lunar Lake laptop > HP Omnibook Ultra Flip 14 - Ultra 9 288V > > Downgrading to linux-firmware-20260221 like the other user fixed the issue, > and it used to work when i first installed fedora. > The fix you made in 6.19.10 and the firmware associated with it did not > resolve the issue for me and the regression still remains. Our issue should have been specific to the Lenovo platforms - it shouldn't have impacted HP platforms. I'll let the team know, in case we've done something that could impact another vendor (I really hope not). Probably worth flagging this to the HP team if you have a way of doing that? Mark
(In reply to Mark Pearson from comment #21) > (In reply to helpmepls477 from comment #20) > > Hi, this exact same issue happens for me on another Lunar Lake laptop > > HP Omnibook Ultra Flip 14 - Ultra 9 288V > > > > Downgrading to linux-firmware-20260221 like the other user fixed the issue, > > and it used to work when i first installed fedora. > > The fix you made in 6.19.10 and the firmware associated with it did not > > resolve the issue for me and the regression still remains. > > Our issue should have been specific to the Lenovo platforms - it shouldn't > have impacted HP platforms. > > I'll let the team know, in case we've done something that could impact > another vendor (I really hope not). Probably worth flagging this to the HP > team if you have a way of doing that? > > Mark I've made a new bug report here (2455132): https://bugzilla.redhat.com/show_bug.cgi?id=2455132 Apologies as I am new to bugzilla and bug reporting in general, I am unsure how to flag the HP team Will
Not sure either I'm afraid :) If nobody from RH chimes in then I can ping the OEM team at Canonical and let them know as they work with HP as well.
Looks like the HP issue is quite different. There are some linux-firmware issues open and under discussion: https://gitlab.com/kernel-firmware/linux-firmware/-/merge_requests/746 https://gitlab.com/kernel-firmware/linux-firmware/-/merge_requests/936 It looks like the Omnibook isn't getting support from HP (but I might be wrong). The user on MR #746 looks to have some contact with HP so can likely help out?
(In reply to Mark Pearson from comment #24) > Looks like the HP issue is quite different. There are some linux-firmware > issues open and under discussion: > https://gitlab.com/kernel-firmware/linux-firmware/-/merge_requests/746 > https://gitlab.com/kernel-firmware/linux-firmware/-/merge_requests/936 > > It looks like the Omnibook isn't getting support from HP (but I might be > wrong). The user on MR #746 looks to have some contact with HP so can likely > help out? It's just odd, because the exact same firmware downgrade worked for me as the lenovo, it used to work perfectly but got broken in newer firmware. I hope it can be fixed soon
Reopening as a general tracker, it seems there's more affected by the same/similar problem.
*** Bug 2467672 has been marked as a duplicate of this bug. ***
Hi Peter, For the issue on the Framework - is there a before and after kernel log available? Need to figure out if fix is needed on the kernel or linux-firmware side. Not sure what FW it's trying (and presumably failing) to load. I couldn't see logs on the dup ticket - let me know if I'm missing them If it's linux-firmware, afraid Framework have to do that. If it's related to the kernel changes then we can help Mark
(In reply to Mark Pearson from comment #28) > Hi Peter, > > For the issue on the Framework - is there a before and after kernel log > available? Need to figure out if fix is needed on the kernel or > linux-firmware side. Not sure what FW it's trying (and presumably failing) > to load. I couldn't see logs on the dup ticket - let me know if I'm missing > them > I have a BZ for this, see bug 2458958. If you need more details, please sync up with me in that BZ instead of this one. > If it's linux-firmware, afraid Framework have to do that. If it's related to > the kernel changes then we can help > It is possible it's linux-firmware, but I don't think Framework would have done it.
I posted this in https://bugzilla.redhat.com/show_bug.cgi?id=2467672 I'm reposting here so it doesn't get missed. It's a workaround Framework have posted. Force loading modules and rebuilding dracut. https://github.com/FrameworkComputer/linux-docs/blob/main/framework12/Fedora-all.md#the-proper-method---should-work-but-it-it-does-not-use-the-service-method I've used it with linux-firmware-20260410-1.fc44 and it seems to work.
(In reply to L.L.Robinson from comment #30) > I posted this in https://bugzilla.redhat.com/show_bug.cgi?id=2467672 I'm > reposting here so it doesn't get missed. It's a workaround Framework have > posted. Force loading modules and rebuilding dracut. > > https://github.com/FrameworkComputer/linux-docs/blob/main/framework12/Fedora- > all.md#the-proper-method---should-work-but-it-it-does-not-use-the-service- > method > > I've used it with linux-firmware-20260410-1.fc44 and it seems to work. hmm, this doesn't seem to work for me, the iio-sensor is still inactive after doing the complicated way or proper way in the link. The framework 12 also seems to use a tigerlake chip, not Lunar Lake, so I don't know how much overlap there is firmware-wise.