(old)Puppy Linux Discussion Forum

n.b. Neko seems to have taken a sabbatical from producing kernels.... another dev - Blaze - is producing some to be found at the end of the Porteus Forum thread.
==========================================
There is a very prolific kernel builder called Neko over at Porteus who regularly produces the most recent 32-bit and 64-bit kernels with aufs patches that can be used in pups with a small bit of configuration.

The downloads are hidden away on Porteus forum page:
https://forum.porteus.org/viewtopic.php?f=75&t=6568

Scroll down to the section headed:

[Updated kernel Example]
==== AUFS Kernel only for Porteus ====

and then click on a link with ALL or RES or BPLUS in its name - e.g.
32bit-BPLUS-kernel5.5-rc2.tar

When it has downloaded click on it to extract 2 files (crippled_sources can be ignored):
vmlinuz & 000-kernel.xzm

Now put those 2 files into a frugal install directory together with the initrd.gz and .sfs files from puppy.

Then the configuration - rename the 000-kernel.xzm file to the zdrv sfs name of your puppy.

The Porteus kernel contains firmware so a separate fdrv will not be needed.

Existing simple Grub4dos boot stanzas can be used unchanged although I guess some puppy boot codes may be ignored....untested.

Screenshots from tests with UPupEE and kernel 5.5-rc2 32-bit are attached.

PROBLEMS The 2barks sound on initial boot fails to appear because this Porteus kernel does not make /dev/mixer. Savefiles should be avoided (use Savefolder) as they can't be resized.

The RES versions of the kernels also work.........example BionicPup32 with k4.19.62

and 32-bit BusterPup with 64-bit Porteus k5.2.4 .............

G'day peebee,

Having had no luck putting a 5.2.4 kernel of yours into an oldish 64-bit kernel, oldish Slacko64 (my problem is no wifi driver nor workable f_drive found), I've just tried a Porteus 64-bit 5.2.5 in my Slacko64-630.

No immediate problem in booting and then adding my Slacko64 application sfs (first screenshot). My applications so far tested ran .

But when I tried to do a hot-backup of the new kernel Pup's save file, it didn't run giving an error message about the home partition being unsuitable. I have not encountered this in all previous Pups, 32 and 64 .

I keep my 64-bit Pups on sdb6 and then I noticed the drive icon for sdb6 showed it mounted (green icon for sdb6 in first screenshot) but not as the home partition. For comparison, the home partition should be a pink or orange icon as per my original kernel Slack64-630 (second screenshot) which does hot-savefile backups.

Any idea about how to fix this odd problem?

Thanks for everything.

David S.

Is this distro independent and why do you need to make a copy, is that for backup or will a renamed symlink/dummy file work?

@davids45 - I've only tried on "recent" woof-ce built pups...see the screenies above

@nic007 - well it seems to work on Slackware, Ubuntu and Debian based pups. A link does work - see post #1.

There are undoubtably some oddities - for instance the 2-barks on initial startup seems to have disappeared - see post #1.....so not 100% perfect.....

G'day peebee,

Thanks for your prompt reply re my 'fist try' problem with the 64-bit porteus 525 kernel in the old Slacko64.

I've looked at your screenshots and wonder if they show the same problem I found - the home partition has been changed to a just-mounted partition? Is the top-right corner mini-icon of the drive icon the colour for a home partition (grey?) or a only-mounted partition (green)?

I'm posting now from a 32-bit ScPup-19.06 with the 32-bit porteus 525 kernel.
It initially booted as expected (home-partition icon orange) and allowed my application sfs to load plus minor changes to allow printing and scanning for example.

But somewhere, the home partition switched to 'just-mounted' (icon colour now blue) and the Pup will not close down.
I think this partition change happened without trying to run the hot-puppy-savefile (initially suspected with the 64-bit trial).

Shut-down fails to complete with a message like:
"..../root/Choices/Rox-Filer/sedj01nRp : Read-only file system"
and the only way I've found to restart the computer is the 5-second button push.

I'll try a less new kernel from Porteus (I did see an older one available) and see if this strange problem recurs.

I also should check how these behave without any extras sfs being added.

Thanks for any ideas, and don't get distracted from your important Puppy developments,

David S.

G'day again,

A little bit more testing this morning with the 32-bit porteus 525 kernel in a ScPup and I think the non-save+non-shutdown problem occurs as soon as the home drive icon is clicked to open it in a Rox window (icon's colour changes from a home partition to just a mounted partition), or the hot-backup-puppysave application is attempted. Before this, Rox windows were openable elsewhere without creating the problem.

I don't know how to attempt a reversion of this un-setting of the home partition.

Nothing else seems affected by this change, except the save-file cannot be backed up, and the computer will not shut-down. Posting from the affected 32-bit ScPup now.

Both 32-bit and 64-bit kernels show this problem so far (only the 5.2.5 porteus kernels tried) with newer Pups.

I have also tried a couple of older 32-bit Pups. Stretch75 and Xenial75, and both did not boot, failing after stating the main Puppy sfs was "done" (yellow text) but followed by multiple lines of coloured text about problems encountered. Another hold-the-button restart needed.

I may try to replace the Rox in one (newer) Pup with an older Rox version to see if there's any different behaviour.

Puzzling.

David S.

It could be that some aufs utilities are not included in the Porteus derived zdrv....

screenie shows the contents of sbin in the 2 zdrvs - top Porteus, bottom Puppy

I'll do some tests later.......

FYI..........Kernel 5.3.0-rc5 & LXQt

It is possible to use a link rather than copying the kernel file - the 1st post has been updated.

The next LTS version of the kernel is getting closer........

Kernel Release: 5.4.0-rc8-porteus
Build Date: Mon Nov 18 11:25:52 UTC 2019
Build GCC: 9.2.0
OS Support: GNU/Linux
Architecture: i686
SMP Enabled: Yes

Thank you, Peebee for this information.
How do you mean of "Then the jiggery-pokery - rename the 000-kernel.xzm file to the zdrv sfs name of your puppy and then make a link from the zdrv to 000-kernel.xzm."

Then the jiggery-pokery - rename the 000-kernel.xzm file to the zdrv sfs name of your puppy and then make a link from the zdrv to 000-kernel.xzm.

Is it make a symbolic link? But I do not see a symlink in the picture of first post.

recobayu wrote:Is it make a symbolic link? But I do not see a symlink in the picture of first post.

Sorry - didn't update screenshots after I changed instructions - yes make a symlink as described.

@peebee later woof-builds can already recognized porteus modules. Just double click the xzm/lzm modules. No need to rename the module. It is a hidden feature of sfs_load