Page 1 of 1

Kernel Question wrt Debian vs Ubuntu

Posted: Sun Sep 08, 2024 1:24 pm
by AQUAR

Okay, so I spend a few weeks with F96-CE_4 to get it to work on my old desktop with an NVidia GT1030 pcie graphics card.

Eventually had to change to an earlier kernel to get KMS with Nouveau drivers (ended up using huge-5.4.86-slacko64 kernel).
Tried many kernel versions 6 plus from Rockedge's repository but all failed to do KMS with Nouveau, so userspace driver always stuck on VESA (possibly an ACPI issue1).

Anyway I thought I should try BookwormPup since it is Debian based, which from what I have read is more a more "conservative" distro that is less likely to break operations.

Now wrt KMS, BookwormPup with Kernel 6.1.94 works OOTB for me, and even better, I can use it with either the Kernel Modesetting driver or the Nouveau driver (jippy).

So a kind of obvious question, but I am still asking because I am still a linux Noob even after the above sucessfull result with F96-CE_4 (very nice OS):
Is the Debian kernel ,its modules, and system firmwares, compiled with more options or hardware inclusivities than the Ubuntu or Slacko kernel?
Or is kernel 6.1.94 the same kernel 6.1.94 regardless of what distro it is facilitating with only kernel modules or firmwares being different?


Re: Kernel Question wrt Debian vs Ubuntu

Posted: Sun Sep 08, 2024 5:35 pm
by rockedge
AQUAR wrote:

Or is kernel 6.1.94 the same kernel 6.1.94 regardless of what distro it is facilitating with only kernel modules or firmwares being different?

The kernel can be different. The configuration of the kernel for compiling it is what matters. For example I only built a couple of kernels with userspace or huge pages configured to be enabled to build the modules included. The vmlinuz and module SFS go hand in hand for a particular kernel. There is some wiggle room with the firmware SFS and can be switched in and out easier. Older style "huge" kernels had the firmware included with the modules and later were seperated out and the fdrv SFS was now added to make the kernels more modular.

It is possible to look at the kernel's configuration file, which in my collection are called something like this: DOTconfig-6.9.0-x86_64-150824 which looks like this:

Code: Select all

#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
# CONFIG_COMPILE_TEST is not set
# CONFIG_WERROR is not set
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_BUILD_SALT=""
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
CONFIG_HAVE_KERNEL_ZSTD=y
# CONFIG_KERNEL_GZIP is not set
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_KERNEL_ZSTD=y
CONFIG_DEFAULT_INIT=""
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_SYSVIPC_COMPAT=y
CONFIG_POSIX_MQUEUE=y
CONFIG_POSIX_MQUEUE_SYSCTL=y
CONFIG_WATCH_QUEUE=y
CONFIG_CROSS_MEMORY_ATTACH=y
CONFIG_USELIB=y
CONFIG_AUDIT=y
CONFIG_HAVE_ARCH_AUDITSYSCALL=y
CONFIG_AUDITSYSCALL=y

#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_IRQ_EFFECTIVE_AFF_MASK=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_GENERIC_IRQ_MIGRATION=y
CONFIG_HARDIRQS_SW_RESEND=y
CONFIG_GENERIC_IRQ_CHIP=y
CONFIG_IRQ_DOMAIN=y
CONFIG_IRQ_SIM=y
CONFIG_IRQ_DOMAIN_HIERARCHY=y
CONFIG_GENERIC_MSI_IRQ=y
CONFIG_IRQ_MSI_IOMMU=y
CONFIG_GENERIC_IRQ_MATRIX_ALLOCATOR=y
CONFIG_GENERIC_IRQ_RESERVATION_MODE=y
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
# CONFIG_GENERIC_IRQ_DEBUGFS is not set
# end of IRQ subsystem

CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_ARCH_CLOCKSOURCE_INIT=y
CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST_IDLE=y
CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
CONFIG_GENERIC_CMOS_UPDATE=y
CONFIG_HAVE_POSIX_CPU_TIMERS_TASK_WORK=y
CONFIG_POSIX_CPU_TIMERS_TASK_WORK=y
CONFIG_CONTEXT_TRACKING=y
CONFIG_CONTEXT_TRACKING_IDLE=y

#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ_COMMON=y
# CONFIG_HZ_PERIODIC is not set
# CONFIG_NO_HZ_IDLE is not set
CONFIG_NO_HZ_FULL=y
CONFIG_CONTEXT_TRACKING_USER=y
# CONFIG_CONTEXT_TRACKING_USER_FORCE is not set
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_CLOCKSOURCE_WATCHDOG_MAX_SKEW_US=100
# end of Timers subsystem

CONFIG_BPF=y
CONFIG_HAVE_EBPF_JIT=y
CONFIG_ARCH_WANT_DEFAULT_BPF_JIT=y

#
# BPF subsystem
#
CONFIG_BPF_SYSCALL=y
CONFIG_BPF_JIT=y
CONFIG_BPF_JIT_ALWAYS_ON=y
CONFIG_BPF_JIT_DEFAULT_ON=y
CONFIG_BPF_UNPRIV_DEFAULT_OFF=y
# CONFIG_BPF_PRELOAD is not set
CONFIG_BPF_LSM=y
# end of BPF subsystem

CONFIG_PREEMPT_BUILD=y
CONFIG_PREEMPT_BUILD_AUTO=y
CONFIG_HAVE_PREEMPT_AUTO=y
# CONFIG_PREEMPT_NONE is not set
# CONFIG_PREEMPT_VOLUNTARY is not set
# CONFIG_PREEMPT is not set
# CONFIG_PREEMPT_AUTO is not set
CONFIG_PREEMPT_RT=y
CONFIG_PREEMPT_COUNT=y
CONFIG_PREEMPTION=y
CONFIG_SCHED_CORE=y

#
# CPU/Task time and stats accounting
#
CONFIG_VIRT_CPU_ACCOUNTING=y
CONFIG_VIRT_CPU_ACCOUNTING_GEN=y
# CONFIG_IRQ_TIME_ACCOUNTING is not set
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_BSD_PROCESS_ACCT_V3=y
CONFIG_TASKSTATS=y
CONFIG_TASK_DELAY_ACCT=y
CONFIG_TASK_XACCT=y
CONFIG_TASK_IO_ACCOUNTING=y
CONFIG_PSI=y
# CONFIG_PSI_DEFAULT_DISABLED is not set
# end of CPU/Task time and stats accounting

CONFIG_CPU_ISOLATION=y

#
# RCU Subsystem
#
CONFIG_TREE_RCU=y
CONFIG_PREEMPT_RCU=y
# CONFIG_RCU_EXPERT is not set
CONFIG_TREE_SRCU=y
CONFIG_TASKS_RCU_GENERIC=y
CONFIG_TASKS_RCU=y
CONFIG_TASKS_RUDE_RCU=y
CONFIG_TASKS_TRACE_RCU=y
CONFIG_RCU_STALL_COMMON=y
CONFIG_RCU_NEED_SEGCBLIST=y
CONFIG_RCU_BOOST=y
CONFIG_RCU_BOOST_DELAY=500
CONFIG_RCU_NOCB_CPU=y
# CONFIG_RCU_NOCB_CPU_DEFAULT_ALL is not set
CONFIG_RCU_NOCB_CPU_CB_BOOST=y
CONFIG_RCU_LAZY=y
CONFIG_RCU_LAZY_DEFAULT_OFF=y
# end of RCU Subsystem

CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_IKHEADERS=m
CONFIG_LOG_BUF_SHIFT=18
CONFIG_LOG_CPU_MAX_BUF_SHIFT=12
# CONFIG_PRINTK_INDEX is not set
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y

