Description of problem: after a fresh install of mageia 8 rc1 as of 26th Jan 2021 no ums support in radeon module during bootup followed by failed to start load legacy module configuration starting net profile checking for new hardware white text based mouse cursor in middle of screen and it, without intervention Version-Release number of selected component (if applicable): ati driver to support radeon hd2400 How reproducible: Steps to Reproduce: simply install mageia with plasma from x86_64 classical installer no special changes or configuration, just the usual install. to fix , edit kernel command line during pre plymouth pat and remove nokmsboot once system is up and running edit /etc/grub2.conf and remove nokmsboot from current or all kernel command lines, and grub2-mkconfig ensure that after reboot kernel command line has it removed. from then on the ati driver for that card works. while this is a minor inconvinience to anyone who can work out how to fix this, it could leave some users high and dry, so i leave it to your judgement how critical this should be. its also old hardware, BUT theres a lot of old hardware around on linux.
Created attachment 12268 [details] install log added install log as requested
CC: (none) => peter.winterflood
Created attachment 12269 [details] added Xorg.log.0 ive added this file, as when I init 2'ed the box to see what error may be in background with startx, it failed to start then as well. and this shows that it does scan for the hd2400, but does not like what it finds
Created attachment 12270 [details] journalctl as requested added journalctl as requested one last point to make, because i think its importand for splitting the root cause out. prior to rebuilding with mga8 rc2 26/1/21 this box was running mga8 beta 2 with all updates and updates testing to the 22end Jan without this problem. and while fixing another problem, as a process of elimination I had also installed KDE Neon 20.5 and that also did not have the issue, kde wise kde neon is just ahead of mageia on some kde stuff.
Many thanks Peter for this bug report. I already asked our devs for that. Can you go to bug 28154 for this. And put here output of "lspcidrake -v" I will sum up here. Best regards, *** This bug has been marked as a duplicate of bug 28154 ***
Status: NEW => RESOLVEDSource RPM: none that im aware of => (none)Resolution: (none) => DUPLICATECC: (none) => ouaurelien
I'm not yet certain this is a duplicate, although it may be fallout from changes Thomas has made to try and fix that bug. Peter, could you attach the output from running (as root) sh -x display_driver_helper --is-kms-allowed
CC: (none) => mageia
Created attachment 12273 [details] as requested as requested
in the journalctl output there was a Jan 24 18:26:13 localhost systemd-udevd[548]: 0000:03:00.0: Process '/sbin/display_driver_helper --load pci:v00001002d000094C3sv0000174Bsd0000E370bc03sc00i00' failed with exit code 1. ignore the date on that box its wrong Sun 24 Jan 23:19:55 GMT 2021
From his message to the dev ML, I think Thomas has found and fixed the problem: On 27/01/2021 15:45, Thomas Backlund (via dev Mailing List) wrote: > With: > > drakx-kbd-mouse-x11-1.32-2.mga8 > ldetect-lst-0.6.24-2.mga8 > > it should all get back to normal...
confirmed that this bug, as filled, whether a duplicate or not has been fixed with the 29/01/2020 classic x86_64 on the same hardware it appeared on regards peter