How to Swap - Change Kernels

[mikeslr]

I know I've provided this recipe several time. But I can never find the posts. Hopefully this location on the Forum with the title used will alleviate that issue.

Edit: This post was written before the 'user-merge' Rule was implemented in some newer Puppys. The recipe still works, but there are now two species of kernels which are not interchangeable OOTB. See the following posts for an explanation and hopefully some guidance.

Changing Kernels enables a User to keep an operating system while taking advantage of any abilities a different kernel may offer. Newer kernels often provide protection against possible malware newly discovered and can work with newer hardware; while older kernels may be needed to work with older hardware.

A Puppy's operating system is modular. On your storage media it consists of several READ-ONLY file/file-systems and --after you've created a SaveFile or SaveFolder-- one READ-WRITE file-system. On boot-up, the READ-ONLY file-systems are copied into RAM and the SaveFile/Folder mounted. For more details see here, https://www.forum.puppylinux.com/viewtopic.php?t=5818 and https://www.forum.puppylinux.com/viewtopic.php?t=6526.

Being a 'layman' I'll try to explain things in 'layman's terms'.

The 'kernel' is sort of the Engine and Chassis of a Puppy. It is what powers applications and against which applications are built. The kernel, itself, is always named vmlinuz. But to connect with and communicate with your computer's hardware --your keyboard, monitor, mouse/trackpad, and wifi-adapter, etc-- the kernel requires drivers and firmware specifically for YOUR hardware. Drivers have to be compiled against the kernel which is to use them. By long tradition, Puppys have packaged drivers in a file-system beginning with the term zdrv.. Puppy devs publish 'huge-kernel' packages containing both the kernel/vmlinuz, itself, and the drivers which have been compiled against them. You can find those packages here, https://www.forum.puppylinux.com/viewforum.php?f=65. You can also 'flinch' both the 'kernel' and its associated drivers/zdrv from any Puppy you already have.

Originally firmware was also packaged within the zdrv. But firmware does not have to be compiled against a kernel. Once you have the firmware required by your computer it can be used by any kernel. Download once, use forever. So some creators of Puppys now package firmware separately. When packaged separately the firmware file-system will begin with the term fdrv. You can find such packages here, https://www.forum.puppylinux.com/viewtopic.php?t=5374, often from the first links on a Puppy's thread, or flinch then from another Puppy.

