Puppy Linux Discussion Forum

Any Beginners Help, readme or FAQ ?

(Puppy Linux Derivative, or...?)

thanks...

I don't know either, I think it's a developer version, What is Kennel Linux ?

Been asked before and answered many times. To be frank, I think the question has no meaning. What is DebianDog, what is Puppy Linux, what is FatDog, and so on?; well... they are distributions that members of this forum develop and discuss and made freely available for others to choose from and use or not use. They are different designs, but all Linux designs contain a lot of components in common and may or may not use parts from others, and Kennel Linux does exactly that on this forum, but there is no limit to the number of variants and it is up to the developers of any such KL variant to make them any way they wish and to include whatever components they wish or agree to include. Yet again, let's just say, no, none of the current KL designs are derivative of Puppy Linux - the current KL designs are all derivatives of FirstRib, which since its first release in early 2019 has used a unique overlayfs based initrd and is constructed from a unique FirstRib build script system that has nothing to do with Puppy Linux design or Puppy's build system woof-CE.

There is, however, nothing to stop someone starting a KL design via a base Puppy Linux system and specially tailoring it to use major parts from other forum distros such as FirstRib, FatDog, DebianDogs. For example the unique FirstRib overlayfs initrd can be used with a Puppy Linux root filesystem (this has been demonstrated in the past) giving the FirstRib frugal install style of functionality but the more general Puppy Linux look and package management. However, none of the current KL distros have taken that approach since they have all adopted the FirstRib build system approach that uses the upstream repo official package manager (such as Void Linux's xbps or Arch Linux pacman or Ubuntu's dpkg/apt) along with upstreams init (such as systemd for the case of KL Ubuntu and Arch Linux variants or runit for the case of KL Void Linux variants).

Summary: KL distros are just alternative distro designs that anyone here is free to use. They are not Puppy Linux, which is another distro that anyone is free to use.

I'll try and give a short "layman's" explanation of what Kennel Linux is.

I'm currently running most of the Kennel Linux distros. All except KLU which is Ubuntu.

In a nutshell I would put it this way, a puppy is generally an operating system utilizing a puppy file system structure built from the woof builder, and uses packages from specific distributions. So when it's said that fossapup is Ubuntu based, that doesn't mean it functions as Ubuntu in any way. It simply means that it's built with packages from the Ubuntu repositories, so it will tend be friendly to applications and libraries available there.

Kennel Linux is more like (or perhaps exactly like) the core operating system of the upstream OS. So Kennel Linux Void is in fact a Void system constructed in a way that it is able to be "frugally" installed. I put "frugally" in quotes because it's not exactly like a "frugal install." There are no "savefolders" so to speak, instead the latest changes are stored in a persistent "upper_changes" layer of the filesystem. Grub4dos bootloader for instance sees Kennel Linux Void as a "Fully installed Linux" though in reality it's not a traditional full install at all. When booting a Kennel Linux, you see the boot process (init) of the base OS file system. It reports "Void LInux" and I assume this is the boot sequence you would also see with a full install of Void Linux.

Because it's built from a first-rib build script, a Kennel Linux will contain the desktop environment, utilities, and applications of the developer who implements the script.

I haven't downloaded and run a mainstream distro since I discovered puppy back in 2007 or so, and as such I'm not sure what installing one even looks like anymore. I still assume it requires formatting a dedicated partition, downloading an iso and running an install script.

Kennel Linux allows one to put a "mainstream OS" along side puppies in any location on a single partition and drive.

To me it's the best of both worlds.

wiak wrote: ↑Mon Jun 19, 2023 12:54 pm

......... FirstRib, which since its first release in early 2019 has used a unique overlayfs based initrd and is constructed from a unique FirstRib build script system that has nothing to do with...........

where is the best place to learn more about firstrib
how it works....
how it is different....
where I can find the scripts.....

geo_c wrote: ↑Mon Jun 19, 2023 2:11 pm

