KMS Not Working For Nvidia GT 1030 (F96CE_XFCE_FUSILLI-4.4)

[AQUAR]

I always seem to be in trouble getting native monitor screen resolution when using puppies.

For bionic pup and fossapup I had to ditch my old amd graphics card and use the newer NVidea GT103 graphics card.
Here KMS is working and the nouveau drivers (both kernel and userspace) are loaded.

But with FUSILLI I am back with no KMS taking place and the VESA driver loaded, meaning the graphics card outputs are not detected by xrandr (just set to default) and no native resolution available. Modelines don't work when paired to default outputs.

Is the nouveau driver included with FUSILLI?

Note I am only a little bit familiar with linux.

[nilsonmorales]

Hello and welcome, could you be more specific please, what puppy are you using with fusilli?, did you compile fusilli by your self in fossa?
I think the video driver comes with the kernel not with the effects, are your puppies bionic and fossa 32 or 64 bits?, there's a Fusilli 4.4 with the kernel 6.0.12FP if this dont work you can try changing the kernel, is in the zdrv.sfs in a frugal install

[AQUAR]

Hi nilsonmorales,

Just using the one from Distributions - Puppy Derivatives (F96CE_XFCE_FUSILLI-4.4.iso).
The recent puppies I try are all 64 bit versions.
Fossapup64 is working great for me as I prefer the non-persistence frugal character for certain online actions (Ditto for Bionic64).

