KLV-Airedale-beta23 with Puppy Linux (Debian) 5.19.11-kernel-kit

[rockedge]

And I was asking about creating an sfs from the upper_changes, and last night I finally realized that the tool is included in KLV.

@geo_c, This is what I use to squash /upper_changes into 07KLV-airedale_rootfs.sfs

Code: Select all

mksquashfs upper_changes 07KLV-airedale_rootfs.sfs  -b 1048576 -comp xz -Xdict-size 100% -noappend

[rockedge]

@geo_c I've been neglecting keeping some important small tools that exist in KLV and are from FirstRib builds from long ago. One is /usr/local/bin/wd_mount which mounts any available partition from the command line. Usable in scripts.

Code: Select all

wd_mount --help
wd_mount sdb1
wd_mount sdd2

[geo_c]

Maybe I just need to create the folder with the label name in /run/media/root first, and then mount it. Or will I break something?

In a do-ocracy you just have to break a few things to figure it out.

Thanks @rockedge, that's probably a better approach than breaking all my usb drives full of installs.

[geo_c]

And I was asking about creating an sfs from the upper_changes, and last night I finally realized that the tool is included in KLV.

@geo_c, This is what I use to squash /upper_changes into 07KLV-airedale_rootfs.sfs

Code: Select all

mksquashfs upper_changes 07KLV-airedale_rootfs.sfs  -b 1048576 -comp xz -Xdict-size 100% -noappend

but what if I want to squash 10 layers, can I list multiple directories? That doesn't seem right because actually what I want to do is merge them, which seems a wee bit more complicated. The newer ones would have to white out or overwrite the older ones.

[rockedge]

here is a look at it

Screenshot(39).jpg (18.67 KiB) Viewed 1035 times

Here are two scripts that work together for w_changes=RAM0 mode. The save tool and then the merge tool. All still in development stage.

[geo_c]

@geo_c I've been neglecting keeping some important small tools that exist in KLV and are from FirstRib builds from long ago. One is /usr/local/bin/wd_mount which mounts any available partition from the command line. Usable in scripts.

Code: Select all

wd_mount --help
wd_mount sdb1
wd_mount sdd2

It seems to me from my best guess, that Void, or maybe Xfce, is doing something a little tricky to display the mounted file system in devices, and show it on the desktop. From what I see so far wd_mount will put the mounted device in /mnt, which my script is actually doing successfully. It's just that the device disappears from Thunar and the desktop, because it's not mounted in /run/media/root. But that mount point doesn't exist until it's mounted.

Perhaps the wd_mount script could be adjusted to accomodate that file system structure. I'm guessing it's not really necessary to mount the same way as Void. It's only an issue when mounting using a script or command line. It changes the location of the mount point from where it would normally occur by clicking on the desktop icon or using Thunar.

[geo_c]

So what I struck out of that earlier post is perhaps first creating the directory for the drive in /run/media/root and then running the command: mount /dev/disk/by-label/my-label /run/media/root/my-label would achieve the same result as clicking on it in Thunar.

[wiak]

And I was asking about creating an sfs from the upper_changes, and last night I finally realized that the tool is included in KLV.

@geo_c, This is what I use to squash /upper_changes into 07KLV-airedale_rootfs.sfs

Code: Select all

mksquashfs upper_changes 07KLV-airedale_rootfs.sfs  -b 1048576 -comp xz -Xdict-size 100% -noappend

but what if I want to squash 10 layers, can I list multiple directories? That doesn't seem right because actually what I want to do is merge them, which seems a wee bit more complicated. The newer ones would have to white out or overwrite the older ones.