Kennel Linux is more like (or perhaps exactly like) the core operating system of the upstream OS. So Kennel Linux Void is in fact a Void system constructed in a way that it is able to be "frugally" installed. I put "frugally" in quotes because it's not exactly like a "frugal install." There are no "savefolders" so to speak, instead the latest changes are stored in a persistent "upper_changes" layer

frugal in that the filesystem can be a sfs?
can I keep more than one version on the same partition?

@williwaw The FirstRib documentation is scattered around a bit. Some is here -> https://firstrib.rockedge.org/

Information is archived here -> viewforum.php?f=130
There is more here -> https://oldforum.puppylinux.com/viewtop ... 56#1028956

I have scripts and PLUG file examples that I can put together and make available.

williwaw wrote: ↑Tue Jun 20, 2023 12:48 am

frugal in that the filesystem can be a sfs?
can I keep more than one version on the same partition?

upper_changes is a directory. Kennel Linux distros will load any folder or compressed file system like an sfs that is prefixed with a two digit number.

So the root filesystems and drivers are sfs files, and the current upper_changes directory is the user modifications. This directory can be renamed with a two digit number (higher than the sfs layers) and it will be loaded at boot time.

The only hitch with this ability is that you can't do it while running the system. It has to be done from outside the running KL system. Once this final piece is added, I think these OS will be gold. Highly valuable to me anyway, which they already are.

So once you number the current upper_changes to something like 30upper_changes-themetweaks, then it becomes part of the layered system and can be rolled back to by deleting the newly created upper_changes that appears automatically at next boot.

If you really like it, 30upper_changes-themetweaks can be squashed and named 30upper_changes-themetweaks.sfs.

And you can have different installs sitting next to each other on a partition in there own directories (which is why it definitely is a type of frugal install) or you can simply have different layers sitting in the same partitions as long as the ones you don't want to load aren't prefixed with a two digit number. So you could have two systems of layers, and switch them out by renaming the files/folders, or just move them into their own folders and switch them in and out of the system directory.

What you can't do is a build a system of sequential numbered changes and delete or move them out of sequence.
So I want to remove layer 27, I have to remove layer 29 and 28 also. If I want to put layer 29 back in, then I need to include 27 and 28.

So it's frugal, I have two copies of KLV-airedale (folders named differently, KLV-airedale and KLV-airedaleDEV) on a USB stick along with KLA, KLV-Spectrwm, F96, jackalpup, and F95 all running off a single partition. Same for my laptop hard drives also.

nice, this would allow me to use a rolling release and roll back if a new build didnt go well, and I wished to abandon the effort.

what is the use case for so many layers in your example?

How to build a FirstRib OS -> viewtopic.php?t=4702

@rockedge

where is the best place for firstrib discussion? the firstrib forum doesnt look very active. and that topic is locked

williwaw wrote: ↑Tue Jun 20, 2023 2:20 am

nice, this would allow me to use a rolling release and roll back if a new build didnt go well, and I wished to abandon the effort.

what is the use case for so many layers in your example?

Glad you asked, I've been building a system of apps and themes, scripts, utilities, a ton of links to files outside the install directory, etc ever since I downloaded the first KLV-beta. I started from scratch only once. I have rolled back a few times after mangling some things while experimenting. Here is the usb stick I was talking about. In the KLV-airedaleDEV directory on the left you can see that I dropped @rockedge's new RC root system sfs's in at various times and labeled my upper_changes accordingly, because if I ever needed to rollback, I would need to put the RC root filesystem back in so that they would function correctly. I have never needed to do that however. I'm not saying my approach is "tidy," but it's logical, and my KLV-airedale is extremely polished and beefed up with my most beloved applicatons as well as themes.

EDIT: also on the right you see I have directories name KLV-bkp and these contain numbered upper_changes and the current upper_changes. I don't like leaving that stuff to chance, and KL distros are as versatile as puppies in that regard once you get the hang of manipulating the persistance folders.

williwaw wrote: ↑Tue Jun 20, 2023 2:24 am

@rockedge

where is the best place for firstrib discussion? the firstrib forum doesnt look very active. and that topic is locked