With F96CE_XFCE_FUSILLI-4.4 I don't need to do nomodeset or nouveau.modeset=0 as I don't get a black screen on booting, like I did with bionic or fossa64 when using the older AMD GPU (HD5670).
That bit is different, as the HD5670 graphics card just won't work unless KMS is disabled, and then the graphics driver for X is set to VESA with non-specific outputs set to "default".
Strangely on an even older AMD GPU (HD 3000 series) it boots fine with KMS loading both the appropriate kernel driver and the X driver (giving the opportunity to define modelines for the GPU outputs (DVI-1 and HDMI-1).

With the GT103 Nvidea GPU the kernel Nouveau driver is loaded but alas the X server is stuck on the VESA driver (unlike fossa64 where the X server Nouveau driver is loaded instead of the VESA driver). So I am thinking is not a kernel issue but some issue preventing X loading the Nouveau driver (blacklisted or missing), but I am still poor in trouble shooting these issues.

Will try some things I came across from the past experiences - look at the log file, try forcing with nouveau.modeset=1, look if its blacklisted, but nothing much deeper than that.
I do know that I have to get it to load a proper driver (not VESA) if I am to get a native monitor screen resolution for my system.

Don't know how to change the kernel unless its a simple swap of the zdrv.sfs file (are different ones are available for F96CE_XFCE_FUSILLI-4.4 - guess I could try the one from fossa64).

Cheerio,

Aquar

[AQUAR]

Instead of the FUSILLI derivative I thought to try the latest F96-CE_4 release (in case it was an issue with the derivative).
But the same issues in getting it to co-operate with the nvidea GT103 graphics card.

From dsmeg we have "nouveau: probe of 0000:01:00.0 failed with error -38"
No idea what error 38 is and dr google is no help, but obviously if the probe of whats in this PCIe slot fails then that is bad.
Trying to force nouveau just kills the puppy OS.

Other issue is that shutting down / rebooting this release is broken on my PC (just gives a flashing cursor).

So I downloaded "huge-5.4.53-fossapup64.tar.bz2" and tried to use the built in kernel replacement program (didn't work - probably user error).
Instead I replaced the F96-CE_4 kernel and kernel modules manually with those in "huge-5.4.53-fossapup64.tar.bz2".
Also disabled ydrv but will see what happens when I include it.

Now F96-CE_4 works fine with the nouveau drivers loaded automatically and providing the desired native resolution (1920 x 1080).

Can only assume a nooby believe that this kernel 6 version doesn't play nicely with my GPU card.
Maybe the gurus here can shed some light on this (even know of a fix/tweak when compiling this kernel).

Hope the above helps those with low cost nvidea GPU's and want to try F96-CE_4 (its seems nicer than fossapup64).

[AQUAR]

Just to conclude the exercise to get a usable screen resolution with f96CE-XFCE-FUSILLI and an Nvidea GT103 GPU PCIE card.

I tried huge-5.4.70-rt40-fossapup64.tar.bz2 (latest 5 kernel in the repository for fossa pup I could find) on both F96-CE_4 and f96CE-XFCE-FUSILLI.
As far as I can tell its all good with F96-CE_4 but no go with f96CE-XFCE-FUSILLI.
With f96CE-XFCE-FUSILLI the rendering is totally broken and the OS locks up requiring a hard reboot (used XORGWIZARD on boot to change various settings but to no avail).

From other linux forums I noticed some talk about Kernel 6.2 with shutdown/reboot issues when using Nvidea graphics cards - rather similar to what I experienced with f96CE-XFCE-FUSILLI.
This specifically related to the nouveau drivers, with the same messages shown in dmesg as I got, but didn't notice any resolutions for the issue.

I suppose I could try Nvidea drivers instead of the nouveau ones, but no time to play some more for now (and I am liking F96-CE_4 with kernel 5.4.7).

All good - learned a few more things about finding my way in linux (used MacPup long time ago).
Need to eventually shift from windows 7 to linux, as win 7 its becoming too deprecated (even firefox is on its last leg with win 7).
Hate the way Microsoft is going with windows 11, and the wife's laptop with windows 10 on it is a pain to retain user control (especially the nagging to "upgrade").

[rockedge]

@AQUAR You could try to swap the kernel fdrv SFS for F96CE-XFCE-FUSILLI and F96-CE_4 with a different one for an experiment.

There is a possibility to swap just the fdrv and try different ones. Find the kernel combination that works and take that fdrv from the working combination, make sure it's named correctly to be used by the system during system start (boot), and start up the system. There is a chance that you'll find a combination of the kernel components and fdrv that will do what you expect it too.

Kernel collection and other components -> https://rockedge.org/kernels/

[AQUAR]

@rockedge

Interesting - I will experiment along the suggested approach and see what happens.
I remembered that there is a readme file on the puppy iso that explains the various .sfs files, so had a look at that.
So, fdrv.sfs overrides some modules in zdrv.sfs, and since those may relate to drivers then swapping fdrv makes experimental sense.

Will report success or failure in case it might helps some other puppy user.

As quick first try!
Since I already had the fdrv that came with 5.4.70 (a combination that works) I tried that first, but same result (stuck on vesa).
So I mounted this 5.4.70 fdrv version and compared it to the one that comes with F96CE.
I note that fdrv has a lib folder with drivers that are not present in zdrv (so its additive and necessary for lots of hardware).
Both have the Nvidea folder associated with the GT 103 GPU (Nvidea's GP108 code - which I looked up before).
Will experiment some more.
Any harm if I try drivers supplied with a later kernel (in case some driver issue was resolved later on)?

[rockedge]

@AQUAR The fdrv contains the firmware components so finding one that has the drivers that the kernel modules can use is the key.

Older huge Puppy Linux kernels and some of the newer versions have the firmware directory included in the zdrv along with the kernel modules but it's best to first focus on the fdrv for this experiment.

[AQUAR]

@rockedge

Thanks, just happen to see what you were pointing out whilst I was giving it a try.
I edited the earlier post accordingly when I saw your response.

[AQUAR]

Doing the opposite viz, keeping fdrv from F96CE but using zdrv from huge-5.4.70-rt40, then F96CE also uses the Nouveau driver.
Unsurprisingly, since when comparing the driver binaries for Nvidea's GP108 based GPU's that came with F96CE with those from huge-5.4.70-rt40, they are identical.
Kind of suggests I need to look at later kernel modules rather than earlier ones, instead of trying to find a nouveau driver that works with kernel 6.0.12 (as in F96CE_4 latest release).

I see from rockedge's repository that there are F96CE compiles with later kernels, so will try one of them.
Possibly a zdrv.sfs from even more recent kernels found in rockedge's repository?

[AQUAR]

The experiment was a good idea, but unfortunately after trying many fdr.sfs from working combinations, we get no dice with any kernel later than 5.
The firmware blobs in fdr.sfs that come with K5 seem to be the same as the ones with K6, at least the ones I compared.

Even tried the propriety Nvidia driver version recommended for the GT 103 (Pet install from fossa repository), it too makes no difference (and the install lists missing dependencies?).
The install did blacklist the nouveau driver, and added to the menu "Nvidia Xserver settings) that does not respond with anything.

So for F96-CE_4 with kernel 6 and up I am back to the same old struggle with this current Nvidea graphics card that I had with my AMD graphics card (if I wish to go K6), viz vesa driver for the Xserver giving low screen resolution.

F96-CE_4 with kernel 5 is all good and F96-CE_XFCE_Fusilli-4.4 graphics needs more than the vesa driver can provide in order to be usable.

[AQUAR]

With BookwormPup and Vanilla Dpup, the GP108 firmwares associated with the Nvidia GT1030 are found and loaded to provide a functional nouveau driver.
When I compare the GP108 firmwares folder in their fdrv.sfs, I note that the firmwares set for F96-CE_4 C is incomplete, so I now get those dmesg error messages about not finding the firmwares needed by nouveau.

However, when I swapped out the fdrv,sfs with the one from Vanilla Dpup, I still get the same dmesg error messages, even though the needed firmwares are available.
Based on some of the comments about kernels (in other threads), I take it that the early K6 version that comes with F96-CE_4 is probably the root cause, and consequently why none of the fdrv.sfs swaps I've tried earlier worked.
I am assuming here that these firmwares are extracted binaries from Nvidia drivers and aren't specific to k6 versions (read that somewhere!).

[mikewalsh]

@AQUAR :-

The experiment was a good idea, but unfortunately after trying many fdr.sfs from working combinations, we get no dice with any kernel later than 5.

So stick with the 5-series. I would. I don't worry about security bugs'n'stuff that are highly unlikely to come near my domestic, single-user computer running an oddball OS. Doubtless others will think me stupid, and are rolling their eyes in amazement at a forum staff member who DOESN'T recommend the very newest of everything all the time to the community. I can't help that. That's just me, I'm afraid. I use - and do - whatever works for ME.....and try to help out others in the community in whatever ways I can.

(I don't insist that's the way things SHOULD be done. I merely report what functions for my use-case, along with mention of possible risk should anyone wish to try it themselves).

~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~

I have k5.4.53 from the original FP64-9.5, running in Tahrpup64 (a 10-yr old Puppy), Bionicpup (a 6-yr old Puppy), and, of course, Fossapup itself. My "daily driver" - Xenialpup64 (an 8-yr old) - is a real "Frankenpup"......for want of a better term! Here, I'm running Oz's k6.1.92, along with a glibc 'upgrade' from the original 2.23 to Fossa's 2.31. This kernel is very responsive here, and appears to be super-stable (perhaps because this particular kernel branch is the same one being considered for SLTS status as was mentioned the other day)..? No idea. All I know is it's rock-solid here. Works for me.

Oz also helped me get suspend under control - hardware-related, I suspect - with a wee script in /root/Startup. Otherwise, the HP will suspend fine, but then won't recover the next time I 'wake things up". Which is, um, unusual..... Seems like it might be another 6-series quirk, 'cos she's fine if I leave her on any 5-series.

Tahrpup64 is running "official", so is stuck on that kernel. Same with Bionicpup64. (More to the point, I just can't be arsed to re-compile the damn thing again...) Xenialpup64, I re-built back in the early summer, and left it on "nouveau". At least that way, I can experiment with different kernels without all that display malarky..!!

Mike.

[AQUAR]

So stick with the 5-series. I would.

Mike.

Yes, nothing wrong with using K5 for F96-CE_4 and it has now become my new Puppy for financial type activities, as my browser needs are met and all is running very stable.
IMHO security wise:
Pros: security through obscurity, non persistence on shutdown, only online for a very short time, and physically unconnected when not being used.
Cons: being root when connected (but risk is very low when used minutes per week), potential man in the middle sneaks into puppy distro's.

Was using Fossapup64, but I have scripts to open encrypted password protected files in a terminal. These have symlinks on the pinboard, but I couldn't obfuscate these by changing the default icon into something less tell tale (won't accept any .png from the icon's folder). It does work with F96-CE_4, so here the icons on the symlinks have a different optics to its real purpose.
These shenanigans are also about security as are hard coded web links and browser settings that are just sufficient to connect to my online accounts.

[mikewalsh]

@AQUAR :-

....security through obscurity....

Heh. Um; yeeees.....

Granted, this has almost been a 'mantra' of the Linux community for long enough. Granted, too, that while there is nothing like the quantity of Linux malware out there in the wild, it DOES exist. And as desktop Linux slowly & steadily increases its market share, that quantity will gradually increase, too.

Most Linux malware still tends to target server and enterprise set-ups more than home users. Linux is a very secure system by default IF used correctly & properly, but 100% secure? That's a pipe-dream. My own view has always been simple:-

"What man can invent, man can circumvent..."

You must credit the hackers/malware authors/bad actors with being at LEAST as intelligent as the people writing the very code they're attempting to break into. This is as true today as it's ever been.

Bad actors are almost always financially motivated. Stat. If they figure it's worth their while.....they WILL "go for it".

========================

Here in the Puppy community, many have long taken the view that Puppy is secure by default due to her oddball construction, and loading into RAM from 'read-only' files. I still think that certain aspects of Puppy's functionality ARE as secure as possible.....but as for "un-hackable", mmm; nah. See above.

At the point when Puppy is fully up-and-running, you need to realise that she is presenting the exact same system file-hierarchy as every other distro out there. And those 'bad actors' are undeniably getting cleverer & cleverer by the day.

It's probably more awkward to "hack" Puppy than most, especially if you don't 'save' at session's end OR don't run with a 'save' in the first place. But I suspect we've lulled ourselves into a false sense of security.....to say she's totally secure is, I think, deluding ourselves. Those 'read-only', 'live' sessions aren't uncrackable.......they just need more work to breach. And bad actors are nothing if not persistent.

Security is an on-going process. You don't just "install & forget" it. Doesn't work like that. Malware constantly evolves, so countermeasures need to do the same.

And there's ONE variable that no amount of software can account for, or mitigate. It's usually between the seat-back and the keyboard.....

Mike.

[AQUAR]

@mikewalsh

Yep - agree totally - no such thing as perfection. (256 bit AES encryption is pretty close until quantum computing becomes a practical reality).
I should know, having spend many years on this beast called RMA (Reliability Maintainability Availability).
My biggest (and last) software application to do with RMA was written in turbo pascal for windows, it was about solving a bunch of non linear differential equations (Kolmogorov equations).

This particular puppy is for a single use purpose only and without ongoing saves to a save file (been like that since MACPup).
Even remastered to delete many builtin apps that are not relevant to this purpose (no need for rubix cube!).

There are/were small portable linux distro's specifically for enhanced secure internet communications created by the DOD.
I forget what it was called, but would you trust the DOD?

Still use windows 7, but the wife let in ransomware (the in between the back of the seat and the keyboard), hence I bought her a laptop with win 10 in S mode - now she can't install apps anymore from the world wide web.
Not bothered with ransomware though (all my OS systems are regularly imaged and each has a clone that I can swap in).