#
# Scheduler features
#
CONFIG_UCLAMP_TASK=y
CONFIG_UCLAMP_BUCKETS_COUNT=5
# end of Scheduler features

CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y
CONFIG_ARCH_WANT_BATCHED_UNMAP_TLB_FLUSH=y
CONFIG_CC_HAS_INT128=y
CONFIG_CC_IMPLICIT_FALLTHROUGH="-Wimplicit-fallthrough=5"
CONFIG_GCC10_NO_ARRAY_BOUNDS=y
CONFIG_CC_NO_ARRAY_BOUNDS=y
CONFIG_GCC_NO_STRINGOP_OVERFLOW=y
CONFIG_CC_NO_STRINGOP_OVERFLOW=y
CONFIG_ARCH_SUPPORTS_INT128=y
CONFIG_CGROUPS=y
CONFIG_PAGE_COUNTER=y
# CONFIG_CGROUP_FAVOR_DYNMODS is not set
CONFIG_MEMCG=y
CONFIG_MEMCG_KMEM=y
CONFIG_BLK_CGROUP=y
CONFIG_CGROUP_WRITEBACK=y
CONFIG_CGROUP_SCHED=y
CONFIG_FAIR_GROUP_SCHED=y
CONFIG_CFS_BANDWIDTH=y
# CONFIG_RT_GROUP_SCHED is not set
CONFIG_SCHED_MM_CID=y
CONFIG_UCLAMP_TASK_GROUP=y
CONFIG_CGROUP_PIDS=y
CONFIG_CGROUP_RDMA=y
CONFIG_CGROUP_FREEZER=y
CONFIG_CGROUP_HUGETLB=y
CONFIG_CPUSETS=y
CONFIG_PROC_PID_CPUSET=y
CONFIG_CGROUP_DEVICE=y
CONFIG_CGROUP_CPUACCT=y
CONFIG_CGROUP_PERF=y
CONFIG_CGROUP_BPF=y
CONFIG_CGROUP_MISC=y
# CONFIG_CGROUP_DEBUG is not set
CONFIG_SOCK_CGROUP_DATA=y
CONFIG_NAMESPACES=y
CONFIG_UTS_NS=y
CONFIG_TIME_NS=y
CONFIG_IPC_NS=y
CONFIG_USER_NS=y
CONFIG_PID_NS=y
CONFIG_NET_NS=y
CONFIG_CHECKPOINT_RESTORE=y
CONFIG_SCHED_AUTOGROUP=y
CONFIG_RELAY=y
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_RD_GZIP=y
CONFIG_RD_BZIP2=y
CONFIG_RD_LZMA=y
CONFIG_RD_XZ=y
CONFIG_RD_LZO=y
CONFIG_RD_LZ4=y
CONFIG_RD_ZSTD=y
CONFIG_BOOT_CONFIG=y
# CONFIG_BOOT_CONFIG_FORCE is not set
# CONFIG_BOOT_CONFIG_EMBED is not set
CONFIG_INITRAMFS_PRESERVE_MTIME=y
CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE=y
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_LD_ORPHAN_WARN=y
CONFIG_LD_ORPHAN_WARN_LEVEL="warn"
CONFIG_SYSCTL=y
CONFIG_HAVE_UID16=y
CONFIG_SYSCTL_EXCEPTION_TRACE=y
CONFIG_HAVE_PCSPKR_PLATFORM=y
CONFIG_EXPERT=y
CONFIG_UID16=y
CONFIG_MULTIUSER=y
CONFIG_SGETMASK_SYSCALL=y
CONFIG_SYSFS_SYSCALL=y
CONFIG_FHANDLE=y
CONFIG_POSIX_TIMERS=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_PCSPKR_PLATFORM=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_FUTEX_PI=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_AIO=y
CONFIG_IO_URING=y
CONFIG_ADVISE_SYSCALLS=y
CONFIG_MEMBARRIER=y
CONFIG_KCMP=y
CONFIG_RSEQ=y
# CONFIG_DEBUG_RSEQ is not set
CONFIG_CACHESTAT_SYSCALL=y
CONFIG_PC104=y
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_SELFTEST is not set
CONFIG_KALLSYMS_ALL=y
CONFIG_KALLSYMS_ABSOLUTE_PERCPU=y
CONFIG_KALLSYMS_BASE_RELATIVE=y
CONFIG_ARCH_HAS_MEMBARRIER_SYNC_CORE=y
CONFIG_HAVE_PERF_EVENTS=y
CONFIG_GUEST_PERF_EVENTS=y

