Solved I think that I have met my match

hruodr said:
As said before, in this situations is better BSD without Desktop Environments, no GhostBSD.
The whole is then simpler and you have more control.
It is good to learn to deal with omnipresent twm.
Click to expand...
I'm just using it as a temporary solution. It's already gone from my system. But you're right, it would have been quicker to cp all of my documents from within but now I know not to waste time installing another operating system, when I could have done the same thing with a bootable usb and a few commands.
 
Cedric62 said:
Any thoughts?
Click to expand...

As I mentioned in my previous posting, you can avoid this problem if you set a ZFS snapshot before you perform the pkg update/upgrade.

(I was also) recently asked to update my existing FreeBSD system and I noticed that my Nvidia drivers were going to get "replaced" by the pkg update/upgrade process. Instead of agreeing "YES" at the pkg "Do you want to proceed?" prompt -- I said "NO" - I stopped - went back to the FreeBSD Operating System and quickly took a ZFS snapshop of my working FreeBSD system. Then I returned and ran the pkg update/upgrade commands normally.

In my case, the pkg update/upgrade to 15.0-RELEASE-p6 went fine - and that was GOOD !

But in case the pkg update/upgrade (DID NOT) go fine, I had the ready option to restore my FreeBSD system "back to normal" from the ZFS snapshot and be back in business again. I have definitely had the pkg update/upgrade process remove my currently working Nvidia drivers and replace them with non-working NVidia drivers. (IF THAT HAD HAPPENED) I would then restore my FreeBSD system from a ZFS snapshot and I would have the "working" NVidia drivers restored back to my FreeBSD system -- and I would have a working FreeBSD system again.

That said if you would like to learn more about the FreeBSD ZFS file system, there is a book written by Micheal Lucas / Allen Jude -- that you can reference (or buy) - which is called (Link Amazon): FreeBSD Mastery: ZFS -- number of pages: 201. In USD it is listed for $21.16.

Good luck !
 
This might be related to the update of the nvidia-driver to version 595. This driver does not support GTX 10xx series graphics cards.

I have a similar PC on which I previously simply installed:
pkg install nvidia-driver (without specifying a version)
Of course, when updating, it switched to a new version that does not support the graphics card.

Solution
Code: 
pkg delete nvidia-driver
and
Code: 
pkg install nvidia-driver-580

Note: During installation, the driver will install nvidia-kmod. If the version nvidia-kmod-580.xxx.xxx does not fully match the version nvidia-driver-580.xxx.xxx, you will first need to install the correct nvidia-kmod-580. xxx.xxx (pkg search nvidia-kmod) and then nvidia-driver-580.xxx.xxx.

And everything should work as before.
 
Black_N said:
pkg install nvidia-driver-580
Click to expand...
Well, I think that I've gotten to the bottom of this, and Black_N has hit the nail on the head.

To begin with, as I was sitting at my desk spinning my wheels this afternoon, I suddenly remembered that I had an old hard drive in my closet, which had a duplicate installation of FreeBSD on it. I plugged this hard drive into one of the sata ports on my mother board, booted from the FreeBSD USB, and then I used the dd command to copy drive in my close onto drive ada0. Next I rebooted, and what do you know, I was back to a configuration from about a month and a half ago.

Next, I took a look at the graphics driver currently being used and below is what I got
Code: 
root@Asus:/home/Simon/Desktop # pkg info nvidia-driver
nvidia-driver-580.119.02_1
Name           : nvidia-driver
Version        : 580.119.02_1
Installed on   : Fri Jan 23 11:02:36 2026 EST
Origin         : x11/nvidia-driver
Architecture   : FreeBSD:15:amd64
Prefix         : /usr/local
Categories     : x11
Licenses       : NVIDIA
Maintainer     : x11@FreeBSD.org
WWW            : https://www.nvidia.com/object/unix.html
Comment        : NVidia graphics card binary drivers for hardware OpenGL rendering
Options        :
    DOCS           : on
Shared Libs required:
    libX11.so.6
    libXext.so.6
(And it goes on and on from here.)

Next I took a look at the packages I have locked on my system by issuing the below command.
Code: 
root@Asus:/home/Simon/Desktop # pkg lock -l
Currently locked packages:
nvidia-driver-580.119.02_1
nvidia-drm-66-kmod-580.119.02.1500068_2
nvidia-settings-580.119.02
nvidia-xconfig-580.119.02

So, if I understand the above information correctly, it appears that I'm using nvidia-driver-580.119.02_1, and that this package should be locked against being upgraded? Does that sound right?

