Discussion, talk and tips
https://forum.puppylinux.com/
Yes, you can copy the files out of the iso and use grub2 or grub4dos to boot - that's what I'd do usually. My simple recent script weedogit.sh in fact does almost exactly that (automates the process) for other distros altogether. But with KLV-Airedale - just copy all the files out (well, you do only need main system files, sfs parts and so on) and then fix up your grub config to boot it.
fredx181 wrote: ↑Sat Feb 19, 2022 7:53 pm/mnt/home is pointing to /mnt/sdb1 and somehow it doesn't get replaced with current mount partition correctly by the script (in my case it's sda7, which became a symlink inside /mnt/home, so became /mnt/home/sda7 which is wrong, /mnt/home should lead directly to contents of sda7 in my case)
This change in '/root/my-applications/bin/swapper.sh' should fix it:
This foreshadowed some questions I have, because I either don't understand something in the loopback design or, something isn't reporting right, as Thunar successfully mounts my sda1 hard-drive while my home directory is sdb1, and can even launch a @mikewalsh portable from sda1, but then nothing else sees that sda1 drive -- not the portable app launched from it, not ROX, and not the terminal. So I think there is an issue in there somewhere.
@geo_c try this test: open a terminal and use the command
Code: Select all
wd_mount sda1then open Rox and go to /mnt and you should see sda1 mounted.
Also experiment with the pup-volume-monitor xbps package that fredx181 made. Install it and reboot. See what you can do with it. You should see double the partition/drives icons, one set from gvfs and the other from the pup-volume-monitor
rockedge wrote: ↑Sun Feb 20, 2022 3:12 am@geo_c try this test: open a terminal and use the command
Code: Select all
wd_mount sda1then open Rox and go to /mnt and you should see sda1 mounted.
Yes that command did the trick. So now ROX, and my applications are seeing and accessing sda1, I'm playing a Musescore file with @mikewalsh's portable and pulse audio is the driver. That's all good.
But oddly, Thunar isn't showing anything on sda1, yet some of the sda1 directories I accessed show up in sdb1, the home drive. So it's kind of like the tables are flipped or something.
wiak wrote: ↑Sat Feb 19, 2022 11:53 pmfredx181 wrote: ↑Sat Feb 19, 2022 7:53 pmBtw, maybe /mnt should be empty at initial boot (i.e. changes not containing anything in /mnt e.g. no leftover previous mounted folders), not sure though, @wiak what do you think ? (think of also the issue lately with filemnt, the previously mounted folder inside upper_changes/mnt).
Yes, I've occasionally pondered about that too. Shutdown script should maybe be tweaked to empty it?
On many of my systems over the years, I maintain some mount local use in /mnt that I create on pristine boot; eg. # mkdir -p /mnt/Test ...
Does this mean that, at end of KLV's use, the local use folder(s) in /mnt that I expect will NOT be present on reboot?
Curious
Edit: In my past use of PUP/DOGs, things I create-mount in /mnt are present over persistance reboots.
I think you may be looking in the wrong place in Thunar. sda1 means /mnt/sda1 so look in there after running wd_mount sda1 (remember to refresh Thunar if necessary) - the files should be visible now.
Clarity wrote: ↑Sun Feb 20, 2022 9:21 amwiak wrote: ↑Sat Feb 19, 2022 11:53 pmfredx181 wrote: ↑Sat Feb 19, 2022 7:53 pmBtw, maybe /mnt should be empty at initial boot (i.e. changes not containing anything in /mnt e.g. no leftover previous mounted folders), not sure though, @wiak what do you think ? (think of also the issue lately with filemnt, the previously mounted folder inside upper_changes/mnt).
Yes, I've occasionally pondered about that too. Shutdown script should maybe be tweaked to empty it?
On many of my systems over the years, I maintain some mount local use in /mnt that I create on pristine boot; eg. # mkdir -p /mnt/Test ...
Does this mean that, at end of KLV's use, the local use folder(s) in /mnt that I expect will NOT be present on reboot?
Curious
Well... that's pretty much why I just leave it as it is on my own systems. Clearly the initrd shouldn't empty /mnt on boot, since initrd is for initialization and cleaning up anything is for after using the system, but whether it is a good idea to do so is a matter of opinion and expected usage I suppose.
I emptied /mnt except for /home and /layers and then squashed the KLV rootfs.
Just tested it out and it started and works as expected.
So far I empty all the caches, /mnt, .bash_history, .history before squashing.
wiak wrote: ↑Sun Feb 20, 2022 9:25 amClarity wrote: ↑Sun Feb 20, 2022 9:21 amOn many of my systems over the years, I maintain some mount local use in /mnt that I create on pristine boot; eg. # mkdir -p /mnt/Test ...
Does this mean that, at end of KLV's use, the local use folder(s) in /mnt that I expect will NOT be present on reboot?
Curious
Well... that's pretty much why I just leave it as it is on my own systems. Clearly the initrd shouldn't empty /mnt on boot, since initrd is for initialization and cleaning up anything is for after using the system, but whether it is a good idea to do so is a matter of opinion and expected usage I suppose.
Yes, well, let's leave it as it now is, indeed saved stuff in /mnt shouldn't disappear on next boot.
rockedge wrote:I emptied /mnt except for /home and /layers and then squashed the KLV rootfs.
/mnt/home symlink should be created at startup IMO, it shouldn't be already there, as it points to a partition that is different for everyone.
And can you change the swapper.sh script the way I suggested above ?
@fredx181 I already put the changes in!
Code: Select all
#!/bin/sh
# utility by fredx181 Jan2022
#
# revison 19Feb2022 by fredx181
#
#### Load swap ####
echo "LOAD SWAP"
for ONESWAP in `fdisk -l | grep ' Linux swap' | cut -f 1 -d ' ' | tr '\n' ' '`
do
echo -n "Loading swap partition $ONESWAP..." >/dev/console
swapon $ONESWAP
done
#########################
#### Create symlink /mnt/home ####
MNTHOME=$(mount | grep "/mnt/layers/merged/mnt" | cut -d'/' -f3 | cut -d' ' -f1)
cd /mnt/
ln -sfn $MNTHOME home
#########################And I will remove the /mnt/home link and /mnt/layers.
Here's package "mime-add" that will configure some mime types and add some icons, after install recognizable icons will show for:
.xbps, .sfs, .squashfs, .pet, .iso and .deb files. (instead of empty or generic icons)
(need to "Reload' Thunar view perhaps)
-------------------------------------------------------------------------
Looks nice, isn't it ? 
Edit: filemnt will be part of default "Open with" too for selected .sfs and .iso.
mime-add-1.1_0.noarch.xbpsEDIT 5-6-2022: replaced mime-add with v1.1 as v1.0 made Rox crash.
Also here's "edit-sfs" (Edit SFS should appear from "open with") originally by old puppy-linux forum member "pizzagood", edited for to work with Thunar (contains also "Convert SFS")
edit-sfs-1.0_0.noarch.xbpsAnd .pet package dir2xbps (64-bit) for to use from Puppy to create a xbps package (can be handy perhaps):
dir2xbps-1.0.0_amd64.petKLV-Airedale-beta2 is available for downloading and testing!
@fredx181's swap partition enable script includes the latest revisions and also added are the packages
mime-add-1.0_0.noarch.xbps
edit-sfs-1.0_0.noarch.xbps
/mnt is empty in the rootfs
All the other additions remain.
Check first post for download link or check https://rockedge.org/kernels
Need a pdf viewer in the build.
The XBPS repository has several ones you can download and install.
I downloaded and installed ePDFView
Seems to work OK to view a PDF.
Seems to have good selection of options.
The other ones seemed to be bigger in size or needed more dependencies.
The other PDFs offer the ability to edit a PDF. If present, it negates the need to upload to Google or cloud services to edit.
For quick frugal install of KLV-Airedale I'm including that as a weedogit.sh choice (I don't alter KLV-Airedale itself at all since don't need to - simply automates the extraction into frugal install directory (like all the other, now 16 total, distros handled) and provides example grub (grub.cfg and menu.lst) templates in outputted file grub_config.txt. Many/most of the community provided utility apps for KLV-Airedale will also work with all the other weedogit distros so practicing with KLV-Airedale is suggested to all weedogit.sh users. The combination of polished KLV-Airedale and weedogit.sh (for 'Other Distros') should prove to be a powerful resource I think. So much for me taking a rest from computing (might do that yet...).
Find the new weedogit.sh for download at usual place here: viewtopic.php?p=50074#p50074
EDIT: As a matter of interest, I just copied the 10gtkdialogGTK3_filemnt sfs into my weedogged Zorin-16-lite XFCE directory and booted that Zorin and filemnt and gtkdialog both work fine... Just an example of using typical forum sfs addons but with these 'Other Distros' that have been 'weedogged'.
@bigpup, @Clarity Good thinking. I also have been pondering what to add for PDF's. I like and use the ability to edit PDF's. Would it work to use a viewer/editor for both read or write functions? Or do we add just the reader and allow the user to decide to install something more sophisticated and able to edit PDF's.
I am leaning towards trying out the viewer/editor in one option.
@wiak I totally agree that KLV-Airedale is a good place to start with experimentation for going that step further and using the utilities contributed by the community that could be used in other Weedogit distro's
@fredx181 This PET package dir2xbps-1.0.0_amd64.pet running on my Bionic64-CE dev system has become indispensable, once again awesome foresight and work Fred.
And Thank You EVERYONE for the all awesome contributions that keep improving KLV-Airedale. Without all of your help we wouldn't be working on this operating system which seems pretty rock solid stable and able to do lots of things.
Most Puppy versions only have a pdf viewer.
I think most people only want to be able to view a pdf.
Someone wanting to make pdf's is probably looking to use a specific program to do that.
On the issue of PDF use, I "think" the option (AND ANY effort) to have the edit feature present is a proper course of action in today's PC.
Years ago, when resources were costly and limited, I might have agreed. But, in today's systems, the cost is negligible for reducing the effort.
Also, in a past, if a user did not have that feature, he would have either given-up abandoning his need to seek other options or just abandoned the use altogether because it was not there for use.
If the cost (and I mean disk-cost/size, as the RAM cost is small for PDF manipulation) is not a concern then it should be considered.
Just another's view, for what its worth.
The work done on this product is wonderful, all around. Thanks to everyone in the many contributions from across the forum in maturing this idea, KLV, to reality.
@rockedge:-
Talking of which, I've got the Trim4SSD uility modified to work correctly with the XFCE terminal now. It's functional, apart from the mount/unmount functions - it'll work OK if you mount your drives first with Thunar - but somebody else will have to take a look at the mount/unmount scripts.
The ones in the utility were modified by mistfire to work 'dynamically' in Puppy.....meaning they won't work in KLV. The code is beyond my current level of comprehension; I don't understand what it does, so am incapable of re-writing it.
I'm happy to admit my shortcomings, but this IS the point of a community, after all; we all have our strong points, as well as our weak ones. So, we help each other out.....
(*shrug*)
Mike.
Thanks @mikewalsh I'll start to work it into KLV and let's see how we do integrating it.
I have installed epdfview on a test version of KLV-Airedale and I do like it. I am using Textmaker via the Textmaker SFS file to make the PDF's and I'm examining them with epdfview.
We need possibly some kind of BlueTooth functionality so what about trying out this viewtopic.php?p=50687#p50687
Or do we look for a solution through the Void Linux repo's?
*** save2flash *** - save on demand, or save on shutdown
This is sort of equivalent to pupmode=13 on Puppy
For testing, I tested adding files, deleting files, installing, uninstalling, all seems to work well saving on demand or at shutdown.
After some studying of the options, I found that booting with w_changes=RAM2 is the way to make this feature work.
@wiak , perhaps you can comment on this ?
Booting with RAM2 creates a directory /mnt/layers/uc_ro to where the changes can be saved.
Install attached xbps package 'save2flash' to make use of this feature, but again, it needs testing and possibly needs improvements.
save2flash-1.0_0.noarch.xbps(it will install dependencies dialog and rsync)
Two options: (but works only when booted with option w_changes=RAM2)
- Save on demand during a session, run save2flash from terminal (or create symlink to /usr/bin/save2flash on the Desktop and run it)
- Save on shutdown/reboot, a dialog will appear on console with choice to save or not.
Screenshot save on demand during a session, run 'save2flash':
Screenshot dialog save or not at shutdown:
@rockedge :-
Erik, you can find the current version of TRIM4SSD for KLV here:-
https://mega.nz/folder/PW4WzAqS#gpbnD4p0FtOux0wS89JNtg
Like I said, someone with more "know-how" than I will need to take a look & figure out how to modify mistfire's scripting of the mount/unmount scripts, to make them work with KLV. It's beyond my comprehension..! 
(I don't know how you use PROBE_PART, never mind with Void's peculiar /run/media/root setup.....)
{*shrug*)
Mike.
(I don't know how you use PROBE_PART, never mind with Void's peculiar /run/media/root setup.....)
Mike, the probepart line should work in cb_mount.sh.gz, since probepart is now included in KLV.
Btw, better use mrxvt (in fstrim.sh) rather than xfce4-terminal IMO, see also:
viewtopic.php?p=47610#p47610
fredx181 wrote: ↑Wed Feb 23, 2022 10:11 pm(I don't know how you use PROBE_PART, never mind with Void's peculiar /run/media/root setup.....)
Mike, the probepart line should work in cb_mount.sh.gz, since probepart is now included in KLV.
Btw, better use mrxvt (in fstrim.sh) rather than xfce4-terminal IMO, see also:
viewtopic.php?p=47610#p47610
@fredx181 :-
Yes, I remember you advocating mrxvt before. But the few times I've tried it, on my screen it comes up so small, and the text is so tiny I can barely read it! I mean, here's a 22" monitor, and I'm having to get up to within a few inches of the screen in order to be able to read it.
I refuse to have to squint at a screen that large because the terminal in use is of microscopic proportions. Um; if you don't mind my asking, why are you so keen on it? (Or is it the 'size' thing again.....trying to keep things as tiny as possible? I know xfce-terminal IS a bit on the "chunky" side compared to what we normally tend to use, and a lot of the command syntax is rather different, too.)
BTW; Can we change the font sizes/colours with mrxvt? And if so.....how? I can't find any way of modifying them at all....
What else? Ah, yes....
With regard to the 'standard' build of TRIM4SSD, what happens when I try to use the mount/dismount functions is that no mounting occurs, and the drive icons disappear off the screen.....and a re-boot is the only thing that brings them back. Which is a bit daft, to my way of thinking....
"cb_mount.sh". Is that the one I remember somebody saying that it brings up TWO sets of drive icons on the screen? (Or has that now been 'fixed'?)
Mike. 
fredx181 wrote: ↑Wed Feb 23, 2022 4:10 pm*** save2flash *** - save on demand, or save on shutdown
This is sort of equivalent to pupmode=13 on PuppyFor testing, I tested adding files, deleting files, installing, uninstalling, all seems to work well saving on demand or at shutdown.
After some studying of the options, I found that booting withw_changes=RAM2is the way to make this feature work.@wiak , perhaps you can comment on this ?
Booting with RAM2 creates a directory /mnt/layers/uc_ro to where the changes can be saved.
Yes, that's correct. It is for the w_changes=RAM2 on grub kernel line optional argument (could have more than one grub entry of course, so can choose to use save2flash or normal direct persistence without w_changes=RAM2.
Good to have that scripted in to KLV-AIredale to make it user-friendly to rsync back all tempt in-RAM changes to media upper_changes when user wishes.
But one error simply in description of how w_changes=RAM2 works above: "Booting with RAM2 creates a directory /mnt/layers/uc_ro to where the changes can be saved."
Actually, /mnt/layers/uc_ro is simply the external upper_changes contents read-only mounted to that directory. It doesn't get changed during operation. More precisely, it is /mnt/layers/RAM/upper_changes, which is an in-RAM-only upper_changes that does get changed throughout the session - that is the one your script must merge back in (which I presume is what you are actually doing or script wouldn't work).
EDIT: Ah, I see now from your screenshots that, of course, you are indeed rsyncing back from /mnt/layers/RAM/upper_changes - it was just your way of expressing it I misunderstood for a second - indeed uc_ro is directly connected (read-only mount) of the actual persistent upper_changes on disk.
I haven't myself tried it out yet (not long up) but will later and also look at the rsync method details you opted for. If it works without apparent issues, I'd go with that of course and will test a bit with different whiteout possibilities (since that's the area where things could go wrong, perhaps only in special cases/circumstances, if they are going to).
Of course this save2flash utility is going to work with all the "weedogit" 'Other Distros' too, so incredibly useful for the likes of weedogged EndeavourOS and so on.
mikewalsh wrote: ↑Wed Feb 23, 2022 11:27 pmfredx181 wrote: ↑Wed Feb 23, 2022 10:11 pm(I don't know how you use PROBE_PART, never mind with Void's peculiar /run/media/root setup.....)
Mike, the probepart line should work in cb_mount.sh.gz, since probepart is now included in KLV.
Btw, better use mrxvt (in fstrim.sh) rather than xfce4-terminal IMO, see also:
viewtopic.php?p=47610#p47610@fredx181 :-
Yes, I remember you advocating mrxvt before. But the few times I've tried it, on my screen it comes up so small, and the text is so tiny I can barely read it! I mean, here's a 22" monitor, and I'm having to get up to within a few inches of the screen in order to be able to read it.
I refuse to have to squint at a screen that large because the terminal in use is of microscopic proportions. Um; if you don't mind my asking, why are you so keen on it? (Or is it the 'size' thing again.....trying to keep things as tiny as possible? I know xfce-terminal IS a bit on the "chunky" side compared to what we normally tend to use, and a lot of the command syntax is rather different, too.)
BTW; Can we change the font sizes/colours with mrxvt? And if so.....how? I can't find any way of modifying them at all....
What else? Ah, yes....
With regard to the 'standard' build of TRIM4SSD, what happens when I try to use the mount/dismount functions is that no mounting occurs, and the drive icons disappear off the screen.....and a re-boot is the only thing that brings them back. Which is a bit daft, to my way of thinking....
"cb_mount.sh". Is that the one I remember somebody saying that it brings up TWO sets of drive icons on the screen? (Or has that now been 'fixed'?)
Mike.
Hi Mike, the reason for me to prefer mrxvt is that the xfce4-terminal was acting strange for me (i.e. asking to Reload or something)
Indeed mounting a device (manually using mount) on /mnt e.g. sda2 makes the drive icon for volume sda2 disappear, also a bit weird, I'd say...
Anyway, using gio mount is the way to go in this setup, I think (no disappearing drive icons).
Attached TRIM4SSD_KLV-portable-mod.tar.gz with fixes, should work ok now, but tell me if something is not ok for your liking:
Size of mrxvt is bigger (also font size) and 'gio mount' used for the mounting (in cb_mount.sh).
(added -xft -xftsz 12 -xftwt bold to the mrxvt command line, where -xftsz 12 sets the font size and -xftwt bold set to use bold)
EDIT:
"cb_mount.sh". Is that the one I remember somebody saying that it brings up TWO sets of drive icons on the screen? (Or has that now been 'fixed'?)
That was about when you have installed pup-volume-monitor and gvfs.
wiak wrote:EDIT: Ah, I see now from your screenshots that, of course, you are indeed rsyncing back from /mnt/layers/RAM/upper_changes - it was just your way of expressing it I misunderstood for a second - indeed uc_ro is directly connected (read-only mount) of the actual persistent upper_changes on disk.
I haven't myself tried it out yet (not long up) but will later and also look at the rsync method details you opted for. If it works without apparent issues, I'd go with that of course and will test a bit with different whiteout possibilities (since that's the area where things could go wrong, perhaps only in special cases/circumstances, if they are going to).
Mmm.. yes, copy from /mnt/layers/RAM/upper_changes to /mnt/layers/uc_ro would have been better way to say.
To explain a little more about what the 'snapmergepuppy' script ("merge changes") basically does (thought it's good to name it the same as in Puppy btw):
- first of all it scans for all files (to be copied) in /mnt/layers/RAM/upper_changes
- and scans for possibly existing 'whiteout' files (removed files) and if corresponding files exist in one of the SFS modules loaded at boot, these will be copied (mask files, in this overlay setup, 'character device' -c).
- if not existing in one of the SFS modules (i.e removed files that were earlier created in changes, not built-in)., it will just be removed from the /mnt/layers/uc_ro
(so you get no 'whiteout' files from not-built-in removed files (in changes), which is important IMO).
Well... difficult to explain, hopefully I'm a little less 'vague' than when we discussed about this earlier, perhaps you remember
Looking forward to your (or anyone's) testing results, as I cannot guarantee that this is bug-free TBH.
I roughly remember. I'm busy this second, but I'll read the script and experiment when I can. I would like to compare result with simple ignore whiteouts in lower sfs files (the way I've been doing it); fact is, the overall implications of the whiteouts all over the place hurt my brain a bit so I need to meditate on it...
@fredx181 :-
Ah, thanks for the info on mrxvt. I installed it into Quirky64 'April' 7.0.1 to have a play around with it - found a date-related package for it (this is Tahrpup-era) over at /ubuntu/pool.
Setting the font size to 14 has made all the difference for me! BTW, those menus act a bit weird, don't they? Like on xvkbd; you have to click & hold to show them; as soon as you release the mouse button, they disappear again..... 
I'll have a look at the modded TRIM4SSD tomorrow; it's WAYYY past my bedtime, so I'm turning in for t'night. Cheers for taking a look, anyway; I don't mind admitting when I'm out of my depth!
Mike. 
wiak wrote:(the way I've been doing it);
Can you write the rsync command line you used ? I like to test that simple method too, I tried something like that first , but resulted in complications, but perhaps I did wrong, so could be that my code in snapmergepuppy is a bit over-complicated.
EDIT:
Tested now with very much simplified snapmergepuppy (without while loop searching for corresponding files to whiteouts in SFS's):
Code: Select all
#!/bin/bash
#set -x
# fredx181 2022 Lesser GPL licence v2 (http://www.fsf.org/licensing/licenses/lgpl.html)
# 25-02-2022, very much simplified version
export LANG=C
PATH="/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R7/bin"
SNAP="/mnt/layers/RAM/upper_changes"
cd $SNAP || exit 1
BASE="/mnt/layers/uc_ro"
echo "Merging $SNAP onto $BASE..."
rsync -a --force $SNAP/ $BASEAnd seems to work well from quick tests, can't recall what the complications were when I tried this in the past. I can't stand it !! 
However, I still think it's preferable to have no whiteouts from not-builtin files (i.e. from new created files and later removed) in the save storage.
(without the while loop as above code it works faster, but not much, as it seems to me)