only the actual file is much longer. There can be significant differences in kernels that are the same version source code depending on the configuration choices.

Here is an attached DOT configuration file that are the settings for 6.9.0-rt5 full real time kernel that the woof-CE kernel-kit used to assemble the vmlinuz, kernel-modules SFS (zdrv) and the kernel-firmware (fdrv) for this kernel version.


Re: Kernel Question wrt Debian vs Ubuntu

Posted: Sun Sep 08, 2024 7:45 pm
by dimkr

Kernels are super easy to misconfigure, with over 10k lines of configuration. One mistake and the kernel you build doesn't support some common piece of hardware, has poor battery life, consumes more RAM under typical use or makes everything feel sluggish.

BookwormPup64 uses a kernel derived from the Debian kernel: same source code and almost the same configuration (<1% difference). And it ships with Debian's firmware selection, which is very generous and (unsurprisingly) compatible with this kernel.

It's not very surprising if this kernel works better for you, because there are more eyes looking at it and it has more users, making you less likely to be the first one who meets an unsolved issue.


Re: Kernel Question wrt Debian vs Ubuntu

Posted: Sun Sep 08, 2024 8:06 pm
by mikewalsh

@AQUAR :-

I tend to find that drivers for unsupported cards - like my GT710 - are impossible to compile under any 6-series kernel. I think support for my card was dropped after the 480-series driver, or thereabouts.......but that's plenty new enough for me. I'm not paranoid about it like some, who MUST run the very newest of everything ALL THE TIME.

I believe your card IS still currently supported, however.

I knew shinobar's getNvidia utility didn't work under Bookwormpup64, from reading reports in that Puppy's thread. I also know that Bookwormpup isn't the same as @dimkr 's VanillaDPup, but he's posted frequently in the former Puppy's thread to advise that users really should use the official drivers from the Debian repos. I've tried these in BWP64, but neither driver available even recognises my card. So I dropped back to the modesetting driver, because frankly, it works better for my setup than the VESA drivers. Even nouveau is glitchy for me there. And I'm not buying a newer GPU just to use a newer OS!

This is one of the main reasons I stick with somewhat older Pups. The last Pup where I was successful at compiling the final supported driver for my card was Fossapup64. This uses k5.4.53.

Me, I suspect the reason getNvidia is failing is because of the "usrmerge" stuff being introduced. It's not shinobar's fault, though the only way round the issue would be to re-write the utility all over again. And, although it works really well at what it does, having once compiled & installed the contents of the Nvidia .run file, you can't uninstall it! You can re-compile and install newer drivers over the top of it, but you're basically stuck with it. If I want to revert to the in-built Intel UHD 610 GPU within the CPU, I have to completely rebuild each and every Puppy in the kennels.......and given how highly-customized my Pups are, that's a MAJOR job of work. Not only that, even if you could remove it, certain components of the default OpenGL stack have to be replaced back to their original state, because the Nvidia driver overwrites them with its own proprietary versions. When that happens, they're gone.

I understand where dimkr is coming from with his advice. Since this stuff is installed by the package manager, it can at least be removed again......and I suspect the Debian maintainers are smart enough to realise that original OpenGL components need reinstating again. Doubtless it all happens at the same time. For certain Pups where I use much newer kernels, I simply rebuild and let them use the nouveau driver instead. It's easier, because I can then upgrade kernels as & when I want!

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

