You are not logged in.
Workaround is here:
https://bbs.archlinux.org/viewtopic.php … 0#p1351600
workaround doesn't always work here. It's probably the nvidia device that needs to be waited
Offline
As I said before, you cannot wait for the nvidia device, since it doesn't properly register with the kernel and thus is unknown to udev.
Offline
For some reasons it's not enough here, I had to add
ExecStartPre=/bin/bash -c 'sleep 2'
to /etc/systemd/system/kdm.service.d/10-wait-for-card.conf service file.
Now, I don't know if I should be pleased for my system performances or pissed off with nvidia or systemd. lol
Offline
Shouldn't adding MODULES="nvidia" to /etc/mkinitcpio.conf and rebuilding initramfs with #mkinitcpio -p linux work, too?
Offline
Shouldn't adding MODULES="nvidia" to /etc/mkinitcpio.conf and rebuilding initramfs with #mkinitcpio -p linux work, too?
yeah, sure it works thank you, much better than my horrible hack.
So, in my case, it's just a matter of adding nvidia module to the mkinitcpio modules array for an early device creation.
I have kms and drm disabled in my system so the files posted by brain0 are not relevant in my case , I think.
Thanks to everyone
Offline
blackout23 wrote:Shouldn't adding MODULES="nvidia" to /etc/mkinitcpio.conf and rebuilding initramfs with #mkinitcpio -p linux work, too?
yeah, sure it works thank you, much better than my horrible hack.
So, in my case, it's just a matter of adding nvidia module to the mkinitcpio modules array for an early device creation.
I have kms and drm disabled in my system so the files posted by brain0 are not relevant in my case , I think.
Thanks to everyone
Just remember that you have it in there. When you pacman -Syu and you get an update for nvidia and linux it might install linux first and run mkinitcpio before having the new nvidia module installed which will cause mkinitcpio to fail. So you simply have to run mkinitcpio again after -Syu is finished and the new nvidia module is installed.
I use this method on both my computers and never had an issue with nvidia and the kernel in years.
Last edited by blackout23 (2013-11-23 09:50:11)
Offline
@blackout23
What a beautiful and simple idea, thanks for sharing.
Help me to improve ssh-rdp !
Retroarch User? Try my koko-aio shader !
Offline
mangus wrote:blackout23 wrote:Shouldn't adding MODULES="nvidia" to /etc/mkinitcpio.conf and rebuilding initramfs with #mkinitcpio -p linux work, too?
yeah, sure it works thank you, much better than my horrible hack.
So, in my case, it's just a matter of adding nvidia module to the mkinitcpio modules array for an early device creation.
I have kms and drm disabled in my system so the files posted by brain0 are not relevant in my case , I think.
Thanks to everyoneJust remember that you have it in there. When you pacman -Syu and you get an update for nvidia and linux it might install linux first and run mkinitcpio before having the new nvidia module installed which will cause mkinitcpio to fail. So you simply have to run mkinitcpio again after -Syu is finished and the new nvidia module is installed.
I use this method on both my computers and never had an issue with nvidia and the kernel in years.
yay, thanks for the tip! give this man a thank button pls!
Offline
saty wrote:When I was trying to figure this on my own I found some "Your system is not currently configured to drive a VGA console on the primary VGA device. The NVIDIA Linux graphics driver requires the use of a text-mode VGA console." messages in the log files. They probably have been there forever but I haven't bothered with them since now.
That is normal and you should remember it when you get actual instabilities. I run nvidia together with efifb and experience no problems so far.
Anyway, I seem to have solved the problem for me, just create two files:
# /etc/udev/rules.d/99-make-udev-drm-aware.rules SUBSYSTEM=="drm", TAG+="systemd"
# /etc/systemd/system/kdm.service.d/10-wait-for-card.conf [Unit] Wants=dev-dri-card0.device After=dev-dri-card0.device
If you have more than one nvidia card, also plug in card1 etc.
Your workarround worked also (sort of) for me.
The file /etc/systemd/system/kdm.service.d/10-wait-for-card.conf didn't exist for me, so I had to add the contents of that file to the [Unit] sections of my /etc/systemd/system/display-manager.service
[Unit]
Description=K Display Manager
After=systemd-user-sessions.service
Wants=dev-dri-card0.device
After=dev-dri-card0.device
[Service]
ExecStart=/usr/bin/kdm -nodaemon
[Install]
Alias=display-manager.service
Offline
The file /etc/systemd/system/kdm.service.d/10-wait-for-card.conf didn't exist for me, so I had to add the contents of that file to the [Unit] sections of my /etc/systemd/system/display-manager.service
[Unit] Description=K Display Manager After=systemd-user-sessions.service Wants=dev-dri-card0.device After=dev-dri-card0.device [Service] ExecStart=/usr/bin/kdm -nodaemon [Install] Alias=display-manager.service
Please learn to read. You are supposed to create the file, and you are supposed to add exactly the contents I posted, not blindly copy the whole kdm.service unit.
Offline
blackout23 wrote:mangus wrote:yeah, sure it works thank you, much better than my horrible hack.
So, in my case, it's just a matter of adding nvidia module to the mkinitcpio modules array for an early device creation.
I have kms and drm disabled in my system so the files posted by brain0 are not relevant in my case , I think.
Thanks to everyoneJust remember that you have it in there. When you pacman -Syu and you get an update for nvidia and linux it might install linux first and run mkinitcpio before having the new nvidia module installed which will cause mkinitcpio to fail. So you simply have to run mkinitcpio again after -Syu is finished and the new nvidia module is installed.
I use this method on both my computers and never had an issue with nvidia and the kernel in years.
yay, thanks for the tip! give this man a thank button pls!
As pointed out: This also works. You just have to remember rebuilding your init image, when your driver is being updated!
Speak when you are angry and you will make the best speech you'll ever regret.
Offline
I was hoping the updated nvidia driver from the testing repo would have fixed the bug, but it did not. Now the hack with the kdm.service.d file & udev rule alone does not work, but i also had to add nvidia as a module in mkinitpio.conf in order to boot into kdm. So basically the new version only made it worse so far ....
Edit: Actually now it is enough to add nvidia as a module; i deleted the two other files.
Edit2: The new nvidia Version from the official repo seems to work fine without any hack necessary
Last edited by tumas (2013-12-07 09:04:30)
Offline
New fresh install.
and kdm not start.
kdm [399]: X server died during startup
kdm [399]: X server for display :0 cannot be started, session disabled
Is this still bug ??
Solution is add nvidia as a module in mkinitpio.conf
Offline
I solved problems
Too quickly system
Fresh installation , no ntfs4 mount in fstab
But added ntfs4 mount in fstab ,boot prosses slow bit and kdm start rigt.
Amazing i have too quick speed the ligt speed system.
Offline
I encountered this same issue last night when I tried a fresh Arch install. I tried the fixes in this thread, but without success. I'm not using KDM, but GDM and Gnome 3, so maybe those fixes don't apply to me.
The 304.xx drivers work fine. Is there any word on a real fix for this problem? Ubuntu 14.04 with Kernel 3.13.1 and the 331.38 drivers works fine, why not Arch? Lots of new users will be discouraged by this problem.
Is this something NVIDIA has to fix, or is it on our end?
Last edited by dwightjl (2014-02-05 17:28:29)
Offline
I encountered this same issue last night when I tried a fresh Arch install. I tried the fixes in this thread, but without success. I'm not using KDM, but GDM and Gnome 3, so maybe those fixes don't apply to me.
The 304.xx drivers work fine. Is there any word on a real fix for this problem? Ubuntu 14.04 with Kernel 3.13.1 and the 331.38 drivers works fine, why not Arch? Lots of new users will be discouraged by this problem.
Is this something NVIDIA has to fix, or is it on our end?
I'd like to know this also. Is this a NVIDIA driver problem or just systemd / kernel ?
Offline
I encountered this same issue last night when I tried a fresh Arch install. I tried the fixes in this thread, but without success. I'm not using KDM, but GDM and Gnome 3, so maybe those fixes don't apply to me.
The 304.xx drivers work fine. Is there any word on a real fix for this problem? Ubuntu 14.04 with Kernel 3.13.1 and the 331.38 drivers works fine, why not Arch? Lots of new users will be discouraged by this problem.
Is this something NVIDIA has to fix, or is it on our end?
Are you sure you have the same problem? I also have GDM/Gnome and adding nvidia to the modules in /etc/mkinitcpio.conf and rebuild the kernel image solved the problem for me perfectly. Have you done all steps?
Offline
Is this something NVIDIA has to fix, or is it on our end?
If in doubt, it's nvidia's fault.
Offline
dwightjl wrote:Is this something NVIDIA has to fix, or is it on our end?
If in doubt, it's nvidia's fault.
But why did it work OK before ?
Offline
brain0 wrote:dwightjl wrote:Is this something NVIDIA has to fix, or is it on our end?
If in doubt, it's nvidia's fault.
But why did it work OK before ?
Ask nvidia.
Offline
That is normal and you should remember it when you get actual instabilities. I run nvidia together with efifb and experience no problems so far.
Anyway, I seem to have solved the problem for me, just create two files:
# /etc/udev/rules.d/99-make-udev-drm-aware.rules SUBSYSTEM=="drm", TAG+="systemd"
# /etc/systemd/system/kdm.service.d/10-wait-for-card.conf [Unit] Wants=dev-dri-card0.device After=dev-dri-card0.device
I do apologize for bumping an old thread, but I cannot find this answer anywhere I've looked. I do not use KDE nor kdm, thus I have "kdm.service.d" directory. So where exactly should I put the 10-wait-for-card.conf file so that it starts automatically with systemd? Thanks for any help.
Offline
You have been warned once about necrobumping. This is your last warning.
Closing
Offline