Created attachment 1761251 [details] requested journalctl. 1. Please describe the problem: On my main laptop (Dell Latitude E5570, BIOS 1.23.3 since april 2020) kernel-5.11 panics during boot. A Latitude 5480, Latitude E5510 and some old Asus laptop boot just fine. I am using a cleanly installed Fedora 33 on XFS. After a day of debugging (disabling SMT, disabling Wifi, disabling ethernet, disabling audio, etc) I managed to boot using acpi=off. Tried acpi_osi=Windows, acpi=ht, pci=noacpi, acpi=noirq, pnpacpi=off, noapci, nolapic , acpi=strict as well, none of them work, only acpi=off boots (though giving me a single core computer without SMT). 2. What is the Version-Release number of the kernel: Currently 5.11.3-50.fc33.x86_64. I recompiled all fc34 5.11 kernels as well, same issue. 3. Did it work previously in Fedora? If so, what kernel version did the issue *first* appear? Old kernels are available for download at https://koji.fedoraproject.org/koji/packageinfo?packageID=8 : All 5.11 kernels exhibit this behaviour. All 5.10 kernels work fine. I even tried 5.12 (kernel-rawhide-nodebug) and that one works as well. 4. Can you reproduce this issue? If so, please provide the steps to reproduce the issue below: Boot with any 5.11 kernel. 5. Does this problem occur with the latest Rawhide kernel? To install the Rawhide kernel, run ``sudo dnf install fedora-repos-rawhide`` followed by ``sudo dnf update --enablerepo=rawhide kernel``: No, kernel-5.12.0-0.rc1.162.fc35.x86_64 boots fine. 6. Are you running any modules that not shipped with directly Fedora's kernel?: Tried with and without, no change. 7. Please attach the kernel logs. You can get the complete kernel log for a boot with ``journalctl --no-hostname -k > dmesg.txt``. If the issue occurred on a previous boot, use the journalctl ``-b`` flag.
Created attachment 1761252 [details] journalctl of working 5.10 boot
Created attachment 1761253 [details] rdsosreport of booot using rd.break=cleanup
Created attachment 1761254 [details] journalctl of booot using rd.break=cleanup
Used rd.break up to cleanup to figure out where the panic occurs. It seems to appear right after the the rd phase, during the sysinit.target. Tried using 'acpi.debug_layer=0x2 acpi.debug_level=0xffffffff' as well but CONFIG_ACPI_DEBUG is not set. I can not really figure out why every bit of hardware works just fine, except for my main laptop, which serves me well for over 4 years now.
Not sure if it is relevant, but I copied the root disk to an external USB drive. Then booting 5.11 on my Dell E5570 it panics, using the same disk on a Dell 5480 it works just fine.
Both kernel-5.11.4-50.fc33 and kernel-5.11.5-50.fc33 exhibit the exact same behavior, no change there.
no changes for kernel-5.11.7-200.fc33, still panics on boot. kernel-5.12.0-0.rc3.170.fc35.x86_64 from kernel-rawhide-nodebug does work in general (not thoroughly tested).
I had the same issue on a Dell Inc. Precision 7710 and kernel 5.11.3-300.fc34.x86_64. It was resolved with 5.12.0-0.rc3.20210318git6417f03132a6.171.fc35.x86_64 which boots fine
Created attachment 1764477 [details] dmesg dell 7710 Goes with c8. In common with original report: [ 5.718740] kernel: dcdbas dcdbas: Dell Systems Management Base Driver (version 5.6.0-3.4) [ 5.718967] kernel: stack segment: 0000 [#1] SMP PTI [ 5.718970] kernel: CPU: 6 PID: 651 Comm: systemd-udevd Not tainted 5.11.6-300.fc34.x86_64 #1 [ 5.718972] kernel: Hardware name: Dell Inc. Precision 7710/01KDY8, BIOS 1.21.3 08/04/2020 [ 5.718974] kernel: RIP: 0010:kobject_put+0x19/0x1d0 [ 5.718977] kernel: Code: c7 c7 40 df d2 b6 e8 46 c3 fe ff eb d6 0f 1f 40 00 48 85 ff 0f 84 b4 00 00 00 41 56 41 55 41 54 55 48 89 fd 53 bb ff ff ff ff <f6> 45 3c 01 0f 84 80 00 00 00 48 8d 7d 38 89 d8 f0 0f c1 45 38 83 [ 5.718979] kernel: RSP: 0018:ffffabaa00443da8 EFLAGS: 00010282 [ 5.718981] kernel: RAX: 0000000000000000 RBX: 00000000ffffffff RCX: 0000000000000000 [ 5.718983] kernel: RDX: 0000000000000001 RSI: 0000000000000000 RDI: d53e78a8f6bc94ea [ 5.718984] kernel: RBP: d53e78a8f6bc94ea R08: 0000000000000001 R09: 0000000000000000 [ 5.718985] kernel: R10: ffff8c9ec2a28400 R11: 0000000000000001 R12: d53e78a8f6bc94ea [ 5.718986] kernel: R13: 000055cdab559fe6 R14: 00007f06dbd2032c R15: ffffabaa00443e88 [ 5.718988] kernel: FS: 00007f06dafbfb40(0000) GS:ffff8ca23dd80000(0000) knlGS:0000000000000000 [ 5.718989] kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 5.718991] kernel: CR2: 000055cdab555b28 CR3: 0000000106734001 CR4: 00000000003706e0 [ 5.718992] kernel: DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 5.718993] kernel: DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 5.718995] kernel: Call Trace: [ 5.718997] kernel: kset_unregister+0x25/0x40 [ 5.718999] kernel: ? 0xffffffffc07bb000 [ 5.719001] kernel: sysman_init+0x20a/0x1000 [dell_wmi_sysman] [ 5.719006] kernel: do_one_initcall+0x44/0x1d0 [ 5.719009] kernel: ? do_init_module+0x23/0x270 [ 5.719012] kernel: ? kmem_cache_alloc_trace+0xef/0x1e0 [ 5.719015] kernel: do_init_module+0x5c/0x270 [ 5.719017] kernel: __do_sys_init_module+0x11d/0x180 [ 5.719019] kernel: do_syscall_64+0x33/0x40 [ 5.719023] kernel: entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 5.719025] kernel: RIP: 0033:0x7f06dbbcd44e Offhand I'm not seeing what might be fixing it in 5.12... Looks related to this: https://bugzilla.kernel.org/show_bug.cgi?id=211895
I tried the proposed patch from the bug report at kernel.org to no avail. As suggested there, adding 'modprobe.blacklist=dell_wmi_sysman' to the boot options makes kernel-5.11.7-200.fc33 bootable.
Perry, can you take a look at this?
> Perry, can you take a look at this? Note a fix for this has been posted upstream, but as I mentioned during the review, the fix contains a bug and a new fixed version of the fix is necessary: https://patchwork.kernel.org/project/platform-driver-x86/patch/20210218191723.20030-1-mario.limonciello@dell.com/#23988825
(In reply to Jared Dominguez from comment #11) > Perry, can you take a look at this? This was one sysman driver crash issue that has been fixed by the patch Hans mentioned. Seeing from Comment 9 , this seems like is a new issue of sysman driver
I've prepared and posted a set of patches which deal with various problems with error-exit path cleanups and general robustness of the dell-wmi-sysman driver: https://lore.kernel.org/platform-driver-x86/20210320143429.76047-1-hdegoede@redhat.com/T/#t Note it is not entirely clear to me what is going on here, so I'm not sure if these patches fix things but hopefully they will help. I've started a Fedora kernel test-build with these patches added here: https://koji.fedoraproject.org/koji/taskinfo?taskID=64195453 Note this is still building ATM it should be done in about 2 hours. See here for generic instructions for installing a kernel directly from koji (the Fedora build-system): https://fedorapeople.org/~jwrdegoede/kernel-test-instructions.txt Please give this kernel a test and let me know if it fixes things. Perry, can you please test this test-build on hardware which actually supports the new WMI interfaces used by dell-wmi-sysman and checks that the dell-wmi-sysman still works correctly on that hardware? ### What would also be helpful, independent of testing the patches, is if someone could boot a 5.11 kernel with dell-wmi-sysman blacklisted to avoid the problem. And then: 1. Switch to a text-console 2. ssh into the machine and run dmesg -w 3. ssh into the machine a second time and run: "sudo modprobe dell_wmi_sysman dyndbg" And then collect log info from the "dmesg -w" and in case there are log messages on the text-console which did not make it into the ssh dmesg -w output, make a picture of those.
Note the scratch/test kernel-build has completed building now, if someone can give this a test on one of the machines where 5.11 does not work that would be great. Perry, can you please test this test-build on hardware which actually supports the new WMI interfaces used by dell-wmi-sysman and checks that the dell-wmi-sysman still works correctly on that hardware?
Created attachment 1764959 [details] dmesg during modprobe dell_wmi_sysman
Tried the scratch build on a Dell Latitude E5570 and it boots fine. dell_wmi_sysman is loaded after boot. dmesg | grep -i wmi [ 2.724671] wmi_bus wmi_bus-PNP0C14:01: WQBC data block query control method not found [ 2.724813] acpi PNP0C14:02: duplicate WMI GUID 05901221-D566-11D1-B2F0-00A0C9062910 (first instance was on PNP0C14:01) [ 2.743025] acpi PNP0C14:03: duplicate WMI GUID 05901221-D566-11D1-B2F0-00A0C9062910 (first instance was on PNP0C14:01) [ 8.132832] input: Dell WMI hotkeys as /devices/platform/PNP0C14:01/wmi_bus/wmi_bus-PNP0C14:01/9DBB5994-A997-11DA-B012-B622A1EF5492/input/input17 [ 10.708045] Modules linked in: iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 iptable_mangle iptable_raw iptable_security ccm des_generic libdes ip_set nf_tables nfnetlink cmac ip6table_filter bnep ip6_tables md4 iptable_filter uvcvideo vboxnetadp(OE) vboxnetflt(OE) vboxdrv(OE) snd_usb_audio(+) videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_common ee1004 videodev snd_usbmidi_lib snd_rawmidi btusb btrtl btbcm btintel bluetooth iTCO_wdt intel_pmc_bxt iTCO_vendor_support mei_wdt mei_hdcp mc sunrpc ppdev intel_rapl_msr ecdh_generic ecc dell_laptop dell_smm_hwmon snd_hda_codec_hdmi x86_pkg_temp_thermal intel_powerclamp coretemp iwlmvm snd_hda_codec_realtek kvm_intel snd_soc_skl snd_hda_codec_generic ledtrig_audio snd_soc_hdac_hda snd_hda_ext_core snd_soc_sst_ipc snd_soc_sst_dsp snd_soc_acpi_intel_match mac80211 snd_soc_acpi snd_hda_intel snd_intel_dspcfg soundwire_intel soundwire_generic_allocation snd_soc_core snd_compress snd_pcm_dmaengine soundwire_cadence Tried the scratch build on a Dell Latitude 5480 and it boots fine as well. dell_wmi_sysman is not loaded after boot. dmesg | grep -i wmi [ 1.834480] wmi_bus wmi_bus-PNP0C14:01: WQBC data block query control method not found [ 5.521307] input: Dell WMI hotkeys as /devices/platform/PNP0C14:01/wmi_bus/wmi_bus-PNP0C14:01/9DBB5994-A997-11DA-B012-B622A1EF5492/input/input11
Freddy, thank you for the tests and for the dmesg which you've attached on the kernel bugzilla. I think I have a good idea now of why the crash is happening, but I do still have a few more questions: 1. Can you do (while running the patched kernel): ls -lR /sys/class/firmware-attributes/dell-wmi-sysman/ On the system where the driver actually loads (E5570) and copy and paste the output here ? I wonder if the driver actually does anything there, or if one of my patches is wrong causing an empty "firmware-attributes" device to show up there. 2. Can you, with the patched-kernel do a "sudo modprobe dell_wmi_sysman dyndbg" on the system where the driver does not load (5480) and then collect dmesg output after that ? 3. When you boot an unpatched kernel on the 5480, does lsmod show dell_wmi_sysman being loaded? I think it may simply never load on that devices because it does not have the WMI GUIDs which the driver binds to. 4. Can you do: "ls /sys/bus/wmi/devices/" on the 5480 and copy and paste the output here?
Here is the requested info. Let me know if you need anything else. 1. Can you do (while running the patched kernel): ls -lR /sys/class/firmware-attributes/dell-wmi-sysman/ /sys/class/firmware-attributes/dell-wmi-sysman/: total 0 drwxr-xr-x. 2 root root 0 21 mrt 12:37 attributes drwxr-xr-x. 4 root root 0 21 mrt 12:37 authentication drwxr-xr-x. 2 root root 0 21 mrt 12:37 power lrwxrwxrwx. 1 root root 0 21 mrt 12:34 subsystem -> ../../../../class/firmware-attributes -rw-r--r--. 1 root root 4096 21 mrt 12:33 uevent /sys/class/firmware-attributes/dell-wmi-sysman/attributes: total 0 -r--r--r--. 1 root root 4096 21 mrt 12:37 pending_reboot -rw-r--r--. 1 root root 4096 21 mrt 12:37 reset_bios /sys/class/firmware-attributes/dell-wmi-sysman/authentication: total 0 drwxr-xr-x. 2 root root 0 21 mrt 12:37 Admin drwxr-xr-x. 2 root root 0 21 mrt 12:37 System /sys/class/firmware-attributes/dell-wmi-sysman/authentication/Admin: total 0 --w-------. 1 root root 4096 21 mrt 12:37 current_password -r--r--r--. 1 root root 4096 21 mrt 12:37 is_enabled -r--r--r--. 1 root root 4096 21 mrt 12:37 max_password_length -r--r--r--. 1 root root 4096 21 mrt 12:37 mechanism -r--r--r--. 1 root root 4096 21 mrt 12:37 min_password_length --w-------. 1 root root 4096 21 mrt 12:37 new_password -r--r--r--. 1 root root 4096 21 mrt 12:37 role /sys/class/firmware-attributes/dell-wmi-sysman/authentication/System: total 0 --w-------. 1 root root 4096 21 mrt 12:37 current_password -r--r--r--. 1 root root 4096 21 mrt 12:37 is_enabled -r--r--r--. 1 root root 4096 21 mrt 12:37 max_password_length -r--r--r--. 1 root root 4096 21 mrt 12:37 mechanism -r--r--r--. 1 root root 4096 21 mrt 12:37 min_password_length --w-------. 1 root root 4096 21 mrt 12:37 new_password -r--r--r--. 1 root root 4096 21 mrt 12:37 role /sys/class/firmware-attributes/dell-wmi-sysman/power: total 0 -rw-r--r--. 1 root root 4096 21 mrt 12:37 autosuspend_delay_ms -rw-r--r--. 1 root root 4096 21 mrt 12:37 control -r--r--r--. 1 root root 4096 21 mrt 12:37 runtime_active_time -r--r--r--. 1 root root 4096 21 mrt 12:37 runtime_status -r--r--r--. 1 root root 4096 21 mrt 12:37 runtime_suspended_time 2. Can you, with the patched-kernel do a "sudo modprobe dell_wmi_sysman dyndbg" on the system where the driver does not load (5480) and then collect dmesg output after that ? modprobe: ERROR: could not insert 'dell_wmi_sysman': No such device 3. When you boot an unpatched kernel on the 5480, does lsmod show dell_wmi_sysman being loaded? I think it may simply never load on that devices because it does not have the WMI GUIDs which the driver binds to. lsmod | grep -i dell dell_rbtn 20480 0 dell_laptop 28672 0 ledtrig_audio 16384 2 snd_hda_codec_generic,dell_laptop dell_smm_hwmon 24576 0 dell_wmi 20480 0 dell_smbios 32768 2 dell_wmi,dell_laptop dcdbas 20480 1 dell_smbios dell_wmi_descriptor 20480 2 dell_wmi,dell_smbios rfkill 28672 8 bluetooth,dell_laptop,dell_rbtn,cfg80211 dell_smo8800 20480 0 sparse_keymap 16384 2 intel_hid,dell_wmi video 53248 3 dell_wmi,dell_laptop,i915 dell_wmi_sysman 49152 0 wmi 36864 6 dell_wmi_sysman,intel_wmi_thunderbolt,dell_wmi,wmi_bmof,dell_smbios,dell_wmi_descriptor 4. Can you do: "ls /sys/bus/wmi/devices/" on the 5480 and copy and paste the output here? ls /sys/bus/wmi/devices/ 05901221-D566-11D1-B2F0-00A0C9062910 8D9DDCBC-A997-11DA-B012-B622A1EF5492 A80593CE-A997-11DA-B012-B622A1EF5492 86CCFD48-205E-4A77-9C48-2021CBEDE341 9DBB5994-A997-11DA-B012-B622A1EF5492
(In reply to Freddy Willemsen from comment #19) > Here is the requested info. Let me know if you need anything else. Thank you. > 1. Can you do (while running the patched kernel): <snip> > /sys/class/firmware-attributes/dell-wmi-sysman/attributes: > total 0 > -r--r--r--. 1 root root 4096 21 mrt 12:37 pending_reboot > -rw-r--r--. 1 root root 4096 21 mrt 12:37 reset_bios Ok, so this is as I expected, your BIOS seems to advertise the functionality to set BIOS settings from within the OS, but it does not list any actual settings to change (which is what triggered the crash before). Interestingly enough it does seem to allow changing the BIOS-passwords from within the OS. I'm not sure if that is intentional on Dell's side or not. I'll discuss with Dell how to proceed with this bit of the issue. I've dropped the patch which allows the driver to still load even though there are no "attributes" to set for now; and I'll submit a merge-req to get the other patches (which will still fix the crash) added to the Fedora 5.11 kernels, so that affected machines will boot again.
No problem, glad to be of service. Thanks for all the efforts in squashing this bug. Look forward to the patched 5.11 fedora kernels.
Here is the merge-req for getting the fixes for this added to the Fedora 5.11 kernels: https://gitlab.com/cki-project/kernel-ark/-/merge_requests/978
(In reply to Hans de Goede from comment #14) > I've prepared and posted a set of patches which deal with various problems > with error-exit path cleanups and general robustness of the dell-wmi-sysman > driver: > > https://lore.kernel.org/platform-driver-x86/20210320143429.76047-1- > hdegoede/T/#t > > Note it is not entirely clear to me what is going on here, so I'm not sure > if these patches fix things but hopefully they will help. > > I've started a Fedora kernel test-build with these patches added here: > https://koji.fedoraproject.org/koji/taskinfo?taskID=64195453 > > Note this is still building ATM it should be done in about 2 hours. > > See here for generic instructions for installing a kernel directly from koji > (the Fedora build-system): > https://fedorapeople.org/~jwrdegoede/kernel-test-instructions.txt > > Please give this kernel a test and let me know if it fixes things. > > Perry, can you please test this test-build on hardware which actually > supports the new WMI interfaces used by dell-wmi-sysman and checks that the > dell-wmi-sysman still works correctly on that hardware? > > ### > > What would also be helpful, independent of testing the patches, is if > someone could boot a 5.11 kernel with dell-wmi-sysman blacklisted to avoid > the problem. > > And then: > > 1. Switch to a text-console > 2. ssh into the machine and run dmesg -w > 3. ssh into the machine a second time and run: "sudo modprobe > dell_wmi_sysman dyndbg" > > And then collect log info from the "dmesg -w" and in case there are log > messages on the text-console which did not make it into the ssh dmesg -w > output, make a picture of those. Hi Hans I got one sample which support sysman feature and will do the testing On Monday today. Dell have a new BIOS fixing previous driver issue and I need to flash the BIOS then i can test your kernel. Perry
Hans. I saw you update your patch to V2. Could you share the V2 test kernel koji link ? I can help to test that version as well.
(In reply to Perry Yuan (Dell) from comment #24) > Hans. > I saw you update your patch to V2. > Could you share the V2 test kernel koji link ? > I can help to test that version as well. The biggest difference in v2 is that I dropped this patch: https://patchwork.kernel.org/project/platform-driver-x86/patch/20210321121607.35717-1-hdegoede@redhat.com/ Because that patch needs more testing, the rest is the same as v1, so please test the v1 kernel which actually has that patch: https://koji.fedoraproject.org/koji/taskinfo?taskID=64195453
Tested Hans V1 test kernel on Dell new Mobile platform which flashed with new BIOS The sysman driver works well and no issue found on that kernel. [root@localhost dell-wmi-sysman]# uname -r 5.11.7-300.bz1936171.fc34.x86_64 BIOS Information Vendor: Dell Inc. Version: 0.2.37 Release Date: 03/10/2021 ROM Size: 32 MB [root@localhost dell-wmi-sysman]# ls attributes/ Absolute Camera FullScreenLogo PasswordLock SignOfLifeByDisplay UefiBootPathSecurity AdminSetupLockout CapsuleFirmwareUpdate GraphicSpecMode PeakShiftBatteryThreshold SignOfLifeByKbdBacklight UefiNwStack AdvancedMode ChasIntrusion HttpsBoot PeakShiftCfg SmartErrors UnobtrusiveMode AdvBatteryChargeCfg ChassisIntrusionReset HttpsBootMode pending_reboot SmmSecurityMitigation UsbEmu AllowBiosDowngrade ClearDellRmtLog HybridGraphics PostMebxKey SpeedShift UsbPortsExternal AmtCap CpuCore IntegratedAudio PowerLogClear Speedstep UsbPowerShare Asset CStatesCtrl IntelTME PowerOnLidOpen StrongPassword UsbProvision AutoOn CustomChargeStart InternalSpeaker PowerWarn SupportAssistOSRecovery VideoPowerOnlyPorts AutoOnFri CustomChargeStop KbdBacklightTimeoutAc PrimaryBattChargeCfg SupportAssistSupportLevel Virtualization AutoOnHr DellCoreService KbdBacklightTimeoutBatt PwdDigitRqd SvcTag VtForDirectIo AutoOnMn DeviceHotkeyAccess KeyboardIllumination PwdLowerCaseRqd TelemetryAccessLvl WakeOnAc AutoOnMon DisUsb4Pcie LogicProc PwdMinLen ThermalLogClear WakeOnDock AutoOnSat DRmt M2PcieSsd0 PwdSpecialCharRqd ThermalManagement WakeOnLan AutoOnSun DynTunML M2PcieSsd1 PwdUpperCaseRqd ThunderboltBoot WarningsAndErr AutoOnThur EmbNic1 M2PcieSsd2 RemoteWipeInternalDrives ThunderboltPorts WirelessLan AutoOnTue EmbSataRaid MacAddrPassThru reset_bios ThunderboltPreboot WirelessWwan AutoOnWed ExtPostTime MasterPasswordLockout SdCard TpmPpiClearOverride WlanAutoSense AutoOSRecoveryThreshold Fastboot MicMuteLed SdCardBoot TpmSecurity WwanAutoSense BIOSConnect FingerprintReader Microphone SdCardReadOnly TrustExecution BiosLogClear FnLock Nfc SecureBoot TurboMode BiosRcvrFrmHdd FnLockMode NonAdminPsidRevert SecureBootMode TypeCDockAudio BlockSleep ForceLpmAspmOff NumLock SHA256 TypeCDockLan BluetoothDevice FOTA PasswordBypass SignOfLifeByAudio TypeCDockOverride
Perry, thank you for testing this. I'll send a pull-req to Linus with the fixes soon. Once those have landed I'll add a comment that the fixes are now upstream to bug 1941416.
FEDORA-2021-e636ce53df has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-e636ce53df
kernel-5.11.9-200.fc33 contains the patches from Hans and solves the issue without the blacklist workaround, tested on a Dell Latitude E5570 and a Latitude 5480. A big thanks to everybody involved! As far as I am concerned this one can be closed.
FEDORA-2021-e636ce53df has been pushed to the Fedora 34 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-e636ce53df` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-e636ce53df See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2021-68b0dd2373 has been pushed to the Fedora 33 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-68b0dd2373` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-68b0dd2373 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2021-25441d8137 has been pushed to the Fedora 32 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-25441d8137` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-25441d8137 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
Hi all! My laptop Dell Vostro 1510 doesn't boot on kernel 5.11. kernel-5.11.9-200.fc33.x86_64 doesn't solve it. BIOS Information Vendor: Dell Inc. Version: A15 Release Date: 03/18/2009 Address: 0xE5080 Runtime Size: 110464 bytes ROM Size: 64 kB Regards.
FEDORA-2021-e636ce53df has been pushed to the Fedora 34 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2021-68b0dd2373 has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2021-9503fffad9 has been pushed to the Fedora 32 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-9503fffad9` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-9503fffad9 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2021-9503fffad9 has been pushed to the Fedora 32 stable repository. If problem still persists, please make note of it in this bug report.