As far as the k6.1.94 kernel is concerned, as I understand it's one of the most recent LTS (long-term support) kernels. This would be why they're using it, given that Debian IS all about stability.

(I was reading about this somewhere a couple of weeks ago. There's some organisation connected with the kernel team, - I forget the name - who have stated their intention to make the 6.1-series into what they term an SLTS kernel (Super Long Term Support), with a support window stretching all the way out to 2034!)

Mike. ;)


Re: Kernel Question wrt Debian vs Ubuntu

Posted: Mon Sep 09, 2024 5:42 am
by dimkr

The problem with third party drivers like NVIDIA drivers is that they target specific kernel versions. When they go EOL and the vendor stops updating them, eventually they stop working against newer kernels, so using a different kernel configuration (same version, configured differently) won't help: your only option is to use an old kernel these drivers are compatible with, despite risks like bugs and security issues that still appear in this kernel version.


Re: Kernel Question wrt Debian vs Ubuntu

Posted: Mon Sep 09, 2024 7:30 am
by AQUAR

@rockedge @dimkr @mikewalsh

Thank you all for those generously informative responses, its so refreshing not to be told to RTFM.
I am starting to see the merit and complications of having this flexible linux kernel to create distro's on top of it, but with different target objectives (audience - hardware - experimental - geeky).

Its totally foreign to those coming from Microsoft Windows, where the end-user expectation is simply one of plug and play, even if hardware like the GPU is 20 years old.

If a puppy is Ubuntu based, and I replace its kernel / companion modules / firmwares with the one specifically compiled for the Debian ecosphere, then should I consider it to be neither a Ubuntu base nor a Debian base but a hybrid?
And would not the different kernel compilation settings have the potential to cause operational incompatibilities when doing such brute force kernel swaps - eg an app needing an kernel module available in one but not the other (sorry about my tangential thinking)?

I used slacko's "kernel set" for F96-CE_4 without even realizing this may lead to unintended consequences because of kernel variables.
As far as I can tell it still looks like F96-CE_4, it all still seems to work, gives me stable portable browser ability and most importantly it now likes my GPU card.

I too tried to compile the Nvidia driver so I could have native resolution with F96-CE_4 with the K6 kernel it comes with - let just say that after installing the compiler then make etc it all failed miserably (also tried the pet version). For my needs I just need rendering at 1920 x 1080, so nouveau is perfectly fine for me, the bookworm default mode setting driver is totally new to me (but seems good too).

If k6.1.94 does become SLTS then this bookworm puppy may well be a somewhat longer term puppy for my static usage (financial transactions). Now I will have to take a look at this other debian vanilla flavored puppy (running out of USB flash drives!).


Re: Kernel Question wrt Debian vs Ubuntu

Posted: Mon Sep 09, 2024 7:56 am
by dimkr
AQUAR wrote: Mon Sep 09, 2024 7:30 am

If k6.1.94 does become SLTS

It's not specifically 6.1.94 that is assigned this special "longterm" status but the entire 6.1.x kernel branch. Some people think that "longterm" means "support from hardware vendors" or "guaranteed compatibility with recent applications", but this is wrong. "longterm" means only one thing: there will be more 6.1.x bugfix releases and 6.1.x won't be phased out soon like "stable" kernels, which receive bugfixes only until the next "stable" branch is out.

