BookwormPup64 10.0.6

[rcrsn51]

V10.0.1 works with ISObooter3.

[peebee]

2 small issues noted:

1. mtPaint -> Actions -> Print doesn't work

2. coloured output printed to CUPS-Pdf only appear in monochrome (also an issue for LunarPup32 - viewtopic.php?p=96385#p96385) e.g. try printing the Help page.

[radky]

1. mtPaint -> Actions -> Print doesn't work

@peebee

Thanks for the report.

Printing images via mtPaint requires installing gtklp (graphical frontend for CUPS).

apt update
apt install gtklp

then

1 - Open mtPaint and go to File -> Actions -> Configure
2 - Select 'Print image' in the list of Actions
3 - In the Command box, change kprinter %f to gtklp %f, and click OK
4 - To print an image, go to mtPaint -> File -> Actions -> Print image

[radky]

2. coloured output printed to CUPS-Pdf only appear in monochrome (also an issue for LunarPup32 - viewtopic.php?p=96385#p96385) e.g. try printing the Help page.

@peebee

RE: CUPS-PDF printing in monochrome only

If I understand correctly, there are multiple bug reports concerning failed color printing with CUPS 2.4.2 in Debian Bookworm and Ubuntu Lunar:

https://github.com/OpenPrinting/cups/issues/421
https://github.com/OpenPrinting/cups/pull/500
https://github.com/OpenPrinting/cups/pu ... 0c48f62f50
https://github.com/altlinux/specs/commi ... 9be400bc5a

Presumably, proper fixes will be available in CUPS 2.4.3 (or later), but I'm not sure when Debian and/or Ubuntu will include the fixes in future releases. It seems Debian Trixie and Sid also have iterations of CUPS 2.4.2, so it may be awhile before this is addressed downstream.

For now, some have suggested a crude workaround to reset the color option for CUPS (at least until a proper fix is available).

For example, for the Puppy CUPS-PDF print option, run the following script in a terminal before printing,
or place the script in /root/Startup to auto-run when booting:

lpadmin -p CUPS-PDF -R print-color-mode-default

Maybe @dimkr or one of our CUPS experts will have a much better solution.

[dimkr]

https://bugs.debian.org/cgi-bin/bugrepo ... ug=1043331 sounds exactly like this problem. Just change the default until this is fixed upstream (unless you want to rebuild CUPS with a patch, which sounds like a very bad idea to me, or become a Debian developer).

[retiredt00]

Dear radky
thank you for this new bookworm version.
Runs pretty well and is really reminiscent of the yester-puppies.

However, I wanted also the SFS convenience of yester-puppies so I used the FatDog 900 6.1.39 kernel to make kbuild-6.1.39.sfs and a new zdrv_dpup_10.0.1.sfs.
Together with the FatDog 900 vmlinuz I uploaded them in Wetranfer* at this link location https://we.tl/t-knipQtL8I6
(md5sum: ce34baa790930b4f47dcadf9083435a6 BP64_aufs.tar.gz)

This aufs-supporting 6.1.39 kernel behaves very well loading and unloading SFSs, so far. kbuild also works as I could build a couple out of tree modules with dkms and without issues.

Anyone that might want to test, just rename the original vmlinuz and zdrv_dpup_10.0.1.sfs and copy/move the 3 files from the BP64_aufs at the root of your BookwormPup64 installation.

(I know dimkr has pointed to woof-ce automated build system, however after a fast look is very hard to see how you can just build a kernel appropriate for a specific puppy without building the entire puppy or getting the logic and sequence of events of the entire yml-based build system. Or maybe I'm just too old )

* I should point out that wetransfer keeps the files for just 1 week and then they are deleted.

Note to the administrators: As this is just my little test I have no intention to keep up with this or support it in anyway. Besides kernel issues would be more appropriate for the FatDg team (that now also provides dkms support). If you think that this post is misplaced here please delete it. There is no point to move it as the wetranfer link will expire in a week and I have no intention to re-upload. THX

[mikeslr]

Thanks, retiredt00, for the package. The SFS-issue is the only thing which has prevented me from asserting that Bookworm is an unqualified success. Have downloaded you package and will try it out.

[amethyst]

Thanks, retiredt00, for the package. The SFS-issue is the only thing which has prevented me from asserting that Bookworm is an unqualified success. Have downloaded you package and will try it out.

This doesn't download for me? Get a message: "Your download has started" but nothing starts. Can someone upload to another location too, please?

[amethyst]

I've downloaded this as is to check out the overlay file structure. Now, I'm not sure what all the boo-ha was all about but this distribution seems to work the same as I'm used to with aufs. I can load and unload sfs's on the fly, I can save my changes to an adrv with the same tool I've used with aufs, etc. It seems the necessary symlinks have just been made to upper-changes (or whatever it's called) and it works as I'm used to with aufs. Am I missing something?

[rockedge]

Am I missing something?

No. Pretty cool eh?

Once the mechanism to load SFS's on the fly with overlayfs layered file system was a solid reliable performer, the differences between AUFS and OverlayFS for the regular user are not really noticeable. One of the features that I always really liked in Puppy Linux was the ability to load and unload SFS's for particular tasks, and glad to see it able to work in the overlayfs environment.

A lot of work went into it to make it so smooth that no one notices.........

[amethyst]

Am I missing something?

No. Pretty cool eh?

Once the mechanism to load SFS's on the fly with overlayfs layered file system was a solid reliable performer, the differences between AUFS and OverlayFS for the regular user are not really noticeable. One of the features that I always really liked in Puppy Linux was the ability to load and unload SFS's for particular tasks, and glad to see it able to work in the overlayfs environment.

A lot of work went into it to make it so smooth that no one notices.........

But there seems to be much confusion about this. If you just go up a few posts here, another poster changed some stuff because he wants it to behave like aufs and mikeslr for example bringing up the sfs load issue again. Why, it works for me as is...

[dimkr]

A lot of work went into it to make it so smooth that no one notices.........

Indeed - https://github.com/puppylinux-woof-CE/w ... ed+overlay

(And if you find any issues, report them and help get them fixed in woof-CE, otherwise they won't go away.)

[amethyst]

A lot of work went into it to make it so smooth that no one notices.........

Indeed - https://github.com/puppylinux-woof-CE/w ... ed+overlay

(And if you find any issues, report them and help get them fixed in woof-CE, otherwise they won't go away.)

I have checked it very very briefly though before returning to my daily driver. Good to know however that I may one day switch to overlay without concerns over general Puppy operation as I know it.

[mikeslr]

My apologies, Radky, and my thanks to amethyst for calling me on what had become a misleading assertion.

IIRC, when Bookworm was first published SFS-load-on-the fly didn't work. A reboot was necessary. I know there were discussions of possible solutions. I think fredx181 provided an application. At least on my system a reboot remained necessary. I don't know of any posts indicating it had been resolved, and the change-log doesn't suggest it was.

Recent posts, and especially amethyst's, suggest that SFS-load-on-the-fly now works OOTB. So I've booted into Bookworm Pup64 10.0.1, pfix=ram, and indeed it does. I am posting using I believe peebee's Chromium64-111...sfs, having loaded it via a Right-Click menu option. I was also able to load-and-unload on-the-fly blender-2.76-x86_64.sfs.

Really great work, radky and all who contributed.

[ozsouth]

Sorry for joining in late, but my impression was that overlayfs with sfs loading only works fully when running in ram. Once a savefile/folder is used, this was not so - integration of loaded files didn't occur (i.e. with devx). Certainly the case in s15pup64 up to end July. Has that now changed?

[radky]

@mikeslr and @ozsouth

In BW64 10.0.1, the sfs_load.overlay GUI provides Info and Help resources with important guidelines for using SFS-load in the OverlayFS environment.

Below is a screenshot of the Info resource:

[amethyst]

Didn't check but what is the command to load an sfs on the fly? I normally use: sfs _load -c -q NameOfSFS.sfs and I put this command in /etc/rc.d/rc.local for automatic loading after startup. I don't use a save file/folder.

[radky]

Didn't check but what is the command to load an sfs on the fly? I normally use: sfs _load -c -q NameOfSFS.sfs and I put this command in /etc/rc.d/rc.local for automatic loading after startup. I don't use a save file/folder.

@amethyst

In the OverlayFS environment, the SFS-Load executable (sfs_load.overlay) is much smaller than legacy sfs_load, and the code is quite different. The command-line switches of legacy sfs_load are not applicable to sfs_load.overlay.

In the OverlayFS environment, when an sfs is loaded dynamically in PUPMODES 5 and 13, the sfs is mounted and the files are copied (cp -asn) to the underlying filesystem as symlinks which do not overwrite any existing files.

Please see /usr/sbin/sfs_load.overlay (starting with line 45 in BW64).

[amethyst]

Didn't check but what is the command to load an sfs on the fly? I normally use: sfs _load -c -q NameOfSFS.sfs and I put this command in /etc/rc.d/rc.local for automatic loading after startup. I don't use a save file/folder.

@amethyst

In the OverlayFS environment, the SFS-Load executable (sfs_load.overlay) is much smaller than legacy sfs_load, and the code is quite different. The command-line switches of legacy sfs_load are not applicable to sfs_load.overlay.

In the OverlayFS environment, when an sfs is loaded dynamically in PUPMODES 5 and 13, the sfs is mounted and the files are copied (cp -asn) to the underlying filesystem as symlinks which do not overwrite any existing files.

Please see /usr/sbin/sfs_load.overlay (starting with line 45 in BW64).

Probably better to invoke a few additional drives then. For personal use I'll probably modify the init to invoke more drives for the sfs's I want to be loaded automatically at bootup since I don't operate with save file/folder OR merge the contents into one of the existing additional drives. Actually it's a "cleaner" method opposed to the "roundabout way" to load sfs's on the fly with overlays. Not a major issue.

[mikeslr]

And fortunately for me, I've only used Pupmode13 since I found out about it.

[wizard]

@mikeslr
@ozsouth
@amethyst

I think the popup message(s) that appear when you click a .sfs file are a bit unclear.
1."mounting" only lets you view the .sfs, "loading" lets you run the application
2. BootManager refers to Menu>Setup>SFS-Load

There are two categories for "loading", Load on reboot and Load now. You should refer to:
Menu>SFS-Load>Help for a better explanation of when each applies.

Thanks
wizard

[dimkr]

And fortunately for me, I've only used Pupmode13 since I found out about it.

I wonder how many Puppy users use PUPMODE 12 or 66 and not 13, and I wonder how many Puppy users don't boot from a flash drive. IMO PUPMODE 13 is the best feature of Puppy

Any Puppy built before https://github.com/puppylinux-woof-CE/w ... 4a19038574 (March 2023) will default to PUPMODE 12 (!) when you boot from a flash drive without specifying pmedia=bootflash, which is not the default in the ISO. Bookworm Pup64 has the fix for this and will default to PUPMODE 13 if booting from a flash drive when pmedia=usbflash or unspecified (the default in the ISO), so I believe that very few users use it with PUPMODE 12 and actually notice the limited support for SFS loading with overlay.

[ozsouth]

Running off an ssd, I either have pupmode 5 (first boot), or when I use a savefolder, pupmode 12, so I noticed the limitation.

[amethyst]

I also run in pupmode 5 all the time but will use pupmode 13 (usb/ataflash) if I had to use a save file/folder (which I never use).

[retiredt00]

After the introduction of savefolder by gyro back then, I always run puppies that I want to use in pupmode 12 (and in the past pupmode 6 and 2) from an etx2/3/4 HD or USB stick/SDcard with a savefolder (BTW that "failing" USB/SDcards is a myth, if you do not get the cheapest of the lot. Through the years I only had one 2GB stick failing).
In puppies I want play with or show to another etc, pupmode 5 and 13 is more likely.
So it depends how you see/envision Puppylinux OS I think.

[dancytron]

And fortunately for me, I've only used Pupmode13 since I found out about it.

I wonder how many Puppy users use PUPMODE 12 or 66 and not 13, and I wonder how many Puppy users don't boot from a flash drive. IMO PUPMODE 13 is the best feature of Puppy

/snip

I always run Pupmode 13 or Dog equivalent, but I run from a hard drive with multiple frugal installs. I just use a usb drive for initial installs, other people's computers, or as a backup.

The only time I use Pupmode 12 Dog equivalent is when I do a big "apt-get upgrade" because you can max out the memory on a low RAM computer.

[mikeslr]

Since I'm correcting mis-impressions I had and asserted, let me thank radky, and/or dimkr for conman wifi application. I had reported that I could find no way to select the signal broadcast by my wifi extender. My router is on the 2nd floor. To access wifi on my Desktop in the basement an extender/repeater is necessary. The extender/repeater broadcasts two signals, the original one it received and another under a different name which is often much stronger. My practice has been to work with that Desktop which has much more resources. My Laptop in the den on the first floor --about six feet from the extender/repeater-- is mostly used to search the internet while watching TV.

For the first time, I just transferred Bookworm from my desktop in the basement to my laptop in the den. The alternate signal displays as 'Open' but requires that the password of the original signal be provided. What I've discovered is that conman works exactly like frisbee: select and provide the password for the original signal, then just switch to the extender's signal.

I don't know if there has been improvements to conman or my previous difficulty had resulted from the weak signal --even with the repeater/extender-- received in the basement. In any event, thanks guys

[Geek3579]

And fortunately for me, I've only used Pupmode13 since I found out about it.

I wonder how many Puppy users use PUPMODE 12 or 66 and not 13, and I wonder how many Puppy users don't boot from a flash drive. IMO PUPMODE 13 is the best feature of Puppy

/snip

I always run Pupmode 13 or Dog equivalent, but I run from a hard drive with multiple frugal installs. I just use a usb drive for initial installs, other people's computers, or as a backup.

The only time I use Pupmode 12 Dog equivalent is when I do a big "apt-get upgrade" because you can max out the memory on a low RAM computer.

I am running a frugal install of Bookwormpup64 10.0.1 on a virtual drive in QEMU, but after trying usbflash, ataflash, etc in the GRUB2 boot script, the OS boots in PUPMODE=12 and I don't get a save icon on the desktop (and the Event Manager/Save Session options are greyed out) . This has never been a problem with other pups in QEMU, as far as I can recall. I have no idea what to try next in this virtual context.

[retiredt00]

Dear all,
I made a couple of SFSs for big programs, for a friend that did not want to fill up his savefile, to complement Bookworm Pup64 10.0.1 offerings and I thought to share for anyone interested.
Apologies if someone else did it already and I missed it.
One has the latest Google Chrome and Skype together (user demand - sorry) and the other the ZOOM application
They are tested with an AUFS enabled kernel but I assume will work with the original overlayfs kernel too.

As before they are in wetransfer and the link will expire in a week
Link: https://we.tl/t-GRlVxCXVkU
Files
chrome_n_skype_170823.sfs sm5sum f87f34b17aac6e8b030088acb413a318 259MB
zoom_170823.sfs md5sum 0e4711e2cb66722bc93fdfae012a9f43 255MB

[mikeslr]

See my post here, https://www.forum.puppylinux.com/viewto ... 646#p96646.

Edit: "What I've discovered is that conman works exactly like frisbee: select and provide the password for the original signal, then just switch to the extender's signal."

Well, almost. Although conman preserves the password, the preference to use the Extender's signal is not preserved, either by a Save or the Utilities' Save2SFS module. After a reboot, setup wifi must be run and the extender's signal selected again.. No big deal, it takes less than a minute.