New Life For Older Puppys

Message

nancy reagan · #31 Post by **nancy reagan** » Thu 13 Mar 2014, 20:16

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 · #32 Post by **saintless** » Thu 13 Mar 2014, 21:09

nancy reagan wrote: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 · #33 Post by **mikeb** » Thu 13 Mar 2014, 21:21

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 · #34 Post by **gcmartin** » Thu 13 Mar 2014, 22:24

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

What would be a reasonable presentation of kernels available for community use?
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 · #35 Post by **saintless** » Thu 13 Mar 2014, 23:07

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 · #36 Post by **sszindian** » Fri 14 Mar 2014, 00:26

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 · #37 Post by **saintless** » Fri 14 Mar 2014, 20:20

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 · #38 Post by **dejan555** » Fri 14 Mar 2014, 23:32

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

saintless · #39 Post by **saintless** » Sat 15 Mar 2014, 07:15

dejan555 wrote: 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 · #40 Post by **mikeb** » Sat 15 Mar 2014, 10:55

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

saintless · #41 Post by **saintless** » Sat 15 Mar 2014, 12:53

Hi, Mike.

mikeb wrote: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...

Can you point me to a tutorial from you with example sfs-kernel + edited initrd to be tested on any puppy? can you point me to a tutorial from you what exactly needs to be edited in initrd file?
Do you think we all have your skills to build separate sfs kernel and edit initrd image to boot multiple sfs modules?

Still faster to build a driver though

Can you point me to a tutorial from you how new user can do it?
And it is not faster if you have ready for use separate kernel modules with all extra options it gives.

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

Sorry to say this but seems you keep your experience in darkness. Otherwise when I type in google:

Code: Select all

puppy linux multiuser
separate kernel module puppy linux

I should see link pointing to your experience.
Just for example the second search string points to this thread on top of the first page.
I'm glad you have experience and you share it somewhere, but it is not easy to be found. You also did not point to anything made from you as a result to be tested in this thread.

This has also a good side - new methods can born from "reinventing the wheel" again.

Toni

dejan555 · #42 Post by **dejan555** » Sat 15 Mar 2014, 13:44

We all know how to replace vmlinuz itself, it's separate file outside of sfs
to add modules to sfs use unsquashsfs and dir2sfs commands to repack sfs (this is how I do all remastering btw), and here's a tutorial how to unpack/repack initrd
http://www.murga-linux.com/puppy/viewtopic.php?t=53019

Further, there's a dir2iso script on forum too to finalize it into iso

I can't write more detailed manual because I only did it once when I thought of upgrading dpup's kernel but I discarded it later

mikeb · #43 Post by **mikeb** » Sat 15 Mar 2014, 14:04

well i described basic requirements for multi user.
I have puppy 2.12 and 4.12 as multiuser but of course you do have to reinvent the wheel for each puppy you do this on so only a template guide can be given...I do of course know of the pitfalls doing this in puppy....eg the limits of tiny login, su/sudo problems etc...

Same for loading ,multiple sfs .... i have that one 2.02, 2.12, 4.12 and lupu 5.15 doing this but you again have to work the changes into the version of puppy its wanted for.

the kernel change in initrd is to duplicate the /lib/modules folder using the same modules and layout from your new kernel including gzipping those modules basically. There may or may not be changes in the init script depending on the quirkiness of the new kernel...tend to be a suck it and see job.

I say is is quicker to make a driver than to edit the initrd, create a modules sfs and any other changes needed to accomodate the new kernel (firmware for example.) Sure if someone does it for you then its quick but installing a pet for a driver is pretty slick I believe.
Takes ~ 30 seconds to build a kernel module on a pentium 3 by the way.

If there is not much out there (i do have a site with isos and modules) then its because i am wary of puppy users generally, some are quite hostile, so prefer to remain pretty anonymous but have forwarded items to interested parties at times...and some not so nice characters unfortunately) This does not stop me giving a few pointers on here though. I didn't post on here for 2 years for similar reasons but continued to pm at times.

mike

saintless · #44 Post by **saintless** » Sat 15 Mar 2014, 15:33

Hi, Mike.

