New Life For Older Puppys

[mikeb]

I was being polite before... I was trying to avoid this...

I gave this a try on a fresh USB flash frugal install of Precise 5.7.1 Retro - took about 8 minutes for the kernel_src-3.12.11-patched.pet install to finish, added about 400mb to the savefile - but both uname -a and the system info utility show the old kernel (3.2.48 IIRC) still in place - even through multiple reboots. Everything looks/functions fine, otherwise.

I don't doubt your good intentions . may I suggest altering your first post with directions to those kernel pets that will provide the update you are suggesting to avoid any further confusion

regards

Mike

[sszindian]

mikeb:

Thanks for your not-so-polite response! 'I was really hoping you would return with some bench-marks as you wanted to know about in a previous post so all would know if anything changed in the performance of your puppy or other programs used by your puppy or not?'

As you can see in the other posts here, some believe nothing happens and an increase in performance is just in my own mind but again, there was 'one programmer who thought we might be on to something?'

Over the last few years, I have tested lots of new puppy's that come to life, hundreds of various programs that are used in those puppy's... Why... to help developers make their builds something to be desired and wanted by users and further the use of puppy in the Linux world. I never pulled an punches... if their program was good, I told them so... if it wasn't, I told them that also (which I'm sure never won me any popularity contest) but... I am a full-time puppy user and have been for a long long time, not like many here who dabble in puppy and are still afraid to let go of their Windows... that's sad!

Because of my extensive testing on puppy's, (I feel) I am able to notice little things like split-second performance differences in areas that probably even the dev's themselves don't notice sometimes.

I listed my experience with what I thought I found in the first post here and will stand by it until proven 100% wrong.

My word... this is 'testing' man, not 'rocket-science.' If something good eventually comes from all this fine! If not... so be it.

One thing it has accomplished thus far... 'certainly ruffled some feathers which I didn't expect or want to happen!'

As far as 'Instructions' there aren't anymore than what I have already mentioned in the other posts in this thread.

If one doesn't like the results after installing these .pet's the nice part is you can always 'UN-INSTALL IT' !

>>>---Indian------>

[mikeb]

really my only answer to that would not be polite so I will withdraw from this and leave my 8 year experience of using and modify puppy including changing kernels out of the picture and leave you to consider if what you have posted is a little misleading

mike

[dejan555]

Kernel placebo. Linux is that good

Sorry sszindian but Mick and Mike are right here, just the fact that those are SOURCE pets / sfs's means that they don't do anything, they are used like any other source - only after compiling you get the working kernel binary/modules which would need to be replaced in puppy filesystem the proper way like Mick said.

[saintless]

Hi, all.

No matter if the approach with source-kernel.pet is wrong or not - the idea to change puppy linux kernel easy from the user is still here and is very good idea. Nothing wrong to make changing kernel easy for the user and without need of special linux skills.
It will really give new live for older puppies.

If the kernel is a separate module and the base module does not contain /lib/modules and puppy can load second module on boot it will make puppy better and more flexible.
What will get wrong if puppy can load 5, 6, 7 modules on boot like Debian live does it for example? It will be an advantage for puppy.

Changing only vmlinuz + initrd.gz and adding second squashfs with /lib/modules (and new firmware if it is needed) will make the same puppy work on different hardware without (or almost without) adding extra size to the system. Yes, it will not work for very old and much newer kernel on the same puppy base module, bit it will work most of the cases. It also will save some hosting space for puppy versions.

Maybe something will come up from this thread and maybe not. I see it as an idea how to create more flexible puppy.

Toni

[mikeb]

Maybe something will come up from this thread and maybe not. I see it as an idea how to create more flexible puppy.

include 10MB of kernel dev files and build modules on the fly rather than kernel swapping every five minutes and have the bonus of a much smaller number of drivers to be included in the basic release.

Remember a new device driver can normally be built on a large range of kernels.

mike

[saintless]

Hi, Mike.