I remember fredx181 supplied a remaster tool a while back - is that not included or did it need some tweaking (I'm in new FR_Arch build at the moment)? I was meaning to look out that remaster tool since that is nicest way to slim distro back down to original size when many upper_changes files exist though the merge tool is also very useful and particularly when you want to keep original base KLV rootfilesystem sfs untouched. I really like KLV nowadays - it amazes me how small and powerful it is compared to other distro XFCE creations. Definitely at a time/stage to polish up these extra utilities like merge and remaster and so on.

From a development point of view the most important items to get into most complete state possible are the f_plug build file, the build_firstrib_rootfs script that uses that, and of course the underlying initrd that provides the overlayfs functionality. With these in good shape it is thereafter very easy to tweak and remodel to other forms and system facilities/requirements.

[geo_c]

[I remember fredx181 supplied a remaster tool a while back - is that not included or did it need some tweaking (I'm in new FR_Arch build at the moment)? I was meaning to look out that remaster tool since that is nicest way to slim distro back down to original size when many upper_changes files exist though the merge tool is also very useful and particularly when you want to keep original base KLV rootfilesystem sfs untouched.

Yes, I think ideally we would want to remaster the upper_changes and leave the base system in tact. I'm looking at the scripts @rockedge provided. And I'm guessing I'll need to add a stanza to menu1st to boot in RAM0 and then try the merge from a clean system.

I really like KLV nowadays - it amazes me how small and powerful it is compared to other distro XFCE creations.

I haven't used a ton of distros, not very many in the big scheme of things. But from what I can tell KLV really pops. @rockedge was mentioning speeding up boot time, but that's one thing I think is super fast. I don't actually clock that stuff, but by feel it's speedy.

To me it's lean in all the right ways while maintaining a sense of bling and functionality.

[rockedge]

I remember fredx181 supplied a remaster tool a while back - is that not included

That's right, I don't think it made it in yet. Do you remember any clues to the location of the original post?

[geo_c]

So what I struck out of that earlier post is perhaps first creating the directory for the drive in /run/media/root and then running the command: mount /dev/disk/by-label/my-label /run/media/root/my-label would achieve the same result as clicking on it in Thunar.

@rockedge, that actually worked. The mount script looks like this:

Code: Select all

mkdir /run/media/root/my-label
mount /dev/mmcblk0p1 /run/media/root/my-label

And it all shows up where it should on the desktop and in thunar. Really quite simple, it just takes me awhile to get a grip on reality, but there is a catch. Unmounting from a right click on the desktop does in fact unmount, but it doesn't remove the directory from /run/media/root like it usually does.

My unmount script will remove that directory, but mix and match might not be the best idea. I'll play around with it.

Also I should probably try the original command:

Code: Select all

mount /dev/disk/by-label/my-label /run/media/root/my-label

Just in case the drive letters are different than expected, since KLV is displaying drives by label everywhere else.

[wiak]

I remember fredx181 supplied a remaster tool a while back - is that not included

That's right, I don't think it made it in yet. Do you remember any clues to the location of the original post?

Done a big digging re: fred's remaster script that may/should work and here are some of the main posts I found in earlier to later date order.
Worth checking this works and incorporating it in KLV for sure!

https://firstrib.rockedge.org/viewtopic.php?p=216&i=2

https://forum.puppylinux.com/viewtopic. ... 319#p36319

This later fredx181 comment contains additional useful info regarding the process: https://forum.puppylinux.com/viewtopic. ... 495#p36495

and yes, @geo_c, tidying up and improving mount options flexibility would be well-appreciated also.

[fredx181]

That remaster script doesn't work for KLV as is now, but I will have a look at it to modify for KLV (problem may be the multiple SFS's in KLV, probably best to remaster to just one rootfs SFS (then the others should be disabled) .

[rockedge]

I just ran the remaster script but stopped it during the final squash into a rootfs SFS. Up to that point it certainly seemed to be doing something and a SFS was underway to being built.

Further tests required but a good indicator.

[fredx181]

@rockedge Yes, probably you changed on top of script to MAINSFS="07KLV-airedale_rootfs.sfs" , then it works well, except that the exclude list would need some changes (was made for Weedog Manjaro initially).
How it is now is in fact a very simple concept, mksquashfs builds 07KLV-airedale_rootfs.sfs directly from / and the great -e and -wildcard options of mksquashfs work well to exclude files and folders (for example /proc/* or /sys/*).
So I could adjust some (e.g. exclude list) to make it more suitable for KLV, keeping the same concept.
But that needs some user actions, e.g. rename other .sfs's to .bak (as these are all merged in 07KLV-airedale_rootfs.sfs) and rename to upper_changes.bak (as the changes are in the rootfs already after remaster).

Perhaps ideally would be that only the changes are merged (not the other sfs's) in the new rootfs .sfs but that'd make it far more complicated.
What's your opinion ? (or anyone else)

[geo_c]

@rockedge Yes, probably you changed on top of script to MAINSFS="07KLV-airedale_rootfs.sfs" , then it works well, except that the exclude list would need some changes (was made for Weedog Manjaro initially).
How it is now is in fact a very simple concept, mksquashfs builds 07KLV-airedale_rootfs.sfs directly from / and the great -e and -wildcard options of mksquashfs work well to exclude files and folders (for example /proc/* or /sys/*).
So I could adjust some (e.g. exclude list) to make it more suitable for KLV, keeping the same concept.
But that needs some user actions, e.g. rename other .sfs's to .bak (as these are all merged in 07KLV-airedale_rootfs.sfs) and rename to upper_changes.bak (as the changes are in the rootfs already after remaster).

Perhaps ideally would be that only the changes are merged (not the other sfs's) in the new rootfs .sfs but that'd make it far more complicated.
What's your opinion ? (or anyone else)

If the merged rootfs.sfs was loaded into ram, that might be problematic for me, as the whole system is up around 3.7GB now, though it might be considerably smaller when merged.

[rockedge]

@fredx181 Yes that's right! I changed those two variables and the run was on it's way to a successful completion.

There was some other function that you made that when I woke up in the morning said "that must be included" but right now I went to do it and I can't recall what it was!

Time for some coffee.

P.S. one thing is make a .desktop file for mksplash

[fredx181]

New remaster tool specially for KLV-Airedale (xbps package) here; https://forum.puppylinux.com/viewtopic. ... 341#p71341

There was some other function that you made that when I woke up in the morning said "that must be included" but right now I went to do it and I can't recall what it was!

Perhaps the xfce-desktop.xml ? (for that every monitor option is perhaps covered, showing the KLV wallpaper)
Yes if you want , include menu item for mksplash .

[wiak]

So what I struck out of that earlier post is perhaps first creating the directory for the drive in /run/media/root and then running the command: mount /dev/disk/by-label/my-label /run/media/root/my-label would achieve the same result as clicking on it in Thunar.

@rockedge, that actually worked. The mount script looks like this:

Code: Select all

mkdir /run/media/root/my-label
mount /dev/mmcblk0p1 /run/media/root/my-label

And it all shows up where it should on the desktop and in thunar. Really quite simple, it just takes me awhile to get a grip on reality, but there is a catch. Unmounting from a right click on the desktop does in fact unmount, but it doesn't remove the directory from /run/media/root like it usually does.

Sorry, was too busy when you first posted above @geo_c, but I took note of it since definitely worth coming back to later as a possible extension to wd_mount that would bring it into line with what thunar in Void expects (and worth checking similarly for similar with pcmanfm and in my KLA - Arch build). Not sure when I'll get round to experimenting with that, but thought I'd at least mention that your idea did raise my interest and will be worked on more eventually, or suggest your own patches to wd_mount and can experiment with these. The issue with mount directory not getting removed at the end reminds me of a similar issue with filemnt when used to mount isos or sfs files - leaving behind mount dirs if user not consistent in unmounting via filemnt later; as a result of that situation, not a bug per se, I tend to end up with tons of empty mount directories hanging off /mnt so have to eventually delete them manually.

[geo_c]

The issue with mount directory not getting removed at the end reminds me of a similar issue with filemnt when used to mount isos or sfs files - leaving behind mount dirs if user not consistent in unmounting via filemnt later; as a result of that situation, not a bug per se, I tend to end up with tons of empty mount directories hanging off /mnt so have to eventually delete them manually.

Well I haven't tried it since I originally posted, but re-reading jogs my memory, and what's a little odd is that if I mount with a script by creating the mount point first, the icon shows up on the desktop mounted. And I can unmount from the icon, but Xfce doesn't remove the directory mount point.

So that suggests that there must be an entry in a file somewhere that has to be updated in Void or Xfce that the right click unmount command references to remove that mount point directory. But it seems strange that it's able to display an icon on the desktop and still not know to remove the mount point when unmounted.