How to switch kernels between Puppy versions

How to do things, solutions, recipes, tutorials
Message
Author
User avatar
charlie6
Posts: 1230
Joined: Mon 30 Jun 2008, 04:03
Location: Saint-Gérard / Walloon part of Belgium

switch kernels to Puppies with separate zdrv_xxx.sfs

#106 Post by charlie6 »

Hi,

subject: switch kernels to Puppies with separate zdrv_xxx.sfs

Just to know if someone has succedeed in trying to perform jrb's method, detailed in page one this thread, and applying it to later puppies isos coming with separate zdrv_xxx.sfs files, and to puppies having only one main sfs file.

I'm here trying-struggling to switch kernels between puppy_wheezy_3.5.2.11-SCSI.iso which comes with one main sfs file, and, e.g. Pupjibaro_wheezy_JWM_1.0.6_22032015.iso; and getting no-success message like "...kernel panic..." and so on... :cry:

For sure i'm cutting and trying from reading postsrelevant to this matter; and am still ignorant about how to built a working puppy; so am i asking for help.

Thanks for any answer :)
Charlie

User avatar
mikeb
Posts: 11297
Joined: Thu 23 Nov 2006, 13:56

#107 Post by mikeb »

Perhaps its the naming of the zdrv that needs looking at.

I just booted the retro tahr kernel on lucid ok... used the new kernel and named the zdrv to match and placed it next to the main sfs.

There is usually some naming convention needed to match the initrds wants....

Of course this all may fail if the kernel you want does not have the initrd drivers built in since it will be unable to load anything....that requires the matching initrd as well.

mike

User avatar
jrb
Posts: 1536
Joined: Tue 11 Dec 2007, 19:56
Location: Smithers, BC, Canada

Re: switch kernels to Puppies with separate zdrv_xxx.sfs

#108 Post by jrb »

charlie6 wrote:Hi,

subject: switch kernels to Puppies with separate zdrv_xxx.sfs

Just to know if someone has succedeed in trying to perform jrb's method, detailed in page one this thread, and applying it to later puppies isos coming with separate zdrv_xxx.sfs files, and to puppies having only one main sfs file.

I'm here trying-struggling to switch kernels between puppy_wheezy_3.5.2.11-SCSI.iso which comes with one main sfs file, and, e.g. Pupjibaro_wheezy_JWM_1.0.6_22032015.iso; and getting no-success message like "...kernel panic..." and so on... :cry:

For sure i'm cutting and trying from reading postsrelevant to this matter; and am still ignorant about how to built a working puppy; so am i asking for help.

Thanks for any answer :)
Charlie
I've built a zdrv with just the kernel and firmware from puppy_wheezy_3.5.2.11.sfs and along with its initrd.gz and vmlinuz have managed to boot Pupjibaro_wheezy_JWM_1.0.6_22032015. I didn't check it too thoroughly but it appears to be working OK. The problem comes when I create a savefile and reboot, X won't start. I don't really have the time to dig deep into this but here's what I did:
1. get the initrd.gz from puppy_wheezy and open it up for editing (click on it). Replace /etc/DISTRO_SPECS with the one from Pupjibaro.
2. place the modified initrd.gz and the vmlinuz from puppy_wheezy in your directory. along with pupjibaro_wheezy_1.0.6.sfs.
3, mount zdrv_wheezy_1.0.6.sfs from Pupjibaro and use it as your guide. Open puppy_wheezy_3.5.2.11.sfs for editing and delete out everything that isn't in zdrv_wheezy_1.0.6.sfs. I also copied in the /boot folder from zdrv_wheezy_1.0.6.sfs, who knows? Now save as zdrv_wheezy_1.0.6.sfs and try rebooting.
Did that make sense? :? Anyway Good Luck! Hope it works for you.

Cheers, J

PS - If you want I can upload the initrd.gz and zdrv files for you, but like I say, It doesn't want to run from a savefile.

User avatar
charlie6
Posts: 1230
Joined: Mon 30 Jun 2008, 04:03
Location: Saint-Gérard / Walloon part of Belgium

#109 Post by charlie6 »

Hi jrb,
many thanks for your answer,

Sorry if I might have been unclear:
My purpose is to use a latest kernel (e.g. 3.17.7 from Pupjibaro, or gfrom Tahr-6.0.2) in puppy_wheezy_3.5.2.11.

I could get a booting wheezy_3.5.2.11 after copying /lib/modules, /lib/firmware, /etc/modules /etc/DISTROSPECS from Pupjibaros main.sfs and zdrv_1.0.6.sfs; along with using Pupjibaros vmlinuz and initrd.gz; BUT with the mouse cursor and keyboard not functionnal nor even recognizes... :cry:

