(old)Puppy Linux Discussion Forum

I have 4.15 ..its 4.12 with a slax kernel.

I use the 4.12 devx for userspace and the slax kernel headers (6MB!) for building drivers. (sources are only needed for making kernels and some in kernel driver builds...out of tree seems to usually work ok)

That's about it really. There are generic kernel function headers in the devx but as far as I have tried they seem happy accross various kernels....there may be a limit to that.

mike

Hi all,

Actually, the questions I asked in my prior post have become academic. I stumbled on the fact that Tahrpup had later kernels which served my purposes and so rebuilt my Pup using one.

But to answer the questions relating to PPM pointing to the what might be the wrong repos:
(a) the application I had in mind was LazyFred, http://murga-linux.com/puppy/viewtopic. ... 9f9#649731, which, however, doesn't seem to be configurable to point to the repos of "alien" distros. And more importantly, does not seem to do even the "dependency" checking and offering of Puppy Package Manager.

(b) Puppy package Manager provides a link to a webpage providing instructions for adding repos "from scratch" by which I mean manually typing information into /root/.packages/DISTRO_PET_REPOS and /root/.packages/DISTRO_COMPAT_REPOS.

For me, manually typing anything is an error-prone activity and without the benefit of "spell-check" almost certainly doomed.

Fortunately, I'm better at cutting and pasting. My less error-prone method, if and when I needed it, would be to boot into the Pup providing the applications, and copy its /root/.packages/DISTRO_PET_REPOS and /root/.packages/DISTRO_COMPAT_REPOS to a temporary location. Later, once my FrankenPup is up and running, I can open both those files and FrankenPup's /root/.packages/DISTRO_PET_REPOS and /root/.packages/DISTRO_COMPAT_REPOS and copy the required lines into the relevant files. And Save (or Remaster),

mikesLr

Jrb's March 29 method is really slick, once I got my head around it. You are not adding a new kernel to the old Puppy - you are adding the old SFS content to the new Puppy.

I even got an existing save folder from the old Puppy to work just by renaming it.

Have any problems appeared with this method since March?

[Edit] I mastered an ISO with the new structure and booted it with ISObooter. But there was a problem - the adrv.sfs was not loaded so there were no kernel drivers for things like Ethernet.

But if I manually loaded the adrv.sfs and modprobed the drivers, I could get a few things working. I guess that there is something different about PUPMODE=5.

[Edit] I burned a boot DVD and had the same problem - adrv.sfs not loaded. But if Puppy happened to find the main sfs and adrv.sfs on the hard drive, it would load them both! Go figure.

[Edit] According to /etc/rc.d/PUPSTATE, Puppy found the adrv file, but failed to mount it.

Is this a problem with all Puppies that have an adrv.sfs in the ISO?

------------------------

I solved my problems in the previous post by deleting all the old savefiles/folders and starting fresh.

But now I have a new problem. I am using Tahrpup602 with the Slacko593 content. I have a hard drive frugal install with a savefile. Whenever I reboot, I get the message "This savefile was last used by version 593 ... Press Enter".

I don't see any other reports of this.

[Edit] I appear to have solved this problem by editing the init at line 1119.
More testing is required.

[Edit] I still couldn't get a PUPMODE=13 flash drive install to work - the RAM layer wasn't being flushed back to the savefile. So I converted it to a PUPMODE=12 setup and it appears to be working OK.

@jrb,
Thanks , I just got puppy_wheezy_3.5.2.11.sfs running on my machine using some files from pupjibaro_wheezy_1.0.6 as per your method, and it works.
This is great because native puppy_wheezy_3.5.2.11 would not work on my new hardware.

There was just one thing, at every boot I got a message like "Updating 1.0.6 to 3.5.2.11" and it took a while to do this.
So I edited the DISTRO_SPECS file in "initrd.gz" changingtoThis did the trick. Now it boots normally.

Hmmm..., since I edited DISTRO_SPECS, I could have also changed DISTRO_PUPPYSFS, DISTRO_ZDRVSFS, DISTRO_ADRVSFS, and DISTRO_YDRVSFS to have all files using the Dpup Wheezy version number.

Looking at the "init" script from pupjibaro_wheezy_1.0.6, I realised that it is fairly modern and includes support for savefolder. However puppy_wheezy_3.5.2.11.sfs does not. So I added the ydrv http://www.fishprogs.software/puppy/whe ... 5.2.11.sfs as ydrv_wheezy_1.0.6.sfs, and converted my savefile to a savefolder using savefile2dir. It works.

gyro

Additional to my previous post:
I recommend installing "sfs_load-2.3.pet", if you want to use savefolder.

Also, I loaded "devx_wheezy_3.5.2.12.sfs" and successfully compiled and ran a program.
For compiling applications I think that the "wheezy_3.5.2.12" is the one to use. Then the DEV stuff matches the libraries in "puppy_wheezy_3.5.2.12".

gyro

Further:
I've now edited the DISTRO_SPECS file in initrd.gz to change all the system file names to those of Dpup Wheezy. Then renamed the files appropriately.
The directory now looks like it contains Dpup Wheezy, and it runs like Dpup Wheezy, except for using the much newer kernel.

Only problem so far is that "ddcprobe" segmentation faults, but this doesn't seem to worry it.

I could remaster "puppy_wheezy_3.5.2.11.sfs" to remove all the stuff corresponding to stuff in "adrv_wheezy_3.5.2.11.sys" so I could rename it to "zdrv_wheezy_3.5.2.11.sys", but I probably won't bother.

gyro

Hi, gyro.

pupjibaro_wheezy uses an older glibc, 2.13. I don't remember which version
of glibc the pemasu wheezy uses, but if different, would it have an impact
when changing kernels?

