QuickPup64 24.01 RC9

[mistfire]

(By the way, have you checked dmesg? overlay warns when you modify files in lower layers and trigger undefined behavior)

I boot Quickpup on overlayfs mode and try to run save2flash. dmesg does not shows any complaints from overlayfs

[mistfire]

I'm trying it with overlayfs. First boot into Pupmode 5 was fine, but on reboot with savefolder created it said couldn't mount into pup_new and wouldn't boot past that.

The initrd was fixed. It can load save file/folder on overlayfs

QuickPup64 22.01 BETA 23 has reuploaded

Download: https://drive.google.com/file/d/1Hey-A2 ... pafjbpzTYe
MD5 Checksum: c5e1e30d449be2f829bf6f380ed8c2b7

[mistfire]

Take note QuickPup64 22.01 BETA 23 has known issue on overlayfs mode: Save file does not work.

Dealing with savefile on overlayfs is much tricky than save folder it seems

[wiak]

I'm trying it with overlayfs. First boot into Pupmode 5 was fine, but on reboot with savefolder created it said couldn't mount into pup_new and wouldn't boot past that.

The initrd was fixed. It can load save file/folder on overlayfs

QuickPup64 22.01 BETA 23 has reuploaded

Download: https://drive.google.com/file/d/1Hey-A2 ... pafjbpzTYe
MD5 Checksum: c5e1e30d449be2f829bf6f380ed8c2b7

Thanks mistfire, booted fine in Pupmode 13 now and I tried the save2flash -> snapmergepuppy_overlay combination and worked same as my results in KLV-Airedale with WDL initrd. That uses fredx181 version of snapmergepuppy (specially made by Fred for overlayfs use) so it is very different script (uses rsync rather than cp command to write back to the rw save folder) - otherwise the result is identical in my experiments though and rm -f the stuff written is exactly what I also did manually prior to the mount -o remount /

Thanks, looks good - let's hope it proves a reliable mechanism.

[mistfire]

On my latest experiment of QuickPup64 overlayfs mode. I sucessfully loaded savefile on overlayfs however added/changed file was saved in /initrd/pup_loop/.overlay/writable instead of /initrd/pup_loop which was the mountpoint of savefile. When I try to change to writable in /initrd/pup_loop it trigger this error message

Code: Select all

overlayfs: workdir and upperdir must be seperate subtrees

This will be the tricky part whether to retain compatibility with aufs for savefile or not

[wiak]

On my latest experiment of QuickPup64 overlayfs mode. I sucessfully loaded savefile on overlayfs however added/changed file was saved in /initrd/pup_loop/.overlay/writable instead of /initrd/pup_loop which was the mountpoint of savefile. When I try to change to writable in /initrd/pup_loop it trigger this error message

Code: Select all

overlayfs: workdir and upperdir must be seperate subtrees

This will be the tricky part whether to retain compatibility with aufs for savefile or not

The way I do it successfully in WDL is that I mount the savefile to a different mount point than what I use when save folder, then I mount bind it across to where savefolder mount would have been

[mistfire]

The way I do it successfully in WDL is that I mount the savefile to a different mount point than what I use when save folder, then I mount bind it across to where savefolder mount would have been

May I see that code in order to have an idea on what you talked about?

[dimkr]

The way I do it successfully in WDL is that I mount the savefile to a different mount point than what I use when save folder, then I mount bind it across to where savefolder mount would have been

woof-CE's overlay support does something similar, https://github.com/puppylinux-woof-CE/w ... /init#L486. When using overlay, pup_rw is a symlink to $SAVE/upper, rather than the mount point of $SAVE.

Yes, this means save file compatibility with aufs is lost, but I think that's the way to go, otherwise the init script, snapmergepuppy, etc' would have to deal with aufs whiteouts even when using overlay, potentially slowing them down. And you have no choice but to create two directories under the save file, because workdir must not overlap with upperdir, yet both must be in the same mount, so compatibility with aufs save files is impossible as far as I see. Save folders are a different creature, because you can always create a folder outside of the save folder, and use that as workdir.

[wiak]

The way I do it successfully in WDL is that I mount the savefile to a different mount point than what I use when save folder, then I mount bind it across to where savefolder mount would have been

May I see that code in order to have an idea on what you talked about?

At first I couldn't get savefile to work, but then this simple arrangement worked without issue. This is new, so I may find a better way to do it later, but what works works:

