[10:57] tseliot: I was just looking at log files and I found that I have the same problem as darkxst with nvidia-drm not loading. [10:58] Or, not loading with modeset=1. It does load automatically later. [11:01] I can also see that modinfo doesn't work for any of the alias module names. (module not found) [11:02] mamarley: yes, I'll have a look at that [11:03] I was actually going to see if I could fix it myself. I don't know how to get modules to be included in the initramfs though. [11:05] I fail to see how the "alias nvidia nvidia_364" doesn't work though, since "modinfo nvidia_364" does work. [11:16] It is almost like the aliases are being ignored entirely. I can't see why. [11:33] mamarley, tseliot, added/tweaked aliases locally (using underscores only) [11:35] ricotz: ok. BTW I'm working on nvidia right now [11:35] tseliot, I was counting on that ;) [11:36] mamarley: "automatically" means maybe the driver loads that module? [11:44] tjaalton: I don't see the kms drivers in the initramfs. They are not built as modules, so I suppose there is nothing to include [11:46] tseliot: huh? i915.ko etc [11:46] /usr/share/initramfs-tools/hooks/framebuffer copies them [11:48] tjaalton: yes, I will have to write a hook for nvidia. I simply could not file the files in the initramfs [11:51] tseliot: Yes, I think nvidia-drm is getting loaded automatically by either nvidia-modeset or nvidia and that is why the driver works even though the modprobe in the udev configuration fails. [11:53] whatever it is, I'll fix it all ;) [11:55] Thanks :) [11:59] tjaalton: I extracted the initramfs and I used find to get a list of the .ko files: http://paste.ubuntu.com/15486764/ [11:59] this is what puzzles me [12:00] you're on trusty still.. [12:00] check if it has that hook [12:00] yes [12:00] and yes, the hook is there [12:00] dunno then [12:01] are you sure that we do that even on systems that are not encrypted? [12:01] yes [12:03] http://sprunge.us/JUfW [12:03] - Restore the framebuffer hook and script, copying KMS and other [12:03] framebuffer drivers into the initramfs, but make them optional; you [12:03] need to set FRAMEBUFFER=y for these to be included. [12:04] tjaalton: ^ Do you have FRAMEBUFFER=y in grub or is your system encrypted? [12:05] FRAMEBUFFER where? [12:05] this one isn't encrypted [12:07] well, actually not grub, somewhere in /etc/initramfs-tools/conf.d/ [12:07] no [12:07] grep gives no hits [12:08] where did you get that text? [12:09] from the changelog of the initramfs-tool package [12:09] *tools [12:10] if you add FRAMEBUFFER=y, plymouth will start much earlier in the boot process [12:18] add where? [12:18] upgrade to xenial already [12:18] :) [12:20] /etc/initramfs-tools/conf.d/splash [12:21] don't have that [12:21] you're on an obsolete distro ;) [12:21] yes, well, echo FRAMEBUFFER=y > /etc/initramfs-tools/conf.d/splash [12:21] my initrd already has all the modules [12:21] the hook does not check for that option [12:21] I'm trying to understand why we don't have the modules on trusty [12:22] just ask apw? [12:22] yes, that's why I'm confusedf [12:22] *confused [12:22] yes, I'll try that [12:22] splash is only needed in the initramfs if you have encrypted things to open to get to root [12:23] oh you're here :) [12:24] so we don't include that lot unless you have crypt thing on there [12:25] which is what I suggested before [12:25] apw: but how about the single drm drivers? [12:25] I don't have them in trusty, but tjaalton does in xenial [12:26] my initrd has all of them, this is a fairly recent install [12:30] * tseliot -> lunch [12:35] tjaalton, it is dependant on you needing them [12:35] so encrypted root, or actually iirc stypidly having crypttools installed at all [12:36] nope, neither [12:40] tseliot, ^ [12:41] well something is triggering them being in there, it is not a normal situation [12:41] basically any hook which needs them sets that FRAMEBUFFER thing and that triggers it [12:41] iirc [12:41] so look at your hooks and one will be asking for it [12:41] or it is broken, which is also possible [12:43] i have a fresh server vm, and it has them too :) [12:43] so maybe it's a bug then [12:44] Does the nvidia-modeset module need to be loaded for DRM KMS to work or just nvidia-drm? [12:58] tjaalton, could be, could you file a bug against initramfs-tools for me, and tell me the number [14:30] mamarley: both, as KMS stands for kernel mode setting, so nvidia-modeset is definitely needed [14:30] That's what I thought. [14:31] apw: thanks, that's what I thought [15:34] tjaalton: so, yes, that does look like a bug: [15:34] * mkinitramfs: Allow scripts to specify OPTION=VAR, and unless VAR is [15:34] set to something other than "n", the script will not be included. [15:34] the framebuffer hook has OPTION=FRAMEBUFFER [15:35] so, if OPTION=FRAMEBUFFER is ignored, and the script is included regardless of that, it's a bug [15:35] darkxst: are you using an encrypted system? [15:37] if not, fixing the aliases should do it [15:42] I am certainly going to add an initramfs hook for encrypted systems though [15:43] * tseliot building the driver with the correct aliases first... [16:24] ricotz, mamarley: the aliases seem to work fine now: http://pastebin.ubuntu.com/15488195/ [16:25] modinfo doesn't seem to resolve the aliases but I think we are fine as long as modprobe does ;) [16:35] tseliot: Cool, thanks! [16:36] so the last step will be a hook for encrypted systems. Then things should be fine. I'm not sure about nvidia-persistence though [16:36] tseliot, is this working for you now? "sudo cat /sys/module/nvidia_drm/parameters/modeset" [16:36] tseliot: Maybe also have it obey that override that apw mentioned? [16:36] ricotz: I still get "N", but I don't see any errors in journactl [16:37] tseliot, mhh, I see [16:37] mamarley: yes, I could have to look at initramfs-tools [16:39] tseliot, or get a bug filed on it and shove it at me [16:39] sounds like something i would have screwed up in my merge with debian if anything [16:39] apw: yes, that would be much better (for me) ;) [16:41] tseliot, shove what you have in a bug, and tell me the number and i'll put it on my todo [16:41] its making peoples initramfs' large and slwo, so i want to wack it [16:41] tseliot: Sorry, I didn't mean for you to fix the initramfs-tools bug, I just meant to make it so when that bug gets fixed that the flag there will affect the nvidia modules too. [16:42] apw: sure, thanks. I'm updating my xenial installation right now, so that I can use ubuntu-bug to file the report, just in case [16:42] tseliot, ack thanks [16:42] mamarley: I'm all for solutions that don't involve me doing the work :P [16:42] * mamarley too :) [16:44] I just confirmed that manually loading the nvidia_drm module with modeset=1 results in "sudo cat /sys/module/nvidia_drm/parameters/modeset" returning Y. [16:45] mamarley: ok, so maybe the udev rule should try to remove the module first (as per the nvidia docs) [16:45] I'm not sure why it would be loaded at all at that point. Unless udev loads it automagically... [16:46] mamarley: ok maybe their X driver? [16:46] Would something in /etc/modprobe.d/ that says "options nvidia_drm modeset=1" work by any chance? [16:47] Would the X driver have started by that point? I was under the impression that the udev thing happened earlier than X starting. [16:47] Also, I would think if X is running, "modprobe -r"ing the module would fail anyway. [16:47] it's worth a shot [16:48] I can try that on my laptop real quick, just a sec... [16:48] and yes modprobe -r failed for me above ^ [16:48] udev starts earlier than X though [16:48] just guessing. I have no idea what else could be pulling that in [16:52] tseliot: That ("options nvidia_drm modeset=1") appeared to work. :) [16:53] mamarley: wouldn't that be nvidia-drm though? (to match the alias) [16:53] I actually put four different lines though, with and without the 364 and -s and _s, because of the alias madness. [16:53] :) [16:54] I'll test it here too [16:55] Hmm, will that work if the module is in initramfs too? [16:55] well, the aliases are in the initramfs [16:56] OK, it should work fine then. I stuck my options in the same file as the aliases. [16:56] and the actual module name would be nvidia_364_drm, whereas nvidia_drm shouldn't exist [16:56] * tseliot rebuilding and testing... [16:57] I understand; I just wanted to cover all the bases since I am not running the version with the fixed aliases yet. [16:57] right [16:57] I think I'll work on the hook tomorrow, as it's EOD for me [16:58] Explosive Ordnance Disposal? ;P [16:59] hehe [16:59] in addition to being almost guitar o'clock [17:14] apw: LP: #1561643 [17:14] Launchpad bug 1561643 in initramfs-tools (Ubuntu) "initramfs-tools ignores the FRAMEBUFFER option" [High,Confirmed] https://launchpad.net/bugs/1561643 [17:15] mamarley: nvidia-drm options didn't work here. I'll mess with it again tomorrow [17:15] * tseliot -> off [17:15] tseliot: OK. It actually didn't work setting options on the alias for me either. [17:15] I think I have to set options with the full module name. [17:16] yes, that would be easy to do [17:17] Yeah, that works. [20:45] anybody know why I would be getting this error? first time i'm seeing it: [20:45] furkan@furkan-pc:~$ Xorg -version [20:45] /usr/lib/xorg/Xorg.wrap: Only console users are allowed to run the X server [20:53] also, tjaalton: MrCooper wrote a patch for the cursor bug https://bugs.freedesktop.org/show_bug.cgi?id=94560#c16 [20:53] Freedesktop bug 94560 in Server/General "[regression, bisected] Xorg 1.18.2 stray cursor appears when some applications are launched maximized on rotated display" [Normal,New] [22:14] tseliot, no my system is not encrypted