However, if I enter the below command in order to see which packages my system wants to upgrade, I see that my Nvidia driver is on that list, even though I used the lock command to try and block it from being upgraded.
Code: 
root@Asus:/home/Simon/Desktop # pkg upgrade -n >/home/Simon/Temp/pkgs.txt
...a lot of packages listed above here.....
nvidia-drm-kmod: 580.119.02 -> 595.58.03 [FreeBSD-ports]
nvidia-kmod: 580.119.02.1500068_1 -> 595.58.03.1500068 [FreeBSD-ports]
...a lot of packages listed below here.....

So, it looks like I had better not ever issue another package upgrade until I find a way of preventing 580.119.02_1 from being replaced by 595.58.03. Hmmm......
 
Cedric62 said:
Well, I think that I've gotten to the bottom of this, and Black_N has hit the nail on the head.

To begin with, as I was sitting at my desk spinning my wheels this afternoon, I suddenly remembered that I had an old hard drive in my closet, which had a duplicate installation of FreeBSD on it. I plugged this hard drive into one of the sata ports on my mother board, booted from the FreeBSD USB, and then I used the dd command to copy drive in my close onto drive ada0. Next I rebooted, and what do you know, I was back to a configuration from about a month and a half ago.

Next, I took a look at the graphics driver currently being used and below is what I got
Code: 
root@Asus:/home/Simon/Desktop # pkg info nvidia-driver
nvidia-driver-580.119.02_1
Name           : nvidia-driver
Version        : 580.119.02_1
Installed on   : Fri Jan 23 11:02:36 2026 EST
Origin         : x11/nvidia-driver
Architecture   : FreeBSD:15:amd64
Prefix         : /usr/local
Categories     : x11
Licenses       : NVIDIA
Maintainer     : x11@FreeBSD.org
WWW            : https://www.nvidia.com/object/unix.html
Comment        : NVidia graphics card binary drivers for hardware OpenGL rendering
Options        :
    DOCS           : on
Shared Libs required:
    libX11.so.6
    libXext.so.6
(And it goes on and on from here.)

Next I took a look at the packages I have locked on my system by issuing the below command.
Code: 
root@Asus:/home/Simon/Desktop # pkg lock -l
Currently locked packages:
nvidia-driver-580.119.02_1
nvidia-drm-66-kmod-580.119.02.1500068_2
nvidia-settings-580.119.02
nvidia-xconfig-580.119.02

So, if I understand the above information correctly, it appears that I'm using nvidia-driver-580.119.02_1, and that this package should be locked against being upgraded? Does that sound right?

However, if I enter the below command in order to see which packages my system wants to upgrade, I see that my Nvidia driver is on that list, even though I used the lock command to try and block it from being upgraded.
Code: 
root@Asus:/home/Simon/Desktop # pkg upgrade -n >/home/Simon/Temp/pkgs.txt
...a lot of packages listed above here.....
nvidia-drm-kmod: 580.119.02 -> 595.58.03 [FreeBSD-ports]
nvidia-kmod: 580.119.02.1500068_1 -> 595.58.03.1500068 [FreeBSD-ports]
...a lot of packages listed below here.....
Click to expand...
Cedric62 said:
So, it looks like I had better not ever issue another package upgrade until I find a way of preventing 580.119.02_1 from being replaced by 595.58.03. Hmmm......
Click to expand...
If I understand correctly, you already lock the packages. I don't understand why you need to find another way to prevent the package from being upgrade which you already did. Enlighten me.
 
Ok, OP only performs dry-run.

For what I experience, it definitely would print some messages informing packages are not being upgraded due to lock when run with the actual pkg-upgrade command.

Let me verify the dry run command on my setup once I back to my desk.
 
Cedric62 said:
could have done the same thing with a bootable usb and a few commands.
Click to expand...
If you have an alternative computer for emergency internet as I proposed before, perhaps an old laptop,
and also have a crossover cable,
you can boot the main computer with PXE for saving data,
you can also boot FreeBSD from a Linux computer as server.
 
Cedric62 said:
nvidia-driver-580.119.02_1
Click to expand...

So this particular NVIDIA driver version (580.119) is reported BROKEN by a lot of people on the Internet... including "by me" :cool: ! Here is my original posting to these Forums on this issue:
So -- I hate to say it but "ultimately" the OP is going to need to get their FreeBSD system running with a more recent NVIDIA driver.

I actually completely ran away from my NVIDIA FreeBSD host system between the months of January to March/April because I couldn't use this NVIDIA driver with FreeBSD and XFCE. When the (new) driver was released with 15.0-RELEASE-p6 that fixed my NVIDIA machine and I was back in business again.

