Discussion, talk and tips
https://forum.puppylinux.com/
@TerryH
Thanks for testing BW64 Beta-1.
There are a few reports about potential issues with the 6.1.X kernel and recent iterations of AMD chipsets, so your success with the Ryzen 7 5800H laptop is good news.
Good to see you on the forum again !
Just installed Bookworm-Pup64 on USB stick (didn't realize it was a Beta version).
Installed save folder to internal drive sda1. Machine: 13yo workstation, 4GB RAM. CPU i3-2100 @3.10GHz, 2 cores; 4 threads. External monitor through HDMI (Loewe TV)
Went ahead to set up as a daily driver for internet use and multimedia, nothing fancy.
*Changed resolution of screen---> Success, no issues.
*Changed global Fonts---> Succes, no issues.
*Installed favorite add-ons in firefox===> Success, no issues.
*Closed machine, saved session---> Success, no issues.
*Next boot: All settings made saved and loaded again---> Success, no issues.
*Load last session in RAM---> Success, no issues.
Bookworm (for me that is) has a solid feel to it. Stable and running smoothly after 3hrs of uptime. All menu items accessible and working as far as opening them from the menu.
Will be using this in the next couple of days as I would do with my current daily OS (Traditional full install Linux Parrot Home edition.)
Will focus on containers, sandbox and global (paid subscription) VPN.
This is good. Everything worked OOTB.
Sorry if this is already reported. I did not want to read 13 pages of posts.
SFS-load program does not work.
Isn't this suppose to run SFS-load-on-the-fly program?
When started, all it does is show a list of SFS packages from someplace.
You can do nothing with this list.
Plus stuff in this list is not usable for Bookworm Pup64.
-------------------------------------------------------------------------------------------------------------
SFSget program gives you this error.
-----------------------------------------------------------------------------------------------------------------
This also applies when using the Puppy Installer -> Install Applications ->
Load and Unload SFS Packages
Choose an SFS file from the official repo
Puppy Installer -> Installer ->
USB hard drive/ SSD
When selected to use this option, get the error.
.
.
I have both plugged into computer.
USB hard drive
USB SSD
@bigpup wrote:
SFS-load program does not work.
Traditionally, Puppy Linux uses aufs for the 'Union File System' which fully supports dynamic (on-the-fly) SFS loading/unloading. Most members of the Puppy community are familiar with this type of SFS loading.
On the other hand, Vanilla Dpup and Bookworm Pup64 (as currently configured) utilize the overlay 'Union File System' which does not directly support dynamic SFS loading. However, dimkr has added limited support for simulated dynamic SFS loading, under PUPMODE 5 (first boot) or 13 (pmedia=bootflash) only.
Consequently, if I understand correctly, the preferred method for SFS loading (when using overlay) is to place the SFS in /mnt/home, select it in sfs_load and reboot, instead of clicking the SFS for dynamic (on-the-fly) loading.
Since SFS loading in the overlay environment is a new concept for most Puppy users, maybe @dimkr will provide additional information.
---
@bigpup wrote:
SFSget program gives ... error.
SFSget is often used in legacy Puppy to download pre-configured applications in SFS format. However, SFSget is not used in BW64 since the APT package manager provides easy access to the comprehensive Debian repositories. Maybe SFSget should be removed to avoid confusion.
---
@bigpup wrote:
Puppy Installer -> Installer ->
USB hard drive/ SSD
When selected to use this option, get ... error.
The puppyinstaller application (/usr/sbin/puppyinstaller) is an old application. I'm not sure it will receive significant additional attention for future revisions in Woof-CE.
More info about using the different ways to suppose to be able to load an SFS
SFS-Load
Boot Manager -> SFS-Packages -> Choose which extra SFS files to load
Puppy Installer -> Install Applications -> Load and Unload SFS Packages
All of these bring up a list of SFS packages which has ones that are not good to be used.
wrong kernel sources, devx, 32bit compatability, etc........
To load and un-load.
It seems if all you do is left click one to highlight it in the listed SFS's, it gets placed in /etc/rc.d/BOOTCONFIG
It does stay highlighted if you close this list and open it again.
To remove the SFS from /etc/rc.d/BOOTCONFIG
click on a highlighted SFS in the list to un-select it.
So it can be loaded and unloaded from the layered file system, but a reboot seems to be needed to do it.
BOOTCONFIG is used when booting, to tell what SFS should be loaded.
UPDATE:
Still the listed SFS are not all good ones to use in this Puppy version.
Most of them have nothing useful for Bookworm-Pup64.
Most specific program SFS's are very old versions of the program.
Well it seems these are my stored SFS packages that are located in /mnt/home
So it is finding the SFS packages that are in /mnt/home
This is my old SFS packages.
So it is allowing you to load or unload your stored SFS packages from /mnt/home location.
Nope, nothing to add. It's supported under PUPMODE 5 and 13 only. It can be implemented with PUPMODE 12 but it will be slow and risky.
It will receive attention if woof-CE gets more active contributors and somebody decides to maintain it. (Also true for PPM and many others things people tend to complain about when they're missing or disabled in the name of stability and maintainability.) Puppy is a do-ocracy.
sfs_load.overlay (the overlay implementation of sfs_load) only allows the user to queue or unqueue SFSs for loading at boot time, when you run it through the menu. The old aufs implementation doesn't distinguish between "queue" and "load" in some text presented to the user.
If you click a SFS in ROX-Filer, sfs_load.overlay will offer you to queue the SFS for loading (again, at boot time), but if using PUPMODE 5 or 13, it will also ask you if you want to load it now (or unload, if already loaded and not at boot time).
To summarize:
1. You can queue a SFS for loading at boot time; you'll need to reboot to load it
2. You can unqueue a SFS that's queued for loading at boot time *and it won't be loaded on reboot); you'll need to reboot now if you want to unload it now
3. You can load a SFS now (= after boot time) but only if in PUPMODE 5 or 13; you can unload it without rebooting
New ISO: Bookworm Pup64 Beta-2
See first post.
dimkr wrote: ↑Mon May 29, 2023 8:06 amNope, nothing to add. It's supported under PUPMODE 5 and 13 only. It can be implemented with PUPMODE 12 but it will be slow and risky.
It will receive attention if woof-CE gets more active contributors and somebody decides to maintain it. (Also true for PPM and many others things people tend to complain about when they're missing or disabled in the name of stability and maintainability.) Puppy is a do-ocracy.
sfs_load.overlay (the overlay implementation of sfs_load) only allows the user to queue or unqueue SFSs for loading at boot time, when you run it through the menu. The old aufs implementation doesn't distinguish between "queue" and "load" in some text presented to the user.
If you click a SFS in ROX-Filer, sfs_load.overlay will offer you to queue the SFS for loading (again, at boot time), but if using PUPMODE 5 or 13, it will also ask you if you want to load it now (or unload, if already loaded and not at boot time).
To summarize:
1. You can queue a SFS for loading at boot time; you'll need to reboot to load it
2. You can unqueue a SFS that's queued for loading at boot time *and it won't be loaded on reboot); you'll need to reboot now if you want to unload it now
3. You can load a SFS now (= after boot time) but only if in PUPMODE 5 or 13; you can unload it without rebooting
And if you load an sfs file with sfs_load -c -q after the initial booting stages, eg: placing the command in /etc/rc.d/rc.local or /root/Startup when running in mode 5 or 13. The result will be the same as if using aufs then?
No. sfs_load.overlay doesn't accept any flags (drop -q, etc'), and there's a performance, RAM consumption and load time penalty for SFSs loaded dynamically, because this is done using symlinks in RAM. If you want to load a SFS at boot time, your best option is to queue it for loading and let initrd load it.
If it's a tiny SFS with very few files, the "cost" of dynamic loading should be very low.
And I forgot to mention - sfs_load.overlay doesn't allow overlap. A dynamically loaded SFS cannot replace an existing file from another SFS, it's only allowed to add files. Loading at boot time doesn't have this limitation.
Short version: Overlays is a crippled system compared to what we've had and are used to. There are only two downsides to continuing with AUFS:
(1) Puppys can't use Linux generated Kernels OOTB. Someone has to modify them to support AUFS. Not a particularly challenging hurdle. Puppy Devs have had the tools to do that and been doing that for years.
(2) There is only one AUFS maintainer. Well, we are all mortal and all have 'real lives' to lead. I don't have immediately at hand the website providing instructions to create AUFS. But it was available the last time I recently looked. And granted that I know little about compiling, the instructions did not look particularly challenging.
In the past someone proposed that 'Puppy' adopt the creation of AUFS as one of its core projects. May I suggest that we revisit that proposal.
dimkr wrote: ↑Mon May 29, 2023 7:37 pmNo. sfs_load.overlay doesn't accept any flags (drop -q, etc'), and there's a performance, RAM consumption and load time penalty for SFSs loaded dynamically, because this is done using symlinks in RAM. If you want to load a SFS at boot time, your best option is to queue it for loading and let initrd load it.
If it's a tiny SFS with very few files, the "cost" of dynamic loading should be very low.
And I forgot to mention - sfs_load.overlay doesn't allow overlap. A dynamically loaded SFS cannot replace an existing file from another SFS, it's only allowed to add files. Loading at boot time doesn't have this limitation.
Thanks. I've been loading sfs's with sfs_load -c -q from /etc/rc.d/rc.local for ages (at least four depending on the Puppy I'm using) without any performance issues or any other snags.
Again, sfs_load.overlay is very different from sfs_load. Your past experience with sfs_load and aufs is irrelevant and you shouldn't assume blindly that what worked for you in the past will work the same way.
Dear All, I have a hard time understanding the fuzz about aufs and overlayfs.
In the curent overlayfs builds (bookworm or vanilladpup) if you replace the Kernel (vmlinuz+zdrv) with an aufs-enabled kernel the system defaults to Aufs use with all the aufs goodies going. (I actually used peebee's kernel from S15pup64 - after moving everything to /usr - to verify that indeed works *)
radky and dimkr like overlayfs over aufs and there is nothing we can (or should) do about it. There are THEIR pupies.
What one CAN do is replace the kernel in Bookworm64 with an aufs-enabled one and become the developer of a brand new Bookworm64A!
* PS: Of course kbuild is not working in this case so ideally the kenel should be rebuild with aufs enabled for full compatibility
I've gone back to making .pets, pup specific. Works for overlayfs or aufs. If I need to compile in overlayfs, I use adrv & bdrv for sources & devx.
(Word of caution, please don't kill me)
Kernels are sensitive. Think (at least) twice before you replace your kernel, because:
1. aufs is a big kernel patch, I've seen kernels where aufs fails randomly or constantly causes kernel crashes the kernel recovers from (with data loss?), and some of these kernel were still officially supported by aufs in that point in time - aufs doesn't get as much QA as it once did because it's out of the default install or live media of the major distros for several years now. When you use aufs the rather unique way Puppy uses it, you're the one doing this QA and don't have other distros as the "first line of defense" between you and issues with aufs.
2. It's very easy to build a misconfigured kernel, which is slow, power hungry, insecure and what not. I trust the Debian kernel team's ability to construct a working configuration file more than I trust myself. Who do you trust?
3. The dpup kernel built by woof-CE rebuilds the Debian kernel source using Debian's toolchain, with super minimal configuration adjustments (https://github.com/puppylinux-woof-CE/w ... s/bookworm - 125 lines out of 10k+). If Debian's developers approved a 6.1.x bugfix release for inclusion in Debian 12 as an update, after QA, this kernel is more likely to be stable, regression-free and safe for use compared to any other kernel that you slap onto your Debian 12 based Puppy, including newer 6.1.x kernels.
4. The DKMS packages for Debian 12 target 6.1.x without the aufs patches, because that's what the Debian 12 kernel is. In a Debian 12 based Puppy with a different kernel, drivers may fail to build (at installation time, that's what DKMS does) or misbehave (fail, crash, trigger undefined behavior, corrupt data ...). If you don't use Debian drivers to avoid these risks and get your drivers elsewhere, you're facing other risks and you're on your own, because the kernel+drivers combination you're using is less common than the kernel+drivers combination Debian users have and doesn't enjoy Debian's QA and regression tracking.
5. If you're using old hardware, your setup is extra sensitive to kernel changes, because most Debian users probably have newer hardware. Your less common hardware introduces a certain voodoo factor: drivers needed by your old hardware may be buggy while newer hardware isn't affected and some bugs are statistical and don't happen 10 out of 10 times. For example, some memory corruption bugs (especially use-after-free bugs) are easier to reproduce in a computer with less RAM. If the Debian kernel works for you, maybe it's because Debian has other users with similar hardware who report bugs and help fix them, before they affect you. When you swap your kernel, you're jumping out of this lifeboat. (I have a good example: I have one 8 years old laptop laptop that's sensitive to the compiler version I'm using to build the kernel: it freezes with a white screen if I boot a kernel rebuilt with a different GCC version. It's a budget laptop and most of these are dead already, so I'm pretty much on my own here. But the Debian kernel works!)
Hi,
I replaced the initrd.gz wmlinuz grubcfg isolinux.bin similar files with each other in the fledgling version that installs sfs files on the hard drive.
not loaded, I tried such a stupid thing 
(öyle olmuyor değil mi)
can you add full install option ?
https://ibb.co/FVVkPMq
Best wishes
Yes. Completely. 178 compared to 2527 lines.
Dear dimkr
nobody is going to kill the ONLY active woof-CE developer. But,
Your disapproval of aufs is well publicized.
On the other hand the preference (with minimal or no complains) of puppy community for aufs is also well documented.
Your arguments against it though may have a touch of exaggeration
1) Aufs is a sizable patch but not for an 80 MB kernel.
2) No one suggests changing toolchain or kernel configuration other than the addition of AUFS support
3) Nothing stops Debian updates to be applied (specially since Debian has nothing to do with AUFS)
4) DKMS is fs agnostic I think. So it is likely not to have issues (but of course needs to be tested).
5) See #2.Τhe Aufs kernel should be build in github with the bookworm toolchain and with the AUFS patch and userspace support files as the only extra.
Debian does not provide an aufs patch after Sid. However, I believe that there is nothing in the Debian kernels that would block integration and function of Aufs, thus the so important Debian vetting could be maintained.
Having an identical overlayfs kernel will also make very easy to identify (and report or fix) any aufs issues too.
Hopefully someone - that would also be willing to address any issues related to aufs kernels - will build the Bookworm/vanialladpup kernel with Aufs support and see how it goes.
Thanks again for the update to the applications and kernel.
I had thought members would focus on the "original" development instead of mixing and matching and attempting to utilise older applications.
Debian Bookworm offers many new opportunities, technologies and advancements.
As with each new offering, it will be adopted by some and others will return to their favourite build.
Keep up the good work guys 
retiredt00 wrote: ↑Tue May 30, 2023 11:51 am5) See #2.Τhe Aufs kernel should be build in github with the bookworm toolchain and with the AUFS patch and userspace support files as the only extra.
If anyone volunteers to add a kernel building pipeline with aufs and maintain it over time - I can help with the logistics of getting this merged into woof-CE. But I don't have the time and the willingness to maintain something like this anymore, considering all the bad experience I have with aufs.
What can I say, I must focus on the 80% I can fix today and leave the remaining 20% for later. Unifying sfs_load.overlay with sfs_load will take time, because the latter is big, messy and full of assumptions only true when using aufs. To move forward now, I had to write something small and limited that at least covers some use cases (like PUPMODE 5 and 13) with minimum code.
A little praise from a lazy end-user perspective:
---------------------------------------------------------------------------------------------------------------------------------------------
*JWM is the lightest interface available in Linux, together with ROX Filer it consumes only a few hundred mb of memory.
*It's non-systemd, so there's not much running in the background, I'm not knocking systemd, I don't know if it has its good points.
*The default installed applications are very well chosen. Celluloid, mpv, DeaDBeeF These are the best multimedia applications in linux.
Celluloid is also an iptv player, DeaDBeeF is an online radio player. The lightest one is mpv video player.
If I want more, it is already compatible with Debian repositories and Synaptic Package Manager is available.
*There's also Flatpak, which is the best, and it's better to be able to easily upgrade to the latest version all the time, including social media apps, than to have it take up a bit more space.
You can add Flatseal by default to the release version if you see fit, it's up to you.
*Screen recording can be taken as gif in video quality, I like this feature.
*I've written before my friends, there is a nice application called Gnome Disk Utility, it has more settings than GParted.
Not only thanks to this application, I don't know if there are other ways to do it in the terminal, Disable Write Cache with Gnome Disk Utility
If it is not suitable for desktop PCs, it will be useful for laptop users to save energy.
Another one, if you don't want to deal with the dd command like me, this application formats hard disk/usb etc. in a healthy way.
There is another application called *GSmartControl, I think it is ssd-oriented, you can consider adding it.
*Does a person's desire end? It does not end. I wish I had these applications.
Android Debug Bridge, I'm not used to mobile, even if it's not on every phone, there may be people who want to install a rum who want to try it on models that work.
*For https://api.invidious.io you can add a small mpv based option similar to smtube.
*I purposely left out other available tools, I'm just a lazy end user used to the graphical interface.
This, my friends, is my reflection on Linux.
The most lightweight and functional Debian based 64 bit distribution Bookworm Pup64
---------------------------------------------------------------------------------------------------------------------------------------------
Flatpak is the best solution for those who want to keep their mobile social media apps in sync with the desktop version and always up to date.
For example, I can try Flatpak applications thanks to my large swap space.
Since Bookworm Pup64 running Frugal can't install Flatpak apps in ram, you will have to backup already installed flatpak apps to usb with pupsave, right?
So for Frugal mode and Flatpak I will need a USB stick with average Read and Write speeds of 1000 MB/s or 500 MB/s.
So now the ads
https://www.pendrivelinux.com/fastest-usb-flash-drives/
Oscar Goes To Bookworm Pup64 
This is a suggestion about SFS_Load.
I edited the file sfs_load.overlay
I added some information to tell people what it will do and how to use it.
.
.
This is my edited version.
(remove the fake .gz from the name and give it execute permissions to run)
.
-------------------------------------------------------------------------------------------
Where is this list coming from?
It seems to be a list of all the SFS packages that I have stored at /mnt/home
So this is a list of the SFS packages I have stored for loading and unloading.
.
.
Note:
this /mnt/home is the location of the save folder, which is a partition different from the one that has the Bookworm frugal install.
That is what is suppose to happen.
/mnt/home is always the partition that the save is stored on.
I did this as a test.
The frugal install is on sdb2 partition formatted fat32.
The save folder is on sdb6 partition formatted ext3.
So /mnt/home location is being correctly used.
.
.
fs_load.overlay.gz file didn't open for me.
this is the interface https://ibb.co/D4Q50d1
-------------------------------------------------------
the previous message is from beta1, the one I just wrote is beta2, I think you can look at it from this menu when you put the sfs files into mnt/home, but the gz didn't open for me 
TBO, while I may decry the loss of flexibility SFSes have provided to Puppys, my current Puppys only use one, a LibreOffice.sfs. All the other applications I used to run as SFSes have been supplanted by AppImages and Portables. Using these with an Overlay system completely avoids the restrictions it imposes on SFSes and -just as important to me on my system-- the errors I reported when using SFSes.
LibreOffice.sfs could be replaced by a portable. MikeWalsh has published one. It's downsides are that it doesn't enable you to choose the libreoffice modules as defaults --e.g., default Word processor > Libreoffice writer-- or add its modules to the Right-Click menu. Taking a clue from how MikeWalsh constructed Wine-portable, I've rebuilt LibreOffice-portable for my own use. I haven't published it as I'm not yet sure I got everything right. Like Mike's Wine-portable, it involves a framework that makes use of an AppImage. See, https://www.forum.puppylinux.com/viewto ... 075#p68075. This has a great advantage: Up-grades are easy; just replace the AppImage.
If someone want's to try it, I can upload the frame-work and point out the issues I still have. FWIW, those issues are minor. AS-IS it appears to function well.
The point of the above is that moving forward it is likely that we can all but abandon Puppys' need to use any 'application SFS'. In this regard fredx181 has published an application, https://www.forum.puppylinux.com/viewto ... 3250#p3250, which simplifies the creation of AppImages, generating a 'portable' as a bi-product. It can also create a chrooted application. fred's 'portable creator' in its present form isn't always successful. But fixing it and/or enhancing it may be both easier and more acceptable than trying to mangle AUFS capabilities into the Overlay system.
There is one other tool involving SFSes which remains useful in this context but can be --should be-- replaced: PaDS, https://www.forum.puppylinux.com/viewto ... 6355#p6355.
Having synaptic is great. But it is not 100% accurate: it expects to run under debian or Ubuntu, not under Puppy which doesn't always have the built-in infra-structure the devs at debian/Ubuntu and/or maintainers of apt/synaptic expect. On a couple of occasions using synaptic I've still had to hunt down libraries Puppys needed for an application to function. And apt/synatic are designed to install packages*. If you chose just to download them (they'll show up somewhere in /var) for each application you can find yourself with dozens of packages. The problem of multiple packages needed for one application is also true if you want, for example, the latest LibreOffice and select 'deb'. My recollection is that about forty debs will be downloaded.
That's where PaDS come in.
I use PaDS primarily because it will take all debs, pets, sfses, tar.xzes and several other packages you place in a folder, serially decompress each, copy their respective contents into a work folder --each file in the right location-- and generate an SFS. I don't use the SFS**. I mount it and copy its contents into a folder. With that folder as the 'source' I can then create a pet, or use fred's application to create an AppImage or portable.
In simple terms, my use of PaDS is entirely because it automates the merger of packgages. I believe there already are other applications that can do this. But I don't know which, or where to obtain them. Moreover, PaDS predates Puppys involvement with the 'User-Merge' Rule so lacks a means to implement it (or not) when necessary. PaDS also can't work with the xbps packages used under VoidPup.
What's needed is a similar tool for merging packages that meets the needs of Puppy in today's Linux environment.
-=-=-=-=-
* That's OK if you don't mind you're overlay>upper folder becoming gargantuan or having Puppy just being another 'spin' of debian/ubuntu just being run as a portable operating system.
** Even to use the application as an SFS some 'adjustments' frequently have to be made: /usr/share/applications...desktop's Categories don't always meet Puppy's criteria, occasionally the Exec= argument is problematic; and the icon to be displayed isn't always found.
What you are describing is fred's "apt2sfs" script in debian dog.
It does one better and builds the .sfs file by installing each .deb file in a chroot.
sucuklu yumurta wrote: ↑Wed May 31, 2023 12:08 pmfs_load.overlay.gz file didn't open for me.
this is the interface https://ibb.co/D4Q50d1
-------------------------------------------------------
the previous message is from beta1, the one I just wrote is beta2, I think you can look at it from this menu when you put the sfs files into mnt/home, but the gz didn't open for me
remove the fake .gz from the name and give it execute permissions to run.
In Rox file manager, right click on file and select rename. then select properties and check all the exec items and refresh.
Also for it to show any SFS packages, you have to have them stored in /mnt/home.
To have a /mnt/home in the file system, you have to make a save, and are booting using the save.
/mnt/home to the file system, will be the partition the save is on.