Puppy Linux Discussion Forum

@fredx181 and other members desiring a Ventoy-SG2D setup EXAMPLE on a system drive instead of a USB.

For some reason, it appears that a prior post for you has been lost on the forum. Hopefully, this post wont get lost.

No USB used on this PC to boot ISO files as well as installed OSes.
Anyway, here's pics on the 2 system drive test PC I have. Its 2nd drive is the main bootable drive of the system out of power-on (POST). It is a Ventoy drive. Hopefully the following is helpful understanding. It is a flawless example in my use. Download ISO files, boot them, and saving forum distro persistence for ALL.

Clarity wrote: ↑Mon Apr 08, 2024 6:31 am

@fredx181 and other members who rather use a system drive for Ventoy/SG2D booting of forum distros without a need to use a USB. For some reason, it appears that a prior post for you has been lost on the forum. Hopefully, this post wont get lost.

Probably not the 'lost' post you are referring to above, Clarity; the following post, detailing how to use Ventoy as a main hard drive installation method, was by me in the KL HowTo section regarding using Ventoy as a universal boot mechanism (more info on that in the other posts I made in same thread back then): viewtopic.php?p=109858#p109858

wiak wrote: ↑Mon Apr 08, 2024 2:22 am

@fredx181

Using Ventoy usb stick on newish Levova ThinkBook 14s Yoga Gen 2

This laptop has nvme hard drives (two actually) per gparted screenshot

Thus the Ventoy usb appears on sda per gparted screenshot

Booted KLV-Airedale-sr12 without issue

.....

I can only suggest there might be some issue with your HP laptop and usb detection, Fred, or some kind of kernel-related timing issue?

Thanks! Yes, may be something strange with this laptop (Asus, btw, very cheap).
Other ISO's (Pups and Dogs) boot OK though, and in general USB boot works fine, but as I said, I can live without ISO booting, good to know anyway that it probably works in most cases for KL too.
---------------------------------------------------------------------------------------------------

Clarity wrote: ↑Mon Apr 08, 2024 4:27 am

I advise to never put Persistence on a USB

Why ?
(I'd say it makes it truly portable having also the changes included on USB)

@fredx181 you ask "Why?"

I have a 'ton' of reasons and it will get long in tooth. But the 2 critical issues is performance (timings), a key as unless a user is using a very expensive USB/SDcard you will never exceed the all around performance and stability of a system drive. Further the benefit extends if you have constant persistence updating occurring versus a only write at the very end of session, the system drive far exceeds persistence use on it.

There much much more, but a 2nd reason is that on initial setup, file placement folders, SAMBA, FTP files, video driver, audio, etc are unique by machine. Thus unless the user is a seasoned linux user (veteran), using a USB/SDcard 'persistence' on another different PC...well you can answer this for yourself as you know.

But wait,there's more....

Oh, one can do it for use only on the local PC not moving the stick elsewhere. But, just not a good idea unless that is the ONLY option available.

In my case, again, every PC I use has a Persistence partition where the distros localizes the vast majority of OS writes to that partition.

If anyone has a preference for wanting to do so, be my guest. NOTHING restricts one from creating persistence on their USB. I just am not one to advise persistence on a USB.

Clarity wrote: ↑Sun Apr 07, 2024 4:10 pm

wiak wrote: ↑Sun Apr 07, 2024 4:00 pm

... Well, somehow, after doing same sort of settings various times and save and exit, suddenlty the usb drive appeared via F9 on boot... Weird. ...

I have an older PC, circa 2012 IIRC, that this happens frequently upon a reboot.

To get around this PC's BIOS bug, I know to shut it down. Unplug and replug the USB and its back to proper discovery following. I am certain this is a shortcoming in the PC's post functioning and/or an issue with the USBs I use. This has been the case for the many years I've had this test PC.

Hope this is helpful.

Yes, Clarity, turns out I have this problem with my older HP Folio laptop. Very annoying issue. Even worse than yours seems to be - is refusing now to find the bootable usb stick at all even on plugging/un-plugging and shut down and so on. Once 'trick' I'm having to resort to on this older machine is to temporarily take it out of UEFI boot mode and put in in Legacy mode (then my UEFI grub Linux Mint on HD won't boot, but usb stick does...). I can't remember if I still have plug-in/unplug issue still; I will retry. Real pain anyway. Dodgy something about the machine itself apparently.