There is much documentation how to unpack and repack initrd and squashfs modules.
I have it working in this and this puppy does not help much.

What is missing as information for Puppy is the most important thing - what needs to be changed to get multiple load working and how to get rid of the need to specify exact puppy-linux module name? How can we make *.sfs multiple modules to be loaded on boot?
If you have this information and desire to share it, please, do it in some form: posting, PM etc.
This will make the initrd universal for all puppy versions and no need to make same kernel module all the time for every different puppy. One separate kernel module + initrd will work on all puppy versions like the debian one.

Several modules with different kernels working on any puppy will give a lot more to the system than building one more module on the same kernel.

Toni

mikeb · #45 Post by **mikeb** » Sat 15 Mar 2014, 17:53

How can we make *.sfs multiple modules to be loaded on boot?

ok on that specific issue the answer is pretty easy...puppy 2

Its the one thing that I did not really have to modify..... what I did do is order the sfs with the main pup_sfs at the bottom but thats a separate issue.

In 2 it just did an ls with the pattern of _xxx.sfs at the end where xxx is the version number in the same place as the pup_xxx.sfs is located.... the result gives the list of sfs to load for later on.

The system nowadays uses find but the same approach should work ok..ie a name pattern match...I assume it only loads the names listed as it is now.

The only refinement was to add _uni.sfs for any that were more generic like open office that work on a range of puppies.

Sometimes life in pupland is more complicated than it needs to be.
As a noob I got a devx sfs and wine and renamed appropriately , stuck them on the hard drive and that was it...save file or no save file...I had no problem even though linux was mostly greek to me.
Now I am supposed to know there is a gui somewhere in the menu and make a frugal install before i can do any of this and certainly not from a ram only boot... I don't see that as progress and comes up too often as a new user question.

example line... initrd has the puppy partition mounted where main sfs is...
MORESFS="`ls -r /mnt/data/*_${PUPPYVERSION}.sfs | grep -v "pup_" | cut -c 11- | tr "\n" " "`"

i changed the clean up from sed to cut but its doing the same thing.
If you want subfolder just insert the variable in the /mnt/data.... path.

mike

saintless · #46 Post by **saintless** » Sat 15 Mar 2014, 18:20

mikeb wrote:example line... initrd has the puppy partition mounted where main sfs is...
MORESFS="`ls -r /mnt/data/*_${PUPPYVERSION}.sfs | grep -v "pup_" | cut -c 11- | tr "\n" " "`"

i changed the clean up from sed to cut but its doing the same thing.
If you want subfolder just insert the variable in the /mnt/data.... path.

Thank you, Mike.
Having this information gives me good starting point and saves me a lot of testing. I will try to make separate universal working puppy kernel module.

Toni

mikeb · #47 Post by **mikeb** » Sat 15 Mar 2014, 19:39

No problem toni ... as I have done for others its a case of code snipets and techniques since more than likely they would be applied in different pups to the ones I experimented with ... I brought them to life using a lightning strike at midnight in the time honoured manner..

mike

mcewanw · #48 Post by **mcewanw** » Wed 19 Mar 2014, 14:17

saintless wrote: Puppy is a modular system and it is disadvantage it can load only one module in /puppy folder on boot (or second module with drivers only if I do not mistake). I think Jemimah included option for second module loaded on boot in Saluki but in general puppy can load only one module on boot.

If puppy keeps the main system without kernel in one module and has second module with kernel only it will become much more flexible. Then the user can choose the kernel that works best for the hardware without changing the puppy version.

I'm not sure how relevant zdrv is to your discussion, but the following thread seemed at least partly related:

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

saintless · #49 Post by **saintless** » Wed 19 Mar 2014, 17:51

Thank you, William. I know Jemimah also included option to load one more module in Saluki and Mavrothal worked in the same direction here:
http://www.murga-linux.com/puppy/viewto ... 5&start=15
I will see what I can do with Mike's tips and posts on this subject.

Toni

(old)Puppy Linux Discussion Forum

(old)Puppy Linux Discussion Forum

New Life For Older Puppys

Kernel .pet

Re: New Life For Older Puppy's