I haven't edited initrd.gz (don't know if necessary)

Cheers, Charlie

User avatar
mikeb
Posts: 11297
Joined: Thu 23 Nov 2006, 13:56

#110 Post by mikeb »

I haven't edited initrd.gz (don't know if necessary)
those kernels you mention appear to have initrd drivers built in.

Again with the save could be a naming convention.... I assume save files are not using any weird tagging system.

Cannot think of another reason off hand ... only things i find are driver related eg matching alsa and nfs ..scripts are scripts.

Again probably of no connection but recent 3 kernels will not find the puppy files on a P3 machine EVEN THOUGH from the initrd I can mount drives and see them with ls from the initrd console. Cannot fathom that one either.

Kernel devs do move things around in /proc, /sys and /dev ..if any script or binary is relying on that then it will be affected (explains the alsa and NFS ...expected behaviour)

mike

User avatar
jrb
Posts: 1536
Joined: Tue 11 Dec 2007, 19:56
Location: Smithers, BC, Canada

#111 Post by jrb »

charlie6 wrote:Hi jrb,

Sorry if I might have been unclear:
My purpose is to use a latest kernel (e.g. 3.17.7 from Pupjibaro, or gfrom Tahr-6.0.2) in puppy_wheezy_3.5.2.11.

Cheers, Charlie
I'm glad that's what you want. :D Turns out it's really easy.
1. Place initrd.gz, vmlinuz and zdrv_wheezy_1.0.6.sfs from Pupjibaro in your folder. Rename "zdrv_wheezy_1.0.6.sfs" to "adrv_wheezy_1.0.6.sfs".
2. Place "puppy_wheezy_3.5.2.11.sfs" in the folder and rename it to "pupjibaro_wheezy_1.0.6.sfs".

Reboot and its a done deal. Works with savefile and gives me my favorite resolution which puppy_wheezy never did. Posting from it right now.

Cheers, J
Attachments
wheezy1.jpg
(16.04 KiB) Downloaded 1512 times

User avatar
jrb
Posts: 1536
Joined: Tue 11 Dec 2007, 19:56
Location: Smithers, BC, Canada

#112 Post by jrb »

The above technique worked so well and was so easy, I just tried it on Racy-5.5. Posting from it now. :D
Attachments
racy1.jpg
(24.06 KiB) Downloaded 1490 times

User avatar
charlie6
Posts: 1230
Joined: Mon 30 Jun 2008, 04:03
Location: Saint-Gérard / Walloon part of Belgium

#113 Post by charlie6 »

@J and @mike,
Hi :) ,

@J,
:shock: wow ! that so easy ! thanks a lot for that tip !

Success here on applying what you described in yout post !

Having had some reading in BK's literature about PuppyLinux, would the adrv_xxx.sfs have precedence on zdrv_xxx.sfs, and therefore the drivers in the main.sfs are ignored during the bootup, wouldn't it?

@mike,
good to know a bit more about recent kernels

Again many thanks for your time !
Bets regards,
Charlie

User avatar
jrb
Posts: 1536
Joined: Tue 11 Dec 2007, 19:56
Location: Smithers, BC, Canada

#114 Post by jrb »

charlie6 wrote:Having had some reading in BK's literature about PuppyLinux, would the adrv_xxx.sfs have precedence on zdrv_xxx.sfs, and therefore the drivers in the main.sfs are ignored during the bootup, wouldn't it?
Yes, in Puppy the adrv.sfs loads first, then the puppy.sfs and then the zdrv.sfs. The first loaded takes precedence over the later ones and so on. By loading the kernel first it covered over any conflicts in the puppy.sfs. I was surprised that it named the savefile properly but /etc/DISTROSPECS seems to have been carried over from the initrd.gz and specified the correct name.

I'm very glad you posted this topic 8) , it wouldn't have occurred to me otherwise.

User avatar
mikeb
Posts: 11297
Joined: Thu 23 Nov 2006, 13:56

#115 Post by mikeb »

The drivers in the main would be ignored as they are in a different folder under the version number.

firmware and other stuff like module configs and bootmanagers on the other hand may be affected by the upsidown layering of standard puppies... adrv was added to do at least one layer properly i believe :)

distrospecs copied from initrd does ring a bell.

mike

User avatar
charlie6
Posts: 1230
Joined: Mon 30 Jun 2008, 04:03
Location: Saint-Gérard / Walloon part of Belgium

#116 Post by charlie6 »

Hi mike,
mikeb wrote:...
firmware and other stuff like module configs and bootmanagers on the other hand may be affected by the upsidown layering of standard puppies... adrv was added to do at least one layer properly i believe :)
mikeb wrote:...
distrospecs copied from initrd does ring a bell.
Then, are there some mysfunctioning to be awaited :?: :?
Cheers,
Charlie