Update: about my previous posts not being able to boot KLV ISO from Ventoy !
Tested now with installing Ventoy to another USB stick and... no problem booting KLV ISO . (should have tried that earlier, to be sure what was causing it , sorry for the trouble !)
So the problem was with my "Verbatim Store n go" USB stick, didn't have a clue because other ISO's booted fine (and manually booting frugal install setups too), so no idea what was exactly happening.
Found out btw when I installed SG2D on that same Verbatim stick (replacing Ventoy) and was unpleasantly surprised that KLV ISO boot didn't work too with that, so I became suspicious about that USB stick.

fredx181 wrote: ↑Mon Apr 08, 2024 5:37 pm

Update: ... so I became suspicious about that USB stick.

Yes, I have seen this as well.

Glad you discovered it as it could take hours (in my case, 'days') going round-and-round with USB that was working, but now not.

fredx181 wrote: ↑Mon Apr 08, 2024 5:37 pm

Update: about my previous posts not being able to boot KLV ISO from Ventoy !
Tested now with installing Ventoy to another USB stick and... no problem booting KLV ISO . (should have tried that earlier, to be sure what was causing it , sorry for the trouble !)
So the problem was with my "Verbatim Store n go" USB stick, didn't have a clue because other ISO's booted fine (and manually booting frugal install setups too), so no idea what was exactly happening.
Found out btw when I installed SG2D on that same Verbatim stick (replacing Ventoy) and was unpleasantly surprised that KLV ISO boot didn't work too with that, so I became suspicious about that USB stick.

That's good to hear Fred. I suspect we should all be more suspicious of the abilities/problems with our usb sticks, expecially older ones. Possibly most isos stored were in nice contiguous blocks or no bad data and the KLV iso was on a flaky part of the usb so was bombing out somehow.

Whilst I only tested this in Airedale-sr12 I believe it applies to all KL distros (assuming sr12 uses latest save2flash/snapmergepuppy).

Though most users stick with root desktop, I do not always. I believe the script snapmergepuppy also needs the following line at the top:

[ "`whoami`" != "root" ] && exec sudo ${0}

With that in place, my quick tests suggest save2flash (and main script snapmergepuppy) work when logged in as a normal user desktop. Without it, permissions are often denied.

Even with the suggested change, however, save2flash/snapmergepuppy doesn't work if you just, for example, su - spot, because DISPLAY isn't set for user spot and DISPLAY existing is tested by snapmergepuppy (is it necessary to test for DISPLAY??).

EDIT: More testing required. Above alone didn't work correctly for me on second quick test some time later. I may have messed up on one of the tests, sorry. Run out of time right now. Of course, it is not just for Airedale I was looking into this: KLfull2fr by default uses upstream repo login so usually logged into desktop as normal user and save2flash wasn't working correctly in that scenario for me; KLV Airedale normal user may or may not be the same in save2flash operation though since KLfull2fr uses a special structure of layering really, but I thought should be the same overall.

wiak wrote:

Though most users stick with root desktop, I do not always. I believe the script snapmergepuppy also needs the following line at the top:

[ "`whoami`" != "root" ] && exec sudo ${0}

No objection to add that on top of snapmergepuppy, but I think it's not supposed to run snapmergepuppy directly, save2flash has that line on top and it is the script designed for to run save on demand.
KLV-Airedale has the spot and weedog users added to the wheel group and /etc/sudoers has at the bottom %wheel ALL=(ALL) NOPASSWD: ALL
(edit: @rockedge probably had a vision about how to handle that, and did well IMO )
So when executing sudo <somecommand> (e.g. sudo xbps-install ....) when logged in as spot or weedog, it is not required to enter the password.
edit: some may argue about if it's good practice to allow unprivileged users to execute admin tasks without the need to enter password, but that's another issue to contemplate about.

