KLA-Manjaro LXDE

[Sofiya]

@josejp2424

test: loads, but research shows no amd video drivers
or something was not delivered ,or something is not installed

Folder /sys/class/backlight is missing and there is no backlight control

most likely something is missing in the kernel

[Clarity]

... Then ran Grub4dos bootloader config since I'm just using bios boot for the vm. ...

You do know, that GRUB2Config builds proper boot instructions no matter if you are using a bios or a uefi in VM.

So even though you have a bios/uefi machine, virtual or bare-metal, is not a reason to choose one boot generator over another.

GRUB2 does everything and more than GRUB4DOS does.

Hope this info is helpful.

[JusGellin]

Here's my crude test of making a backup sfs file and testing to see if it works.

Here's the steps:
1. Make a backup of the current session
Menu>Accessories>PackIt
Make sfs file of upper_changes, call it _12MyBackupTest.sfs
2. Add a text file called MYTEST to the desktop.
3. Reboot and save the session.
4. See that the MYTEST text file is still on the desktop (it should be).
5 Rename the backup sfs to 12MyBackupTest.sfs
6 Delete upper_changes folder
7. Reboot and not save session.
8. When it comes backup there is no MYTEST text on desktop.
9. The upper_changes folder is recreated.
10. Select the save2flash shortcut on the desktop to reload the upper_changes folder with the current session.
11. The sfs file, 12MyBackupTest.sfs can again be renamed or deleted if not needed.
It seems to work.

I was wondering if the number in front of the sfs file is the order it is loaded or is just a reference to tell the system to load the sfs.

Thanks

[TerryH]

Here's my crude test of making a backup sfs file and testing to see if it works.

Here's the steps:
1. Make a backup of the current session
Menu>Accessories>PackIt
Make sfs file of upper_changes, call it _12MyBackupTest.sfs
2. Add a text file called MYTEST to the desktop.
3. Reboot and save the session.
4. See that the MYTEST text file is still on the desktop (it should be).
5 Rename the backup sfs to 12MyBackupTest.sfs
6 Delete upper_changes folder
7. Reboot and not save session.
8. When it comes backup there is no MYTEST text on desktop.
9. The upper_changes folder is recreated.
10. Select the save2flash shortcut on the desktop to reload the upper_changes folder with the current session.
11. The sfs file, 12MyBackupTest.sfs can again be renamed or deleted if not needed.
It seems to work.

I was wondering if the number in front of the sfs file is the order it is loaded or is just a reference to tell the system to load the sfs.

Thanks

The steps you have above, you create the 12MyBackup.sfs before you create the MYTEST text file. It won't be on the desktop when you reboot, as it wasn't there when you created the backup. It was in the upper_changes directory you deleted in step 6, created after the backup.

As upper_changes doesn't exist when you reboot, a new empty version will always be created.

[geo_c]

I was wondering if the number in front of the sfs file is the order it is loaded or is just a reference to tell the system to load the sfs.

Thanks

The number of the sfs file is CRUCIALLY IMPORTANT, because the numbers are the layered filesystem stack order. Files in lower number layers are overwritten by files with the same name in higher number layers.

The below considerations are especially important if you installed anything in upper_changes using the package manager before backing up and squashing:

You can roll back to a previous upper_changes by deleting the current one, but you can't skip numbers and delete an upper_changes with a lower number while leaving the higher. That will mess up the package manger,

So if I backup an upper_changes and call it 20upper_changes-SomeNewApps.sfs, delete current upper_changes.

Then I reboot and install more apps in the newly created upper_changes. Back it up, squash it to 21upper_changes-AddtionalApps.sfs. Delete current upper_changes.

Reboot again, and install more apps, backup and squash to 22upper_changes-EvenMoreApps.sfs.

Now the filesystem is stacked like this:
00-Modules.sfs
01-Firmware.sfs
07-RootFileSystem.sfs
20upper_changes-SomeNewApps.sfs
21upper_changes-AdditionalApps.sfs
22upper_changes-EvenMoreApps.sfs

It's a guarantee that you'll break your package manager if you delete or hide 20upper_changes and try to run with 21upper_changes and 22upper_changes.

You can roll back to 21upper_changes, or remove or hide 22 and 21 to roll back to 20.

It has to be sequential.

But as tried to demonstrate in a post above, it's possible to do all sorts of things with layers and removing and editing them if you don't mess up the crucial logic of the system, mostly the package manager.

