Description of problem: Detected a loaded display driver kernel module which conflicts with the driver that X server is configured to use. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Set runlevel 3, remove splash quite from boot line 2. install all updates except the following: fglrx-kernel-3.8.0-desktop-0.rc5.1.mga3-9.012-2.mga3.nonfree.x86_64.rpm fglrx-kernel-desktop-latest-9.012-2.mga3.nonfree.x86_64.rpm kernel-desktop-3.8.0-0.rc5.1.mga3-1-1.mga3.x86_64.rpm kernel-desktop-devel-3.8.0-0.rc5.1.mga3-1-1.mga3.x86_64.rpm kernel-desktop-devel-latest-3.8.0-0.rc5.1.mga3.x86_64.rpm kernel-desktop-latest-3.8.0-0.rc5.1.mga3.x86_64.rpm kernel-userspace-headers-3.8.0-0.rc5.1.mga3.x86_64.rpm 2. Reboot and verify everything works. 3. install the above and reboot. 4. note about half way through services you get the Description text.
Just did another clean install. Installed all updates which picked up the xorg* and did not install any kernel packages. Working pretty good. Changed my nic boot order, did a dracut -f rebooted, and get the error. XFdrake will not fix the problem. Off to do my 8th reinstall. :(
Sorry, that xorg* should have been X11-server*. Seems if I install either X11-server* or kernel*, and run a dracut -f creates the problem and I can not get a startx to give me a KDE desktop.
Assignee: bugsquad => thierry.vignaudSource RPM: (none) => drakx-kbd-mouse-x11
(In reply to comment #2) > Sorry, that xorg* should have been X11-server*. > Seems if I install either X11-server* or kernel*, and run a dracut -f > creates the problem and I can not get a startx to give me a KDE desktop. I suppose systemctl start prefdm.service doesn't work either?
CC: (none) => marja11
(In reply to comment #3) > I suppose > systemctl start prefdm.service > doesn't work either? Did not check. No idea if prefdm.service is started in a default runlevel 3 setup. Everything works until I install either X11-server* and do a dracut -f or just install kernel* with xorg-vesa only or just install kernel* with fglrx*
(In reply to comment #4) > (In reply to comment #3) > > > I suppose > > systemctl start prefdm.service > > doesn't work either? > > Did not check. No idea if prefdm.service is started in a default runlevel 3 > setup. > I don't know, only that after doing "init 3" in safe mode, starting prefdm.service does start KDM and then KDE fine in two 3beta2 installs, of which the one /can/ get a hard freeze before reaching KDM and the other one does /always/ freeze. Probably different issues, though, neither one gives your error message.
Whiteboard: (none) => 3beta2
s/freeze./freeze when booting into rl 5./
(In reply to comment #2) As a guess I would have thought this is a dracut problem instead of drakx-kbd... > Seems if I install either X11-server* or kernel*, and run a dracut -f > creates the problem and I can not get a startx to give me a KDE desktop. FYI: system is setup to use labeled partitions. $ head -1 /etc/fstab LABEL=cauldron / ext4 acl,relatime 1 1 $ blkid | grep cauldron /dev/sda6: LABEL="cauldron" UUID="35f73-8aa8-18680267dda6" TYPE="ext4" # grep cauldron /boot/grub/menu.lst | head -1 kernel (hd0,5)/boot/vmlinuz BOOT_IMAGE=mga3_64_beta1 root=LABEL=cauldron nokmsboot vga=794
Same problem here with 3.8 kernels, no problem with 3.7.1-desktop-1.mga3. My system is a mageia3 beta1 64 bits with updates. X11 1.13.2
CC: (none) => philippe.flat
Sorry , I forgot to give the video driver in use: Card:ATI Radeon HD 6400 and later (radeon/fglrx)
The problem seems to be with mkinitrd. In installed Mageia 3b1, 3.8.0-desktop-0.rc4.1.mga3 kernel. All ok. An update to that installed the rc5.1 kernel. Upon boot to run level 3, it would display maybe 30 lines of output (more or less - my guess) and then the monitor would show <OUT OF RANGE> error message. The rc4.1 kernel continued to work. I installed 3b2 into a different partition a few days ago. the rc4.1 kernel worked. Then, today, an update installed the rc5.1 kernel. Same problem upon reboot, <OUT OF RANGE>. I decided to try rebuilding the initrd for rc.5, but bungled the copy/paste. I rebuilt the initrd for rc4.1. I then went ahead and rebuilt the initrd for 5.1. Both now fail to boot in the same manner. I note that disk activity after the <OUT OF RANGE> message suggests boot is continuing, but I cannot get a monitor display so I am dead in the water. System AMD dual-core Athlon 7450, video card Radeon HD3200. xorg.conf is set for vesa, but since the machine does not get far in rebooting I do not think this would be the problem anyway. On 3b1, fglrx was installed in the kernel, but never worked. I resumed using the vesa driver. On 3b2, I never bothered to install the fglrx driver. I note that both 3b1 and 3b2 have updated to a new version of dracut, but cannot tell you when that happened for 3b1. For 3b2, it was in todays update. Any suggestions? I can still boot to the 3b1 rc4.1 kernel, and have tried rebuilding the rc5.1 initrd, which continues to fail in the same manner. I also did a bind to the subdirectories of 3b2 for /proc, /sys/ and /dev and did a chroot to the 3b2 partition and rebuilt those initrd.img yet again. Same story.
CC: (none) => jdbeard
The description matches my bug 8863. I did search before starting mine, but missed it. My bug should be marked a duplicate of this bug. Bit Twister, you will see a comment by me there that you didn't mention having the problem, because you had a Radeon card. I was wrong. you should be able to detect that the nouveau driver is loaded, and is causing the conflict.
CC: (none) => laidlaws
To my little mind: (a) No, dracut isn't the problem; (b) The problem is right across the distros. Is it really an upstream issue?
(In reply to comment #11) > Bit Twister, you will see a comment by me there that you didn't mention having > the problem, because you had a Radeon card. I was wrong. you should be able > to detect that the nouveau driver is loaded, and is causing the conflict. Tell me how to detect that the nouveau driver is loaded and I will check. I did a clean install with xorg->vesa and still had the problem so I have no idea where X server driver would be nouveau wb2 has Caicos HDMI Audio [Radeon HD 6400 Series] wb has RS880 [Radeon HD 4200] GPU R700
On my system, even with xorg.conf showing nvidia, lsmod showed that the nouveau kernel was loaded, and I couldn't unload it, because it was in use. Because it was loaded, the wanted module would not load. Putting nouveau into xorg.conf made everything happy, but that isn't an option for you. There are a couple of workarounds listed on my bug 8863. wobo has been on that one. They really need to be consolidated. One workaround was to boot into runlevel 3 then run startx. I thought that you made a practice of that, anyway.
(In reply to comment #14) > One workaround was to boot into runlevel 3 then run > startx. I thought that you made a practice of that, anyway. Yep, that is default setup. My current workaround is to not install the kernel* and X11-server* files. To continue testing, easy solution is exclude them in the skip.list file. cat /etc/urpmi/skip.list # Here you can specify the packages that won't be upgraded automatically # for example, to exclude all apache packages : # /^apache/ /^kernel/ /^fglrx/ /^X11-server/ #************* end /etc/urpmi/skip.list ****************
(In reply to comment #15) Ooops, that should be /^x11-server/ not /^X11-server/ New/improved. $ cat /etc/urpmi/skip.list # Here you can specify the packages that won't be upgraded automatically # for example, to exclude all apache packages : # /^apache/ /^kernel/ /^fglrx/ /^x11-server/ #************* end /etc/urpmi/skip.list ****************
My problem in booting identified. I let the machine boot to completion and accessed it from another machine. grep radeon /var/log/dmesg shows: [ 2.274719] [drm] radeon defaulting to kernel modesetting. [ 2.333025] [drm] radeon kernel modesetting enabled. [ 2.352457] fb: conflicting fb hw usage radeondrmfb vs VESA VGA - removing generic driver [ 2.373075] radeon 0000:01:05.0: VRAM: 256M 0x00000000C0000000 - 0x00000000CFFFFFFF (256M used) [ 2.373080] radeon 0000:01:05.0: GTT: 512M 0x00000000A0000000 - 0x00000000BFFFFFFF [ 2.374298] [drm] radeon: 256M of VRAM memory ready [ 2.374301] [drm] radeon: 512M of GTT memory ready. [ 2.374364] [drm] radeon: irq initialized. [ 2.403490] radeon 0000:01:05.0: WB enabled [ 2.403495] radeon 0000:01:05.0: fence driver on ring 0 use gpu addr 0x00000000a0000c00 and cpu addr 0xffff880193652c00 [ 2.403501] radeon 0000:01:05.0: fence driver on ring 3 use gpu addr 0x00000000a0000c0c and cpu addr 0xffff880193652c0c [ 2.403762] radeon 0000:01:05.0: setting latency timer to 64 [ 2.436156] [drm] radeon: power management initialized [ 2.492684] fbcon: radeondrmfb (fb0) is primary device [ 2.509002] radeon 0000:01:05.0: fb0: radeondrmfb frame buffer device [ 2.509096] radeon 0000:01:05.0: registered panic notifier [ 2.509182] [drm] Initialized radeon 2.28.0 20080528 for 0000:01:05.0 on minor 0 The radeon will not work with the machine, and in fact is not installed on it. How do I create an initrd that will avoid this drm conflict?
Perhaps I should specify that "the radeon" is specifically the ati (open source) and fglrx (proprietary) drivers. Currently, neither will work with my old Radeon 3200HD card. In the case of my Beta 1 install, I tried both the ati and fglrx drivers. They failed to work, but are on the system. In the case of the Beta 2 install, I chose the vesa driver during the install, and neither the ati nor the fglrx driver is on the system. Thus, when there is a conflict between vesa and drm (radeondrmfb) and vesa is removed, I have no functional driver on the system. If vesa and drm do not play nicely together, this could be a Linux problem of widespread nature.
Sounds as though the problem with Radeons is different from the problem with nVidias (my bug 8863.) In my case, the nouveau driver is "grabbed" by the kernel and blocks any driver specified in xorg.conf. I thought it might be "grabbed" even when the card was a Radeon. BitTwister's result suggests not. But really, the diagnostics are for more knowledgeable people than me.
Workaround: In /etc/dracut.conf.d/50* add omit_dracutmodules+=" drm " I also added DRACUT_SKIP_FORCED_NON_HOSTONLY=1 hostonly="yes" and put a # in front of omit_dracutmodules+=" network I then used dracut --force --fstab initrd-3.8.0-desktop-0.rc4.1.mga3.img 3.8.0-desktop-0.rc4.1.mga3 and in consequence got an initrd that boots and is only appx 60MB in size. I have not tried this for rc5.1 (got an errand to run) but think that too will work.
I'm having the same issues with two desktops and a laptop. From here, appears to be the same as Doug's nvidia bug 8863 - radeon (or nouveau) driver is loaded and dm service cannot load the proprietary fglrx (or nvidia) driver; all this on the 3.8.0-desktop586-0.rc5.1.mga3 kernel (rc.4 works fine). Prior to starting dm, the loaded modules of interest are: [root@DaddysLappy ~]# lsmod|grep radeon radeon 870247 3 i2c_algo_bit 13197 1 radeon drm_kms_helper 43161 1 radeon ttm 71480 1 radeon drm 227906 5 ttm,drm_kms_helper,radeon i2c_core 30189 6 drm,i2c_piix4,drm_kms_helper,i2c_algo_bit,radeon,videodev [root@TimmysPC ~]# lsmod|grep nouv nouveau 861886 1 button 13599 1 nouveau video 18690 1 nouveau mxm_wmi 12893 1 nouveau wmi 18590 2 mxm_wmi,nouveau i2c_algo_bit 13197 1 nouveau drm_kms_helper 43161 1 nouveau ttm 71480 1 nouveau drm 227906 3 ttm,drm_kms_helper,nouveau i2c_core 30189 5 drm,i2c_piix4,drm_kms_helper,i2c_algo_bit,nouveau This, despite choosing the proprietary display driver (in XFdrake) in all cases. Laptop is running 32-bit kernel with Radeon HD 6250, Desktop 1 is 64-bit with Radeon HD 6550D, Desktop 2 32-bit with a GeForce GT 220. For what it's worth, all systems boot into a proper graphical desktop with the rc5 kernel and the open source driver.
(In reply to comment #21) > Workaround: > > In /etc/dracut.conf.d/50* > add > > omit_dracutmodules+=" drm " > > I have not tried this for rc5.1 (got an errand to run) but think that too will > work. I will confirm the omit drm will work on a 64 bit 3.8.0-desktop-0.rc5.1.mga3 for both wb2 has Caicos HDMI Audio [Radeon HD 6400 Series] wb has RS880 [Radeon HD 4200] GPU R700 flrgx drivers or a xorg->vesa setup. My solution: $ cat /etc/dracut.conf.d/80-my_dm.conf # /etc/dracut.conf.d/80-my_dm.conf # patch to fix https://bugs.mageia.org/show_bug.cgi?id=8852 # # fix is for runlevel3. no clue as to a runlevel5 setup # omit_dracutmodules+=" drm " #*********************** end /etc/dracut.conf.d/80-my_dm.conf ***********
CC: (none) => inster.css
@Bit Twister i don't understand, i have Ati Radeon HD 5870 i try your solution : [root@Aranud aranud]# cat /etc/dracut.conf.d/80-my_dm.conf cat: /etc/dracut.conf.d/80-my_dm.conf: Aucun fichier ou dossier de ce type thank you
(In reply to comment #24) > i try your solution : > [root@Aranud aranud]# cat /etc/dracut.conf.d/80-my_dm.conf > cat: /etc/dracut.conf.d/80-my_dm.conf: Aucun fichier ou dossier de ce type Going to assume "Aucun fichier ou dossier de ce type" means No such file or directory What you need to do is create /etc/dracut.conf.d/80-my_dm.conf with the same contents I showed in my solution.
So in root : Kwrite /etc/dracut.conf.d/80-my_dm.conf I put : # /etc/dracut.conf.d/80-my_dm.conf # patch to fix https://bugs.mageia.org/show_bug.cgi?id=8852 # # fix is for runlevel3. no clue as to a runlevel5 setup # omit_dracutmodules+=" drm " #*********************** end /etc/dracut.conf.d/80-my_dm.conf *********** Save and reboot, I have still conflict :( Thank you
okay Jim Beard help me, is now fixed for me :) thank you everybody
Priority: Normal => release_blockerCC: (none) => mageia, tmb
I have now successfully applied Jim's fix to the nVidia situation (bug 8863.)
In view of the comments about runlevel, I should add that I can now boot into runlevel 5 as normal. But a 60MB initrd? Mine has reduced from 6.3M to 4.5M.
That should read 6 MB initrd. My earlier attempts to create an initrd resulted in sizes of 19-25 MB, and expecting an initrd of that size I misread the size of the initrds created later. E.g., -rw------- 1 root root 19256041 Jan 29 13:20 mkinitrd_initrd-3.8.0-desktop-0.rc4.1.mga3.img -rw------- 1 root root 6012020 Jan 30 19:22 /boot/initrd-3.8.0-desktop-0.rc4.1.mga3.img The top initrd was created with mkinitrd, and included all drivers and modules available. That can get quite large when you have multiple Far Eastern languages on the machine. The latter was created with dracut, with options set to include only modules needed for the specific machine.
I thought that it had to be a mistake :) This bug seems to have attracted the "heavyweights," who seem to be inclined to use Radeon cards. The nVidia bug 8863, by contrast, seems to have a few beginners. For that reason, I have there set out in detail the steps I took and have made my 50-mageia.conf an attachment there. It is just as useful for Radeon users.
(In reply to comment #30) > That should read 6 MB initrd. My earlier attempts to create an initrd resulted > in sizes of 19-25 MB, and expecting an initrd of that size I misread the size > of the initrds created later. E.g., > > -rw------- 1 root root 19256041 Jan 29 13:20 > mkinitrd_initrd-3.8.0-desktop-0.rc4.1.mga3.img > > -rw------- 1 root root 6012020 Jan 30 19:22 > /boot/initrd-3.8.0-desktop-0.rc4.1.mga3.img > > The top initrd was created with mkinitrd mkinitrd is just a wrapper around dracut these days. So it'll be the same code generating it even if you type a different command. > and included all drivers and modules available. This means it's a non-hostonly initrd. There are basically two modes of initrd generation 1) A host-specific initrd tailored to only include the drivers for the specific machine. and 2) a generic initrd that should be able to boot most systems, regardless of their setup/configuration. So both initrds are from dracut, but just generated under different circumstances. By default we will generate a host-only initrd, but under some circumstances we will not. Typically when we do not, it's when you've booted into a rescue system and chrooted in but forgot to bind mount the /run directory such that the udev database is available for querying. We specifically check that /run/initramfs is a folder (it's created by dracut when booting and we require a "dracut boot" to generate a host-only initrd as we need to know that udev was started early in the initrd to ensure all metadata regarding LVM and raids etc. needed to mount / is available in the udev db. dracut should print out a warning when generating a non-hostonly initrd: WARNING: Activating non-hostonly initrd due to distro upgrade. Your initrd will be larger than needed for compatibility. You can disable this by setting DRACUT_SKIP_FORCED_NON_HOSTONLY=1 Anyway, that's why they are different sizes. Hope that clarifies things.
Thanks for the above. Failure to bind mount /run seems to be the main reason I came up with a large initrd with dracut. But while dracut seems to be the only choice available for Mageia, Mandriva is still providing the old mkinitrd, with name mkinitrd-mkinitrd. I mounted the partition that contained that, and built an initrd with it. It must have worked, as I kept the thing around (would have deleted one that did not work at all). I was in sort-of random experiment mode, and did not test it to any great degree. Later experiments with dracut work better, and I did nothing more with the output of mkinitrd-mkinitrd.
mkinitrd will not work going forward. We need to start udev early such that all metadata relating to disks etc is available in the udev database to get a complete picture of the hardware and configuration of the machine. As mkinitrd does not start udev but DOES e.g. initialise raid and LVM volumes (if needed for /) critical information about these devices is lost which is needed by modern userspace to provide a proper hotplug friendly, device driven async boot. Add to this that mkinitrd will not mount /usr and you've got a whole bunch of supported layouts that mkinitrd will simply not cope with. So please don't use it. Dracut is our only supported initrd generator from mga3 onwards.
Same problems. The x86_64 3.8.0-desktop-0.rc4.1.mga3 continues to work fine. Any kernel after that does not. I'm using the the fglrx 6400 and later driver. I get the same loaded driver conflict message in the boot process or a blank screen.
CC: (none) => bcm.alaska
Latest updates and kernel did not fix the problem. The older 3.8.0-desktop-0.rc4.1 continues to work fine however.
I don't know whether this is related or not. I run nVidia and started bug 8863. After yesterday, I can get a desktop and a terminal; I can type into the terminal, but after I hit <Enter>, nothing further happens.
yeah, the display_driver_helper is currently not able to do the unloading / reloading of modules properly anymore so it needs fixing. It might also be some udev changes that we have missed... I haven't yet had time to debug it, but I now atleast have a system that I can reproduce it on, so I'll see what shows up the blacklisting of dracut drm module is a workaround, as the stuff in drm module in dracut 025, was in plymouth module in dracut 023
(In reply to comment #36) > Latest updates and kernel did not fix the problem. The older > 3.8.0-desktop-0.rc4.1 continues to work fine however. Can you attach an lsintrd output of that working initrd, and of a nonworking initrd from 3.8.0-desktop-1.mga3 so I can compare the results with my findings
Created attachment 3527 [details] working kernel lsinitrd
I'm getting the "file too large" error on the non-working initrd. I put it on Google drive. here is the link: https://docs.google.com/file/d/0BzcC-G0iWyB4QmNrNTFXbDFrU1E/edit?usp=sharing
Created attachment 3534 [details] diff on lsinitrds for working 3.8.0-rc7.1 kernel, non-working 3.8.0-1 kernel lsinitrd was run against initrds for a working rc.7 kernel and for the new non-working 3.8.0-1 kernel, and the outputs saved. Date and time were deleted from each line of each to allow diff to work. diff was then run against the two, and the output is the attachment. The radeon stuff for rc7.1 is irrelevent. I tried using fglrx with the kernel but it did not work (and will not -- my Radeon is HD3200 and nothing before HD5000 is supported by current drivers). In theory, the two lsinitrd runs could have output two files with the same file name and byte count but different contents. diff would not have recognized them as different. The initrd for 7.1 contains the drm module (libdrm.so). Omitting the drm module was a work-around for earlier kernels but was not required for this one.
I don't really grok all the drm stuff (I only really have intel machines), but I noticed there is an upstream commit that makes the drm module only load on dependency. Might help to exclude it without so much magic? It's not in our pkg yet. commit 8a3c4957fc90a6cd9415e57592ef0771bb5e8524 Author: Harald Hoyer <harald@redhat.com> Date: Fri Feb 8 14:12:59 2013 +0100 drm/module-setup.sh: make drm module only install on dependency diff --git a/modules.d/50drm/module-setup.sh b/modules.d/50drm/module-setup.sh index 47fe9a6..e471c11 100644 --- a/modules.d/50drm/module-setup.sh +++ b/modules.d/50drm/module-setup.sh @@ -3,7 +3,7 @@ # ex: ts=8 sw=4 sts=4 et filetype=sh check() { - return 0 + return 255 } depends() {
If I am not contributing much, it is because I don't have the knowledge. But anything that cures this bug will fix Bug 8863, so I am watching it with great interest.
Is it me or was the module correctly loading at the time of 3b2 which came with 3.8rc4 kernel? It seems to have broken with rc5? What changed between releases?
CC: (none) => philippe.l
I seem to be back at the beginning with kernel 3.8.0-server-2.mga3. I can boot into the nouveau driver. With the nvidia driver set, I couldn't get a complete bootup. After applying Jim's fix as before, I get the message boox that the nouveau driver is conflicting with the selected nvidia driver, so that fix is no longer sufficient. Something has changed.
bug is found and fixed in dracut-025-5.mga3 so just install that, and regenerate initrd and it should just work again
I rebuilt the rc5 and rc7 kernel initrd's, including the drm module which I had earlier omitted as a workaround. Both work fine. ATI HD3200 Radeon card. Using the vesa driver, as the new fglrx supports nothing earlier than HD5000. The initrd,s are a megabyte or two larger due to inclusion of the drm module and modules dependent on it.
(In reply to Thomas Backlund from comment #47) > bug is found and fixed in dracut-025-5.mga3 > > so just install that, and regenerate initrd and it should just work again Install all updates which picked up dracut-025-5.mga3. Removed the omit_dracutmodules+=" drm " statement. did a dracut -f and rebooted all three systems with video cards mtv: ATI RS780L [Radeon HD 3000] tb: ATI Caicos [Radeon HD 6400M/7400M Series] wb: ATI Cedar PRO [Radeon HD 5450/6350] and the problem no longer shows up.
Booted into 4.1, and ran urpmi --auto-update, then rebooted into the latest kernel and all works just fine using the 6400 and later fglrx driver.
You lucky b----s. Still no luck with nvidia.
I got my nvidia working too. Tho' i got hit by the bug in drakxtools that stops X from starting by default. After i figured that out everything worked just fine..
CC: (none) => sander.lepik
The new dracut + a dracut -f solves the problem for my Radeon. Thanks
Bug resolved for everyone it seems, closing then. Thanks everyone.
Status: NEW => RESOLVEDResolution: (none) => FIXEDSource RPM: drakx-kbd-mouse-x11 => dracut
Fixed for nvidia as well. Bug 8863 is already marked as fixed.