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]

[tooltip][/tooltip]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).