On boot-up, after the vmlinuz the next file copied into RAM is the one named initrd, usually compressed so ending with either a .gz or xz. Initrd contains instructions as to what other files-systems on storage to copy into RAM. Initrd looks for files-systems bearing name and version number specified by those instructions. That's the name which appears on each puppy's core/base SFS. [The core/base SFS contains the file-and-window manager and all the applications that Puppy's creator thought most Users would usually need]. For example, we may refer to the original as fossapup or fossapup64, but its core/base file-system is puppy_fossapup64_9.5.sfs and its initrd will only load into RAM a zdrv named zdrv_fossapup64_9.5.sfs and an fdrv named fdrv_fossapup64_9.5.sfs.

Once you have an alternate kernel (and fdrv) to use it you have to rename it so that it bears the required version name and number. There's an application which may make renaming easier. Your Puppy may already have it. Start Menu>Setup>Quickpet, then click the button named 'change kernel' and follow the instructions. If Change Kernels isn't built-in, you can install it from here, https://www.forum.puppylinux.com/viewto ... 1497#p1497.

But AFAIK. the Change Kernel application has never been updated* to reflect that sometimes firmware has been packaged separately in an fdrv.sfs. And I've never used it. I always renamed file-systems manually. It's done as follows:

If starting with a 'Hugh Kernel Package', decompressing it will reveal two file-systems: one named vmlinuz-SERIES_NUMBER, the other named kernel-modules.sfs-SERIES_NUMBER; e.g. vmlinuz-5.2-64oz and modules.sfs-5.2-64oz. To use them with fossapup64_9.5, I'd Right-Click the former, select Rename, and remove the description so that it only reads vmlinuz. I'd also Right-Click the latter and rename it zdrv_fossapup64_9.5.sfs.

When starting with file-systems flinched from another Puppy, it's even easier. No need to rename vmlinuz and only the name and version number specified of the zdrv have to be changed.

If an fdrv is needed, the above procedure would be used to provide it with the name required for your Puppy's initrd to copy it into RAM.

-=-=-=-=-=-
* Note to those who know and/or to those who know scripting: If the Change Kernel Application has been modified to automate renaming fdrv, please post saying so. If it hasn't, shouldn't it be?

The use of the names modules.sfs and zdrv aren't entirely arbitrary. Originally both drivers and firmware included in the ISO were in one file-system. It was named zdrv as that was the last file-system initrd would copy into RAM. Drivers copied into RAM from the file-system on storage are placed --in the file-system in RAM-- into folders named "modules".

[MochiMoppel]

@mikeslr Thanks, that's a nice overwiew.

Being a 'layman' I'll try to explain things in 'layman's terms'.

Me being a dummy (at least when it comes to kernels) I need an explanation in dummy terms.

You can also 'flinch' both the 'kernel' and its associated drivers/zdrv from any Puppy you already have.

And this is supposed to work?

Here is my problem:
I'm testing @radky 's Bookworm64, which comes with a 6.1.25 kernel. I already know from F96-CE_4, which comes with a 6.0.12 kernel, that the 6x kernels don't seem to like my old HW. I experience occasional failures to wake up from suspend. so, for F96-CE_4, I successfully 'flinched' the 5.4.53 kernel and the associated zdrv from an earlier F96 build, and it worked.

The same trick doesn't work with Bookworm, The vmlinuz/zdrv combo from F64 doesn't work well (no internet connection, among other glitches). I also tried to keep Bookworm's zdrv and only flip vmlinuz. Doesn't work either. So how do I get to a working zdrv for an older kernel?

[Wiz57]

@mikeslr Thanks, that's a nice overwiew.

Being a 'layman' I'll try to explain things in 'layman's terms'.

Me being a dummy (at least when it comes to kernels) I need an explanation in dummy terms.

You can also 'flinch' both the 'kernel' and its associated drivers/zdrv from any Puppy you already have.

And this is supposed to work?

Here is my problem:
I'm testing @radky 's Bookworm64, which comes with a 6.1.25 kernel. I already know from F96-CE_4, which comes with a 6.0.12 kernel, that the 6x kernels don't seem to like my old HW. I experience occasional failures to wake up from suspend. so, for F96-CE_4, I successfully 'flinched' the 5.4.53 kernel and the associated zdrv from an earlier F96 build, and it worked.

The same trick doesn't work with Bookworm, The vmlinuz/zdrv combo from F64 doesn't work well (no internet connection, among other glitches). I also tried to keep Bookworm's zdrv and only flip vmlinuz. Doesn't work either. So how do I get to a working zdrv for an older kernel?

Mochi,
You might also want to grab the associated fdrv from your working F96. That's how I did it with ScPup 32 on my old Acer Aspire One netbook.
Wiz

[ozsouth]

@MochiMoppel - Bookworm is using a usrmerge kernel - so old kernels & fdrvs won't work.
For an alternative 5.10 usrmerge kernel & howto, see: viewtopic.php?p=90438#p90438

[mikeslr]

The dictum 'Linux is about choice' has spawned hundreds of Linux distros and the 'Puppy Family' numbering over 6,000. Other than that its binary had to be on --or symlinked onto-- 'The Path' in order for an operating system to run it, where a Dev chose to locate any files was 'Dev's Choice', as long as it worked. The term for 'every man did what was right in his own eyes', Judges 21:24 KJV is anarchy.

When Linux began operating systems were deployed on floppy drives. That limited how much you could stuff into any folder. As it grew in complexity, all binaries could no longer be located in /bin and libraries no longer could be located in /lib on one floppy. For technical details see, http://lists.busybox.net/pipermail/busy ... 74114.html

The 'work-around' was to create additional 'bin' and 'lib' folders: /usr/bin, /usr/local/bin, /usr/sbin and /usr/local/sbin; and /usr/lib and /usr/local/lib and add them to The Path. [Unique to Puppy, we also have /root/my-applications/bin and /lib].

Great for individual creativity. Not so much when you're an organization trying to update from one version to another; or figure out what's going wrong especially when the problem application is not 'home grown' by your organization's team. [And Puppy --being woofed primarily using the binaries of Slackware, debian and Ubuntu-- faces additional obstacles: When 64-bit operating systems came into existence, decisions had to be made as to where to locate their binaries and libraries. Slackware created folders named lib64, at top-level, under /usr and under /usr/local. debian named them --perversely -- /x86_64-linux-gnu; and Ubuntu --as much of its applications are derived from debian-- followed debian's lead.]