Other KL versions may not have this %wheel mechanism (didn't test, so don't know), one way to specify only certain application(s) to run as "user" with admin permissions (assuming it's in the 'wheel' group) without requiring to enter password is to add a file, e.g. "user_wheel" in /etc/sudoers.d with e.g. content %wheel ALL= NOPASSWD: /usr/bin/save2flash and chmod the file :
chmod 0440 /etc/sudoers.d/user_wheel
(can be multiple commands, needs to be comma separated, e.g. I have in DebianDog: %wheel ALL= NOPASSWD: /sbin/shutdown, /sbin/reboot, /sbin/poweroff, /usr/bin/wmpoweroff, /usr/bin/wmreboot, /usr/bin/save2flash, /usr/sbin/pm-suspend)

Even with the suggested change, however, save2flash/snapmergepuppy doesn't work if you just, for example, su - spot, because DISPLAY isn't set for user spot and DISPLAY existing is tested by snapmergepuppy (is it necessary to test for DISPLAY??).

Can't see the logic of needing to run su - spot when logged in as root to save changes

fredx181 wrote: ↑Sun Apr 14, 2024 4:27 pm

KLV-Airedale has the spot and weedog users added to the wheel group and /etc/sudoers has at the bottom %wheel ALL=(ALL) NOPASSWD: ALL

Well it is myself who gave these instructions to add normal users to the wheel group and with no password along with most similar code lines I used in my first pre-weedog void releases even and more in WDL_Arch early releases.

First done in WDL-Arch64 developments and published sometime later May2020 here https://oldforum.puppylinux.com/viewtop ... 3#p1058043:

Just a general update on WeeDog developments.
Shortly to release rc2 version of WeeDogLinux Arch64.
...
but Start menu includes userswitch entry to immediately restart X as user weedog (or next time used toggles back to autologin root user straight into its openbox desktop X session),
or autologin(ON/OFF) entry, which toggles to ON or OFF for next restart of X session, so can login as other users prior to X starting or autologin as either root (which is the first boot default) or normal user weedog (who is in wheel group so can sudo without being asked to enter password).

However, I will continue looking at save2flash/snapmerge puppy until it works for me as normal user the way i want it. Doesn't seem to at the moment, that's all. I may be wrong but will report back once I have time.

fredx181 wrote: ↑Sun Apr 14, 2024 4:27 pm

Can't see the logic of needing to run su - spot when logged in as root to save changes

By the way, you seem to have misunderstood what and why I was giving a su - example. It was not at all because I feel it should be necessary to use su - spot or similar when root in order to save changes...

Rather, I was trying to give an example of what I found isn't working and was using su - as a way to show it not working. Okay, confusing. A simpler example:

Lets say you are autologged in as user spot and in directory /home/spot there is a file already embedded in the 07KLV-Airdale-sr12.sfs at location /home/spot/filea (where filea can be any already existing file in that layer of the overlay). Let's say we remove that filea; the result should be a type c whiteout file. If as that user spot, you now do save2flash, that whiteout file would need to be rsync'd back to upper_changes. I believe that does not happen. Thus on reboot filea still exists.

Of course, no such problem occurs if you manually create a file at /home/spot and then delete it; no whiteout file is involved in that at all, so save2flash works fine for that kind of case.

wiak wrote:

Lets say you are autologged in as user spot and in directory /home/spot there is a file already embedded in the 07KLV-Airdale-sr12.sfs at location /home/spot/filea (where filea can be any already existing file in that layer of the overlay). Let's say we remove that filea; the result should be a type c whiteout file. If as that user spot, you now do save2flash, that whiteout file would need to be rsync'd back to upper_changes. I believe that does not happen. Thus on reboot filea still exists.

Strange... I cannot reproduce that, just now tested thoroughly on sr12, changed autologin to spot first, rebooted and deleted several files from /home/spot existing in the main sfs one by one , ran save2flash manually in between, rebooted, deleted another file, rebooted again, also among that I tested choosing "Save" at shutdown (instead of manually run save2flash) and the files are gone in all cases (and show as character device in uc_ro).

Btw, rc12 doesn't seem to have the latest save2flash installed (has v1.6) , but I tested same as above after installing latest v1.9 and same result, works also fine for me.

EDIT: I boot using this (frugal in dir AIRE-SR) :
w_bootfrom=UUID=34b10665-11c5-493c-9bff-f4f1e7db86f2=/AIRE-SR w_changes=UUID=34b10665-11c5-493c-9bff-f4f1e7db86f2=/AIRE-SR w_changes1=RAM2
(don't know if it is related to how save2flash works)

Btw, rc12 doesn't seem to have the latest save2flash installed (has v1.6) , but I tested same as above after installing latest v1.9 and same result, works also fine for me.

I will have to double check but I think I updated to save2flash-1.8 in the current sr12 ISO that is available. I will upgrade to save2flash-1.9 in sr12 and repackage the rootfs SFS and then the ISO.

rockedge wrote: ↑Mon Apr 15, 2024 4:40 pm

Btw, rc12 doesn't seem to have the latest save2flash installed (has v1.6) , but I tested same as above after installing latest v1.9 and same result, works also fine for me.

I will have to double check but I think I updated to save2flash-1.8 in the current sr12 ISO that is available. I will upgrade to save2flash-1.9 in sr12 and repackage the rootfs SFS and then the ISO.

Yes, the files are from v1.8 in sr12 (checked just now) so it's correct, but I noticed when I installed the latest v1.9 (by right-click > install xbps package) the output said that it was upgrading from 1.6 to 1.9 so the installed version number seems to be just wrong registered, don't know why .

fredx181 wrote: ↑Mon Apr 15, 2024 3:36 pm

wiak wrote:

Lets say you are autologged in as user spot and in directory /home/spot there is a file already embedded in the 07KLV-Airdale-sr12.sfs at location /home/spot/filea (where filea can be any already existing file in that layer of the overlay). Let's say we remove that filea; the result should be a type c whiteout file. If as that user spot, you now do save2flash, that whiteout file would need to be rsync'd back to upper_changes. I believe that does not happen. Thus on reboot filea still exists.

Strange... I cannot reproduce that, just now tested thoroughly on sr12, changed autologin to spot first, rebooted and deleted several files from /home/spot existing in the main sfs one by one , ran save2flash manually in between, rebooted, deleted another file, rebooted again, also among that I tested choosing "Save" at shutdown (instead of manually run save2flash) and the files are gone in all cases (and show as character device in uc_ro).

Hmmm... I must have messed up my install somehow. What you got is what I want. I'll try again later...

wiak wrote: ↑Sun Apr 14, 2024 2:04 pm

Whilst I only tested this in Airedale-sr12 I believe it applies to all KL distros (assuming sr12 uses latest save2flash/snapmergepuppy).

Though most users stick with root desktop, I do not always. I believe the script snapmergepuppy also needs the following line at the top:

Code: Select all

[ "`whoami`" != "root" ] && exec sudo ${0}

I still believe my above comment is correct.

An example to show what I mean remains:

Log in to user spot desktop.

Try and remove an existing hidden file such as .bash_logout

save2flash

Reboot and .bash_logout is still there because snapmergepuppy rsync skipped it from the FILESAVE list because it did not consider it a regular file unless run as root user (or sudo). Or am I missing something?

wiak wrote: ↑Tue Apr 16, 2024 6:06 am

wiak wrote: ↑Sun Apr 14, 2024 2:04 pm

Whilst I only tested this in Airedale-sr12 I believe it applies to all KL distros (assuming sr12 uses latest save2flash/snapmergepuppy).

Though most users stick with root desktop, I do not always. I believe the script snapmergepuppy also needs the following line at the top:

Code: Select all

[ "`whoami`" != "root" ] && exec sudo ${0}

I still believe my above comment is correct.

An example to show what I mean remains:

Log in to user spot desktop.

Try and remove an existing hidden file such as .bash_logout

save2flash

Reboot and .bash_logout is still there because snapmergepuppy rsync skipped it from the FILESAVE list because it did not consider it a regular file unless run as root user (or sudo). Or am I missing something?

save2flash runs as root (by using sudo), it calls /usr/bin/snapmergepuppy which is then automatically running as root too, not ?
(to be sure I tested adding whoami on top of snapmergepuppy, ran save2flash from terminal and showed "root")
(edit: do you have snapmergepuppy in /usr/local/bin perhaps? (as you once mentioned to prefer that))

I tested yesterday with a pristine install of sr12, one of the files I tested to delete was /home/spot/.bash_logout (and was gone after reboot), just now I started sr12 fresh again, logged in as spot, deleted .bash_logout and again was gone after save2flash > reboot.
No idea what' s happening on your setup, did you test with a pristine boot ?
And if you do add [ "`whoami`" != "root" ] && exec sudo ${0} on top of snapmergepuppy, is the problem fixed for you ?
----------------------------------------------------------------------------------------------------------------------------------------------------------------------
@rockedge would you mind testing save2flash too ? (similar as wiak and I did), so we know more about if there's a problem or not.

fredx181 wrote: ↑Tue Apr 16, 2024 7:38 am

I tested yesterday with a pristine install of sr12, one of the files I tested to delete was /home/spot/.bash_logout (and was gone after reboot), just now I started sr12 fresh again, logged in as spot, deleted .bash_logout and again was gone after save2flash > reboot.
No idea what' s happening on your setup, did you test with a pristine boot ?
And if you do add [ "`whoami`" != "root" ] && exec sudo ${0} on top of snapmergepuppy, is the problem fixed for you ?
----------------------------------------------------------------------------------------------------------------------------------------------------------------------
@rockedge would you mind testing save2flash too ? (similar as wiak and I did), so we know more about if there's a problem or not.

Okay, it was me. I couldn't be bothered changing autologin to spot, and somehow messed up my testing. But now I did it more sensibly with autologin spot and you are correct, working fine with KLV.

I'll be back though, cos as it stands I don't think it will work with KL_full2fr, which is particularly important to me cos I run Linux Mint, but via KL_full2fr method.

Anyway, maybe it will work also with KL_full2fr, but I suspect it won't. Reason I think not is that I note the main rsync while loop is searching through loaded sfs files, but full2frugal uses actual uncompressed Linux Mint on main partition as the root_filesystem layer. In fact, seems save2flash isn't yet ready for KL builds that mix sfs files with uncompressed dir layers(?).

Just prior to going out I did have save2flash working with my Linux KL_full2fr after modifying snapmergepuppy, but it was just a quick hack so may well be very imperfect. Worked as far as I tested the mods though, but then wouldn't work correctly with the usual KL distros. Might need a special snapmergepuppy for KL_full2fr I therefore suspect, but that will be fine.

@rockedge would you mind testing save2flash too ? (similar as wiak and I did), so we know more about if there's a problem or not.

I followed along and repeated the test as described and could not find a problem.

wiak wrote:

Anyway, maybe it will work also with KL_full2fr, but I suspect it won't. Reason I think not is that I note the main rsync while loop is searching through loaded sfs files, but full2frugal uses actual uncompressed Linux Mint on main partition as the root_filesystem layer. In fact, seems save2flash isn't yet ready for KL builds that mix sfs files with uncompressed dir layers(?).

The while loop in snapmergepuppy searches the mountpoints from the sfs's in /mnt/layers.
Isn't that working the same when using uncompressed dir layers ?, i.e. that it creates the same numbered folders in /mnt/layers (but didn't follow all when dir layers was discussed TBH).
I tested briefly on KLV-Airedale by unsquashing 16gtkdialogGTK3_filemnt64.sfs and then renamed squashfs-root to 6gtkdialogGTK3_filemnt64 (no extension .sfs, is that the right method?), booted that way , shows 16 in /mnt/layers and save2 flash worked as expected for me.

fredx181 wrote: ↑Tue Apr 16, 2024 1:00 pm

wiak wrote:

Anyway, maybe it will work also with KL_full2fr, but I suspect it won't. Reason I think not is that I note the main rsync while loop is searching through loaded sfs files, but full2frugal uses actual uncompressed Linux Mint on main partition as the root_filesystem layer. In fact, seems save2flash isn't yet ready for KL builds that mix sfs files with uncompressed dir layers(?).

fredx181 wrote: ↑Tue Apr 16, 2024 1:00 pm

wiak wrote:

Anyway, maybe it will work also with KL_full2fr, but I suspect it won't. Reason I think not is that I note the main rsync while loop is searching through loaded sfs files, but full2frugal uses actual uncompressed Linux Mint on main partition as the root_filesystem layer. In fact, seems save2flash isn't yet ready for KL builds that mix sfs files with uncompressed dir layers(?).

The while loop in snapmergepuppy searches the mountpoints from the sfs's in /mnt/layers.
Isn't that working the same when using uncompressed dir layers ?, i.e. that it creates the same numbered folders in /mnt/layers (but didn't follow all when dir layers was discussed TBH).
I tested briefly on KLV-Airedale by unsquashing 16gtkdialogGTK3_filemnt64.sfs and then renamed squashfs-root to 6gtkdialogGTK3_filemnt64 (no extension .sfs, is that the right method?), booted that way , shows 16 in /mnt/layers and save2 flash worked as expected for me.