Good point, but building modules on the fly is not easy for new linux user. Puppy loose nothing and gain something more as option if it can load more modules on boot from /puppy folder.
Separate kernel modules will make puppy easy to use for new comers if the kernel does not work well on their hardware. Creating few kernel modules is not a problem, but puppy can't use them on boot. Maybe not needed to have base module without /lib/modules but the option to test easy new kernel on the same puppy will be welcome for new puppy users.

it is just an idea to add one more option in puppy. I know it is too late for all existing puppy version to include it but it is never too late for new ideas to be considered for the future development.

Toni

[jamesbond]

saintless - in Fatdog64, all kernel modules are kept in kernel-modules.sfs inside initrd. If you want to replace the kernel, just replace vmlinuz, open initrd, replace kernel-modules.sfs, and re-pack it (a program is even included to repack it). It has been like that for a few years now.

In FatdogArm, it's even easier because it doesn't use humoungous initrd like Fatdog64: I distribute FatdogArm as an SFS + a bunch of "kernel packages" (for different platforms). The kernel packages contains vmlinuz+initrd. Want to build your own "kernel package"? Same as above - replace vmlinuz, open existing initrd (*any* one of them), replace kernel-modules.sfs; and re-pack.

[saintless]

Thank you, Jamesbond!

I see you have even better approach but it works only for FatDog.
I will check out your FatDogArm solution. Sounds like something I try to do for small debian based system.
I might be able to do something similar borrowing your method if you do not mind?

Toni

[mikeb]

Good point, but building modules on the fly is not easy for new linux user.

actually I believe there is a script or pet to do exactly that for Nvidia since that requires the building of a custom kernel module.

Build a kernel module is one of the simpler compiling jobs.... unpack, cd and make ...in other words something that could be done with a script that's a whole lot simpler than the puppy package manager.

Seems easier to make a module than to play pick and mix with a bunch of kernels in an attempt to juggle hardware support.

It is more akin to the windows model where drivers are only installed for the hardware present.

Anyway was just musing around possibilities as others have on this thread.

mike

[nancy reagan]

Though I hardly know what a kernel -is- I'd like to point to this thread about switching kernels:

http://www.murga-linux.com/puppy/viewtopic.php?t=60180

[saintless]

http://www.murga-linux.com/puppy/viewtopic.php?t=60180

Thank you for the link, Nancy Reagen!

So we have one more option for manual rebuilding the main sfs module with different kernel.
We have so many options for users with some linux experience and still no option for non-experienced puppy linux user.And just because Puppy can not load more modules on boot. If it could the kernel change instruction was going to be:

Download this archive, extract it in /puppy folder and reboot the computer with your new kernel.

Maybe not important to think about since kernel can be changed the hard ways. Just thoughts about the existing choices and possibilities...

Edit: Sorry for hacking your thread, Sszindian. It just seems to me your idea is heading in the same direction.

Toni

[mikeb]

And just because Puppy can not load more modules on boot.

yes removing that option after puppy 2 seemed a little odd to me...so I kept it

mike

[gcmartin]

As is pointed out, by all here, 2 things surface.

1. What would be a reasonable presentation of kernels available for community use?
2. Is there a packaging utility that would allow kernels to be added or exchanged so that an ISO (or additions to filesystem) would result to allow kernel selection at boot via bootmanager?A frontend-backend modified form of ISO master use comes to mind.

There appears to be consensus for everyone sees benefit.

[saintless]

Hi, gcmartin.

1. I would say 2-3 older and 2-3 newer kernels will be a good starting point for tests. More to add in time from community members.
As I see it separate archive includes vmlinuz + initrd.gz + sfs module with /lib/modules. Firmware can stay in the main puppy module or inside kernel module. Every puppy to the moment has all included anyway.

2. I see it more as an option to download separate archive with kernel module and use it in frugal install. IsoMaster is good program to produce iso with more kernels and choice which one to boot.

Example: Boot any puppy linux and make frugal install. Download different kernel archive and extract vmlinuz1, initrd1.gz and 02-kernel-3.12.sfs in /puppy folder. Add in grub menu list new entry to point vmlinuz1 and initrd1.gz and reboot.
It is important the new initrd file not to look for specific main module name. It is needed to load all sfs modules in alphabetical order.