EDIT: I say it has to be sequential, but you can renumber the layers, and there can be gaps in the numbering, but they have to be in the proper order to maintain the integrity of the package manager,

So I could renumber those three squashed layers:
20upper_changes-SomeNewApps.sfs
30upper_changes-AdditionalApps.sfs
58upper_changes-EvenMoreApps.sfs

and that will work just fine because the layers will still be stacked in the proper order.

[JusGellin]

@geo_c
Thanks for bringing up that clarifying informaiton.

In your example then, I can't get rid of 21upper only because it will break 22upper.
I have to get rid of 21 and 22. The order is from higher down of that named .sfs

Is there a rule for naming these if a seqence will be added?
20upper_changes-SomeNewApps.sfs
21upper_changes-AdditionalApps.sfs
22upper_changes-EvenMoreApps.sfs
Your example shows the name to the dash is the same but after the dash as different informaiton.

Also is the folder upper_changes to be left alone and to just allow the layers to set up what is used?
If the upper_changes folder is deleted and the save2flash shortcut is selected, does it rebuild from all the .sfs files again?

Thanks for your help. I appreciate it especially when you provide examples like this.

[geo_c]

In your example then, I can't get rid of 21upper only because it will break 22upper.
I have to get rid of 21 and 22. The order is from higher down of that named .sfs

That's correct

Is there a rule for naming these if a seqence will be added?
20upper_changes-SomeNewApps.sfs
21upper_changes-AdditionalApps.sfs
22upper_changes-EvenMoreApps.sfs
Your example shows the name to the dash is the same but after the dash as different informaiton.