Sadly... this same change appears to have broken the OP. (Sorry about that... believe me I know how it feels to have your FreeBSD system suddenly "turned into silicon" right before your eyes... NOT FUN)

That said - (one potential fix) you can try is to see if XFCE is your issue. For a few weeks I switched to the Cinnamon desktop and it was actually a "Not bad!" replacement for XFCE. See the FreeBSD Handbook on how to switch over to Cinnamon Desktop - (Link FreeBSD Handbook): FreeBSD Handbook Desktops

If you switch to Cinnamon Desktop - you might want to add "pkg automount" to simplify adding and remove media (aka USB sticks, USB drives, etc). Thank you to VERMADEN for creating such a cool package !

You can also try Wayland... YMMV

But ULTIMATELY -- OP is going to have to get their hardware working with an NVIDIA driver beyond (580.119) at some point.

BTW: The other option is to purchase a second machine with (perhaps) an Intel based video card (aka "i915kms") and you can "like me" avoid all of the NVIDIA issues for awhile :cool:. The truth is: You never know when the "snake is going to strike" - so better to be prepared up front !

Good luck !
 
CShell said:
See the FreeBSD Handbook on how to switch over to Cinnamon Desktop
Click to expand...
At the moment I have both Xfce and Cinnamon within FreeBSD, and I couldn't get either of them to load, because the login greeter screen was replaced by the black screen of death. For a while I was thinking to get rid of Xfce and use only Cinnamon, but I'm starting to think that Xfce is a better desktop, at least for me.
 
hruodr said:
If you have an alternative computer for emergency internet as I proposed before, perhaps an old laptop,
and also have a crossover cable,
you can boot the main computer with PXE for saving data,
you can also boot FreeBSD from a Linux computer as server.
Click to expand...
That might be just a little bit beyond my skill level land experience. However, for the time being I was able to connect an external Seagate hard drive while it was running Ghost, and I was able to get my stuff copied over that way. I still have a lot to learn.
 
claudiuschan said:
If I understand correctly, you already lock the packages. I don't understand why you need to find another way to prevent the package from being upgrade which you already did. Enlighten me.
Click to expand...
Because it appears that even though these packages were earlier locked by me, somehow they got replaced when I upgraded my packages the other day. It seems, at least in my case, that locking packages may not be an absolutely certain way to ensure that a package won't be overwritten. But I admit, maybe I misinterpreted things as they were unfolding before my eyes, because at that time I was trying to focus on another project I was working on for a friend.
 
claudiuschan said:
Ok, OP only performs dry-run.

For what I experience, it definitely would print some messages informing packages are not being upgraded due to lock when run with the actual pkg-upgrade command.

Let me verify the dry run command on my setup once I back to my desk.
Click to expand...
Below is what I used to create my list of upgradable packages.

Code: 
pkg upgrade -n >/home/Simon/Temp/pkgs.txt
 
CShell said:
But ULTIMATELY -- OP is going to have to get their hardware working with an NVIDIA driver beyond (580.119) at some point.
Click to expand...

I agree and understand, but I'm thinking that I should be able to use my current driver for at least a few weeks / months?
 
Well, here is something interesting I learned today...

Earlier I created a list of all the packages which needed to be upgraded on my system by invoking the below command.
Code: 
# pkg upgrade -n >/home/Simon/Temp/packages.txt
The above command gave me a file which looked similar to the below.
Code: 
FreeBSD-clibs-dev: 15.0 -> 15.0p6 [FreeBSD-base]
FreeBSD-kernel-generic: 15.0p5 -> 15.0p6 [FreeBSD-base]
FreeBSD-kernel-generic-dbg: 15.0p5 -> 15.0p6 [FreeBSD-base]
FreeBSD-runtime: 15.0p5 -> 15.0p6 [FreeBSD-base]
alsa-lib: 1.2.14 -> 1.2.15.3 [FreeBSD-ports]
amtk: 5.9.1 -> 5.9.2 [FreeBSD-ports]
aom: 3.13.2 -> 3.13.3 [FreeBSD-ports]
aspell: 0.60.8.1_1,1 -> 0.60.8.2,1 [FreeBSD-ports]
assimp: 6.0.2 -> 6.0.4 [FreeBSD-ports]
at-spi2-core: 2.56.7 -> 2.56.8 [FreeBSD-ports]
babl: 0.1.116 -> 0.1.124 [FreeBSD-ports]
bind-tools: 9.20.20 -> 9.20.22 [FreeBSD-ports]
bsdisks: 0.38 -> 0.40 [FreeBSD-ports]
 (Goes on and on for over a hundred rows below)

