Pre-release testing identified a problem with LiveCD Gnome x86_64 tmb is aware, discussed on IRC, seems to think it will affect all LiveCDs. During live boot it attempts to switch to the nvidia driver from nouveau and asks to reboot. 'The system has to be rebooted due to a display driver change' After 30 seconds it reboots automatically and spits the CD out. Cancelling the reboot request fails to start X. You can switch to tty2 though and log in as root without a password. A workaround is to add xdriver=nouveau to kernel options at boot. Xorg.0.log http://pastebin.com/cyN1fNCR syslog errors.. gdm-binary[1253]: WARNING GdmDisplay: display lasted 0.473984 seconds gdm-binary[1253]: WARNING GdmLocalDisplayFactory: maximum number of X display first message is repeated a few times theres is a NVRM message too, several lines kernel: [number here] NVRM: The nvidia probe routine was not called for 1 device(s)
Anssi, is there a way to teach the "driver switch" to not trigger on livecds ? As there is point in rebooing a livecd...
CC: (none) => anssi.hannula
We need the "driver switch" on live cds, otherwise X won't be configured at all. However, that message is triggered when a conflicting driver has been loaded already. In this case, I guess somehow the nouveau is getting loaded before the X server configuration phase, which shouldn't happen. If so (dmesg needed to confirm I guess), this means that either the livecd initrd now loads nouveau (while it didn't previously load), or /sbin/display_driver_helper (which udev calls instead of modprobe for display drivers) wrongly loads nouveau when asked to. One possible suspect is the hacky "live cd" check in /sbin/display_driver_helper (which is used to differentiate between "X server without xorg.conf, KMS driver is needed" and "X server without xorg.conf, and livecd, so don't load anything yet as configuration will be done later": [ -e "/etc/X11/xorg.conf" ] || [ -e "/etc/sysconfig/harddrake2/kernels" ] || [ -e "/etc/sysconfig/harddrake2/xorg" ] || [ -e "/boot/grub/menu.lst" ] If none of those files exist, live cd is assumbed. There is a $DEBUG_DISPLAY_DRIVER_HELPER variable in /sbin/display_driver_helper that can be enabled so that the script produces a /dev/ddh_debug file that can be used to debug what happens during boot (hmm, maybe it could be made to trigger with a kernel parameter as well, would be easier...).
well, livecd dracut initrd is built with hostonly=no, so I guess kernel autoloading will pick it up. As for checking if we are running on a livecd, you could parse kernel command line for "mgalive" wich we use to trigger our custom dracut module for livecds
OK, so this is not caused by the check, then. It is just that livecd initrd contains the drivers now, so they are loaded automatically there. So we need to either a) drop those drivers from livecd initrds, or b) boot livecd with 'nokmsboot'.
Or c) add "-e mgalive" to this line in /lib/udev/rules.d/80-drivers.rules: SUBSYSTEM=="pci", ATTR{class}=="0x03*", DRIVER!="?*", PROGRAM=="/bin/grep -qFw -e nokmsboot -e failsafe /proc/cmdline", GOTO="drivers_end"
Created attachment 2024 [details] dmesg There were xorg logs up to Xorg.5.log if they are useful, I saved them and can attach them if needed.
I'm not sure I want to run livecds with "nokmsboot" as they are fully capable of running kms, since they include all needed firmwares, and also the prebuilt nonfree drivers... I wonder if option c is the best way. OTOH, I could build the initrd with hostonly=yes, and list the modules I really need to dracut. That would save space on livecds ...
CC: (none) => mageia
nokmsboot only disables loading KMS drivers in initrd, it doesn't do anything else. It doesn't disable KMS.
gah, I forgot about that... so that's another thing to test before rc
(In reply to comment #0) > Pre-release testing identified a problem with LiveCD Gnome x86_64 > > tmb is aware, discussed on IRC, seems to think it will affect all LiveCDs. > > During live boot it attempts to switch to the nvidia driver from nouveau and > asks to reboot. > > 'The system has to be rebooted due to a display driver change' > > After 30 seconds it reboots automatically and spits the CD out. Cancelling the > reboot request fails to start X. You can switch to tty2 though and log in as > root without a password. > > A workaround is to add xdriver=nouveau to kernel options at boot. > > NB when you use the workaround by adding this option (or any option) the second choice of the menu is automatically selected : "install" .... if you don't see this and push the "enter" button there may be some problems !!! This needs a new bug report !
CC: (none) => philippedidier
Thomas, dropping the KMS modules from initrd seems the best option (as they really are unneeded there AFAICS), but if it can't be easily done, I agree that just altering the udev rule might be best. Will you be working on that?
CC: (none) => mailinglistsduraph
Blocks: (none) => 5537
The workaround does not work on my hardware: an old GF2 MX/MX400 and the monitor's EDID is broken. It dropped back to a debug shell, complaining that it could not access tty. A real installation works with the VESA driver but not the nouveau driver.
CC: (none) => 0123peter
Peter, a better workaround is to boot with the "nokmsboot" parameter, that will allow the LiveCD to use the driver it wants to, instead of nouveau.
(In reply to comment #11) > Thomas, dropping the KMS modules from initrd seems the best option (as they > really are unneeded there AFAICS), but if it can't be easily done, I agree that > just altering the udev rule might be best. > > Will you be working on that? I probably can build the initrd with "hostonly=yes" and list the other modules that needs to be on it. That would save some space on the initrds. I assume adding nokmsboot on kernel command line would also work
Well, doesn't hostonly=yes determine the needed modules from the host system hw, which would cause the included modules to differ depending on where the livecd was build?
Yep, wich is why we defaulted to hostonly=no. Problem with that is that it grew the initrd from 7M to 20M wich is a lot on a livecd. So if I switch to hostonly=yes, it would create smaller initrd, but I will have to use dracut configs to add needed modules and blacklist those that comes from the build server to try and sort it out.
What about using hostonly=no and then blacklisting what isn't wanted? That way the buildhost wouldn't affect the build.
Yep, that should work too. Do I still need to add nokmsboot to the kernel command line then ?
As for using "hostonly=yes", the idea is to save space :)
(In reply to comment #18) > Do I still need to add nokmsboot to the kernel command line then ? Nope, nokmsboot just disables loading KMS in initramfs. If there are no KMS modules there, nothing gets loaded anyway.
just as a reminder dracut manual says: -H, --hostonly Host-Only mode: Install only what is needed for booting the local hostinstead of a generic host. Warning If chrooted to another root other than the real root device, use "--fstab" and provide a valid /etc/fstab.
CC: (none) => anaselli
Yes I know, but you can after that specify a list of modules to add with -a on dracut command line or with "add_drivers+=" <kernel modules> " in dracut.conf
yes in livecd-tools, i added /etc/dracut.conf.d/99livecd.conf with filesystems+=... drivers+=... add_dracutmodules+=... hostonly=no I cannot help more on what is in and what is not, since i haven't worked on it and left it untouched for a long time, i'd expect a lot of work there yet :)
There are a confusion of bugs. When I use a live CD bug number 5518 bites. After installation from a DVD booting from the hard disk the VESA driver works, but the nouveau driver fails. That does not belong in this bug report. Sorry for the confusion.
Priority: Normal => release_blocker
Closing after RC tests. Feel free to reopen if needed
Status: NEW => RESOLVEDCC: (none) => ennael1Resolution: (none) => FIXED
reopen seems still valid, works with: acpi=off noacpi xmodule=nv the card : Card:NVIDIA GeForce 6100 to GeForce 360: nVidia Corporation|G86 [GeForce 8600M GS] [DISPLAY_VGA] (vendor:10de device:0425 subv:1631 subd:c105) (rev: a1) (from the coming duplicate) looks like the ati one: https://bugs.mageia.org/show_bug.cgi?id=5426#c45
Status: RESOLVED => REOPENEDResolution: FIXED => (none)
*** Bug 5825 has been marked as a duplicate of this bug. ***
CC: (none) => chvan
Summary: Beta 3 LiveCDs (Probably all) fail to boot with nvidia GPU => LiveCDs (Probably all) fail to boot with nvidia GPU
Is Bug 5825 truly a simple duplicate ? there seems to be an acpi problem... besides the GPU problem Live RC KDE works out of the box for me : graphic card GT200 (GeForce 210) without adding any kernel option Identifiant du fabricant: â10de Identifiant du périphérique: â0a65 Identifiant secondaire du fabricant: â1043 Identifiant secondaire du périphérique: â8353
(In reply to comment #28) > Is Bug 5825 truly a simple duplicate ? > there seems to be an acpi problem... besides the GPU problem Indeed sorry,I will close again, thanks and sorry
Status: REOPENED => RESOLVEDResolution: (none) => FIXED
*** Bug 6128 has been marked as a duplicate of this bug. ***
CC: (none) => garaud