(OLD) (ARCHIVED) Puppy Linux Discussion Forum

[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...

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

[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

[jrb]

[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...

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

Cheers, Charlie

[mikeb]

[jrb]

[jrb]

The above technique worked so well and was so easy, I just tried it on Racy-5.5. Posting from it now.

[charlie6]

@J and @mike,
Hi ,

@J,
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

[jrb]

[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

[charlie6]

Hi mike,

[mikeb]

[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
.

[Pelo]

translated french traduction française tarhpup procedure

[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.php?p=847738#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