There is no reason for you to stick with 6.1.94: if you want stability and security, you should update to a later 6.1.x kernel (every time there's a new one, or periodically), with fixes for more bugs and vulnerabilities.

(See https://www.kernel.org/category/releases.html if you want to RTFM :) )


Re: Kernel Question wrt Debian vs Ubuntu

Posted: Mon Sep 09, 2024 8:00 am
by AQUAR
mikewalsh wrote: Sun Sep 08, 2024 8:06 pm

@AQUAR :-

I believe your card IS still currently supported, however.

For certain Pups where I use much newer kernels, I simply rebuild and let them use the nouveau driver instead. It's easier, because I can then upgrade kernels as & when I want!

Mike. ;)

So the K6 kernel that comes with the current F96-CE_4 puppy, might be missing some attributes that are needed for the nouveau driver to work with a still supported GPU?
The Geforce GT1030 is still sold in shops as a low end GPU card, so ought to be supported.


Re: Kernel Question wrt Debian vs Ubuntu

Posted: Mon Sep 09, 2024 9:55 am
by mikewalsh

@AQUAR :-

I wouldn't have thought anything was "missing". The GT1030 is quite an old card by today's standards, and if my calculations are correct has been around since the days of the late 4-series kernels.......maybe even a little longer. So any required "fixes" for the nouveau driver would have been put in place a LONG time ago.

(I was thinking of getting one of these myself a few months back. I'm not a gamer, but I do quite a bit of video-rendering.....and the Openshot & Lightworks video editors will let you "offload" this kind of 'grunt work' to a discrete GPU IF you have one. It does need to be using the official drivers.

But then I thought, why bother? I like my GT710; it's silent - passively-cooled, you see - and it copes happily with what I use it for. And although it's an old architecture, this was a new re-release from Asus, with 4 HDMI ports. It works for me.......but the GT1030 will be 'on the cards' if, as & when it packs up.)

This is the newest driver for your GT1030. I never understand Nvidia's driver numbering system; they'll steadily progress upwards for a while, then suddenly jump back to a much lower number for a few releases, then back to the higher numbers again. Unless those are "LTS" drivers receiving updates; I don't know if Nvidia even DO such a thing.....

https://www.nvidia.com/en-us/drivers/details/230357/

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

AQUAR wrote: Mon Sep 09, 2024 7:30 am

Thank you all for those generously informative responses, its so refreshing not to be told to RTFM.

We like to try and educate if at all possible. We'll not only explain HOW to do stuff.....but where appropriate, explain WHY it's necessary. I do this as and where I sense the OP is curious - and interested - enough to WANT to know.

It's a community here. It's not merely a 'help-desk'. We try to help not only newcomers, but also each other.

Mike. ;)


Re: Kernel Question wrt Debian vs Ubuntu

Posted: Mon Sep 09, 2024 11:21 am
by rockedge
AQUAR wrote:

So the K6 kernel that comes with the current F96-CE_4 puppy, might be missing some attributes that are needed for the nouveau driver to work with a still supported GPU?

We compiled the kernel for release of F96-CE_4 to be as general purpose as possible. At the time the "6" series of kernel was just starting out. There is also the considerations of the size of the firmware module being too large for the target size of the F96-CE_4 ISO so we try to limit the size using a very inexact filtering script.

This is why swapping kernels or just experimenting with swapping the fdrv SFS can bring the desired results, that being the system works like it's been designed too.

I've used a Void Linux kernel extracted for use on KLV's on a F96-CE_4 which worked nicely but really is for experimenting. Most "huge" type kernels built for Puppy Linux will work if put together in the expected modular form in a variety of different Puppy Linux's.

Probably a VoidPup64 stock kernel will work in F96-CE_4 for example. That's the great thing about it.....like the box of chocolates thing...one never knows really what you're going to get...........keeps us on our toes.


Re: Kernel Question wrt Debian vs Ubuntu

Posted: Mon Sep 09, 2024 11:33 am
by AQUAR
mikewalsh wrote: Mon Sep 09, 2024 9:55 am

@AQUAR :-

I wouldn't have thought anything was "missing".
(I was thinking of getting one of these myself a few months back.
This is the newest driver for your GT1030.
https://www.nvidia.com/en-us/drivers/details/230357/
Mike. ;)

I just can't get a handle on why I don't get KMS with Nouveau when using K6 with the Ubuntu based puppies and the GT1030.
I just presumed it was a K6 issue after the experimenting with different K6 kernels, but then with bookworm pup it stuffed that perception.
The nouveau kernel graphics driver is loaded but there is no KMS during boot (tell tale no change in text size during the boot process).
And userspace nouveau seems to have issues with the GPU cards memory address location, so never gets loaded.

