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