Description of problem: ASUS UX333FA freezes at boot just after selecting the line to boot and starting the system, leavinf a black square on the Grub background. This is linked to https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/issues/1 Version-Release number of selected component (if applicable): microcode-0.20190514-1.mga6.nonfree.noarch.rpm microcode-0.20190514-1.mga7.nonfree.noarch.rpm How reproducible: Always This seems specific to some recent Asus hardware. Steps to Reproduce: 1. Install Mageia 6.1 2. Reboot. It's fine 3. Update the system 4. Rebbot : the system halts after Grub step 1. Try to boot Mageia-7-rc-Live-Plasma 2. The system halts after Grub step Workaround: Add dis_ucode_lbr as kernel option.
Priority: Normal => release_blockerSeverity: normal => critical
(In reply to papoteur from comment #0) > Description of problem: > ASUS UX333FA freezes at boot just after selecting the line to boot and > starting the system, leavinf a black square on the Grub background. > This is linked to > https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/issues/1 > > Version-Release number of selected component (if applicable): > microcode-0.20190514-1.mga6.nonfree.noarch.rpm > microcode-0.20190514-1.mga7.nonfree.noarch.rpm > > How reproducible: > Always > This seems specific to some recent Asus hardware. > > Steps to Reproduce: > 1. Install Mageia 6.1 > 2. Reboot. It's fine > 3. Update the system > 4. Rebbot : the system halts after Grub step > > 1. Try to boot Mageia-7-rc-Live-Plasma > 2. The system halts after Grub step > > Workaround: > Add dis_ucode_lbr as kernel option. We can't fix released ISOs, so it would be nice if this could get fixed before Mga7 release
Assignee: bugsquad => kernelSummary: ASUS UX333FA freezes at boot => ASUS UX333FA freezes at boot (dis_ucode_lbr as kernel option fixes it)CC: (none) => isobuild, marja11
CC: (none) => j.biernacki
Sorry, workaround is dis_ucode_ldr Found the report for Ubuntu: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1829620
See Also: (none) => https://launchpad.net/bugs/1829620Summary: ASUS UX333FA freezes at boot (dis_ucode_lbr as kernel option fixes it) => ASUS UX333FA freezes at boot (dis_ucode_ldr as kernel option fixes it)
Yeah, we cant really fix something that apparently needs an bios / efi firmware update according to the threads... unless Intel guys find out how to work around it... I'd say best thing for now is to add it to errata
CC: (none) => tmb
instead of errata, is there a mean for the installer do adapt itself to the environment ? I mean, we know that for this hardware, things go wrong. Is it possible to add somewhere in the installer a kind of " if(getHardwareVersion() == BUGGY_INTEL_HARDWARE){ add_grub_option("dis_ucode_ldr");} " ?
(In reply to Jybz from comment #4) > instead of errata, is there a mean for the installer do adapt itself to the > environment ? IIUC, disabling the firmware loading will as a result disable many of the Spectre/Meltdown mitigations. I don't think that's something we should do automatically. The Ubuntu bug report indicates that there is now a BIOS update that fixes this.
CC: (none) => mageia
(In reply to Martin Whitaker from comment #5) > (In reply to Jybz from comment #4) > > instead of errata, is there a mean for the installer do adapt itself to the > > environment ? > > IIUC, disabling the firmware loading will as a result disable many of the > Spectre/Meltdown mitigations. I don't think that's something we should do > automatically. > Yes, but is there an easy way, for the installer, to detect the configuration (bios version + intel processor product) and in this case, install the previous microcode ? The previous microcode embed the vulnerabilities mitigation but doesn't freeze the system. > The Ubuntu bug report indicates that there is now a BIOS update that fixes this. > We have a mageian who confirm that a BIOS update fixed the up to date microcode package. https://www.mageialinux-online.org/forum/topic-26264-5+echec-d-installation-de-mageia-live-dvd-7-release-candidate-sur-asus-zenbook.php#m254053
Keywords: (none) => IN_ERRATA7
What to do with this report? There is no other action expected here. A Dell 7400 has been reported to have the same problem this days.
Target Milestone: --- => Mageia 8CC: (none) => ouaurelien
Hi, This is release_blocker for a reason. Making Mageia even better than ever is best direction. In order to do right thing, this bug should be examined and fixed as soon as possible. Packagers, please change the status to "Assigned" when you are working on this. We will make a decision on the relevance of the release_blocker tag on 1st October 2020 QA meeting.
Hello, On my side, this report can be closed. The only reason to keep it open is that if someone has the same problem, he can find the report. There is no action that will be taken on our side.
This seems need a BIOS update. Closing this and as it is already in errata 7 + (In reply to papoteur from comment #9) > Hello, > On my side, this report can be closed. > The only reason to keep it open is that if someone has the same problem, he > can find the report. There is no action that will be taken on our side.
Target Milestone: Mageia 8 => Mageia 7Priority: release_blocker => HighStatus: NEW => RESOLVEDResolution: (none) => WONTFIX