Similar issues with the AMD HD5670 that I had in this desktop PC, as it failed to KMS with K4 and above (I did run bionic with the lower vesa resolution for a while, until I got peeved at needing to scroll web pages all the time). Problem could just as likely be hardware related, cause my AMD HD3000 series in an even older desktop pc (core2duo) does KMS better ???.

The GT1030 I bought second hand for just a few dollars along with a few others oldies (junk box at a computer store) this GT1030 is also fanless and has 2GB of DDR5 memory (so its the good version as many have DDR4). I think one of the other ones is a GTX710 with 2 fans and has VGA output too (never fired it up).
You might be disappointed in that it only has 1 HDMI port and one DVI-D port - and during boot only one port can be active and the hardware default is DVI-D if anything is connected to it.
Still a great GPU card for anything but gaming needs.

I tried to compile the NVIDIA-Linux-x86_64-470.223.02.run driver to go with F96-CE_4 but alas I need to give that much more effort.

@dimkr
Rest assured, I also want to read them manuals. Especially if I am pointed to a specific one.
Edit: I read the manual - even I can cope with reading one page on categories of kernel releases.

@rockedge
I like those boxes of chocolates!
Don't mind experimenting - its never a waste of time as you always gain something from just doing things.
Very happy with F96-CE_4 and the slacko K5 - for now my working puppy.
But very motivated to play with the Debian puppies in the mainline distributions.
Especially since OOTB it has IPV6 enabled and gives me 2 graphics drivers to boot.


Re: Kernel Question wrt Debian vs Ubuntu

Posted: Mon Sep 09, 2024 12:23 pm
by mikewalsh

@AQUAR :-

AQUAR wrote: Mon Sep 09, 2024 11:33 am

The GT1030 I bought second hand for just a few dollars along with a few others oldies (junk box at a computer store) this GT1030 is also fanless and has 2GB of DDR5 memory (so its the good version as many have DDR4).

I snagged my Asus GT710 "passive-cooler" right at the start of COVID.....before prices went mental. It's also equipped with GDDR5 (2 GB). I picked it up from Amazon, brand-new, for GBP £36. It's NOT a popular card!

Oh, it could have been a return, it's true.....but I inspected it very carefully when it turned up, and there wasn't a sign of the slightest scratch or anything on the contacts, so I'm inclined to believe it WAS new. I'm no gamer; mine mainly renders short-ish videos (no major stuff here), and for that it's quite happy.

I have to have a low-power card, because this HP desktop rig has a weird, slimline, low-output PSU of only 180W. And upgrades are out of the question, because nobody makes them. (I know. I've investigated thoroughly, believe me). The GT710 draws just 19W, through the PCI-e slot, so it "fit the bill" perfectly for me.

I wouldn't say I'm computing on a shoestring, but I'm definitely scrapping around at the lower end of the spectrum! Can't throw the cash at it like some folks seem to be able to..... :roll:

Mike. ;)


Re: Kernel Question wrt Debian vs Ubuntu

Posted: Tue Sep 10, 2024 12:52 pm
by AQUAR

@mikewalsh

Unless you're into gaming I don't think you are missing out on anything when using older PC's. My friend calls them "boat anchors".
I bought a current model laptop for my better half, loaded with win11 - to me the operational response is much the same for our application usages.
In fact I prefer my Puppy OS once it has loaded from the USB flash drive.

Pity you live on the other side of the world, as I have a box full of non ATX power supplies. Some long skinny ones up to 250 watt.
The GT1030 only needs 35 watts or so but performance is so much better than the GTX710.
Brand new here they only cost $95 AU.
If you connect just one monitor to HDMI all works well (ie it will push out the boot process on the HDMI port)


Re: Kernel Question wrt Debian vs Ubuntu