No, that's just so it's easy to identify what's going on in my example.
You can literally put anything after the 1st 2 digits, except maybe spaces and special bash characters.
You could actually just call these layers
50
51
59
But you wouldn't know what's in them. I have all kinds of naming conventions just like we all have for other files. But the KL system is not bothered by the name, It's looking for the layer number 00-99, with 00, 01, and 07 being reserved for modules, firmware, and the rootfilesystem. So you can't rename one of your new squashed layers with 00 (corrected after reading @wiak's reply)

Also is the folder upper_changes to be left alone and to just allow the layers to set up what is used?
If the upper_changes folder is deleted and the save2flash shortcut is selected, does it rebuild from all the .sfs files again?

The upper_changes are created on boot if no upper_changes are found. That's automatic. So after squashing your backup, if you are running in w_changes=RAM2, which only saves when you use save2flash, then you can delete the upper_changes folder and immediately shutdown and reboot. You should immediately shut down because you just deleted the folder that any new operations might need to load executables from, and your new layer is not loaded yet. You can't load it with a load-on-the-fly tool like you find in pups, because it won't be layered into the filesystem the same way.

Now I don't personally run in RAM on any of my KL's or puppies. I save in realtime, and then backup, and delete my upper_changes from another instance in a KL-multi-instance install. Another purely genius invention of @wiak.

So because I don't run in RAM, I might be telling you the wrong way to build your system. But the KL builders like @Sofiya and @rockedge, @wiak and @fredx181, I believe run in RAM all the time and that makes building systems easier.

But me I use these as daily drivers and build them as I do my day job. So the multi-instance approach works great for me.

EDIT And if I wasn't clear about it, the upper_changes are ALWAYS the very top layer, so once you squash them, you must reboot to create a new one.

One more thought as I re-read the posts.

Just to be clear, a new upper_changes created on boot does NOT contain the files in the lower layers. Those are read only like puppy.sfs files, The upper_changes are instead fresh, for new files, much like a pupsave. Only difference with KL's is that the pupsave can be squashed and layered in as read only, then another upper_changes with basically nothing in it is created to store any new changes.

[wiak]

@geo_c
Thanks for bringing up that clarifying informaiton.
...
Is there a rule for naming these if a seqence will be added?
20upper_changes-SomeNewApps.sfs
21upper_changes-AdditionalApps.sfs
22upper_changes-EvenMoreApps.sfs
Your example shows the name to the dash is the same but after the dash as different informaiton.

Also is the folder upper_changes to be left alone and to just allow the layers to set up what is used?
If the upper_changes folder is deleted and the save2flash shortcut is selected, does it rebuild from all the .sfs files again?

Thanks for your help. I appreciate it especially when you provide examples like this.

Your general understanding is perfectly correct.

But sometimes very useful three things to remember:

First, only the two numeric digits of the filename are important, so you can rename layer as you wish except the numeric you give determines layer position. That is, for example, 07KLX.sfs could be renamed any of: 07xxxANYTHINGyyyyyy.sfs or even simply 07.sfs and it will be used for layer position 07 and work the same. ALL numeric named layers are treated as read-only when being booted and used. Only the unnumbered upper_changes folder is treated special and always used as the topmost layer of the stack and able to be written to during session i.e. it is read-write.

Second, in KL distros you can use normal directories as layer components (i.e. dont need to sfs compress them). So, for example could make own layer 21 and name it as directory 21mylayer or simply name the directory as 21 or 21whateverzzzzz... I make little uncompressed normal directory layers like that all the times to add in new firmware or text config files in appropriate internal filesystem structures. For example I might include a new firmware in numbered directory 45/usr/lib/firmware/mynewfirmware
Note that whilst you can easily edit these normal numbered directories, they are treated as read-only by the overlay filesystem layering software after rebooting. However, if you edit them such as adding in new files and reboot, the new or modified files will appear and be used in that reboot overlay.

Third, the upper_changes topmost layer is also just a normal directory. You can edit it prior to rebooting and the manual changes you made will then be seen in your new layer structure. You can even delete it (though lose whatever files it provided). If deleted a new empty upper_changes folder wlll be automatically created on next boot. You might want to make a backup copy before you delete it and experiment of course!!!

[wiak]

Note well that only numbered layer 00 is reserved for a special purpose. You can use different number for 01firmware or 07KL. Sometimes I use 08 instead of 07 or move firmware to different layer number or use more than one numbered layer for different firmware. It doesnt matter as long as you remember higher number layer files of same name and directory position will over-write lower numbered ones. Nothing actually gets deleted by layering effect; they just get hidden by the overlay so only deleted in that sense of being hidden and not used on reboot.

[wiak]

Could do with a perfectly improved doc on using KL numbered layers and stored in some easily found location....

An understanding and practice using it is really key to getting the most out of KL distros.

Multi-instance usage, whilst completely optional, is really really also useful in practice; allows user to experiment and break things yet still have plenty of other 'instances' to use instead (or differently). And multi-instance creation does not effect RAM or CPU resource usage and only needs a couple of kilobytes! of extra disk space per new instance to set it up. The effect is like magical yet effectively free.

No need to learn how to do multi-instances though, or can try that later. Can set it up easily at any time from already being used KL frugal install (which would become instance00).

[JusGellin]

The steps you have above, you create the 12MyBackup.sfs before you create the MYTEST text file. It won't be on the desktop when you reboot, as it wasn't there when you created the backup. It was in the upper_changes directory you deleted in step 6, created after the backup.

As upper_changes doesn't exist when you reboot, a new empty version will always be created.

I thought I responded to your post, but didn't.
I see that I didn't do it correctly and misled myself thinking it worked.

I've received so much good information on this. Thanks everyone!!

I'm going to do more testing to help my understanding.
I'll have to re-read this over a few times until I get it.

I'm using Manjaro-LDE-1.1 in a virtual machine that has a snapshot of its initial install that I can easily keep going back to
in order to start over when I make mistakes.

[JusGellin]

I noticed something I hadn't seen before on other Linux and Puppy installations.
When I set this distro up the internal disk as msdos, ext4, and then run Menu>SystemTools>Grub2bootloader config, it gives an error message
that mbr only accepts vfat/ntfs/ext2/ext3 and then fails.
But if I make it msdos, ext3, it works.

I was just wondering why this happens when I'm able to use that format for other installs and should it do that here also.
Thanks

[wiak]

I noticed something I hadn't seen before on other Linux and Puppy installations.
When I set this distro up the internal disk as msdos, ext4, and then run Menu>SystemTools>Grub2bootloader config, it gives an error message
that mbr only accepts vfat/ntfs/ext2/ext3 and then fails.
But if I make it msdos, ext3, it works.

I was just wondering why this happens when I'm able to use that format for other installs and should it do that here also.

Of course, the aim is always to make it work with anything relevant. Grub2bootloader config is new feature on KL as far as I know so probably has a few teething problems, missing bits, to iron out. Help if you can because that's ultimately the point of the forum - a place to learn, interesting powerful distros free to use, but a combined effort to produce them. Notification of missing bits is an important part of that since someone who finds time and has sufficient knowledge will later fix it for sure, but sometimes the person reporting, being closer to the issue, actually finds what the source of the issue is, which is a very satisfying feeling that will come to all of us now and then. But yes, part or full failure reports like these are welcome and useful and I have little doubt someone will provide the fix soon now that the issue is known.

[Sofiya]

it works for me on (msdos, ext4)
The question is which one (Grub2) do you use?
my bootloader was installed frugalpup-41
mode where you need to format into 2 partitions - Fat32 and ext4

[JusGellin]

I installed this on qemu virt-manager as a virtual machine using bios mode. That's probably why this happens for me.
This happens after I format the internal drive and run the menu item, Grub2 bootloader config to set up the boot part.

But I do have several other installs of various Linux installs that this doesn't happen.

I'm using the bios boot because several years back, it indicated that it can't make snapshots using uefi boot. I haven't looked to see if that still is the case.

Thank you @Sofiya and @wiak

[Amol]

Hello everyone !
@josejp2424: a very good release; a light looking, everything i tested runs like the way it should.Only a tool for managing touchpad is missing for me.
Keep up the good work,
Amol

[JusGellin]

Just a followup on bios boot in a vm not booting if drive is configured msdos ext4.

I ran Grub4dos bootloader on msdos ext4 drive with bios boot and that worked for this install.

So it seems that msdos ext 4 drive is capable of running, but the menu item Grub2 bootdloader config just doesn't accept it.
Thanks

[josejp2424]

I noticed something I hadn't seen before on other Linux and Puppy installations.
When I set this distro up the internal disk as msdos, ext4, and then run Menu>SystemTools>Grub2bootloader config, it gives an error message
that mbr only accepts vfat/ntfs/ext2/ext3 and then fails.
But if I make it msdos, ext3, it works.

I was just wondering why this happens when I'm able to use that format for other installs and should it do that here also.
Thanks

hi @JusGellin

MBR , only supports FAT32, EXT2, and 3. It does not support EXT4, which is a newer file system.

[josejp2424]

@josejp2424

test: loads, but research shows no amd video drivers
or something was not delivered ,or something is not installed

Folder /sys/class/backlight is missing and there is no backlight control

most likely something is missing in the kernel

hi @Sofiya
It's the Radeon drivers.

[rockedge]

Grub2bootloader config is new feature on KL as far as I know so probably has a few teething problems, missing bits, to iron out.

This is true. Adapting Grub4Dos and Grub2config to work in KLV-Airedale is still not 100% as far as boot stanza construction goes. Both programs work to install the boot loaders BUT both still write Puppy Linux syntax for the generated boot stanza's. I have not worked on that portion as of yet.

Experimenting with the latest grub2config versions it is clear the program is evolving and is still in the process of being fully adapted.

Would like to combine Grub2config and wd_grubconfig in some way.....

[josejp2424]

Grub2bootloader config is new feature on KL as far as I know so probably has a few teething problems, missing bits, to iron out.

This is true. Adapting Grub4Dos and Grub2config to work in KLV-Airedale is still not 100% as far as boot stanza construction goes. Both programs work to install the boot loaders BUT both still write Puppy Linux syntax for the generated boot stanza's. I have not worked on that portion as of yet.

Experimenting with the latest grub2config versions it is clear the program is evolving and is still in the process of being fully adapted.

Would like to combine Grub2config and wd_grubconfig in some way.....

If possible, combine wd_grubconfig, but it takes a long time to recognize all the KL in the system

[JusGellin]

Hello all,
I just wanted to mention this is really a great distro. I'm really liking all the work being done here and throughout the whole site.
Thank you all. I've received a lot of great help since I made my account at the beginning of this year.

I would like to make sure I'm doing what is right for this.
It looks like when something is new and improved, it is put into a forum to discuss it.
So people try it out and let it be known if they like it or not and submit when they find problems
or things that are strange to them.

Is my take correct? Being so new, should I mention what I see sometimes?
I'm not in any way just looking for the bad. I can see a lot of work and pride goes into all of this.
I'm enjoying the learning involved.

I'm still very new to this and see discussions going on about things way over my head.
At times I don't feel qualified to even ask my silly questions.
I feel free to be able to ask, though.

It's also a blast to look in on the different topics. Sometimes I even learn things.

[josejp2424]

Hello all,
I just wanted to mention this is really a great distro. I'm really liking all the work being done here and throughout the whole site.
Thank you all. I've received a lot of great help since I made my account at the beginning of this year.

I would like to make sure I'm doing what is right for this.
It looks like when something is new and improved, it is put into a forum to discuss it.
So people try it out and let it be known if they like it or not and submit when they find problems
or things that are strange to them.

Is my take correct? Being so new, should I mention what I see sometimes?
I'm not in any way just looking for the bad. I can see a lot of work and pride goes into all of this.
I'm enjoying the learning involved.

I'm still very new to this and see discussions going on about things way over my head.
At times I don't feel qualified to even ask my silly questions.
I feel free to be able to ask, though.

It's also a blast to look in on the different topics. Sometimes I even learn things.

@JusGellin
There's no such thing as a dumb question; everything is part of the learning process. The best way to learn is by asking and putting it into practice.

[Sofiya]

Grub2bootloader config is new feature on KL as far as I know so probably has a few teething problems, missing bits, to iron out.

This is true. Adapting Grub4Dos and Grub2config to work in KLV-Airedale is still not 100% as far as boot stanza construction goes. Both programs work to install the boot loaders BUT both still write Puppy Linux syntax for the generated boot stanza's. I have not worked on that portion as of yet.

Experimenting with the latest grub2config versions it is clear the program is evolving and is still in the process of being fully adapted.

Would like to combine Grub2config and wd_grubconfig in some way.....

By the way, I was able to draw a conclusion for KLV-Airеdale

but the output lines for Puppy had to be removed
the name for the lines is taken from the second section of ext4

[JusGellin]

What I usually do is the following. Notice that there is a file 10KLA-Manjaro.sfs. The SFS I created, I rename it to 13KLA-Manjaro.sfs. This makes it start with the system.

Back to understanding this.
For this iso, I see it has 07KLA-manjaro.sfs and 10KLA-Manjaro-03.sfs. Does the KLA make them related (07KLA and 10KLA)?
If they are related, inside 10 just contains a couple of folders, opt and usr with items different than the 07 has. So you can
turn 10 off and on but 07 would be the main sfs for the system to run.
How would you add small items like this to combine with a base like this?
In this example, how was it determined what was needed for the additional folders to have or not have a new feature?

I think that is showing a building on (10KLA) with new features to a base system (07KLA), right?

Thanks

[josejp2424]

What I usually do is the following. Notice that there is a file 10KLA-Manjaro.sfs. The SFS I created, I rename it to 13KLA-Manjaro.sfs. This makes it start with the system.

Back to understanding this.
For this iso, I see it has 07KLA-manjaro.sfs and 10KLA-Manjaro-03.sfs. Does the KLA make them related (07KLA and 10KLA)?
If they are related, inside 10 just contains a couple of folders, opt and usr with items different than the 07 has. So you can
turn 10 off and on but 07 would be the main sfs for the system to run.
How would you add small items like this to combine with a base like this?
In this example, how was it determined what was needed for the additional folders to have or not have a new feature?

I think that is showing a building on (10KLA) with new features to a base system (07KLA), right?

Thanks

07KLA-manjaro.sfs is the main sfs, 10KLA-Manjaro-03.sfs only contains the Midori browser. If you want to add
programs, you can create a new sfs with the number 13KLA-Manjaro-03.sfs.
Or you can decompress 10KLA-manjaro.sfs using the program Uextract, add the configurations or programs you
need, and then repack it with Packit.

[JusGellin]

@josejp2424
Good, that's how I thought it worked.

So how did you add the midori browser to 10KLA-Manjaro-03.sfs?
I see it contains two folders - opt and usr

Thanks

[josejp2424]

Hello everyone !
@josejp2424: a very good release; a light looking, everything i tested runs like the way it should.Only a tool for managing touchpad is missing for me.
Keep up the good work,
Amol

@Amol
Install this package and restart X. The touchpad should work.

https://sourceforge.net/projects/kla-ma ... kg.tar.zst

[josejp2424]

@josejp2424
Good, that's how I thought it worked.

So how did you add the midori browser to 10KLA-Manjaro-03.sfs?
I see it contains two folders - opt and usr

Thanks

@JusGellin
Download Midori browser for Arch, extract it with uextract, and copy it to SFS.

[JusGellin]

Great, thanks - pretty simple.