Solved I learned something interesting this week.

C

Cedric62

Well, I recently learned something very interesting, and even though the following is probably something very basic to most people reading this, I thought that I would share it anyway, in case it might help someone else in the future.

Recently, I broke my desktop login screen by upgrading my nvidia driver to a newer driver which was not compatible with my video card. So instead of seeing my normal login screen, I was stuck at a black screen with a frozen cursor in the upper left hand corner.

After unsuccessfully monkeying around in a second terminal (Ctrl+Alt+F2) I decided that my only option was to do a fresh reinstallation of the operating system, and to restore all of my packages and settings from a backup I had made earlier.

At first, this new installation of FreeBSD seemed to work well, and I did not have any problems until after I tried to restore from a backup I had created just a few days prior. At this point I should probably mention that I have a line within the script that I use to restore my backup, and this particular line tells the script to use a text file list to reinstall all of my packages. The line I’m referring to is shown below.
Code: 
pkg install $(cat /diskbkp/backup/package_list.txt)

(Above line from my restore script file used to reinstall packages)

The problem with the above line is that it doesn’t necessarily download and install exactly the same version of the package which was in use when the above package_list.txt text file was first created. Instead, it seems to download and install whatever package name happens to be residing in the repository. (If I’m wrong about this, please let me know.)

In my case, this was a problem because, originally my installation of FreeBSD was using Nvidia driver 580.119.02, but when I invoked the package upgrade command, my Nvidia driver got upgraded to driver-580-580.142, and this particular driver did not seem to work with my video card (NVIDIA GeForce GT 1030).

Also, once again when I tried to restore my packages using the list of packages on contained within package_list.txt, the newer incompatible driver got installed, instead of the original driver which had been in use when I created my backup. Hmmm...So after restoring from my backup, I was still looking at a black screen instead of my normal login screen.

Luckily I had another internal hard drive sitting on in a box, and this particular drive just happened to have a nearly identical installation of FreeBSD on it using the correct Nvidia driver. I had forgotten about this drive, and really hadn’t planned on using as a backup to restore my system.

I then used the dd command to clone the installation of FreeBSD contained on my spare drive onto drive ada0 inside my computer, and when I rebooted, I now had a working installation that was only about a month or two out of date.

However, I realized that if I were to issue the package upgrade at this point, then I would probably destroy this installation as well. So the next thing I did was to issue the below command to create a backup of all of my installed packages, and also of all of their dependencies as well.

Code: 
pkg create -a -o /diskbkp/backup/var/cache/pkg/

(diskbkp is the mount point for a second internal hard drive inside my computer)

Running the above command took approximately half an hour, and when it was finished, the backup pkg folder turned out to be considerably larger than the original working pkg folder located at /var/cache/pkg.