The while loop in snapmergepuppy searches the mountpoints from the sfs's in /mnt/layers.
Isn't that working the same when using uncompressed dir layers ?, i.e. that it creates the same numbered folders in /mnt/layers (but didn't follow all when dir layers was discussed TBH).
I tested briefly on KLV-Airedale by unsquashing 16gtkdialogGTK3_filemnt64.sfs and then renamed squashfs-root to 6gtkdialogGTK3_filemnt64 (no extension .sfs, is that the right method?), booted that way , shows 16 in /mnt/layers and save2 flash worked as expected for me.

Yes, realised that just after going to bed. Should be fine. Experiment KL_full2fr is a different scenario. Will think about it later.

About theming:
I see a lot in /usr/share/themes, but nothing is displayed in Settings > Appearance > Style, don't really understand, I guess these are "just" xfwm4 themes, not gtk
From the Void repo I can install e.g. Bluebird or Greybird theme and then it can be selected from Appearance > Style, works ok.
Perhaps add a little choice for choosing a theme in next release ?.
The huge "tbox" archive that @geo_c shared (thanks again!) has a lot of themes gtk2 or/and gtk3 supported.

Another thing (about gtk2):
Looking at your screenshot of YRadio @rockedge : viewtopic.php?p=117833#p117833, it looks ugly IMHO, it is using yad GTK2 build as included in the appimage.
Can look better by installing a theme in KLV, and select it, that supports gtk2 as well as gtk3, e.g. Bluebird or Greybird.