The restrictions regarding folder size ceased to exist long ago* and a 'user-merge rule' was suggested more than a decade ago. As I understand it, the 'user-merge' Rule --as implemented-- prohibits who can place libraries in Top-level folders to the devs who create the Linux Operating System. [Remember, Puppys are derivative --woofed from the binaries of other Linuxes; so Puppy Devs are NOT the creators in that context]. In short, if you are not the creator you CAN NOT locate files in /bin, /lib, /lib64 or /sbin. The expectation was that consequently you would have to place such files under /usr. [But remember Puppy has /root/my-applications on its Path. My exploration, and I believe rockedge's, suggests that the Rule is a restriction rather than a mandate: sometimes --I don't know the limitations-- files could be located in Puppys' unique /root/my-applications folder; whereas under other Linuxes --Top level folders being prohibited-- such files would have to be located under /usr].

Arch and Fedora implemented it before Ubuntu. https://community.tmpdir.org/t/the-hist ... -merge/496. Ubuntu decided to implement it after it first published Ubuntu Focal Fossa but made the mistake of applying the Rule to Fossa updates. Googling reveals the mess that caused. For once, debian followed Ubuntu's lead and implemented it with its publication of Bookworm.

As far as I can tell, Slackware has NOT implemented the Rule... yet.

I don't know why implementation of the Rule effects the location of drivers and firmware under Puppys. I have never found them located in a Top-Level folder. Perhaps I'm wrong about the 'Rule' being a prohibition rather than a mandate.

Maybe ozsouth can explain. I know he creates kernels and firmware modules for both Slackos, and 'Ubuntus', distinguishes between them, and on his recent posts has cautioned which could be used for 'new Puppys' and which for 'Old'.

At any rate, for now there are limitations on the ability to 'swap kernels'. I recommend --if you don't know which other kernels your Puppy can use-- carefully reading the posts here, https://www.forum.puppylinux.com/viewforum.php?f=65 or ASK --providing relevant details about your computer and specifying which Puppy.

-=--=-=--=-
* You would think that there no longer being a size limitation and the original reason for creating /usr/lib etc. having ceased to exist, the simplest solution would have been to merge everything into Top-level folders. As that didn't happen, I can only suggest another factor came into play: the perversely human condition that those with power will garner to themselves whatever advantage they can.

[ozsouth]

@mikeslr - Slackware-based pups have firmware under /lib & drivers under /lib/modules.
After that, things get complicated.
Like you, I don't understand why things couldn't all be under /bin & /lib.
As for x86_64-linux-gnu, just weird; obviously for compatibility. I guess what is, is.

[dimkr]

As for x86_64-linux-gnu, just weird; obviously for compatibility. I guess what is, is.

Moving libraries to this directory allows libraries for multiple architectures to be installed side by side. Both 32-bit x86 and 32-bit ARM use /lib, while both 64-bit x86 and ARM use /lib64. This means you can install only two side-by-side - 64-bit x86 and 32-bit x86, 64-bit x86 and 32-bit ARM, 64-bit ARM and 32-bit x86 or 64-bit ARM and 32-bit ARM. But you can't install libraries for two 32-bit or two 64-bit architectures, because the libraries use the same paths.

This extra directory solves the problem. For example, on my computer, I have libraries for at least 5 architectures: I have 64-bit libraries for native applications, 32-bit x86 applications for Steam and Wine, ARM libraries (32 and 64 bit) and MIPS libraries (32 bit) for cross-compilation.

[MochiMoppel]

You might also want to grab the associated fdrv from your working F96. That's how I did it with ScPup 32 on my old Acer Aspire One netbook.

Thanks. Was worth the try but didn't help. I can boot to the desktop and many applications work, but Internet and some utilities don't.

@all Thanks for trying to help. What I get from this discussion is a sense that kernel creation and zdrv construction is a kind of black art. Confusing

[fredx181]

You might also want to grab the associated fdrv from your working F96. That's how I did it with ScPup 32 on my old Acer Aspire One netbook.

Thanks. Was worth the try but didn't help. I can boot to the desktop and many applications work, but Internet and some utilities don't.

@all Thanks for trying to help. What I get from this discussion is a sense that kernel creation and zdrv construction is a kind of black art. Confusing

As @ozsouth mentioned, Bookworm64 has a "usr-merged" filesystem , meaning that e.g. /bin and /lib are symlinks to /usr/bin and /usr/lib .
Older zdrv SFS's (e.g. from FossaPup) have inside /lib as a regular directory so that conflicts with the main puppy SFS from Bookworm (where /lib is symlink).
Solution can be to edit the zdrv sfs from F96, create /usr directory inside and move /lib to /usr so then you get /usr/lib/modules/....
(similar goes for the fdrv on a usr-merged system, it's /usr/lib/firmware rather than /lib/firmware).

[MochiMoppel]

Solution can be to edit the zdrv sfs from F96, create /usr directory inside and move /lib to /usr so then you get /usr/lib/modules/....
(similar goes for the fdrv on a usr-merged system, it's /usr/lib/firmware rather than /lib/firmware).

This is indeed a solution and so far works very well. Thanks!