Description of problem: Tried installing the latest version of Cauldron from the net boot iso. nvidia graphics were recognized and the proprietary driver was offered - accepted. Rebooted and it blocked at EDAC skx: ECC is disabled on imc 0 hid-generic 0003:0B05:180D.0001: No inputs registered, leaving. And there it hangs. Ctlr-Alt-F2 works and login is available. No sign in the journal that the nvidia GTX 1080Ti card had even been detected. Xorg.0.log confirms that no video device has been detected. The HDMI interface is being used and that presents no problem in Mageia 6. Switching to vesa or nouveau ends up in the same place - no graphics. Tried nomodeset - nothing doing. Other messages indicate that the login session has been started. Trying 'startx -bpp 24' fails. No idea where to go from here. I would say that this is specific to this model nvidia graphics card because Cauldron works on other workstations with earlier models, like the GTX 970. Version-Release number of selected component (if applicable): How reproducible: On every attempted bootup. Steps to Reproduce: 1. Install Cauldron from USB device containing net-boot nonfree iso 2. Before rebooting confirm that proprietary nvidia driver is to be used 3. Observe that no graphics device is detected 4. Try drakx11 from console to reinstall the nvdia driver 5. Observe the same failure on reboot 6. Console - drakx11 - install nouveau or vesa driver and reboot 7. Observe same failure.
If it works in Mga6 and not in Cauldron then there is definately a bug, as we have the same nvidia-current driver in both... Can you attach the /root/drakx/report.bug.xz and journal from a bootup of the installed system so we can see what the system is detecting/doing...
CC: (none) => tmb
Created attachment 10350 [details] Report from net install of Cauldron
Attached. All the logs from that installation are available.
(In reply to Len Lawrence from comment #3) > Attached. > > All the logs from that installation are available. @ tmb Do you still need the boot journal you also asked for, or is report.bug.xz enough? There are those lines in the "configureX" step: * kernel-desktop-devel-latest not installed, Too many levels of recursion in macro expansion. It is likely caused by recursive macro declaration. * kernel-desktop-devel-4.18.5-3.mga7 not installed, Too many levels of recursion in macro expansion. It is likely caused by recursive macro declaration. * dkms-minimal not installed, Too many levels of recursion in macro expansion. It is likely caused by recursive macro declaration. * dkms not installed, Too many levels of recursion in macro expansion. It is likely caused by recursive macro declaration. * dkms-nvidia-current not installed, Too many levels of recursion in macro expansion. It is likely caused by recursive macro declaration. * nvidia-current-doc-html not installed, Too many levels of recursion in macro expansion. It is likely caused by recursive macro declaration. * x11-driver-video-nvidia-current not installed, Too many levels of recursion in macro expansion. It is likely caused by recursive macro declaration.
Assignee: bugsquad => kernelCC: (none) => mageiatools, marja11
Ok, this is weird... @tv, is this only a logging bug or do we have bigger issues / bufs...: duplicated package names: starting installing packages created transaction for installing on /mnt (remove=0, install=0, upgrade=1) radeon-firmware-20180710-1.mga7.nonfree.noarch radeon-firmware-20180710-1.mga7.nonfree.noarch removing installed rpms (radeon-firmware-20180710-1.mga7.nonfree.noarch.rpm) from /mnt/var/cache/urpmi/rpms [...] created transaction for installing on /mnt (remove=0, install=0, upgrade=7) kernel-desktop-devel-latest-4.18.5-3.mga7.x86_64 kernel-desktop-devel-4.18.5-3.mga7-1-1.mga7.x86_64 dkms-minimal-2.0.19-39.mga6.noarch dkms-2.0.19-39.mga6.noarch dkms-nvidia-current-390.87-1.mga7.nonfree.x86_64 nvidia-current-doc-html-390.87-1.mga7.nonfree.x86_64 x11-driver-video-nvidia-current-390.87-1.mga7.nonfree.x86_64 kernel-desktop-devel-latest-4.18.5-3.mga7.x86_64 kernel-desktop-devel-4.18.5-3.mga7-1-1.mga7.x86_64 dkms-minimal-2.0.19-39.mga6.noarch dkms-2.0.19-39.mga6.noarch dkms-nvidia-current-390.87-1.mga7.nonfree.x86_64 nvidia-current-doc-html-390.87-1.mga7.nonfree.x86_64 x11-driver-video-nvidia-current-390.87-1.mga7.nonfree.x86_64 removing installed rpms (dkms-nvidia-current-390.87-1.mga7.nonfree.x86_64.rpm kernel-desktop-devel-4.18.5-3.mga7-1-1.mga7.x86_64.rpm nvidia-current-doc-html-390.87-1.mga7.nonfree.x86_64.rpm x11-driver-video-nvidia-current-390.87-1.mga7.nonfree.x86_64.rpm dkms-2.0.19-39.mga6.noarch.rpm dkms-minimal-2.0.19-39.mga6.noarch.rpm kernel-desktop-devel-latest-4.18.5-3.mga7.x86_64.rpm) from /mnt/var/cache/urpmi/rpms
CC: (none) => thierry.vignaud
Sorry, I did not notice the extra request. Shall attach it just in case.
Created attachment 10351 [details] Latest boot journal for Cauldron
When I have time I shall try a netinstall of mga7 on other hardware.
Just checked the MD5sum - that is OK. Tried the netinstall on a machine which already had a working Cauldron partition (upgrade probably) and it hung on reboot. No nvidia module loaded. Tried reinstalling nvidia for the GTX 970 with DisplayPort connection but could launch X. Installed nouveau and it still hung on the reboot but the nouveau module was loaded. The logs are preserved but shall hold off attaching them and try the netinstall on another machine.
Ok, whats the output of the commands: rpm -qa kernel* rpm -qa |grep nvidia dkms status
@tmb, re comment #10 $ rpm -qa kernel* kernel-doc-4.18.5-3.mga7 $ rpm -qa | grep kernel* kernel-firmware-20180606-1.mga7 kernel-desktop-devel-4.18.5-3.mga7-1-1.mga7 kernel-userspace-headers-4.18.5-3.mga7 kernel-desktop-4.18.5-3.mga7-1-1.mga7 kernel-desktop-latest-4.18.5-3.mga7 kernel-firmware-nonfree-20180606-1.mga7.nonfree kernel-desktop-devel-latest-4.18.5-3.mga7 dkms-nvidia-current-390.87-1.mga7.nonfree # dkms status nvidia-current, 390.87-1.mga7.nonfree, 4.18.5-desktop-3.mga7, x86_64: installed
Re comment #9: Tried a third netinstall on a machine with nvidia GTX 770 and that failed to boot to a graphical desktop also. On that machine the already installed Cauldron, on another partition, gets as far as a black screen with a mouse cursor. Looks like X is running but the display manager is in trouble.
It looks like this bug needs to be renamed 'graphics' rather than 'nvidia graphics'. Tried the netinstall on my Dell XPS 13 netbook because it is the only machine here without nvidia graphics. It is all Intel. The reboot failed at the graphics stage as before; a black screen with a block mouse cursor only. No ttys available. Booted into rescue mode in order to copy the diagnostics files to the /data partition, fortunately already mounted. Attaching the report bug file and the boot journal.
Created attachment 10352 [details] report.bug.xz for Dell XPS 13
(In reply to Len Lawrence from comment #13) > It looks like this bug needs to be renamed 'graphics' rather than 'nvidia > graphics'. Tried the netinstall on my Dell XPS 13 netbook because it is the > only machine here without nvidia graphics. It is all Intel. > > The reboot failed at the graphics stage as before; a black screen with a > block mouse cursor only. No ttys available. Booted into rescue mode in > order to copy the diagnostics files to the /data partition, fortunately > already mounted. > Attaching the report bug file and the boot journal. (In reply to Len Lawrence from comment #7) > Created attachment 10351 [details] > Latest boot journal for Cauldron This might indeed be two entirely different bugs. In your bootlog, "graphical.target" returns nothing, but there is: > Sep 04 11:22:02 canopus systemd[1]: Reached target Multi-User System. > -- Subject: Unit multi-user.target has finished start-up That looks like bug 22593 "After classical installation, running "systemctl set-default graphical.target" is needed to get a login screen on boot." Can you try, as root: systemctl set-default graphical.target It is weird that there were no ttys available in RL3 on your DEll, did you try switching to tty2 with ctrl+alt+F2? There was a bug about tty1 not showing a prompt in tty1: Bug 22620 "No runlevel 3 prompt in tty1 after fresh install, running "systemctl enable getty@tty1.service" fixes it."
Summary: No nvidia graphics after net boot install => No graphics after net boot install, probably bug 22593
Please close this bug as duplicate of bug 22593 if you think it indeed is a dup ;-)
Created attachment 10353 [details] boot journal fo Dell XPS 13
@Marja, comment #16 It may well be the same but I need to see if I can apply the workaround first. Thanks.
@Marja, comment #15 Yes, nothing happened on Ctrl-Alt-F2 so I cannot pursue other avenues on the netbook. Going back to the workstations to see if other command-line options have any effect.
Pursuing the command-line options on machine vega (nvidia GTX 770) When the boot process hung I tried both these commands in tty2: # systemctl set-default graphical.target # systemctl enable getty@tty1.service and rebooted. This time there was a level 3 login prompt in tty1. Logged in as user and tried $ systemctl default Nothing changed. Logged in as root and checked for nvidia module using lsmod - nothing there. Tried to load the nvidia module - out of my depth here: # modprobe -a nvidia-current lsmod showed nvidia module loaded but nothing with modeset in the name. I seem to remember that such a module always accompanies nvidia. For instance, on this machine (not reporting from the test machine) : # lsmod | grep nvidia nvidia_modeset 1110016 2 nvidia 14393344 84 nvidia_modeset ipmi_msghandler 53248 2 ipmi_devintf,nvidia So, back to the test machine. Loaded nvidia_modeset. $ startx This reported that the X server was already running. # systemctl start sddm.service This blanked the screen, which appeared to be tty1. Nothing there. Possible to go back to tty2. Don't know what to conclude from all this because I am just stabbing in the dark, without a clue.
Is the nouveau module loaded? Try to blacklist it and reboot.
CC: (none) => hamnisdude
I'll check nouveau when I get back to that machine and Ahem... How do you blacklist it? Switched to the new Skylake machine to implement Marja's suggestions. Now looking at Mate in Cauldron. It came up fine after all the fiddling. This is what I did, I think, and the order is important. Booted Cauldron. Loaded the nvidia-current and nvidia_modeset modules when the sequence hung then # systemctl set-default graphical.target # systemctl enable getty@tty1.service Rebooted and the sequence ran better and hung at "Starting GNOME Display Manager" Guessed that it was waiting for a response so switched to tty2 and logged in as user. That seemed to satisfy gdm because $ startx startmate brought up the desktop at the proper 3K resolution. Ran drakx11 to set the launch at boot option and rebooted.
Again the sequence stopped at "started gdm" Switched to tty2 $ startx Straight to Plasma Logged out to blank screen. Rebooted and tried startmate in tty2. Failed because the X server was not running. Tried again. gdm is obviously hoping that the X server is running so appears to hang. Switched to tty2. # systemctl default That appeared to start X because # systemctl start sddm brought up the display manager screen and allowed user to login to Mate desktop. So, a user can login to a graphical desktop provided all the hoops have been navigated. I still do not know if this bug should be closed as a variant of bug 22593 or left open.
(In reply to Len Lawrence from comment #23) > > So, a user can login to a graphical desktop provided all the hoops have been > navigated. I still do not know if this bug should be closed as a variant of > bug 22593 or left open. I may have been wrong :-) And maybe only GDM doesn't work well. What does the following command (as root) return: systemctl status gdm.service You can try whether SDDM works better on bootup, without having to jump hoops, with: systemctl disable gdm.service systemctl enable sddm.service and reboot.
Summary: No graphics after net boot install, probably bug 22593 => No graphics after net boot install
In reply to Marja from comment 24. systemctl status gdm.service This shows that gdm is still active. ● gdm.service - GNOME Display Manager Loaded: loaded (/usr/lib/systemd/system/gdm.service; enabled; vendor preset:> Active: active (running) since Wed 2018-09-05 17:32:19 BST; 2h 40min ago Disabled gdm and enabled sddm before rebooting. That did the trick - you are a genius Marja. Just need to confirm that other machines boot smoothly.
See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=23531
Len, what about this bug? It was filed against MGA 7 which is EOL since June 2021. Comment 25 suggests that you where able to fix it but never answered back...can we close this as OLD?
CC: (none) => tarazed25
Yes, close this as OLD. Cannot even remember what all this was about. Not relevant anymore.
Closing then...
Resolution: (none) => OLDStatus: NEW => RESOLVED