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 those numbers.

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.