BFN.

musher0

Hi musher0,

Why take a chance when you have a matching devx and puppy_sfs?
I'm thinking of the "include" files in the devx matching the actual ".so" files in the puppy_sfs.

gyro

Hi gyro.

I was just wondering if you had had any glibc problems running the
programs in your edited Puppy-wheezy, in view of the difference in glibc
versions between the pupjibaro-wheezy and the upup-wheezy.

Or maybe the glibc version doesn't matter when it comes to kernels? Isn't
the kernel compiled against a particular version of the C libraries? It has
to, no?

Perhaps the Linux kernel is in Assembly language or in another computer
language altogether? In which case the version of the C libraries wouldn't
matter, right? (Just thinking out loud here.)

I'd like to try my hand at the kernel procedure myself to update the old
Puppy Precise-5.4.3, but I'd like to upgrade the glibc version at the same
time. (Glibc is at version 2.22 now.)

Or are they two different operations?

Thanks in advance for shedding some light on this. BFN.

musher0

Hi musher0,

I've had no problems with compiling application code and running it. The libraries in "puppy_sfs" and development stuff in "devx" are in sync.

I will not be attempting to compile a kernel on it.
Why would I, I already have a much newer kernel than that which comes with Dpup Wheezy.

As to kernel conflicting with libc, I don't know. I'm not a kernel compiling person.

gyro

gyro wrote:Hi musher0,

I've had no problems with compiling application code and running it. The libraries in "puppy_sfs" and development stuff in "devx" are in sync.

I will not be attempting to compile a kernel on it.
Why would I, I already have a much newer kernel than that which comes with Dpup Wheezy.

As to kernel conflicting with libc, I don't know. I'm not a kernel compiling person.

gyro

Hi gyro.

That's fine. I'm not asking you to compile any kernel!

Actually, this is what I needed to hear, and it's re-assuring:
"I've had no problems with compiling application code and running it. The
libraries in "puppy_sfs" and development stuff in "devx" are in sync."

Many thanks for sharing your experience.

BFN.

@musher0

As far as I know, the gcc version has more impact on compiling (kernel drivers to be specific) with a different kernel than the libc (be it glibc, uClibc, musl-libc or whatever).

Further technical reading <-- https://www.win.tue.nl/~aeb/linux/lk/lk-3.html

01micko wrote:@musher0

As far as I know, the gcc version has more impact on compiling (kernel drivers to be specific) with a different kernel than the libc (be it glibc, uClibc, musl-libc or whatever).

Further technical reading <-- https://www.win.tue.nl/~aeb/linux/lk/lk-3.html

Thanks. I'm on it now.

Musher0, don't Wary, be Happy
Things go better in reality . Do it, Don't worry about details.
What is wrong shall be easily corrected, once installed.
Put your wheezy instead of tahrpup sfs, go on ! Go ahead
Wheezy is not my cup of tea, really not.

For Mikeslr, who needs to remasterized its lovely Teenpup, to get wired.
Newbies get successful results, because they apply the process, simply, without asking questions ! They don't presume any problem.
Few years ago, i missed to be condemned to the flames of the pyre because i changed the kernel of Wolx2014 to get wireless working.

Hi All,

The original objective was to use a new kernel with Slacko 5.7. http://murga-linux.com/puppy/viewtopic. ... 831#962831. But 5.7 wasn't published with a separate zdrv. Newer kernel packages contain vmlinuz --the kernel-- and a modules-sfs containing the drivers compiled to work with that kernel which, before use is renamed to zdrv_WHICHEVER PUPPY+VERSION you intend to use. But separating out Slacko 5.7's 'zdrv' so that it could be replaced appeared to entail a lot of work for questionable results.

Edit in response to nic007's post below: He is, of course, correct. If you read the above thread, I was thinking Woofy as, in addition to remaster, changing kernels was an objective. There were reports on the Woofy thread of problems with Slacko. In looking for a solution to those problem, I overlooked the obvious: use Slacko 5.7's builtin remaster to separate zdrv.

Fortunately, rg66 had already and successfully done that hard work in creating a version of xslacko based on either slacko 5.6 or 5.7. So, it occurred to me to use xslacko instead. http://murga-linux.com/puppy/viewtopic. ... 784#962784 I report regarding the functional Franken-xslacko on page following the cited post.

mikesLr

mikeslr wrote:Hi All,

The original objective was to use a new kernel with Slacko 5.7. http://murga-linux.com/puppy/viewtopic. ... 831#962831. But 5.7 wasn't published with a separate zdrv. Newer kernel packages contain vmlinuz --the kernel-- and a modules-sfs containing the drivers compiled to work with that kernel which, before use is renamed to zdrv_WHICHEVER PUPPY+VERSION you intend to use. But separating out Slacko 5.7's 'zdrv' so that it could be replaced appeared to entail a lot of work for questionable results.

Fortunately, rg66 had already and successfully done that hard work in creating a version of xslacko based on either slacko 5.6 or 5.7. So, it occurred to me to use xslacko instead. http://murga-linux.com/puppy/viewtopic. ... 784#962784 I report regarding the functional Franken-xslacko on page following the cited post.

mikesLr

Puppys builtin remasterscript can create a seperate zdrv if you choose to do so (handy if your puppy didn't come with a zdrv). Whether that created zdrv can be swapped with another I have not tested.

Zdrv cannot be changed with another if it contains kernel modules. It has to be the same kernel as shown in distrospecs. you must change distrospecs to fit kernel. Distrospecs is in initrd, usually

Just a link to the application rcrsn51 posted,http://www.murga-linux.com/puppy/viewto ... 33#1004533.