Next I changed the line within my restore script file into the below line, so that it would no longer referenced the list of packages contained within my text file, and it would instead just add all of the packages contained within the backup pkg folder.
Code: 
pkg add /diskbkp/backup/var/cache/pkg/*

As a test, I did another fresh reinstallation of FreeBSD on my spare hard drive, I ran my restore script, and it worked! All of my packages were reinstalled from my backup pkg folder I had created on /diskbkp, and I was not stuck with upgrading to the newer Nvidia driver. This was a huge achievement for a numpty like me.

At this point, I no longer invoke the package upgrade command without first doing a dry run and diverting the output of the command to a text file in my temp folder. Something similar

Code: 
pkg upgrade -n >/home/Steven/Temp/packages.txt

That way I can now look through the new text file I have just created, and then I can upgrade packages manually, or create a new package upgrade list without any mentions of Nvidia packages in it.

Well, I realize that this is differently not the most efficient way to get things done, and eventually I will have to come up with a better strategy, (such as snapshots) but for the time being it seems to work for me.
 
While I don't understand the problem in detail, I think you should go source-based for everything because of specific needs that aren't covered by a default installation of binary programs and drivers. Is it a good idea to rely o pkg and the pkgdb if you have hardware-specific demands?
 
It might be worth mentioning that doing pkg upgrade without a y (for yes) flag, will also show what packages will be upgraded. Then, you don't have to bother with the dry run, you'll see that what packages will be upgraded and you're asked if you should proceed and you can choose no.
There are a lot of threads about Nvidia on the forums--one of the Nvidia developers is a regular here--and they've explained why nvidia updates may break things. (Too lazy to search right now, but if you do a forum search for nvidia posts by T-Aoki, you'll probably find something useful.)

For what it's worth--aside from the bectl solution I'd mentioned before, giving you a way to painlessly revert to your earlier system--I've found, more or less through fumbling around, that I can---almost always--fix an Nvidia issue after an upgrade by running
Code: 
 portmaster nvidia-drm-kmod
(After first making sure my ports tree is up to date with the latest). As for packages, I use latest rather than quarterly, which may cause some of my nvidia problems.
 
scottro said:
Are you familiar with bectl and/or beadm? It's a good way to be able to get back into your system as long as it boots. To, as usual, spam my own page, https://srobb.net/fbsdbe.html. This is assuming you installed on ZFS.
Click to expand...
I guess it has become a right of passage discovering the 'time travel' capabilities of ZFS. There are those that are enlightened, and there are those that have yet to discover the better way.
 
MG said:
While I don't understand the problem in detail, I think you should go source-based for everything because of specific needs that aren't covered by a default installation of binary programs and drivers. Is it a good idea to rely o pkg and the pkgdb if you have hardware-specific demands?
Click to expand...
I've only been using FreeBSD for approximately three months, and prior to that, most of my experience was limited to using Ubuntu on a home based desktop PC. So at this point my knowledge is still somewhat limited, but my knowledge is slowly growing. By source based, do you mean I should get my Nvidia driver directly from the Nvidia website? Sorry, still grasping the fundamentals, and maybe I will try hitting the handbook again later this week.
 
scottro said:
Are you familiar with bectl and/or beadm? It's a good way to be able to get back into your system as long as it boots. To, as usual, spam my own page, https://srobb.net/fbsdbe.html. This is assuming you installed on ZFS.
Click to expand...
No, I didn't pick ZFS during my initial setup, because based upon my limited understanding of things, it appeared that my computer's hardware might not meet the minimum requirements for mirroring, so I went with UFS instead. So far I haven't encountered a problem in which FreeBSD refused to boot, and it appears that my most recent problem was really more of a desktop problem, and not so much of an operating system one. I was able to get into another terminal by pressing Ctl+Alt+F2, but at that time I didn't really know what to do, so I didn't really accomplish very much, even though I could still get to the command line. However, this time I think that I have a better idea of what to do should this problem reoccur in the future.
 
Alain De Vos said:
Just don't specify exact version ie ncurses-15358._bis_ter. Just install ncurses ? Not.
Click to expand...
Below is a sample of the original text file I used to use with my script in order to restore my system. The below nvidia packages listed in my text file don't seem to make any mention of version number, so I'm not sure what is happening?

Code: 
lightdm
lightdm-gtk-greeter
lightdm-gtk-greeter-settings
links
mc
nemo
neofetch
numlockx
nvidia-drm-kmod
nvidia-settings
nvidia-xconfig
okular
peazip-qt5
pfetch
pinentry-gnome
pinta
pkg
pwcview
 
Alain De Vos said:
neofetch will reviel which video card you have.
then you can install video drivers & xorg & desktop with "pkg install"
Click to expand...
So I guess that I have GPU 108 and my card is GT 1030

Code: 
root@Asus:/home/Simon # neofetch
```                        `       Simon@Asus
  ` `.....---.......--.```   -/    ----------
  +o   .--`         /y:`      +.   OS: FreeBSD 15.0-RELEASE-p8 amd64
   yo`:.            :o      `+-    Uptime: 20 mins
    y/               -/`   -o/     Packages: 1225 (pkg)
   .-                  ::/sy+:.    Shell: sh
   /                     `--  /    Resolution: 1920x1080
  `:                          :`   DE: Xfce 4.20
  `:                          :`   WM: Xfwm4
   /                          /    Theme: Adwaita [GTK3]
   .-                        -.    Icons: elementary-xfce [GTK3]
    --                      -.     Terminal: xfce4-terminal
     `:`                  `:`      Terminal Font: Monospace 12
       .--             `--.        CPU: Intel Pentium Gold G5400 (4) @ 3.700GHz
          .---.....----.           GPU: GP108 [GeForce GT 1030]
                                   Memory: 2213MiB / 8075MiB
 
Cedric62 said:
No, I didn't pick ZFS during my initial setup, because based upon my limited understanding of things, it appeared that my computer's hardware might not meet the minimum requirements for mirroring, so I went with UFS instead. So far I haven't encountered a problem in which FreeBSD refused to boot, and it appears that my most recent problem was really more of a desktop problem, and not so much of an operating system one. I was able to get into another terminal by pressing Ctl+Alt+F2, but at that time I didn't really know what to do, so I didn't really accomplish very much, even though I could still get to the command line. However, this time I think that I have a better idea of what to do should this problem reoccur in the future.
Click to expand...
I have used OpenZFS 2.0 on 32-bit FreeBSD 12 with only 2GB of installed RAM and mirrored 32GB SSDs. There were three machines in the battery powered cluster and they ran just fine despite the documentation at the time saying 64-bit and 8GB RAM minimum. Back then during COVID, ZFS just needed a few sysctl.conf tweaks. A lot of old code was developed on 32-bit systems, but some maintainers (not necessarily FreeBSD maintainers) don't want to test on 32-bit so they put discouragements in the Make file to dissuade the casual tinkerer from trying it. I have no idea if OpenZFS 2.4 runs on 32-bit, and I am not likely to try it. The point I am making is that it if the software originated on a platform when the system RAM was measured in Megabytes it is worth experimenting.
 
Cedric62 I have that same card. I use latest for pkgs. As I mentioned above, I have almost always been able to fix Nvidia issues by, first updating my ports tree, then using portmaster to build nvidia-drm-kmod. (Though I do have to use the nvidia-580 stuff, as mentioned in /usr/ports/UPDATING's entry of 20260327. Our card is an older card,so we have to use the 580 version.
 
scottro said:
first updating my ports tree, then using portmaster to build nvidia-drm-kmod.
Click to expand...
Alright, but I think that I've been using packages since I started using FreeBSD this past February. Is it a wise idea to suddenly switch to ports at this point?
 
vmb said:
I have used OpenZFS 2.0 on 32-bit FreeBSD 12 with only 2GB of installed RAM and mirrored 32GB SSDs. There were three machines in the battery powered cluster and they ran just fine despite the documentation at the time saying 64-bit and 8GB RAM minimum. Back then during COVID, ZFS just needed a few sysctl.conf tweaks. A lot of old code was developed on 32-bit systems, but some maintainers (not necessarily FreeBSD maintainers) don't want to test on 32-bit so they put discouragements in the Make file to dissuade the casual tinkerer from trying it. I have no idea if OpenZFS 2.4 runs on 32-bit, and I am not likely to try it. The point I am making is that it if the software originated on a platform when the system RAM was measured in Megabytes it is worth experimenting.
Click to expand...
Well, I have a lot to learn. Also, if I decide to go with ZFS at this point, does that mean doing a complete reinstall, and repartitioning? I suppose that I could do a ZFS installation on my spare drive when I have some time.
 
Cedric62 said:
Well, I have a lot to learn. Also, if I decide to go with ZFS at this point, does that mean doing a complete reinstall, and repartitioning? I suppose that I could do a ZFS installation on my spare drive when I have some time.
Click to expand...

To benefit from ZFS Boot Environments it is probably better to start again.

If 'spare drive' means a drive that you can be swapped in as a boot drive, then you could do a fresh ZFS install on that. If the original drive can be connected after the new install so that both drives are present, it can be mounted to transfer data from it to your new ZFS pool.
 
Cedric62, sorry I wasn't very clear. I use packages almost entirely. However, as I've mentioned, somewhere on this forum there are explanations as to why Nvidia packages sometimes don't work, usually because they will be out of sync--I forget if it's more common with setting pkg to latest or quarterly. Anyway, when I use portmaster to build nvidia-drm-kmod, it will pull in any necessary other ports--for example, if the driver is also outdated, portmaster will bring in the driver as well.
Generally, it is NOT a good idea to mix ports and packages, but I've found, at least in my experience, that doing it with Nvidia stuff, can often fix issues if the pkg version isn't working and is, again in my experience, worth a try if the pkg upgrade doesn't work well.

Again, going by my experience, having one or two pkgs that you install with ports won't break things. Generally, however, it's best to stick with one or the other, as on occasion, the versions can be different and use different dependencies. I don't feel I've explained very well, so feel free to ask any further questions about it.
 
You must log in or register to reply here.
Back
Top