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" <jbt...@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@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
--
Tomoaki AOKI <junch...@dec.sakura.ne.jp>
_______________________________________________
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