Next I removed any reference regarding Nvidia from the above text file. After that I invoked the below command in an attempt to only upgrade the packages listed within my above text file.

Code: 
pkg upgrade $(cat /home/Simon/Temp/packages.txt)

However, after I attempted to run the above command, I realized that I had remove the version number from each package listed in my text file, so my file ended up looking something like the below.
Code: 
alsa-lib
amtk
aom
aspell
assimp
at-spi2-core
babl
bind-tools
bsdisks
cairomm11
cantarell-fonts
caribou
cinnamon-screensaver
cinnamon-settings-daemon
cjs
colord
cups-filters
curl
(Goes on and on below this point)

I ran my above command to only upgrade the packages contained within my text file, and the process seemed to work very well, however, the below packages had to be upgraded one at a time manually.
Code: 
FreeBSD-runtime-dev: 15.0 -> 15.0p7 [FreeBSD-base]
FreeBSD-runtime-dev-lib32: 15.0 -> 15.0p7 [FreeBSD-base]
FreeBSD-runtime-lib32: 15.0 -> 15.0p7 [FreeBSD-base]

Also, after I manually upgraded the above runtime packages, I then ran the upgrade command with the -n switch once again, outputting to a new text file, and now the only packages which seem to be listed for an upgrade are my Nvidia packages. See below.

Code: 
Installed packages to be UPGRADED:
    nvidia-drm-kmod: 580.119.02 -> 595.58.03 [FreeBSD-ports]
    nvidia-kmod: 580.119.02.1500068_1 -> 595.58.03.1500068 [FreeBSD-ports]

So, will this type of solution get me by for a while, until I figure out away around the issue with the new Nvidia driver? Also, I had to go through a lot of cumbersome steps in order to execute the above, so is there any easier way to avoid accidentally upgrading my Nvidia driver?
 
Cedric62 said:
At the moment I have both Xfce and Cinnamon within FreeBSD, and I couldn't get either of them to load, because the login greeter screen was replaced by the black screen of death.
Click to expand...

OK - just to eliminate something:

What happens if you edit /etc/rc.conf and set: lightdm_enable="NO" -- (Or just comment this line out with a #)? Then reboot your system.

What you should get is a normal terminal "login:" and "password:" prompts. Then login and type "startx". If XFCE or Cinnimon doesn't load you will get logging output under /var/log. What will be interesting to see if the output in this /var/log file. You never know - your problem might be easier to fix than you think.

You can always turn lightdm back on again in /etc/rc.conf after the test.
 
CShell said:
OK - just to eliminate something:

What happens if you edit /etc/rc.conf and set: lightdm_enable="NO" -- (Or just comment this line out with a #)? Then reboot your system.

What you should get is a normal terminal "login:" and "password:" prompts. Then login and type "startx". If XFCE or Cinnimon doesn't load you will get logging output under /var/log. What will be interesting to see if the output in this /var/log file. You never know - your problem might be easier to fix than you think.

You can always turn lightdm back on again in /etc/rc.conf after the test.
Click to expand...
Since everything seems to be stable at the moment, and I have a few things to take care of, I will give this a try on Saturday, that way I have more time in case I cause a real problem. Also, I think that I tried this a few months back, but when I typed "startx" it took me to an environment with several terminal windows, but it didn't start a real desktop environment.
 
Cedric62 said:
Also, I think that I tried this a few months back, but when I typed "startx" it took me to an environment with several terminal windows
Click to expand...

Interesting - that sounds like Tiny Window Manager (twm) -- did it look like this? (Link): Tiny Window Manager (twm)

This (generally?) means that you have not set anything in your $HOME directory .xinitrc file. For XCFE4 - my .xinitrc file looks like this:

Code: 
$ cd $HOME
$ cat .xinitrc
. /usr/local/etc/xdg/xfce4/xinitrc
$

NOTE: There is a (SPACE) between the period "." and the first "/"

You can see the .xinitrc settings in the FreeBSD Handbook: (Link): FreeBSD Handbook

lightdm is (also) going to look at this file to understand how to start your "X Windows" session.
 
(ALSO IMPORTANT) - DO NOT enable lightdm in /etc/rc.conf until you have "startx" working. This is because until startx works -- lightdm is definitely NOT going to work :cool: !

And ya - getting a completely black unusable screen at boot/login time (can be) a result of lightdm going "Uh.. I don't know what to do!"

The FreeBSD handbook should be clearer about this (IMO).
 
You must log in or register to reply here.
Back
Top