You can add as many kernels you like on the same puppy easy.
The only problem is puppy does not allow more than one module loaded on boot, but this can be fixed inside new initrd file in every new kernel module (if I do not mistake).

Similar example is this Debian based iso:
http://www.smokey01.com/saintless/Light ... g-test.iso
It has only one kernel but it can easy have many more included.
it boots with debian initrd or porteus initrd giving different system structure and save file options.
It also has separate kernel module and base module without kernel. It is not really needed to separate the kernel but I can easy keep the size of the system small by replacing the kernel module instead adding one more to the system.

Toni

[sszindian]

saintless wrote:
Sorry for hacking your thread, Sszindian. It just seems to me your idea is heading in the same direction.
-----------------------------------------------------------------------------------------------------------
No problem, keep after it Toni !!! At least now things seem to be going somewhere... I appreciate 'the heads of knowledge' that have gathered here and hope to test the first build that develops!!!

'Thanks to all"

>>>---Indian------>

[saintless]

Hi, all.

Just to prove the concept separate kernel works without issues I decided to do quick and dirty experiment and it worked like charm. I'm more than happy with the result
Tested with KDPup-484 main sfs module (renamed to 01-KDpup-484.squashfs)
http://murga-linux.com/puppy/viewtopic.php?t=55301
placed in /live folder with 011-kernel-486.squashfs separate kernel module and initrd1.img and vmlinuz1 from DebianDog here:
http://www.smokey01.com/saintless/Light ... g-test.iso
On the picture you can see the content of /live boot folder.
Here is the boot code if someone like to experiment the same:

Code: Select all

title DebianDog initrd1.img 486
rootnoverify (hd0,0)
kernel /live/vmlinuz1 boot=live config swapon noprompt nofastboot autologin persistent
initrd /live/initrd1.img
boot

Note puppy sfs module has its own firmware and Kernel 2.6.30-5. There is no firmware in the kernel 3.2.0.4-486 module.
This means we can boot puppy main module with debian kernel and initrd.img but getting debian system structure and debian save file options. And getting back the option to load up to 9 modules on boot.
KDPupup is debian based puppy so it is not 100% sure this will work with any puppy module but I guess it will.
Of course puppy save file will not work like in puppy. You can create save file from the same running Kdpup + debian kernel system but after this rename it to live-rw and place it on the top of the partition /
The save file will work in pure debian live way.
Here is the kernel output:

Code: Select all

# uname -r
3.2.0-4-486
# uname -a
Linux puppypc 3.2.0-4-486 #1 Debian 3.2.51-1 i686 GNU/Linux
#

Keep in mind the structure is different:
/initrd/pup_rw = /live/cow
/initrd/pup_ro2 (or /mnt/home) = /live/image


Toni

[dejan555]

Dude that's sick o.0 And no issues at all?
I'm gonna try this when I can.

[saintless]

And no issues at all?

I haven't test it much but it boots without errors to xorgwizard and after that to X desktop. network setup script works, Firefox works. Mtpaint works, mount-drives works...
I guess there will be some problem with scripts pointing to /mnt/home but easy fix for this will be link /live/image -> /mnt/home and /live/cow -> /initrd/pup_rw

Anyway the point is if we have few puppy native initrd.gz edited to allow more modules on boot with corresponding vmlinuz and second sfs module containing /lib/modules, then this will make all existing puppy versions to boot with such modified puppy initrd.gz file and separate kernel module.
This will really give new life for older puppy as the thread points.

Using kernel and initrd from different linux is just an experiment for anyone who wants to test and use such combination. Seems it is working with Puppy the same way as in DebianDog giving choice to have different system structure and save file just by changing the initrd file.

Edit: I almost forgot this important thing - using kernel 3.x and above gives option to use squashfs-tools with xz support. This means we can compress any puppy module with xz compression which gives 20-30% smaller size (but will increase a little the CPU usage).

Toni

[mikeb]

Well i replace kernels by making an sfs of the new modules which gets loaded at boot and edit the initrd adding its new selection of modules...done.

Course it works...

Still faster to build a driver though

Glad my experience is once again of no use.... its fun here

mike