Code: Select all

mount "${ucimg}" ${layers_base}/uc_rw && mkdir -p ${layers_base}/uc_rw/upper_changes ${layers_base}/uc_rw/work
mount --bind ${layers_base}/uc_rw/upper_changes ${layers_base}/uc_ro

In WDL layers_base is /mnt/layers/.
KLV-Airedales save2flash -> snapmergepuppy variant by fredx181, with savefolders rsync back to uc_ro
so above makes that same script (without change) now also rsync back to uc_rw (the rw mounted Linux-formatted savefile) via uc_ro

Possibly I could do things via symlinks instead (uc_ro being made symlink to uc_rw here), but above worked quickly, and without as I say needing any changes to existing KLV-Airedale save2flash -> snapmergepuppy routines of fredx181 (and I was already taking too long coding all the combinations after many failures - I'll try Linux filesystem symlink later...).

EDIT: yes, as far as WDL initrd itself is concerned symlind instead of bind mount certainly fine, but I remember now - Fredx181's simple wee rsync script detects RAM2 mode (like Pupmode 13 basically) via noticing uc_ro is mounted, hence I used a bind mount for savefile case so no change needed to the save2flash script - could be changed of course, but I'll just leave it as it is since just for savefile and working okay.

I have never myself been interested in using savefiles before (and still much prefer save folders), until recently when wanted to install various KLV and WDL-initrd-booted distros to ntfs partition, so KLV-Airedale did not include savefile support until I implemented it recently, but savefile support all working fine now no matter the weedog RAM modes selected (like Pupmodes in a way and DebianDog porteus boot changes= modes, but done per my own recipes/experiments).

Above code is used in WDL RAM2 mode which mounts existing savefile on top ro overlayfs layer and session changes (top overlayfs rw layer) into RAM/upper_changes, which as I say ends up getting rsync'd back to the rw mounted savefile when save2flash done.

[mistfire]

QuickPup64 22.01 BETA 24 released

Changes:
* Loading pupsave file now works on overlayfs (not compatible with aufs savefiles, it will just create a new session under pupsave-overlay folder if aufs savefile was used. Only overlayfs savefolder was compatible on aufs)
* Overlayfs support bugfixes
* Linux kernel 5.19.7-lxpup64
* Some system bugfixes

WARNING: Overlayfs mode was still experimental. Use at your own risk.

Download: https://drive.google.com/file/d/1JcYAEd ... 5PliWl_6qc
MD5 Checksum: e4385dc95148061f20006d096f58a382

[wiak]

I really like QuickPup look and feel mistfire. Very attractive XFCE Pup - I almost don't want to call it a Pup because it is so full-featured and up there with the big distros in terms of user looks and friendliness. Nice piece of work.

[mistfire]

I really like QuickPup look and feel mistfire. Very attractive XFCE Pup - I almost don't want to call it a Pup because it is so full-featured and up there with the big distros in terms of user looks and friendliness. Nice piece of work.

I wish that broken XFCE status tray icon and dbus error message when clicking files on desktop was fixed. I hope that someone can found out the root cause of those problems that makes QuickPup64 stayed at beta state. When those are fixed then its possible to became a final version.

Yep this puplet was able to compete with major distros.

[wiak]

I really like QuickPup look and feel mistfire. Very attractive XFCE Pup - I almost don't want to call it a Pup because it is so full-featured and up there with the big distros in terms of user looks and friendliness. Nice piece of work.

I wish that broken XFCE status tray icon and dbus error message when clicking files on desktop was fixed.

Sorry, I've not been following the thread more generally, so didn't know about such issues existing - or what "broken XFCE status tray icon" refers to.

[Clarity]

These are some of the same known issues from opening post, here

[wiak]

These are some of the same known issues from opening post, here

Thanks Clarity.

I don't have any knowledge about Slackware packages.

However, I have an idea about this one (not a great idea though):

Icon artifacts on system-tray on xfce4-panel.

Seems to me that Status Tray Plugin doesn't work with Puppy tray apps. I couldn't say why since I know nothing about how these work (gtk issue?... I don't know). Problem is that xfce4-panel does not seem to include internal plugin "Notifications Area" (systray) that I not peebee uses in VoidPup64 xfce4 ydrive addon - that seems to work with Puppy tray apps. However that version of xfce4-panel is not what Void Linux repos provide by default - they supply version 4.16... whereas peebee is using 4.14.4; so if you can find a way to downgrade xfce4-panel to 4.14.4 seems you may get "Notification Areas" which will not have these artifacts. Then you wouldn't need to use the external, what seems to me, problematic Status Tray Plugin.

Having said that, that using an older version of xfce4-panel is not a good longterm solution - if indeed these Puppy Tray apps have a problem with newer xfce4 then that problem really needs addressed properly via fixing the Puppy tray apps or future of any xfce4-based Puppy is not good. I am not sure if I am correct about Notifications Area, but certainly doesn't seem to be there and I also note that rockedge uses 4.16... in KLV-Airedale and again with System Tray Plugin - but that works fine there since no Puppy Tray apps are used.

I didn't understand the issue regarding Dbus - I'd need an exact example to try it, and that Thunar issue is a major one by the sounds of it.

[Dry Falls]

Hi @mistfire. Wiak is right vis xfce4 version differences between 4.14 and 4.16; it's night and day. No longer any support for gtk2. But I think the difference is even greater than that. I've been playing with TWM in lighthouse with a rox panel and stalone tray. This is about as old a system as you can get. TWM doesn't deal well with compositing but will support the rox desktop (which does) overlay. The result of configuring stalone tray with pseudo or full transparency produces the same icon artifacts seen in quickpup. This led me to believe your problem may have to do with the compositer. Xfce4 panel as well as its plugins demand xfwm4 window manager be running or problems ensue.

The test I would try would be to install all the xfce packages from slackware (you can exclude elementary-icon-theme and mousepad) to rule out missing dependencies. But you'll still have to run xfwm4 on top. It may be you already do (I just don't recall) so sorry if I'm repeating the obvious.

Another alternative mentioned above is to use a different panel. Other panels as well as stand-alone systrays will run fine along with xfce4-panel. Just an idea to keep the menus, apps etc you already have working well. For ex. remove systray plugin from the main panel and run lxdepanel (or what have you) with only the systray enabled.

These frigging bugs associated with compatibility (or "security") issues can be a real bummer.

df

[wiak]

About the overlayfs mount remount, I found the following interesting link, not that I've worked out what it all means...

https://patchwork.kernel.org/project/li ... gmail.com/

[mistfire]

QuickPup64 22.01 BETA 25 released

Changes:
* Linux kernel 6.0-lxpup64
* Fixed package management
* Isolated user files (experimental) - Tired of moving your personal files from one savefile to another when your Puppy setup broke? By putting "phomedir=<folder name>" boot parameter, your personal file will be saved outside the save file and you can easily switch savefiles from one to another without loosing your personal files. This will only works if a savefile was loaded and the location where the savefile was stored must be linux filesystem. How it works? Upon setting up the layered filesystem, a folder defined by phomedir boot parameter was created beside the savefile then mounted to /home and /root folder.

Download: https://drive.google.com/file/d/1k3rOXy ... SZcdhxyq2e
MD5 Checksum: def6d974d37010b5292cc123f1d0bd68

NOTE: The filesize was increased because of SPIRV and GLSL libraries which was added as dependencies of FFMPEG. I wonder why slackware devs include those libs

[Clarity]

@mistfire this is a status report

QEMU and SG2D ISO file booting to desktop without issues. Boots with good progress messaging...runs fast...stable! QEMU Stanza which works very well is:
qemu-system-x86_64 -enable-kvm -m 2G -vga std -smp 2 -device AC97 -cdrom quickpup64_22.01-beta-25.iso
Further when boots are coupled with locations to save-sessions, then saves AND rebooting, this distro finds its sessions without problems or issues to desktop.

Question:

Has anyone tried QEMU with a UEFI BIOS parm?

[mistfire]

QuickPup64 22.01 BETA 26 released

Changes:
* Linux kernel 6.0.3-lxpup
* Updated blueman and python
* Updated gstreamer

Download: https://drive.google.com/file/d/1nLUSQ_ ... qGvcnED47g
MD5 Checksum: 0376a2b568dc4384a2e6a78365d854d4

[Clarity]

Downloaded and booted to VM desktop: No changes to QP v26 Menu (merely allow it to boot top Menu stanza). Total time 95 secondsqemu-system-x86_64 -enable-kvm -m 2G -vga std -smp 2 -device AC97 -cdrom quickpup64_22.01-beta-26.iso
BUT: Upon initial testing, the system will NOT shutdown by clicking the Menu's button and OK in the opening window showing Shutdown.

boot-QPv26.jpg (17.45 KiB) Viewed 6420 times

To shutdown, instead, one needs to exit to the command prompt and type 'poweroff'. Where one would expect to get the session-save script, it does not show up. Bug?

[williams2]

To shutdown, instead, one needs to exit to the command prompt and type 'poweroff'. Where one would expect to get the session-save script, it does not show up. Bug?

Does it continue the shut down process if you press ctrl+alt+backspace?

If yes, then you can fix that by editing /usr/bin/wmexit
near the bottom of the file add X Xorg to the end of the line:

Code: Select all

for i in xfce4-panel lxsession lxqt-session `cat /etc/windowmanager` jwm icewm openbox

like this:

Code: Select all

for i in xfce4-panel lxsession lxqt-session `cat /etc/windowmanager` jwm icewm openbox X Xorg

This is fixed in FossaPUP and later.
It may be fixed in the operating system updates, or not.

If killing X does not allow the shutdown to finish, it's probably not this bug.

[one]

Hi,

I have two frugal installs - one on a ext. SSD (ext4), the other on a SD card (FAT32), both with a savefile.
Both installs shutdown properly and are asking whether to save or not.

edit: booting pristine (without an existing savefile), the problem described by @Clarity does indeed occur.

ALT-CTRL-BACKSPACE exits Xorg to command prompt ... shutdown process does not proceed.

PS: many utilities in the menu>Setup do not work for me - clicking on them does nothing (Quicksetup, SFS-Load, ...)

peace

[mistfire]

@Clarity, @williams2, @one

I finally found the bug. The root cause was the gtkdialog was broken due to missing libncurses.so.5
I will reupload the iso file as soon as possible

[mistfire]

QuickPup64 22.01 BETA 26 has been reuploaded

* libncurses problem has been fixed

Download: https://drive.google.com/file/d/1nLUSQ_ ... qGvcnED47g
MD5 Checksum: 73d2927809ae10314d0454a992e87186

[one]

Hi @mistfire,

I tested your re-uploaded beta 26, created a new savefile and all is well now.

Thank you

peace

[mistfire]

QuickPup64 22.01 BETA 27 released

Changes:
* Linux kernel 6.0.7-lxpup64
* HAPSD (HDD shock protection) and Thermald enabled by default
* Added pulseaudio-equalizer
* Chooselocale bugfix
* Some optimizations

Download: https://drive.google.com/file/d/1bG1zV3 ... WlWPoGVvAA
MD5 Checksum: 9dbff77c38aa15450e0b1b4230838cbd

[Clarity]

QP64-v27b runs extremely well in QEMU as well as ISO file boots to desktop via SG2D. Stable, quick, and good layout.

Persistence for Frugal operations is what we all expect; as it finds the partition for saving when booted pristine as well as on all subsequent boots. There are no need for boot stanza changes for success in this PUP's navigations for its needs....NONE.

SAFE to Enjoy!

[mistfire]

QuickPup64 22.01 BETA 28 released

Changes:
* Linux kernel 6.0.11
* Added Salix-tools (time, users and groups, and hostname)
* Some puppy core apps integrated with xfce4-settings-manager
* Under-the-hood bugfixes

LINK REMOVED due to defect

[mikeslr]

There's something wrong with Internet connections under BETA 28. I haven't been able to figure out what.
On boot-up a notice appears that there are available networks and a launcher to configure networks appears on the task-bar. Clicking the launcher opens a GUI to select from available networks. After one's password is entered and "Ok?" selected no further action occurs other than that the taskbar launcher disappears.

None of the choices available if Internet Connection Wizard is 're-run' work. Installing older versions of network-manager, frisbee and Simple Network Setup proved unsuccessful. Switching kernels and associated drivers and firmware to that successfully used by Quickpup 22.01 also didn't help. I'm posting from that iteration now.

By 22.01 I mean the ISO I downloaded in mid-to-end-of October and didn't get around to examining. I think it was beta26 as that's the version I have 'in storage'. No SaveFile/Folder was created since the download. I think my attention until now have been focused on what Linux Mag should know, what new Puppy should be called to DistroWatch's attention and my own explorations of Woof. So, my apologies if the problem arose before this last iteration.