User avatar
mikeb
Posts: 11297
Joined: Thu 23 Nov 2006, 13:56

#117 Post by mikeb »

Then, are there some mysfunctioning to be awaited
in your case sounds like its fine... just mentioned the reasons why this may not work out and ways to fix really for others....

sorry to confuse :)

mike

User avatar
CatDude
Posts: 1563
Joined: Wed 03 Jan 2007, 17:49
Location: UK

#118 Post by CatDude »

Hi

Reading through this thread i see no mention regarding compiling in these new frankenpup's, which leaves me asking a few questions.

Those questions are:
Does one need to make any changes to the devx, and if so, then what would those changes be :?:

Also, am i correct in assuming that one would have to use the kernel sources from the donor Puppy :?:

Maybe i'm not thinking this through properly, but i just had to ask.

CatDude
.
[img]http://www.smokey01.com/CatDude/.temp/sigs/acer-futile.gif[/img]


User avatar
mikeslr
Posts: 3890
Joined: Mon 16 Jun 2008, 21:20
Location: 500 seconds from Sol

How to get a FrankenPup to point to the right repos?

#120 Post by mikeslr »

Hi All,

Picking up on CatDude's above inquiry, I would think that the Pup version which provided the vmlinuz & zdrv is the one whose devx would be used in compiling. I've refrained from referring to it as "donor". I have a problem conceptualizing which of the two Pups should bear that name. Both are donating something.

As I see it, the END-PUP, in Charlie6's situation, is pretty much Pupjibaro_wheezy_1.0.6 wearing puppy_wheezy_3.5.2.11's clothing.

Maybe referring to them as "the base pup" --in the above case Pupjibaro-- and the outfitter --wheezy-- would be easier to remember.

I suspect that the employment of a more modular design in Puppy builds since this tread first started is the reason jrb's last technique became possible.

The following seem to be logical conclusions. Just some thoughts. The "real world" isn't always logical. Please feel free to "flesh-out" or correct any:

(a) The zdrv_xxx.sfs from Wheezy_3.5.2.11 serves no useful purpose: firmware is being provided by Pupjibaro's zdrv. If so, Wheezy's firmware/zdrv.sfs can be discarded.

(b) If the ISO's of either or both Pups being used to build an END-PUP lacks a zdrv, simply remaster to create it/them before combining the desired parts. I've used the term "simply" because in this instance all that would be required is to boot a Pup to which no changes were made, and accept all defaults except to select having a zdrv.

(c) A remaster of the END-PUP, should be able to "convert" its current "adrv" into the remastered Pup's zdrv if the unused zdrv was discarded.

More Important than my ramblings above:

Employing the terminology I used above, I just "outfitted" azami's Vividpup 4.0.1 PAE, http://murga-linux.com/puppy/viewtopic. ... 738#847738 with tahrpup 6.0.2's applications. Working my way thru the menu to see what works, and for any problems, everything I tried seemed to work, although there were occasional references to tahrpup, such as to a tahrpup SaveFile when, in fact, it had correctly created a vivid_SaveFile.
A significant problem, however, is that although this is essentially a vividpup, ppm points to tahrpup's repo, and ubuntu's trusty tahr repos rather than VividVervet and VividPup's repos. What's a simple way to correct this?

Perhaps better --as many apps created for TrustyTahr/Tahrpup may function in Vivid Vervet/VividPup, and vice-versa-- didn't RSH/LazyPuppy create an app making it easy to add repositories?

mikesLr

User avatar
mikeb
Posts: 11297
Joined: Thu 23 Nov 2006, 13:56

#121 Post by mikeb »

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

User avatar
mikeslr
Posts: 3890
Joined: Mon 16 Jun 2008, 21:20
Location: 500 seconds from Sol

Getting the right repos

#122 Post by mikeslr »

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

User avatar
rcrsn51
Posts: 13096
Joined: Tue 05 Sep 2006, 13:50
Location: Stratford, Ontario

#123 Post by rcrsn51 »

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?

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

User avatar
rcrsn51
Posts: 13096
Joined: Tue 05 Sep 2006, 13:50
Location: Stratford, Ontario

#124 Post by rcrsn51 »

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.

Code: Select all

if vercmp ${DISTRO_VERSION} gt 9.9.9
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.
Last edited by rcrsn51 on Wed 23 Sep 2015, 12:22, edited 1 time in total.

gyro
Posts: 1798
Joined: Tue 28 Oct 2008, 21:35
Location: Brisbane, Australia

#125 Post by gyro »

@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" changing

Code: Select all

DISTRO_VERSION=1.0.6
to

Code: Select all

DISTRO_VERSION=3.5.2.11
This 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

Post Reply