Xenialpup64 CE 7.5 / 25 Nov 2017

Message

p310don · #481 Post by **p310don** » Thu 23 Nov 2017, 12:56

Are you using the 32bit version of the NVIDIA package?

No. The .run file is the correct one. It compiles the 64bit driver.

rcrsn51 · #482 Post by **rcrsn51** » Thu 23 Nov 2017, 13:06

When the installer asks about installing the OpenGL libs, you should say no.

p310don · #483 Post by **p310don** » Thu 23 Nov 2017, 13:29

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.

666philb · #484 Post by **666philb** » Thu 23 Nov 2017, 13:47

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)

jamesbond · #485 Post by **jamesbond** » Thu 23 Nov 2017, 14:13

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.

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.

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.

Is there a performance overhead of running 32bit wine with 32bit compatibility layer that would cause such a massive drop in performance?

No.

I'll try 64bit wine and see if that plays differently.

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.

bigpup · #486 Post by **bigpup** » Thu 23 Nov 2017, 14:21

the game plays like molasses

What is the game????

jamesbond · #487 Post by **jamesbond** » Thu 23 Nov 2017, 15:26

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 · #488 Post by **jamesbond** » Fri 24 Nov 2017, 11:33

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:

Code: Select all

echo "blacklist nouveau" > /etc/modprobe.d/nouveau.conf
echo /usr/lib32 >> /etc/ld.so.conf

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:

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 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:

Code: Select all

cd /tmp
sb2dir.sh nvidia-340.104
rox nvidia-340.104

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:

Code: Select all

dir2pet nvidia-340.104

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.

s243a · #489 Post by **s243a** » Fri 24 Nov 2017, 15:14

jamesbond 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.

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.sh

bigpup · #490 Post by **bigpup** » Fri 24 Nov 2017, 18:02

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?

666philb · #491 Post by **666philb** » Fri 24 Nov 2017, 18:24

Thanks everyone!

it's been a long time coming .....
xenialpup64 final is now available. new link on first post

p310don · #492 Post by **p310don** » Fri 24 Nov 2017, 22:01

Thanks Phil.

I knew you'd do this. Been seriously working on getting stuff to work on the last version, and now you go and put up a new one! Lucky I learnt some stuff.

Time to start afresh

666philb · #493 Post by **666philb** » Fri 24 Nov 2017, 22:43

hi p310don,

it's worth trying the 340 driver from quickpet again as it was compiled against this kernel

Billtoo · #494 Post by **Billtoo** » Sat 25 Nov 2017, 00:12

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.

jamesbond · #495 Post by **jamesbond** » Sat 25 Nov 2017, 00:37

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?

It's about "how to build a Nvidia driver pet, using sandbox".

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.

Something wrong with the driver pets already in Quickpet?

At the time of wrigin, from what I understand, it was not compiled against the same version of kernel in 7.0.8.6.
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.

bigpup · #496 Post by **bigpup** » Sat 25 Nov 2017, 02:22

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.

bigpup · #497 Post by **bigpup** » Sat 25 Nov 2017, 03:19

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.

mavrothal · #498 Post by **mavrothal** » Sat 25 Nov 2017, 06:25

666philb wrote:Xenialpup64 CE 7.5
built with woofCE testing

Congratulations!!!
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.

s243a · #499 Post by **s243a** » Sat 25 Nov 2017, 09:26

I just did a fresh install on a virtualbox on windows 8,1. A window pops up with the following error mesage:

"pmcputemp-0.63

unfortunately does not work on your system

(c) Michael Amadio

2015

GPLv2
"

I'm not sure if it has anything to do with xenialpup or not.

Billtoo · #500 Post by **Billtoo** » Sat 25 Nov 2017, 12:30

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

(old)Puppy Linux Discussion Forum

(old)Puppy Linux Discussion Forum

Xenialpup64 CE 7.5 / 25 Nov 2017

Xenialpup64 CE 7.5

Re: Xenialpup64 CE 7.5

Xenialpup64 CE 7.5