Posted: Tue Sep 10, 2024 2:42 pm
by rockedge

I don't think you are missing out on anything when using older PC's

Every machine I use is over 10+ years old. Main development platform is a DELL PowerEdge R210 II rack server. Was a main file server in a factory that builds electrical harnesses and cable trees for Otis Elevator and Pratt&Whitney Jet Engines Plant for years before it was replaced and was red tagged, their main IT guy asked if I wanted it because it was headed towards the dumpster. Replaced the HDD's and RAM cards. Typing on it now.

My laptop lived in a Pre-school for around 10 years before I got it with a dead WiFi device. I use an ethernet cable or a $9.95 WiFi USB dongle from China. Runs KLV-Hyprland-CE and KLV-plasma-KDE surprisingly well for a Windows XP machine and years of use by teachers and 4-5 year old kids.

All my other machines range from Dell Optiplex 990 and 980 that lived in a stock brokers offices in NYC until replaced. Run solid, love Puppy Linux and KLV. Do EasyOS nicely.

I haven't bought a computer in 20 years and even my Android powered phone I was gifted before it landed in a it was once something drawer.

I can play chess on them.


Re: Kernel Question wrt Debian vs Ubuntu

Posted: Wed Sep 11, 2024 1:39 pm
by AQUAR

@rockedge

Probably showing my age here but my first "computer" was a Commodore VIC20. It came with a basic interpreter, and I wrote a program on it for sizing remote area solar power systems.
Upgraded that to an IBM clone with MSDOS on it. Was an early mouse adopter with my amiga 1000 (OS on 2 by 3.5 inch floppies, and state of the art!).


Re: Kernel Question wrt Debian vs Ubuntu

Posted: Wed Sep 11, 2024 4:53 pm
by mikewalsh
AQUAR wrote: Wed Sep 11, 2024 1:39 pm

@rockedge

Probably showing my age here but my first "computer" was a Commodore VIC20. It came with a basic interpreter, and I wrote a program on it for sizing remote area solar power systems.
Upgraded that to an IBM clone with MSDOS on it. Was an early mouse adopter with my amiga 1000 (OS on 2 by 3.5 inch floppies, and state of the art!).

@AQUAR :-

Oooh! Almost with ya, there; mine was a Commodore 64 (just after leaving school at 17 - with 2 'A' levels (UK education system; I'd already got 7 'O' levels 2 years earlier)) - the "upgrade" from yours. All of 64 KB of, well.....SOME kind of memory. Wasn't DDR-anything, I know that much!

I can't find the website now for the life of me, but a coupla years back I was reading about some guy who's a right C64 freak. He stripped the guts out of "the breadbin", and proceeded to replace it with the contents of a modern NIC.....including a high-end Core i9, 64 GB of actual DDR-whatever RAM, and at least 3 TB of high-speed M.2 SSD storage. To this he added an optical drive - the detachable type from the older business-class Dell Latitudes, along with sundry other goodies and stuff. Essentially, it WAS a modern, top-end NIC stuffed into a very old case!

Remind me, will ya? How much did the VIC-20 have? I remember 4 KB.....I think. Or was it 5 KB? Summat like that.

Mike. ;)


Re: Kernel Question wrt Debian vs Ubuntu

Posted: Thu Sep 12, 2024 5:06 am
by AQUAR
mikewalsh wrote: Wed Sep 11, 2024 4:53 pm

Oooh! Almost with ya, there; mine was a Commodore 64 .

Remind me, will ya? How much did the VIC-20 have? I remember 4 KB.....I think. Or was it 5 KB? Summat like that.

Mike. ;)

My Vic-20 had a staggering 5KB of RAM with 3.5KB free for doing great things. My employer had a mainframe with dummy terminals to connect to it, and our engineering section had an HP-85 with the moon lander program on it (none of us could land that lunar module).
Bought the C64 for my Dad with a dot matrix printer and he used it to play chess and type airmail letters on it (so much better than the Vic-20).