Created attachment 6063 [details] cedar gfxcard cauldron hwinfo --gfxcard Halt without nomodeset occurs in less than 4 seconds from making Grub selection. Failure occurs using either VGA or DVI output. Last line on on tty1 at halt: [...] fb: conflicting fb hw usage radeondrmfb vs VESA VGA - removing generic driver CAD produces reboot. Replacing 3 with 5 on cmdline does not help. Rebuilding 3.14 initrd with dracut does not help. Normal boot restored by reverting gfxcard upgrade. No similar problem with Cauldron (3.19.1), Rawhide (4.0.rcx) or Tumbleweed (3.19.1).
Do you have radeon-firmware installed?
Assignee: bugsquad => tmb
(In reply to David Walser from comment #1) > Do you have radeon-firmware installed? mga4: lib64drm_radeon1, lib64llvmradeon9.1.6 & radeontool only Cauldron: lib64drm_radeon1, radeon-firmware-20150204 & radeontool installed Rawhide: no *radeon* installed Tumbleweed: libdrm(-32bit)-radeon1 only *radeon* installed Installing radeon-firmware triggered dracut to produce a 16% larger initrd (9,716,211), resulting in 3.14 working as expected without nomodeset on cmdline. Why does 3.14 depend on firmware that (original release) 3.12 kernels do not, in a package which is apparently not a dependency of any base package?
in 3.12 most radeon hw still works without nonfree firmware, but in 3.14 it expects to find nonfree rlc firmware to enable all/more features on newer gpus unless you use nomodeset And core kernel package cant require a nonfree package as we dont force nonfree stuff on anyone, not to mention adding requires on it would install it on systems where it's not needed
I just had the same boot problem, after just performing an upgrade from mga3 to mga4 on one of my systems. boot halts with "fb: conflicting fb hw usage radeondrmfb vs VESA VGA - removing generic driver". Only, it doesn't actually halt, it only halts the display. I can access the system fine through ssh. It was working in mga3. I do not have nonfree media enabled. So can I no longer use this system without installing the proprietary nonfree radeon-firmware package? My display card is a Radeon HD 4850.
CC: (none) => cooker
I have the same problem after upgrading frm mga4 to mga5.
Version: 4 => 5Whiteboard: (none) => MGA4TOO
there is now a 4.1.7 in testing,but you will still need radeon-firmware... if you dont need full hw acceleration you could try to configure the system to use the modesetting driver
(In reply to Thomas Backlund from comment #6) > if you dont need full hw acceleration you could try to configure the system > to use the modesetting driver How does one do that for multi-user.target? The only modesetting driver I'm aware of is only for X.
Keywords: (none) => NEEDINFO
Mass-reassigning all bugs with "kernel" in the summary that are still assigned to tmb (or wrongly assigned to someone with "tmb" in his e-mail address) to the kernel packagers group, but without adding "kernel" to the SRPM field. Please reassign if needed, or add kernel to the SRPM field if this is correct.
Assignee: tmb => kernel
(In reply to Felix Miata from comment #7) > (In reply to Thomas Backlund from comment #6) > > if you dont need full hw acceleration you could try to configure the system > > to use the modesetting driver > > How does one do that for multi-user.target? The only modesetting driver I'm > aware of is only for X. I'm sorry that no one saw your question, Felix, and that I don't know the answer. Anyway, did this bug get fixed? If so, please change its status to RESOLVED - FIXED If it didn't, then we regret that we weren't able to fix it in Mageia 5. Mageia 5 has officially reached its End of Life on December 31st, 2017 https://blog.mageia.org/en/2017/11/07/mageia-5-eol-postponed/ It only continued to get important security updates since then, because we are waiting for a big Plasma5 update in Mageia 6, that'll fix many of the Mageia 5 => 6 upgrade issues. If you haven't seen that this bug got fixed, then please check whether this bug still exists in Mageia 6. If it does, then please change the Version (near the top, at the left) to "6". If you know it exists in Cauldron, then change Version to Cauldron. If you see it in both Cauldron and Mageia 6, then please set Version to Cauldron and add MGA6TOO on the Whiteboard. Thanks, Marja
Whiteboard: MGA4TOO => (none)CC: (none) => marja11
Given the problem depended on a pre-3.19.x kernel, and MGA5 made it to kernel 4.4.114, it's pretty safe to assume the problem is long gone. I've just installed a PCIe Radeon HD6450 in a 32-bit Intel 865 GPU PC with MGA5 and TDE last updated 60 weeks ago. Boot time was quite long with mandriva-everytime.service taking 123 seconds and network-up.service taking 24 seconds, but it did finally reach an otherwise normal boot. Subsequently upgrading it to MGA6 via urpmi was uneventful.
Status: NEW => RESOLVEDResolution: (none) => FIXED