No. The .run file is the correct one. It compiles the 64bit driver.Are you using the 32bit version of the NVIDIA package?
Xenialpup64 CE 7.5 / 25 Nov 2017
I have some success to report.
Using the getnvidia.pet method loads the nvidia driver, as well as creating a .pet and .sfs.
The loaded driver does not work, and gives me the errors mentioned previously. Rebooting with a vanilla save file, I blacklisted the nouveau module and then installed the nvidia-glx-340.104-k4.9.58.sfs file created by the installer. Reboot and voila. Something is working. glxgears works as it should as does mpv.
However, my game in wine is still terrible. I don't know how to measure FPS, but I can almost count them, it's that slow.
So I'm not sure now whether I have an nvidia driver problem, or a wine configuration problem.
Note, I have tried bigpup's suggestion of unticking sync to vblank. Makes no difference.
Is there a performance overhead of running 32bit wine with 32bit compatibility layer that would cause such a massive drop in performance? I'll try 64bit wine and see if that plays differently.
Using the getnvidia.pet method loads the nvidia driver, as well as creating a .pet and .sfs.
The loaded driver does not work, and gives me the errors mentioned previously. Rebooting with a vanilla save file, I blacklisted the nouveau module and then installed the nvidia-glx-340.104-k4.9.58.sfs file created by the installer. Reboot and voila. Something is working. glxgears works as it should as does mpv.
However, my game in wine is still terrible. I don't know how to measure FPS, but I can almost count them, it's that slow.
So I'm not sure now whether I have an nvidia driver problem, or a wine configuration problem.
Note, I have tried bigpup's suggestion of unticking sync to vblank. Makes no difference.
Is there a performance overhead of running 32bit wine with 32bit compatibility layer that would cause such a massive drop in performance? I'll try 64bit wine and see if that plays differently.
hi p310don,
the problem with installing the 340 driver is that if you choose to install the 32bit compatibility libs it overwrites the 64bit ones in /usr/lib. as it installs the main driver to /usr/lib64 however in xenial this is a symlink to /usr/lib newer nvidia drivers install the 32bit libs to /usr/lib/i386. this was why you were getting wrong elf class errors.
with getnvidia the .pet it produces might work but the .sfs probably won't although i don't think that getnvidia makes the 32bit libs.
the 340 driver in quicket is built against xenialpups release kernel which is slightly different from the one you are using, and the driver may work with the release iso. (coming soon)
the problem with installing the 340 driver is that if you choose to install the 32bit compatibility libs it overwrites the 64bit ones in /usr/lib. as it installs the main driver to /usr/lib64 however in xenial this is a symlink to /usr/lib newer nvidia drivers install the 32bit libs to /usr/lib/i386. this was why you were getting wrong elf class errors.
with getnvidia the .pet it produces might work but the .sfs probably won't although i don't think that getnvidia makes the 32bit libs.
the 340 driver in quicket is built against xenialpups release kernel which is slightly different from the one you are using, and the driver may work with the release iso. (coming soon)
Bionicpup64 built with bionic beaver packages http://murga-linux.com/puppy/viewtopic.php?t=114311
Xenialpup64, built with xenial xerus packages http://murga-linux.com/puppy/viewtopic.php?t=107331
Xenialpup64, built with xenial xerus packages http://murga-linux.com/puppy/viewtopic.php?t=107331
Which is why in my manual method (a few posts before) I specified --compat32-libdir=lib32. This will tell the installer to install it in /usr/lib32; which you can then access by adding "/usr/lib32" to /etc/ld.so.conf.666philb wrote:the problem with installing the 340 driver is that if you choose to install the 32bit compatibility libs it overwrites the 64bit ones in /usr/lib. as it installs the main driver to /usr/lib64 however in xenial this is a symlink to /usr/lib newer nvidia drivers install the 32bit libs to /usr/lib/i386. this was why you were getting wrong elf class errors.
wine may or may not be built with OpenGL support. You need to find glu32.dll.so inside the wine.sfs. If this file exists, your wine should be able to use the 32-bit libGL.so library, as above.
No.Is there a performance overhead of running 32bit wine with 32bit compatibility layer that would cause such a massive drop in performance?
Don't bother unless the game you're trying to run is a 64-bit Windows program. 64-bit wine only runs Win64 apps; it doesn't run old Win32 apps. And AFAIK, it's still a bit on the rough side.I'll try 64bit wine and see if that plays differently.
Fatdog64 forum links: [url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Latest version[/url] | [url=https://cutt.ly/ke8sn5H]Contributed packages[/url] | [url=https://cutt.ly/se8scrb]ISO builder[/url]
I was about to suggest to using sandbox.sh to do the manual process and then use dir2sfs to pack it up. Then I booted xenialpup in qemu and found that sandbox.sh isn't working
I ported sandbox.sh to Woof-CE about two years ago and announced it in website last year: http://blog.puppylinux.com/?viewDetailed=00015, because somebody asked me about it.
Anyway, it's broken for now. I'm not sure how long it has been broken; nobody reported (or I was not paying attention - been away for awhile), or apparently it's not popular enough, which is a pity, because it can be very useful for cases like this.
I've traced the "brokenness" problem in xenialpup and found out the reason: the topmost branch of aufs (the "rw" branch ==> /initrd/mnt/tmpfs/pup_rw) is not listed in /proc/mounts. I was running in RAM (no savefile/savedir) when testing this.
There is nothing I can do to fix this - the fix must come from initrd. It looks like a bug from this side of the pond because I can see that /initrd/mnt/tmpfs is indeed inside /proc/mounts, but /initrd/mnt/tmpfs/pup_rw (which is the aufs top-layer) is not.
EDIT: Actually sandbox.sh works. The above problem only happens when booting with pfix=ram (no savefile). It still qualify as bug - which, now as I remember it - has been there from day one.
EDIT: another thing - /tmp doesn't work from within sandbox. That's because in Xenialpup, /tmp is a symlink. The solution is - as soon as you're inside sandbox, just do "rm /tmp" and "mkdir /tmp". That should do the trick.
I ported sandbox.sh to Woof-CE about two years ago and announced it in website last year: http://blog.puppylinux.com/?viewDetailed=00015, because somebody asked me about it.
Anyway, it's broken for now. I'm not sure how long it has been broken; nobody reported (or I was not paying attention - been away for awhile), or apparently it's not popular enough, which is a pity, because it can be very useful for cases like this.
I've traced the "brokenness" problem in xenialpup and found out the reason: the topmost branch of aufs (the "rw" branch ==> /initrd/mnt/tmpfs/pup_rw) is not listed in /proc/mounts. I was running in RAM (no savefile/savedir) when testing this.
There is nothing I can do to fix this - the fix must come from initrd. It looks like a bug from this side of the pond because I can see that /initrd/mnt/tmpfs is indeed inside /proc/mounts, but /initrd/mnt/tmpfs/pup_rw (which is the aufs top-layer) is not.
EDIT: Actually sandbox.sh works. The above problem only happens when booting with pfix=ram (no savefile). It still qualify as bug - which, now as I remember it - has been there from day one.
EDIT: another thing - /tmp doesn't work from within sandbox. That's because in Xenialpup, /tmp is a symlink. The solution is - as soon as you're inside sandbox, just do "rm /tmp" and "mkdir /tmp". That should do the trick.
Fatdog64 forum links: [url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Latest version[/url] | [url=https://cutt.ly/ke8sn5H]Contributed packages[/url] | [url=https://cutt.ly/se8scrb]ISO builder[/url]
Typing this from Xenialpup64 7.0.8.6 with NVIDIA driver running. So this works.
Preparation
=======
1. Make sure you have downloaded devx.sfs, kernel-source.sfs, and the correct version of NVIDIA driver for Linux 64-bit (open terminal, type "lspci" and find the version of the NVIDIA card/chip inside your PC, and use this figure out the version of the driver you need).
2. Put these files in some partition (or USB drive) which you can access later on.
3. I tested this on a machine with 8GB RAM. If you have anything less see below.
Creating the driver
============
1. Boot without savefile (with pfix=ram if needed)
2. Once booted, open terminal. Type:
3. Reboot. Xenialpup will ask you to create a savefile. Do what it says. Create a savefile. Note: savefile, not savedir. I only tested this step with a savefile. Use an normal (unencrypted savefile), again, this is because I've only tested with that.
4. You will need to create at least 512MB savefile. 1GB is plentiful.
5. Reboot, using the savefile you create in step 4 (if you multiple savefiles).
6. You should now be back in the low-resolution desktop; because we have disabled nouveau in step 2. If you're still in hi-res desktop, something is wrong, so re-start the process from #1.
7. sfs_load your kernel and devx.
6. open terminal. Start sandbox.sh by typing "sandbox.sh". Choose all layers.
7. Once inside sandbox, type "rm /tmp; mkdir /tmp" to remove the /tmp symlink and create a proper /tmp directory (see previous post about the bug).
8. Open another terminal (I will call this as terminal #2, while the terminal that runs sandbox is terminal #1).
9. From this terminal #2, copy the NVIDIA driver you downloaded before to /mnt/sb/sandbox/tmp (you can also use Rox to copy it if it makes your more comfortable - but you still need to have terminal #2 open for later).
10. Inside terminal #1, do this:
When it asks you to install 32-bit libs, answer "Y" (yes) unless you don't need it. ("Yes" is the default).
When it asks you if you want to run nvidia-xconfig, answer "N" (no - which is the default).
Wait until it says that the driver has been installed. Leave terminal #1, there do not do anything else there (definitely don't close it).
11. Inside terminal #2, do this:
That 340.104 is a number that represents your own NVIDIA driver. I use that number because that's the version of NVIDIA that I use. You can use another number. But you **must** provide a number there (dir2pet needs it).
12. The previous step will open a rox filer folder. You need to remove stuff from this folder.
13. These are the stuff you need to remove (all relative to the folder you open in step 11, not from your own system)
a) etc/ld.so.cache
b) lib/modules/4.9.58/modules*. Note: delete all the modules* files, but keep the "kernel" folder. Very important: do not delete lib/modules/4.9.58/kernel and everything else underneath it.
c) delete that "tmp" folder
d) delete var/cache folder. Or if you feel like it, just delete that entire "var" folder.
OK clean up is done.
If you make a mistake and delete things you shouldn't, no problem. Just delete the entire /tmp/nvidia-340.104 folder, and re-start from step 11.
14. Go back to terminal #2. Run:Remember, your 340.104 may be different, it's what you specified previously in step 11.
You will now go through the process of creating a pet package. Follow the prompt as usual. If you're not sure on how to create a pet package, then you can read for it in the forum.
15. At the end of the run, you will find nvidia-340.104.pet inside /tmp. (the numbers, again, depends on what you specified in step 11). Copy this .pet file safely somewhere.
If you want to be safe, you can also copy the entire nvidia-340.104 folder somewhere for safekeeping too. (or even keep a copy of the original un-deleted folder from step 11, so you can repeat this process as many times as you want).
16. When everything is done, type "exit" in terminal #1. This will end sandbox session and you're back in normal terminal.
17. From terminal #2, you can also now safely "rm -r /tmp/nvidia-340.104" that you created before.
18. Final step: install the pet you created in step 15. And the reboot. You should be running the full NVIDIA driver in all its glory. You can launch "nvidia-settings" to change its configuration.
If you want to use it with wine, you probably need to run "ldconfig" after you load the 32-bit sfs and wine.sfs.
______________
If you have less-endowed machine in terms of RAM, you can use rw-sandbox.sh instead of sandbox.sh. rw-sandbox.sh uses a image file to keep its contents instead of RAM. The rest of the procedure is the same.
EDIT: Additional info on step 10.
Preparation
=======
1. Make sure you have downloaded devx.sfs, kernel-source.sfs, and the correct version of NVIDIA driver for Linux 64-bit (open terminal, type "lspci" and find the version of the NVIDIA card/chip inside your PC, and use this figure out the version of the driver you need).
2. Put these files in some partition (or USB drive) which you can access later on.
3. I tested this on a machine with 8GB RAM. If you have anything less see below.
Creating the driver
============
1. Boot without savefile (with pfix=ram if needed)
2. Once booted, open terminal. Type:
Code: Select all
echo "blacklist nouveau" > /etc/modprobe.d/nouveau.conf
echo /usr/lib32 >> /etc/ld.so.conf
4. You will need to create at least 512MB savefile. 1GB is plentiful.
5. Reboot, using the savefile you create in step 4 (if you multiple savefiles).
6. You should now be back in the low-resolution desktop; because we have disabled nouveau in step 2. If you're still in hi-res desktop, something is wrong, so re-start the process from #1.
7. sfs_load your kernel and devx.
6. open terminal. Start sandbox.sh by typing "sandbox.sh". Choose all layers.
7. Once inside sandbox, type "rm /tmp; mkdir /tmp" to remove the /tmp symlink and create a proper /tmp directory (see previous post about the bug).
8. Open another terminal (I will call this as terminal #2, while the terminal that runs sandbox is terminal #1).
9. From this terminal #2, copy the NVIDIA driver you downloaded before to /mnt/sb/sandbox/tmp (you can also use Rox to copy it if it makes your more comfortable - but you still need to have terminal #2 open for later).
10. Inside terminal #1, do this:
Code: Select all
cd /tmp
sh NVIDIA-* -x
cd NVIDIA-*
./nvidia-installer -a -ui=none --no-x-check --compat32-libdir=lib32
When it asks you if you want to run nvidia-xconfig, answer "N" (no - which is the default).
Wait until it says that the driver has been installed. Leave terminal #1, there do not do anything else there (definitely don't close it).
11. Inside terminal #2, do this:
Code: Select all
cd /tmp
sb2dir.sh nvidia-340.104
rox nvidia-340.104
12. The previous step will open a rox filer folder. You need to remove stuff from this folder.
13. These are the stuff you need to remove (all relative to the folder you open in step 11, not from your own system)
a) etc/ld.so.cache
b) lib/modules/4.9.58/modules*. Note: delete all the modules* files, but keep the "kernel" folder. Very important: do not delete lib/modules/4.9.58/kernel and everything else underneath it.
c) delete that "tmp" folder
d) delete var/cache folder. Or if you feel like it, just delete that entire "var" folder.
OK clean up is done.
If you make a mistake and delete things you shouldn't, no problem. Just delete the entire /tmp/nvidia-340.104 folder, and re-start from step 11.
14. Go back to terminal #2. Run:
Code: Select all
dir2pet nvidia-340.104
You will now go through the process of creating a pet package. Follow the prompt as usual. If you're not sure on how to create a pet package, then you can read for it in the forum.
15. At the end of the run, you will find nvidia-340.104.pet inside /tmp. (the numbers, again, depends on what you specified in step 11). Copy this .pet file safely somewhere.
If you want to be safe, you can also copy the entire nvidia-340.104 folder somewhere for safekeeping too. (or even keep a copy of the original un-deleted folder from step 11, so you can repeat this process as many times as you want).
16. When everything is done, type "exit" in terminal #1. This will end sandbox session and you're back in normal terminal.
17. From terminal #2, you can also now safely "rm -r /tmp/nvidia-340.104" that you created before.
18. Final step: install the pet you created in step 15. And the reboot. You should be running the full NVIDIA driver in all its glory. You can launch "nvidia-settings" to change its configuration.
If you want to use it with wine, you probably need to run "ldconfig" after you load the 32-bit sfs and wine.sfs.
______________
If you have less-endowed machine in terms of RAM, you can use rw-sandbox.sh instead of sandbox.sh. rw-sandbox.sh uses a image file to keep its contents instead of RAM. The rest of the procedure is the same.
EDIT: Additional info on step 10.
- Attachments
-
- shot.png
- (130.34 KiB) Downloaded 174 times
Last edited by jamesbond on Sat 25 Nov 2017, 07:23, edited 1 time in total.
Fatdog64 forum links: [url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Latest version[/url] | [url=https://cutt.ly/ke8sn5H]Contributed packages[/url] | [url=https://cutt.ly/se8scrb]ISO builder[/url]
I love sandbox.sh. I hope the ports get fixed in other versions of puppy For us non linux experts it is so much easier to build packages using sandbox.shjamesbond wrote:I was about to suggest to using sandbox.sh to do the manual process and then use dir2sfs to pack it up. Then I booted xenialpup in qemu and found that sandbox.sh isn't working
I ported sandbox.sh to Woof-CE about two years ago and announced it in website last year: http://blog.puppylinux.com/?viewDetailed=00015, because somebody asked me about it.
Anyway, it's broken for now. I'm not sure how long it has been broken; nobody reported (or I was not paying attention - been away for awhile), or apparently it's not popular enough, which is a pity, because it can be very useful for cases like this.
I've traced the "brokenness" problem in xenialpup and found out the reason: the topmost branch of aufs (the "rw" branch ==> /initrd/mnt/tmpfs/pup_rw) is not listed in /proc/mounts. I was running in RAM (no savefile/savedir) when testing this.
There is nothing I can do to fix this - the fix must come from initrd. It looks like a bug from this side of the pond because I can see that /initrd/mnt/tmpfs is indeed inside /proc/mounts, but /initrd/mnt/tmpfs/pup_rw (which is the aufs top-layer) is not.
EDIT: Actually sandbox.sh works. The above problem only happens when booting with pfix=ram (no savefile). It still qualify as bug - which, now as I remember it - has been there from day one.
EDIT: another thing - /tmp doesn't work from within sandbox. That's because in Xenialpup, /tmp is a symlink. The solution is - as soon as you're inside sandbox, just do "rm /tmp" and "mkdir /tmp". That should do the trick.
jamesbond
Nice post!
Thanks!!
A little confused.
Is the post all about how to build a Nvidia driver pet, using sandbox, or is it about correcting some problem with the normal way of building the driver, using Getnvidia?
Something wrong with the driver pets already in Quickpet?
Nice post!
Thanks!!
A little confused.
Is the post all about how to build a Nvidia driver pet, using sandbox, or is it about correcting some problem with the normal way of building the driver, using Getnvidia?
Something wrong with the driver pets already in Quickpet?
The things they do not tell you, are usually the clue to solving the problem.
When I was a kid I wanted to be older.... This is not what I expected
YaPI(any iso installer)
When I was a kid I wanted to be older.... This is not what I expected
YaPI(any iso installer)
Thanks everyone!
it's been a long time coming .....
xenialpup64 final is now available. new link on first post
it's been a long time coming .....
xenialpup64 final is now available. new link on first post
Bionicpup64 built with bionic beaver packages http://murga-linux.com/puppy/viewtopic.php?t=114311
Xenialpup64, built with xenial xerus packages http://murga-linux.com/puppy/viewtopic.php?t=107331
Xenialpup64, built with xenial xerus packages http://murga-linux.com/puppy/viewtopic.php?t=107331
hi p310don,
it's worth trying the 340 driver from quickpet again as it was compiled against this kernel
it's worth trying the 340 driver from quickpet again as it was compiled against this kernel
Bionicpup64 built with bionic beaver packages http://murga-linux.com/puppy/viewtopic.php?t=114311
Xenialpup64, built with xenial xerus packages http://murga-linux.com/puppy/viewtopic.php?t=107331
Xenialpup64, built with xenial xerus packages http://murga-linux.com/puppy/viewtopic.php?t=107331
Xenialpup64 CE 7.5
I installed to a 32gb flash drive for use on my Lenovo desktop:
root# inxi -bw
System: Host: puppypc19319 Kernel: 4.9.58 x86_64 (64 bit) Desktop: JWM 2.3.7 Distro: xenialpup64 7.5
Machine: Device: desktop System: LENOVO product: 7491B8U v: ThinkCentre M58e serial: MJ01509
Mobo: LENOVO model: N/A serial: INVALID BIOS: LENOVO v: 5HKT39AUS date: 06/17/2009
CPU: Dual core Intel Core2 Duo E8400 (-MCP-) speed/max: 2003/3003 MHz
Graphics: Card: NVIDIA GF108 [GeForce GT 430]
Display Server: X.org 1.18.4 driver: nvidia tty size: 107x27 Advanced Data: N/A for root
Network: Card: Marvell 88E8057 PCI-E Gigabit Ethernet Controller driver: sky2
Drives: HDD Total Size: 351.5GB (0.4% used)
Weather: Conditions: 46 F (8 C) - Mostly Cloudy Time: November 24, 7:00 PM EST
Info: Processes: 166 Uptime: 47 min Memory: 279.0/3952.0MB Client: Shell (bash) inxi: 2.3.8
root#
The Nvidia driver was just released today.
I added some applications with PPM.
Looks good so far,
Thanks.
root# inxi -bw
System: Host: puppypc19319 Kernel: 4.9.58 x86_64 (64 bit) Desktop: JWM 2.3.7 Distro: xenialpup64 7.5
Machine: Device: desktop System: LENOVO product: 7491B8U v: ThinkCentre M58e serial: MJ01509
Mobo: LENOVO model: N/A serial: INVALID BIOS: LENOVO v: 5HKT39AUS date: 06/17/2009
CPU: Dual core Intel Core2 Duo E8400 (-MCP-) speed/max: 2003/3003 MHz
Graphics: Card: NVIDIA GF108 [GeForce GT 430]
Display Server: X.org 1.18.4 driver: nvidia tty size: 107x27 Advanced Data: N/A for root
Network: Card: Marvell 88E8057 PCI-E Gigabit Ethernet Controller driver: sky2
Drives: HDD Total Size: 351.5GB (0.4% used)
Weather: Conditions: 46 F (8 C) - Mostly Cloudy Time: November 24, 7:00 PM EST
Info: Processes: 166 Uptime: 47 min Memory: 279.0/3952.0MB Client: Shell (bash) inxi: 2.3.8
root#
The Nvidia driver was just released today.
I added some applications with PPM.
Looks good so far,
Thanks.
- Attachments
-
- screenshot.jpg
- (46.75 KiB) Downloaded 717 times
-
- screenshot2.jpg
- (90.94 KiB) Downloaded 741 times
It's about "how to build a Nvidia driver pet, using sandbox".bigpup wrote:A little confused.
Is the post all about how to build a Nvidia driver pet, using sandbox, or is it about correcting some problem with the normal way of building the driver, using Getnvidia?
If you just want to install Nvidia driver from source (not making a pet, just install it), then you can skip all the parts that says "sandbox" in it.
Specifically, only do steps:
- Preparation
- 1,2,3,4,5,6,7, 9 (copy your NVIDIA-* to /tmp instead of /mnt/sb/sandbox/tmp), and 10.
That's it.
At the time of wrigin, from what I understand, it was not compiled against the same version of kernel in 7.0.8.6.Something wrong with the driver pets already in Quickpet?
But Phil has fixed it in his next release, so there is no need to do the manual method anymore. Good to have it for reference, though.
Fatdog64 forum links: [url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Latest version[/url] | [url=https://cutt.ly/ke8sn5H]Contributed packages[/url] | [url=https://cutt.ly/se8scrb]ISO builder[/url]
Xenialpup64 7.5
Frugal + save folder.
Did several downloads and installs to make sure was not bad download and install.
Tried this with both of the Quickpet Nvidia drivers.
Same results.
Tried to install the Nvidia drivers offered in Quickpet.
After the download, install, and reboot.
Pup-Sysinfo reports the Nvidia driver is being used.
Something is wrong.
glxgears will not run
nvidia x server settings will not run.
Get this error.
See image attached.
Trying to run nvidia-xconfig just totally breaks it.
Running xorgwizard
Selecting nvidia and correct settings.
Has no affect on solving the problems.
Frugal + save folder.
Did several downloads and installs to make sure was not bad download and install.
Tried this with both of the Quickpet Nvidia drivers.
Same results.
Tried to install the Nvidia drivers offered in Quickpet.
After the download, install, and reboot.
Pup-Sysinfo reports the Nvidia driver is being used.
Something is wrong.
glxgears will not run
nvidia x server settings will not run.
Get this error.
See image attached.
Trying to run nvidia-xconfig just totally breaks it.
Running xorgwizard
Selecting nvidia and correct settings.
Has no affect on solving the problems.
- Attachments
-
- capture15499.jpg
- (25.16 KiB) Downloaded 1776 times
The things they do not tell you, are usually the clue to solving the problem.
When I was a kid I wanted to be older.... This is not what I expected
YaPI(any iso installer)
When I was a kid I wanted to be older.... This is not what I expected
YaPI(any iso installer)
Xenialpup64 7.5
Frugal + save folder.
Used:
Getnvidia-1.0-64.pet to install Getnvidia program.
Nvidia-Linux-X86_64-384.98.run package.
Used them to:
Built, installed, and now using this driver.
nvidia 384.98
glxgears works OK.
Nvidia X server settings works OK.
So, this way works for installing the Nvidia driver.
Frugal + save folder.
Used:
Getnvidia-1.0-64.pet to install Getnvidia program.
Nvidia-Linux-X86_64-384.98.run package.
Used them to:
Built, installed, and now using this driver.
nvidia 384.98
glxgears works OK.
Nvidia X server settings works OK.
So, this way works for installing the Nvidia driver.
The things they do not tell you, are usually the clue to solving the problem.
When I was a kid I wanted to be older.... This is not what I expected
YaPI(any iso installer)
When I was a kid I wanted to be older.... This is not what I expected
YaPI(any iso installer)
Re: Xenialpup64 CE 7.5
Congratulations!!!666philb wrote:Xenialpup64 CE 7.5
built with woofCE testing
You would want to formally announce that in http://blog.puppylinux.com/
add a patch to update http://puppylinux.com/index.html#download to point to them
and alert BK to also put it in his blog.
== [url=http://www.catb.org/esr/faqs/smart-questions.html]Here is how to solve your[/url] [url=https://www.chiark.greenend.org.uk/~sgtatham/bugs.html]Linux problems fast[/url] ==
Xenialpup64 CE 7.5
I used the UEFI Installer - Flash Drives to install to a 16gb SDHC card
for use on my Imac
root# inxi -bw
System: Host: puppypc6788 Kernel: 4.9.58 x86_64 (64 bit) Desktop: JWM 2.3.7
Distro: xenialpup64 7.5
Machine: Device: desktop System: Apple product: iMac8 1 v: 1.0 serial: W8811GXLZE2
Mobo: Apple model: Mac-F226BEC8 v: PVT serial: 1
UEFI: Apple v: IM81.88Z.00C1.B00.0802091538 date: 02/09/08
CPU: Dual core Intel Core2 Duo E8135 (-MCP-) speed/max: 1600/2400 MHz
Graphics: Card: Advanced Micro Devices [AMD/ATI] RV610/M74 [Mobility Radeon HD 2400 XT]
Display Server: X.org 1.18.4 drivers: ati,radeon (unloaded: modesetting,fbdev,vesa)
tty size: 80x26 Advanced Data: N/A for root
Network: Card-1: Broadcom BCM4321 802.11a/b/g/n driver: b43-pci-bridge
Card-2: Marvell 88E8058 PCI-E Gigabit Ethernet Controller
driver: sky2
Drives: HDD Total Size: 266.1GB (3.4% used)
Weather: Conditions: 46 F (8 C) - light showers rain Time: November 25, 7:16 AM EST
Info: Processes: 176 Uptime: 53 min Memory: 411.3/3949.1MB
Client: Shell (bash) inxi: 2.3.8
root#
I installed applications with PPM
Only problem so far is that JWMDesk Manager has the up-arrow bug when
editing a file with geany the up-arrow starts Mtpaint.
************************************************
Edit: I changed kernels:
root# uname -ra
Linux puppypc6788 4.9.65-x86_64 #1 SMP Fri Nov 24 21:09:37 EST 2017 x86_64 x86_64 x86_64 GNU/Linux
root#
The up-arrow isn't a problem because the 8 on the numeric keypad works like the up-arrow normally works and the up-arrow is great for taking screenshots
for use on my Imac
root# inxi -bw
System: Host: puppypc6788 Kernel: 4.9.58 x86_64 (64 bit) Desktop: JWM 2.3.7
Distro: xenialpup64 7.5
Machine: Device: desktop System: Apple product: iMac8 1 v: 1.0 serial: W8811GXLZE2
Mobo: Apple model: Mac-F226BEC8 v: PVT serial: 1
UEFI: Apple v: IM81.88Z.00C1.B00.0802091538 date: 02/09/08
CPU: Dual core Intel Core2 Duo E8135 (-MCP-) speed/max: 1600/2400 MHz
Graphics: Card: Advanced Micro Devices [AMD/ATI] RV610/M74 [Mobility Radeon HD 2400 XT]
Display Server: X.org 1.18.4 drivers: ati,radeon (unloaded: modesetting,fbdev,vesa)
tty size: 80x26 Advanced Data: N/A for root
Network: Card-1: Broadcom BCM4321 802.11a/b/g/n driver: b43-pci-bridge
Card-2: Marvell 88E8058 PCI-E Gigabit Ethernet Controller
driver: sky2
Drives: HDD Total Size: 266.1GB (3.4% used)
Weather: Conditions: 46 F (8 C) - light showers rain Time: November 25, 7:16 AM EST
Info: Processes: 176 Uptime: 53 min Memory: 411.3/3949.1MB
Client: Shell (bash) inxi: 2.3.8
root#
I installed applications with PPM
Only problem so far is that JWMDesk Manager has the up-arrow bug when
editing a file with geany the up-arrow starts Mtpaint.
************************************************
Edit: I changed kernels:
root# uname -ra
Linux puppypc6788 4.9.65-x86_64 #1 SMP Fri Nov 24 21:09:37 EST 2017 x86_64 x86_64 x86_64 GNU/Linux
root#
The up-arrow isn't a problem because the 8 on the numeric keypad works like the up-arrow normally works and the up-arrow is great for taking screenshots
- Attachments
-
- screenshot2.jpg
- (56.45 KiB) Downloaded 1591 times
-
- screenshot.jpg
- (54.93 KiB) Downloaded 5595 times