Since the FirstRib build system and special overlayfs-based initrd is used so much to produce current Kennel Linux distributions, I'd suggest you organise some documentation in new threads/sections under Kennel Linux section and discuss these matters in relation to KL builds there too. As rockedge says, FirstRib docs are a bit all over the place so organising that from KL point of view is a job someone could take on to advantage for anyone using KL distros. Aside from that old forum, which doesn't really have much in it (or getting old), the archived FirstRib sections do contain a lot of probably always useful info, and I have a blog I sometimes write to (on holiday... at the moment only) at https://www.tinylinux.info/ that contains some more solid FirstRib-related info.

The archived FirstRib HowTo "Cheat Sheet" is probably the best source of most information outside of above tinylinux info blog FirstRib material: viewtopic.php?p=36426#p36426
Note that the name of the distros I was building changed back to their original "FirstRib" Linux name rather than somewhat confusing WDL name (I preferred original designation), but the technical details didn't change at all.

One day I do hope to create a specific FirstRib-related website, but that may be a year from now so I wouldn't wait for that since KL is pretty active as a distro area.

My two sons and myself use FirstRib built and based KL distros all the time, so FirstRib components are likely to be supported for many years to come no matter how much or how little it continues to be used in KL distro designs (I continue to read threads in KL-related areas). I'm just busy in complex job of moving home and country for all of coming year; slow process sorry - not travelling light though wish I was really... result I suppose of modern disease consumerism (lots of cables, computers, books, technical junk in my case...). But at least I got as far as polishing FirstRib build system and FR initrd sufficiently to be long time hopefully useful as a distro building system, though much can be improved later and particularly in terms of user-created system script components for the likes of managing the FR-provided layer rollback capabilities and so on. It is definitely a case of many hands make light work.

Two of the key features of FirstRib that make it particularly useful (for me anyway):

