Discussion, talk and tips
https://forum.puppylinux.com/
Been having problems with bionicpup64 not getting the internet.
Tested out ubuntu 21.10, and it gets the internet just fine.
How would I get the kernel for ubuntu 21.10, and put it into bionicpup64.
Assume that I would have to compile the kernel.
And I am confused on what parts of the kernel is needed.
Appreciate any advice you can give me on this.
A quick search reveals that Ubuntu 21.10 has kernel 5.15. You could possibly try one of Oz’s 5.15 kernels out. Someone else would need to verify this, as I’m using 5.4.65 in my bionic and I have no experience with any of the newer ones
Use the change_kernels program to change the kernel.
viewtopic.php?t=317
This kernel will probably give you what you are looking for, maybe!
viewtopic.php?t=5079
Use the Ubuntu derivative one.
Been having problems with bionicpup64 not getting the internet.
Some specific details would help.
What specifically happens when you specifically do what?
What is the specific hardware?
WIFI or wired connection?
Changing the kernel may or may not fix the problem.
You may also need to add firmware.
Quite likely to be a missing firmware problem rather than a missing driver in the kernel - unless your wifi is very new - remember that BionicPup is 18.04 vintage so quite long in the tooth.
To test - replace the fdrv.sfs with one from a Pup where your wifi works or get the complete firmware package from:
http://www.fishprogs.software/puppy/firmware-sfs/
and use that.
dmesg | grep firmware
in a terminal will also indicate if it is a firmware problem.
Bonicpup64 does not have a fdrv.sfs file.
So how would I go about fixing bonicpup64, so it can get the internet.
@Lassar:-
Try out Fossapup's k5.4.53 kernel.
This HP Pavilion desktop of mine is one of these modern oddities that has wireless in addition to ethernet. Now, normally I run with ethernet, but I've always had an issue in Bionicpup64 where ethernet simply refuses to function. I'm not going into details, except to say that we tried everything to get it functional, but.....nada. Zilch. Zip. No dice.
I also run an install of Fossapup64. This connects quite happily via ethernet, but I found out, experimenting - as you do - that the combo wireless/Bluetooth chip also works fine on wireless with k5.4.53. So; I decided to try swapping Bionic's k4.19.23 for Fossapup's k5.4.53. Whaddya know? Fully functional wireless.....
This was after ozsouth had actually compiled me a driver + firmware to work with Bionic's default kernel, but I like experimenting, and the results speak for themselves.
Take copies of Fossapup's vmlinuz, zdrv & fdrv. Rename these to:-
Zdrv - zdrv_bionicpup64_8.0.sfs
Fdrv - fdrv_bionicpup64_8.0.sfs
Vmlinuz - no change
Remove Bionic's vmlinuz & zdrv (put them somewhere safe, in case you want to replace them later). Now, move the re-named Fossapup copies to where you've just removed Bionic's original ones from.
Now, re-boot. Check whatever network connection tool you use.....and see if you have 'wlan0' now showing. (This assumes you're using 'net.ifnames=0' on the kernel line; otherwise, it'll be something like 'enpsxxxx.....whatever'. Or perhaps that's only the ethernet connections. Not sure about this.) Anyway, if you now have a wireless adapter showing, you ought to be able to set up a connection without too much trouble.
Might help, might not. It should do, unless you've got an extremely recent wireless adapter there...
Mike. 
How about answering my questions, so we can understand exactly what the problem is 
Tried "dmesg | grep firmware"
Is dmseg spelled right?
At the terminal get dmseg not found.
@Lassar :
Had the same problem with no Internet in Bionicpup64.
As Mikewalsh adviced:
But just the fdrv is needed.
I Just placed the fdrv_fossapup64_9.5.sfs from extracted Fossapup64 to the Bionicpup64 and renamed fdrv_fossapup64_9.5.sfs to fdrv_bionicpup64_8.0.sfs.
Now i have working Internet.
Simple Procedure.
@backi :-
Hm. Interesting. I wasn't aware the frdv could be used on its own.....I was under the impression it needed to be kept with the kernel it was originally built for.
Ya live & learn...
Mike. 
The Fossapup64 9.5 fdrv SFS only has the firmware in it.
so, it is only adding firmware, maybe not already there.
But it is firmware that was available 1.5 years ago.
Could have anything in the fdrv SFS.
Looking in a few of the latest Puppy versions.
Firmware seems to be all that is in their fdrv sfs.
I know that the OP is old but...
I haven't found any working 5.4 kernel for bionicpup64. As the 5.4.5 on the huge kernel page doesn't have matching kernel sources ("rt3" version is not present); hence I can't use getnvidia to compile the nvidia driver.
And if I use the 5.4.65 kernel (mentioned before) - getnvidia can't produce a driver, it gets stuck, same thing for fossa's.
The original problem is the following: bionicpup64 + any nvidia driver supported by my card (gtx 650) + any chrome based browser = jelly effect on any page. Solvable by force composition (as was suggested by 666philb here https://forum.puppylinux.com/viewtopic.php?t=1238) The downsize of this approch is too diverse to talk about. It's not very important, rather annoying.
The interesting aspect is that doesn't happen in fossa, using the very same nvidia driver and chrome browser.
The jelly effect cause is the adaptive clock behaviour - imho. It remains on low speeds, even if chrome requests more processing power.
If the kernel swap will not work, I'll give up.
(let the base of discussion be: nvidia driver = 470.86 and chrome >= 104)
@baraka :-
Strange. I know it's an older driver, true, but the supplied 340.108 driver wouldn't work for my Quadro NVS-135m when I bought the refurb'd Dell Latitude last year. This was under Fossapup64.
However, I WAS able to compile the 340 driver myself using getNvidia under Fossa's k5.4.53. For some reason, my own build worked, whereas the 340 driver Phil B had originally packaged for Fossa64 seemed to have half its contents missing.
The supplied 450 driver, on the other hand, has always worked perfectly for my GT 710 in the main HP rig....
Sod's law, ain't it?
Mike. )
Yes, swapping kernel is a great feature, but...
getnvidia script requires a kernel "made" for bionic, and yes, this is not always the case (other distros have no problem, like tahr64).
Even that is not for sure true. All I know is that kernels from the kernel 5 family, in combination with bionic64, I tried 4 or 5 of them, have this peculiarity.
All of this is beside the point. The jelly effect syndrome is old, 18 months and counting.
And I can say for sure, by testing it, bionic64 + 4.19.23 kernel + 340.108 nvidia driver + chrome 104 + gtx 650 = jelly effect.
The mind boggling is this situation: why fossa + 5.4.53 kernel + 470.86 + chrome 104 + gtx 650 doesn't produce the effect and
bionic + 4.19.23 kernel + everything the same = jelly
It must be the 5.4 kernel.
Resons why full composition trick is not great:
- trash completely the vdpau feature, cant be used together
- introduce lagging and a sort of tearing (v-sync related) in some video games or in some hardware accelerated apps.
I'm up too early and haven't had my second cup of coffee. So ignore this if it doesn't make sense.
Two options. If the nvidia binary is NOT kernel specific, you can use the default bionic64 kernel and devx to run getnvidia, then switch.
ozsouth published corresponding kernel sources and headers for (most/all?) hugh-kernels he made. You can find the kernels here, https://archive.org/download/Puppy_Linux_Huge-Kernels and its companion packages here, https://archive.org/download/Puppy_Linux_Huge-Kernels. You can start in the Additional Software Section to find out what kernels he's published, Having picked one you can search the first link for the kernel, then the second link for its companions. If you're not picky, I know that the companions for huge-5.15.50-ubun64oz are located at the other URL.
@mikeslr
Yes, you are wrong, sir! But I can't ignore you. Thx for your effort.
Clarification: nvidia driver can be loaded only if the running kernel and compiling kernel are a match - kernel specific.
Of course I know about those sites. The problem is none of the 5.4's gets along with the getnvidia script.
5.4.5 (the only one made for bionic64) - doesn't have matching kernel sources - the file exists, sure, yet the version doesn't match, kernel is 5.4.5 and sources are 5.4.5-rt3 (or the other way). getnvidia will not put up with it.
5.4.65 (suggested by a previous post, somebody was very happy running bionic64 with it) and 5.4.53 (fossa's) - getnvidia error, something about directory structure.
(the other kernels specially made for bionic64 get along with getnvidia, but none of them is a 5.4)
There are a bunch of 5.4s out there, I tried a few of them, no luck.
And I need a bionic64 5.4.
Other clarification: jelly effect is a cross platform bug. It is present in tahr64, xenial64 and bionic64 with every driver that you'll think about. Evidently, for this specific video card, gtx650.
By sure is related to adaptive clock. It's working, but not how is supposed to.
Only in fossa with the latest driver disappear.
And I'm talking only about clean installs - original files + necessary files for compiling nvidia + chrome.
This is the other link, for related stuff https://archive.org/download/Puppy_Linux_Kernels
Sorry, only being half awake, I didn't catch that your computer is 'allergic' to the 5 series kernels. If you start your search from the 'Kernels' Sub-Section of the Additional Software, you'll find links to 6 series Kernels and their companion Headers and Sources such as this one to ozsouth's 6.1.4-64oz-ao, https://www.forum.puppylinux.com/viewto ... 167#p78167.
And while I don't generally recommend reversions, somewhere on ally's repo you'll find some 3 series kernels with companion headers and sources.
Perhaps a series 4 kernel will work well. Maybe one like huge-4.14.71-bionicpup64.tar.bz2 would work better on this machine. I compiled it with low latency PREEMPT but it works well as a general purpose kernel in Bionic64-8.0. This kernel was compiled in Bionic64 and the kernel sources are here
This one I had good results with on troublesome systems -> huge-5.4.5-bionicpup64.tar.bz2 which is also built for low latency but is not a full real time kernel.
These are here-> https://rockedge.org/kernels/ under the Kernels directory or direct https://rockedge.org/kernels/data/Kernels/64bit/
I WAS able to compile the 340 driver myself using getNvidia under Fossa's k5.4.53.
Hi Mike, I have a D630 almost like yours:
cpu=t7500
ram=4g
video=Quadro NVS-135m
Hoping you will share your driver and tips for using.
Thanks
wizard
@rockedge
Thx. I knew about the site.
5.4.5 doesn't have matching source files - getnvidia says that.
4.14.71 - just finished testing it - no luck, some result - jelly effect.
I'll describe the bug more precisely:
- nvidia x server setting - powemizer tab - 0 1 2 levels for graphics clock (0 lowest speed, 2 fastest)
- random wiki page
- nvidia driver is stuck at level 0, producing the jelly effect. Of course if I access a really graphic intensive url, ex google maps, the driver will jump to the next level and for a short time the jelly effect will disappear.
In fossa and only in fossa (everything else being the same) the level will be up even when I scroll a wiki page, or in another words, it's functioning properly.
@mikeslr
Thx, I'll give a try.
Nevertheless, getnvidia and bionic doesn't match well with kernel equal or beyond 5 if the kernel is not specially made for bionic. The script will break almost for sure.
@wizard
Why waiting?!!
https://forum.puppylinux.com/viewtopic.php?t=123
Why waiting?!!
If it needs to be tweaked or blacklisting needs to be done @mikewalsh will have already worked that out and save me going down that rabbit hole. 
wizard
@wizard :-
Gawd, this is embarrassing.
Looking through things, it appears I instructed getNvidia to create packages for Xenial64's k4.9.58 AND Tahr64's k3.14.79.....but when it came to Fossapup64, I vaguely recall being so annoyed about having to re-build the Nvidia driver package, that I unticked the checkboxes for 'Make SFS' and 'Make .pet'.....simply to speed the process up.
So it seems I don't in fact HAVE any packages for Fossa's k5.4.53. If I had, you'd be more than welcome.... 
I am so sorry, mate. I suppose I could use the Xenial64 package as a template to try and build a .pet for Fossa, but there's no guarantees it would behave itself. There's certain items the script adds-in when you create a package that it apparently doesn't bother with when you're simply doing a direct "build & install".....like the 'pinstall.sh' & 'puninstall.sh' scripts that blacklist or reset the nouveau driver when adding or removing the package.....or another one in /root/Startup that fixes a bunch of things in addition to creating a shed-load of sym-links.
I can certainly try if ya want, but I don't guarantee it'll work the way it should.
Mike. 
@wizard
Here you have the nvidia-glx-340.108-k5.4.53-64.pet https://drive.google.com/file/d/1fxTkrI ... LXrKc/view
If xorg doesn't start then
1) run "xorgwizard" and choose new (or reset) xorg file, something like that
2) run "xwin"
If xorg does start but nvidia driver is not loaded, log out and step 1&2.
@rockedge
Surprisingly even the ancient 340 with fossa's 5.4.53 doesn't produce the jelly effect. Of course that in bionic with the original kernel does.
@wizard :-
Sorry, mate.....the old grey matter's not what it once was..!
I've been reading back over the thread where I "introduced" the D630. I'd forgotten; it was Xenialpup64 where I had all the hassle with the 340.108 driver. As far as Fossa was concerned, the package mentioned above by baraka is what I used myself, and it installed without a murmur of trouble. Ran OOTB, too.....and of course, it explains why I don't have a package for it. Didn't need to build one, after all.
(*shrug*)
Mike.
Used baraka's pet file and went right in without problems. This looks like it solved my issues with browsers locking up the system.
My problem Mike is I know I have stuff, just can't find it. Having 20+ old computers and 20 or more extra hard drives doesn't help either. 
Thanks Guys
wizard
@mikeslr @shinobar
I wonder if someone has asked himself why I didn't use getnvidia in fossa, build the driver under 5.4.53.
Then switch the kernel in bionic with the 5.4.53 and, finally, load the previous obtained driver. (maybe that was the original mikeslr's question, before the second cup of coffee, and I didn't catch it)
Because it doesn't load.
This is a separate bug. In bionic64, any nvidia driver could only be loaded by getnvidia script.
For example, if you have a working nvidia sfs in bionic (by sure) and you attempt to manually load the driver (or simply unload and then load the thing), a window will flash "Nvidia driver is found, but couldn't be loaded, restart blabla".
You'll get an infinite loop, and xorgwizard doesn't fix it. This is happening just in bionic64, thankfully.
As you saw, wizard could load without any fuss an appropiate driver in fossa.
I wonder if shinobar is still visiting this forum?!!
baraka wrote: ↑Wed Jan 25, 2023 3:28 am@mikeslr @shinobar
I wonder if someone has asked himself why I didn't use getnvidia in fossa, build the driver under 5.4.53.
Then switch the kernel in bionic with the 5.4.53 and, finally, load the previous obtained driver. (maybe that was the original mikeslr's question, before the second cup of coffee, and I didn't catch it)
Because it doesn't load.
This instruction set from jamesbond in the old forum might be useful. He walks through the steps to compile an Nvidia driver manually.
If I try to load ANY driver already made, this is what I get in a window (same with the original bionic, in fact with any kernel and the corect driver in bionic):
Code: Select all
The NVIDIA driver is found, but the X-server is not currently using it. You need to restart X to enable the NVIDIA driver.and I can't overpass the situation. (the only way is to let getnvidia handle the first module load)
This is not happening with getnvidia and the other official distros.
If I change the kernel with fossa's kernel, getnvidia will crash with:
Code: Select all
/usr/X11R7/lib No such file or directory.If I try to manually build the driver, following jamesbond post, sandbox.sh command will throw this: (thx @dogcat for the idea)
Code: Select all
mount-FULL: /mnt/sb/fakeroot: wrong fs type, bad option, bad superblock on aufs, missing codepage or helper program, or other error.
Unable to mount aufs br:/mnt/sb/sandbox=rw:Error:=ro:Expected=ro:at=ro:least=ro:6=ro:tokens=ro:for=ro:--checklist,=ro:have=ro:4.=ro:Use=ro:--help=ro:to=ro:list=ro:options.=ro