Re: [RFC] rename nvidia-driver port binaries [ and other comments]

Hi.
If including its version to nvidia.ko and nvidia-modeset.ko,
[hard / symbolic] link to it with current name should be needed
not to bother admins every time upgrading.

BTW, I personally using below in rc.conf for safety.
This only helps situations that...

 *Insufficient loader memory, but OK after kernel is started.

 *Accidentally backed to older version that doesn't have
  nvidia-modeset.ko and only nvidia-modeset.ko is written in
  /boot/loader.conf.

## Temporary settings for nvidia-driver when failed loading via loader.conf
kldstat -q -n nvidia.ko
if [ 0 -ne $? ] ; then
  echo "Loading nvidia-driver modules via rc.conf."
#  kldload nvidia
  if [ -e /boot/modules/nvidia-modeset.ko ] ; then
#    kldload nvidia-modeset
    kld_list="${kld_list} nvidia-modeset.ko"
  else
#    kldload nvidia
    kld_list="${kld_list} nvidia.ko"
  fi
fi


On Mon, 15 May 2017 06:41:33 -0700 (PDT)
"Jeffrey Bouquet" <jbtakk_at_iherebuywisely.com> wrote:

>  Just had a unique to me, unbootable backup [beside the point,
> just a sidebar comment... ]  quandry dealing with the nvidia-driver update
> that  mesa-libs needed.  [ or was appurtenant to it, unsure... ]
> 
>   12.0 - CURRENT
> 
>   [ my previous 'saves' -- files to consult...  were in .jpg, so no avail for me to peruse as I was in the terminal ]
> 
> Lessons I learned, maybe
> 
> [RFC]  rename nvidia-driver.ko to include its version, for instance nvidia-modeset-37539.ko
>           which would make one's diagnosis a fix easier. 
> 
> [suggestions]
> 
> ... Document that the kernel will load a /boot/modules/_nvidia.ko if you'd thus made it 'unavailable'
> ... document better that one can load nvidia[modeset] later than /boot/loader.conf [cli, rc.conf...]
> 
> [ mini 'what fixed it for you '  and/or stalled the same ... 
> ] 
> ... I had a make.conf in place, 'trapping' a
>     make -DMAKE_JOBS_UNSAFE=yes CC=".../clang39"  [and the other two...] install in failure
> ... I had no clue if Xorg was at fault, and luckily did not have to rebuild.
> ... I had no access to the forums, as the desktop could not be loaded [yet]
> ... I had to do strings nvidia.ko |grep 26 [39] | less to detect the not usable module numbers,
>     THUS THE REQ FOR RENAME of the nvidia.ko binary [vs port] to include its 5 digit number
>     as above.
> ... I was taken aback by the less infomative
>     this client has the .39 but the module has the .26 ... 
>     specifically stating which file/port/kernel module the 'client' refers to
>    and which specific modules 'this module' was referring to.  Unknown if that is
>    fixable here in a .c, .h , or is closed-source upstream in nvidia [corp ] where we can
>     ask them to be more specific or code in some more verbose error messages.
> ...  Relieved I did not have to rebuild Xorg nor the kernel, just move files out of the
>   way and do a simple rebuild of the nvidia-driver.
> [... Not relieved that the nvidia-driver needed install during the mesa-lib reshuffle,  maybe
>    did not need to be, just a hazy recollection on my part.  So ignore this little bit ]
> 
> ... All in all a learning experience.  Howsoever, I would like this nvidia stuff to be put eventuall
>  in /usr/src/UPDATING so the half or third of persons who run into this yearly will have a more
>  authoritative flowchart of sorts to determine the next course of action.
>    something like
>   if ... this thta
>    if... this that
>    if ... this that
>   OTOH... error message... a... you may need to...
>        ...
>                error message ... r... you may need to...
> 
>  ... And it would have maybe saved a bit of time here, and I would almost if eventually
>      possible be sure to copy /usr/src/UPDATING to /usr/ports/x11/nvidia-driver for
>      more easy access if the desktop was broken....
> 
> 
> Apologies for the hurried post. Indeed, I have tasked myself to write it up here
> locally [ still in scribbled notations...] so I can forestall/fix more quickly this
> error the next time.
> also...
> Running late  in other personal matters, and out of time.
> 
> Respectfully..
> 
> J. Bouquet 
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"
> 


-- 
Tomoaki AOKI    <junchoon_at_dec.sakura.ne.jp>