1. the FR initrd can be used to boot pretty much any pre-built root filesystem, which is why the old weedogit script was able to take most any mainstream iso (such as Linux Mint, for example) and use its root filesystem to provide a FirstRib-style frugal installation of Linux Mint (and similarly with Manjaro and so on).
2. The FR build system script can be used to build a unique root filesystem to user's design. Basically it provides a skeleton filesystem structure starting with nothing in it but busybox binary and then allows the user to add an upstream package manager (or not) and, optionally, can provide a barebones init script just to get things going. In other words, simplest FR root filesystem ends up just with simple init shell script and busybox and whatever binaries (other than busybox) the user includes via their build script plugin (addon). Usually, however, the builder uses FR build script option to include an upstream package manager, and thereafter of course the user build script plugin (just a list of commands really) can use the then included package manager to include whatever other upstream repo components they want. For example, first major distro that was targetted was based on FR initrd, busybox, and Void Linux's xbps package manager, so using that choice (which rockedge employs) you can add the likes of runit (Void Linux alternative to systemd or old sysVinit). The end result of such a build is fully compatible Void Linux root filesystem (but only includes whatever packages and system components the FR builder wants to include... e.g. alternative desktop managers and apps and so on). And the FR initrd then boots that root filesystem to provide all the frugal install capabilities the KL distro user is familiar with; and the build is made to include various user-created system shell scripts that help manage that FirstRib functionality (such as Fredx181 save2flash script to help utiliise FR "RAM2 save on demand mode).

The end result of many KL designs is more about the user system shell scripts and configurations (e.g. themes the FR builder includes or utility/system apps taken from elsewhere such as Puppy Linux for example), especially if a desktop like XFCE is added from upstream repo since XFCE provides a well-known stable and quite comprehensive environment that is quite efficient even on ten year old computers. But it is perfectly possible to use simpler desktops like JWM or openbox with the likes of tint2, but much more user/builder work is then required to be included in the user-created build plugin since simpler desktops don't themselves provide much of a desktop environment (apps/utilities/configurations needed and so on). Or can just build the simplest of systems using FR build script with no package manager even, with or without X or Wayland or whatever, but such a system has much less use for most people than one that provides a typical XFCE or similar capability. You can of course decide to include pulseaudio, or pipewire, or X, or Wayland and so on, though some configuration may well be required in your build system plugin script depending what you are intending to achieve. You can also start with a simple initial build and then add to it and remaster the final result of course.

ok

pup2023 wrote: ↑Thu Jul 13, 2023 1:30 pm

tmi https://forum.puppylinux.com/viewtopic.php?t=9158

Too Much Info according to you, but that would depend on your level of interest in Kennel Linux and on your expertise. Maybe you just need it explained to you slowly that Kennel Linux is a distro, like other distros are distros... Too Little Info.
(TLI). But comes across to me like you are wasting my dev time with unnecessary back-comments.

Hi,

I've read some topics about Kennel Linux but still have some questions.

I understand that one can keep the original full installation at root / and install several Kennel Linux systems, one at each directory under /.
Besides having disk space for all 'distros', what is gained vs. having a GPT partition for each one of those?

What is your use case for all these Kennel systems?

I read about creating a SFS from Firefox that could be considered portable. Do you share SFS between the Kennel 'distros'?

Or do you share only home data SFS? If so, is it so different from having a separate /home directory that could be mounted in each distro when it's running?

Do you do any kind of advanced SFS 'architecture' in between 'distros'? Like sharing some, avoid some others for some of the distros?

Thanks.

libertas wrote: ↑Tue Nov 07, 2023 11:02 pm

I've read some topics about Kennel Linux but still have some questions.

I understand that one can keep the original full installation at root / and install several Kennel Linux systems, one at each directory under /.
Besides having disk space for all 'distros', what is gained vs. having a GPT partition for each one of those?

Sounds to me like you are mixing things up a bit because Kennel Linux is very flexible so there are different ways of using them, but you shouldn't mix the alternatives all together in terms of understanding how one method works.

The first question I'd have of you is: have you ever used the other distro on this forum called Puppy Linux?

If so, it is pretty easy to understand the main way Kennel Linux distros are used, which is as frugal installs, pretty much same way as Puppy Linux distros get installed in their own frugal install subdirectories of some partition. The difference is that Kennel Linux distros do not use Puppy Linux initrd.gz at all. Nor are they constructed using woof-CE so their underlying system scripts are completely different. And also the boot loader config arguments required by KL distros are not related to the ones used by Puppy Linux, since it is an entirely different distribution. So, if you have installed Puppy Linux and find it useful being able to install several varieties of it in separate subdirectories and boot these independently then you can enjoy exactly the same frugal installation advantages with KL distros. Of course you can make frugal installations in separate partitions if you so wish, but I can't say there is any advantage (or disadvantage really) in doing so.

We do not in usual practice ever made full installations of any KL distribution. And, like Puppy Linux, KL frugal installations are comprised of a kernel (vmlinuz) an initrd.gz, and various sfs files that get overlayed together on boot to create the overall filesystem. The existing KL distros all use a unique 'FirstRib' initrd.gz that has always used overlayfs as the overlay method (Puppy Linux on the other hand traditionally uses aufs as its overlay method, which is very different, but does a similar job).

What may have confused you is that the unique FirstRib initrd.gz is actually able to boot an existing full installed major upstream distro (such as full installed Linux Mint) in such a way that it behaves then as a frugal installation, which has the advantage that all the frugal install 'tricks' then work with it. But until you have some experience with normal KL frugal installs (which is all most people probably use) I'd just forget about that special other ability for now.

Summary: using a KL distro is just like using Puppy Linux or Debian Dog distros except they are all different distros in terms of how they implement their frugal installations, but the end result is very similar in the way they work with addon sfs files. It comes down to choice, and what you find you prefer or most efficient. That's all.

@libertas :-

libertas wrote: ↑Tue Nov 07, 2023 11:02 pm

I've read some topics about Kennel Linux but still have some questions.

What is your use case for all these Kennel systems?

A 'simplistic' answer - probably not within the scope of this query - or not what you're wanting! - would be to ask ANY enthusiastic Linux user a similar question:-

"Why do you run more than one operating system? Where is the point?"

That's exactly what you'll get from most Windows, Apple or Android users. They simply don't understand. It's something best known only to the individual.....

(*shrug...*)

Mike.

mikewalsh wrote: ↑Fri Nov 10, 2023 10:41 am

A 'simplistic' answer - probably not within the scope of this query - or not what you're wanting! - would be to ask ANY enthusiastic Linux user a similar question:-

"Why do you run more than one operating system? Where is the point?"
Mike.

More specifically, to me, formatting partitions to install a new portable OS like the ones found on this forum is a pretty big deal, as formatting drives is dangerous to the data.

I have anywhere from 5-10 different OS's installed on any drive on any of my machines. With these OS's, puppy-linux & Kennel Linux, I can delete or add OS's in about 5 minutes.

Copy the OS files into a folder, add a boot stanza to my boot loader, and I'm good to go.

I see absolutely no downside to this approach, only advantages.

Of course if for some reaon I wanted each OS on it's own dedicated partition, there's nothing stopping me from setting up these same OS's like that. There simply isn't much reason to do it however.

@geo_c :-

Absolutely, mate; I couldn't agree more with you. But I'm kinda playing "devil's advocate" here; you can see where I'm coming from, yes? From the average computer user's viewpoint - who probably spends a good part of their time fighting a balky Windows system - they can't possibly comprehend why some of us voluntarily choose to run 2.....or 3....or 5.....or 10....or 20 OSs! They have problems with just one; from their point of view, we must be masochists of the highest order!!

Of course, 99% of these have never tried Linux at all, so don't realise how much more straight-forward & rewarding it can be......

(*shrug...*)

Mike.

FIY, I run Linux in more than one distro, NetBSD, FreeBSD, OpenBSD, Haiku and DOS and also use Windows professionally.

I'm curious about the use cases because I'm trying to widen my perspective hearing from others.
There are some people that prefer not to answer and to address things a different way.

So, I'll ask in a different way.
Being puppies and kennels derived from different Linux distros, does it make sense to have SFS with configs or with programs installed (with dependencies) that can be applied irrespective of the main distro.

Ex: From a puppie created from debian, what kind of SFS can I create there that can be applied to Slacko?

libertas wrote: ↑Tue Nov 14, 2023 12:44 pm

Ex: From a puppie created from debian, what kind of SFS can I create there that can be applied to Slacko?

If that is the question you are asking it in the wrong forum section. I'd suggest you need to ask it maybe in Puppy Slacko main section: viewforum.php?f=118
Or on Puppy Linux sections of the forum (Users area maybe viewforum.php?f=4) but not in Kennel Linux section which is entirely different distro to Puppy Linux itself.

Personally I continue not to actually understand your question. Maybe my brain is not functioning (?) so I'll leave others to answer wherever they consider appropriate.

I would add that an sfs is just a filesystem in directory format that has been squashed up. You can certainly add it as a layer in Kennel Linux or to a Puppy Linux distro. Whether it turns out to be appropriate to use debian components when you are adding it as a layer to a Slackware distribution depends on the likes of binary compatibility, which includes what shared libraries it depends on. Some programs can be assembled in almost standalone portable format so often work even in these mixed environments, but not always - up to the sfs creator to make sure the result breaks nothing in the main distro.

In what way do you 'run Linux in more than one distro' such as DOS, for example? Are you talking about running Linux in a virtual machine - that's just Linux when run in that way no matter the host OS used.

This document creation date: 25May2024 Revised: 25May2024

The Kennel Linux FirstRib-based distros

HISTORY AND ...

The original FirstRib-based distros were called WeeDog distros. However, since much user-level functionality was missing, I suggested a few years ago, in a PM to the main admin and creator of the new Puppy Linux forum, rockedge, the idea of a “Kennel Linux” named distro, whose only design requirement was that it should use parts from any forum project to encourage collaboration and also thus benefit directly from wider forum project creativity.

Though I offered up an old WDL_Arch FirstRib-based design to be KL developed in order to start the ball rolling, my idea was that a KL distro could be built from any forum project component parts such as different initrd, different root filesystem build systems, different main system init systems, and whatever utility apps and portable addons forum members liked to use. Nevertheless, in practice, all current KL distros have been constructed using the general purpose FR initrd and often a root filesystem built by the FR build system script, but longer-term that FR-relationship is actually optional in the intentionally more generic Kennel Linux part of the forum. The rest of this document will concern itself with FirstRib-based KL designs only.

The FirstRib project itself began in May 2019 as a root filesystem builder that utilised internally only two main pieces of software: a static build of busybox, and (optionally) a static build of Void Linux package manager xbps. The root filesystem builder was specially designed to be easy to use since it only requires the distro builder to write a simple text file (f_XXX.plug) containing basic Linux commands to optionally use whatever package manager chosen to be provided and to configure the resulting root filesystem ready for booting via a suitable initrd, or for direct use within the likes of a container or chroot.

By June 2019, FirstRib included the design and build of a simple version of the current FR initrd for booting it as a distro in its own right, the bootable distro being called WeeDog at that time as a nod towards the Puppy Linux forum that FirstRib was first announced and discussed on. The FirstRib system is not however derived at all from Puppy Linux and from its 2019 start used overlayfs and not aufs for its layered filesystem.

The root filesystem build component of FirstRib is a simple single bash script, which in addition to an ability to build perfectly Void Linux compatible root filesystems, has since early 2019 also been able to build root filesystems (via an approprately written f_XXX.plug) that are fully compatible with Arch Linux or, using official Debian debootstrap underneath, root filesystems that are fully compatible with Debian, Devuan, or Ubuntu, as well as Fedora and more besides.

It was and is, however, possible to complete FirstRib builds without using any of the provided package managers, and/or only using a package manager to the extent desired by the distro builder such that FirstRib can be used to build extremely small (micro/mini) distros when so desired, but all FirstRib-based distros always include full FirstRIb provided frugal install flexible functionality. For example a KL/FR builder could provide a simple main root filesystem init system of their own to control the end created distro along with a selection of small self-compiled apps, with or without GUI support.

Furthermore, the FirstRib initrd was designed from scratch and without copying code from any other initrd design. It provides the typical frugal install flexibile feature set a typical forum member might want or expect (such as providing save persistence directly or only by demand when save is wanted or even full copy to and run from RAM), but includes the ability to use up to 99 numbered sfs addon layers, where the 2-digit start of the addon file name determines the layer position that the addon contents will be merged into the filesystem as a whole.

A particularly powerful feature of FR layering is that the addon layers can be either compressed squashfs (sfs) filesystems, and/or normal directories (which provides many powerful benefits including making their contents thus simple to edit and modify).

All the addon layers can be stored either in the original boot directory or anywhere else on the system (or both); they can even be stored inside the initrd itself. A set of boot manager kernel line arguments are used to indicate where everything is. Alternatively, a simple boot directory text file called w_initconfig can be used to provide the same sorts of information. FR can use either official upstream kernels or specially created huge kernels plus module and firmware addons, such as used in Puppy Linux systems.

The FR initrd itself was specially designed to allow its main overlayfs functionality and algorithm code to be easily edited and thus modified for any purpose without usually having to uncompress the initrd. This ease of editing the boot init per developer wishes was achieved through spitting the init into two separate parts:

1. a simple init stored inside the compressed initrd that simply contains the code needed to mount the partitions where the FR distro has been installed.
2. w_init, which is a simple text file of Linux commands that can be stored outside the initrd and is thus directly editable with any available text editor.

All of the above features are also implemented such that they work correctly when any KL/FR distro is booted as an iso via Ventoy.

The most important aspect of FirstRib-based distros is that its initrd has been designed to be root filesystem agnostic, so can boot any of the above root filesystem builds, or any official root filesystem available from upstream repos of these distros, but also pretty much ANY root filesystem from most any other distro available elsewhere (a capability usefully employed in old "weedogit" system builder which could frugal install most any big Linux system via an underlying FR initrd). The end result is ALWAYS a FirstRib initrd frugal installation with all the flexible features such as save on demand persistence and addon sfs or uncompressed directory layers that FirstRib design automatically provides.

fredx181 wrote:

Oh, and contains hidden spam, delete it.

Found the spam link before I deleted the user and the post when I saw your post