Or: copy e.g. "Stardust" (gtk2 theme, so only for gtk2 based applications) from @geo_c's archive to /usr/share/themes and create ~/.gtkrc-2.0 with simple content:
gtk-theme-name="Stardust"
(just example (Stardust) what I experimented with) and will look (better IMO) when launching Yradio appimage (with gtk2 yad):
(EDIT: Also Xdialog messages or when using gtk2dialog will look better I think)
EDIT2; Optional or maybe required (not sure) are packages: gtk-engine-murrine and/or gtk2-engines

fredx181 wrote: ↑Thu Apr 25, 2024 2:54 pm

About theming:
I see a lot in /usr/share/themes, but nothing is displayed in Settings > Appearance > Style, don't really understand, I guess these are "just" xfwm4 themes, not gtk
From the Void repo I can install e.g. Bluebird or Greybird theme and then it can be selected from Appearance > Style, works ok.
Perhaps add a little choice for choosing a theme in next release ?.
The huge "tbox" archive that @geo_c shared (thanks again!) has a lot of themes gtk2 or/and gtk3 supported.

It's been my understanding and practice that using these Void/Xfce combinations, it makes sense to store Xfce's xfwm4 window themes in /usr/share/themes, while the gtk themes go in /root/.themes. It works if they all go in /usr/share, but it was setup in /root when I originally created the tbox.

It makes sense to separate them simply for organizational purposes, the window manager and gtk themes being in separate directories. If you use the linking script in the tbox it will symlink the tbox gtk themes to /root/.themes and the xfwm4 themes to /usr/share/themes.

One note, if using the tbox KLV-CONTROL-PANEL gxmessage script to link themes, the Xfce theme chooser tends to take quite a few seconds to read and display them.

For info:
Today I installed mpv , install seemed to work fine, but didn't run (got some error message about pw_thread when running from terminal).
Ok, I associated it (pw) with "pipewire", but ok, decided to upgrade all packages (xbps-install -Su) as I initially wanted to do anyway.
And mpv runs OK again (probably needed the pipewire upgrade ).
So my lesson learned for on Void: best to upgrade all packages before installing a single package.

So my lesson learned for on Void: best to upgrade all packages before installing a single package.

Yes! I have experienced this as well. Couldn't install a package once, the system wouldn't do it until I performed a xbps-install -Suy complaining of broken dependencies.

I also have now the pipewire and wireplumber upgrades since Tuesday or so.

I have doing this daily without issues.

This could be an option in cron; but manual is still fine.