BookwormPup64 10.0.6

[MochiMoppel]

For switching to/from ConnMan and legacy Connect Wizard utilities, BW64 also provides Menu -> Setup -> Internet Connection Switcher, which automatically adjusts the requisite exe and rc files.

Could this be implemented in a way that does not require a reboot? I'm using PUPMODE 5.

The best of those on my system --fewest loss of connections: don't ask me why-- is Network Connection Wizard. But it's GUI needs adjustment. Without regard for what I set my Screen Resolution at, I have to 'maximize-y' to see its controls.

Most likely it needs gtk2dialog.

[rerwin]

For switching to/from ConnMan and legacy Connect Wizard utilities, BW64 also provides Menu -> Setup -> Internet Connection Switcher, which automatically adjusts the requisite exe and rc files.

Thank you for pointing that out to me.

Since there is no need for my crude workaround package, I am removing the postings for it. Pleased to see Internet Connection Switcher is also in fossapup64_9.6CE.

[Clarity]

I posted earlier about the inability to reference the boot device. Some might ask "why" someone would want to do so.

Example Reasons

• To upgrade/change the physical Ventoy USB

• to download/add/delete ISOs to its BOOTISOS folder

• to access other files/folders of info/data contained on the USB

• I'm sure there are many more that I miss

FYI

[Clarity]

New Issue
@gyrog 'may' know the answer to this: Why is this version NOT using SAVESPEC on initial boot?
It is present, properly, in the BOOTISOS folder along with the ISO files, yet on a 'default' pristine boot with NO intercepts/changes to the PUP's menu, it is not using it for shutdown/reboot session processing ???

Question
Bug or operational change?

HOLD the Presses!!! There may be more info coming forth from my testing.
SAVEFILE contents

Code: Select all

SS_ID='Persistence'
SS_DIR='/Sessions'
SS_MEDIA='atahd'

[Clarity]

Update report of ISO file booting

There is a problem that I will report to Ventoy.

Sceanrio

1. SG2D ISO file launch
   Since 2019, WoofCE PUPs ISO files have been able to boot being launched from SG2D, with few issues. Recently all few issues seem to have vanished as PUPs progressed.

2. I've reported on several issues that are observed when the PUP is launched from Ventoy.

   • 1st was an inaccurate report of missing filesystem (exFAT). This exposure disappeared when booted USB was removed and re-inserted.

   • Then a report of a "lodged' partition upon desktop arrival not allowing system access where CLI commands thought to allow disconnect and re-connection of devices would solve the need for physically removing the USB.

   • This, externally, seemed to remove the USB and to reinsert it, BUT the locked USB problem persisted; again until physical removal of the USB and re-inserting it .

All of this was observed in desktop operations giving the allusion it was something in the PUP distro at fault.

In testing, NONE of this problem has ever existed when booting from SG2D/ISObooter.

Even as some might view the problem is minor, it is still a problem that I feel is a Ventoy problem causing the PUP's behavior, IMHO. I am not a developer, so cannot say for sure, but my current view suggest this. A PUP developer may know something different.

The pinpointing element of this locked partition is exposed by lsblk command:

• When booting from SG2D, the boot partition is not locked and no issues exist in accessing (mounting) the USB's partitions. lsblk command shows this.

• When booting from Ventoy, lsblk shows this lock.

Another interesting element to this puzzle is:
I have an SG2D ISO file on the BOOTISOS partition
When booting Ventoy and using it to launch SG2D ... then allowing SG2D to boot this distro, there is NO problem at all. The lsblk command show no such lock condition. And here's where my understanding of this problem is muddled and is leaning toward something of what the PUP is doing that could lead to this problem.

I am clueless fumbling around in the dark for something better to present to developers.

Aside from this issue
The PUP's desktop operations ALL perform as expected excepting for a shutdown-reboot issue: On pristine use, the SAVEFILE content's instructions are NOT respected when launched from Ventoy.

In the meantime
Until this matter is resolved, I advise all Ventoy users booting this distro to either

• launch SG2D ISO file from the Ventoy Menu

• Select the BKW64 from the SG2D list and all will boot with no stanza interactions needed

OR

1. Launch the BKW64 ISO file from the Ventoy Menu

2. Edit BKW64'S menu stanza you want to boot

3. Add Puppy's "psave=..." option (my sample example is psave=Persistence:/Sessions/)

4. Allow BKW64 to boot with this change. It will NOT ONLY find any existing prior session if any exist and shutdown-reboot processing will behave as expected.

Lastly, TO BE VERY CLEAR: "This report on ISO booting IS NOT A REQUEST FOR SUPPORTING ANY PRODUCT OUTSIDE OF THIS FORUM!!!" The reports are observations of what is exposed when forum distro ISO files are launched. This applies no matter if booted via QEMU, GRUB2, SG2D, ISObooter, Ventoy or other tests. We are not trying to fix anyone else's products outside of this forum. That is their responsibility...not ours, here. PLEASE, Please, please understand this

[radky]

For switching to/from ConnMan and legacy Connect Wizard utilities, BW64 also provides Menu -> Setup -> Internet Connection Switcher, which automatically adjusts the requisite exe and rc files.

Could this be implemented in a way that does not require a reboot? I'm using PUPMODE 5.

@MochiMoppel

Switching to/from ConnMann and legacy network tools entails stopping/killing/starting network services and related background processes, as well as unmounting and mounting network shares. For example, see /etc/init.d/connman for requisite steps to properly initialize ConnMan. Managing all of this on-the-fly and fully switching all network files and background processes may be possible but rebooting allows Puppy shutdown and startup scripts to cleanly manage the switch with no remnant of the prior connection manager.

If I understand correctly, @rerwin may have plans to integrate ConnMann management in Network Wizard. I don't know if this will include on-the-fly switching.

[radky]

Update report of ISO file booting

There is a problem that I will report to Ventoy...

@Clarity

I appreciate your interest in Ventoy as a third-party application for Puppy Linux. However, I do not use Ventoy to multi-boot ISO files and have no interest in researching the issue further since my limited time for Puppy is now devoted to refining basic functionality of BW64. If you or other proponents of Ventoy have sufficient time to investigate the issue and provide viable solutions, that would be great.

[fredx181]

Lastly, TO BE VERY CLEAR: "This report on ISO booting IS NOT A REQUEST FOR SUPPORTING ANY PRODUCT OUTSIDE OF THIS FORUM!!!" The reports are observations of what is exposed when forum distro ISO files are launched. This applies no matter if booted via QEMU, GRUB2, SG2D, ISObooter, Ventoy or other tests. We are not trying to fix anyone else's products outside of this forum. That is their responsibility...not ours, here. PLEASE, Please, please understand this

Instead of this (sort of) disclaimer you post almost every time, it might be better to make your own thread about Ventoy, ISO booting etc... (and about which Puppy systems nowadays work with it or not)
Developers are busy with solutions to possibly fix problems OR/AND add improvements on the system itself, I guess that has priority, so your posts are often off-topic IMHO (despite the "disclaimers" ).

[Clarity]

... it might be better to make ... thread about Ventoy, ISOboot etc... (and about which Puppy systems nowadays work with it or not)...

Good idea as this could serve the purpose for users to know what works, and developers could know if something built into their solution are invalidating the distro's ability to boot its ISO directly to desktop.

Over the years there have been many-many posts by users discovering boot issues. A Forum thread dedicated to boot issues would centralize many user reports and developer/support guidance. In essence, everyone would benefit in the existence of such a location.

Thanks, I will take this request idea via PM to this Forum's Organizers for such a location and placement.

[Clarity]

BTW: 'Preliminary" from Ventoy says there is a bug within the PUP distro. They will review their end further.

[TerryH]

To install KDE:

Code: Select all

apt update
apt install plasma-workspace
echo false > /etc/desktop_app
echo startplasma-x11 > /etc/windowmanager

Seeing thiss post on installing alternate WM's / Desktops, I decided to have a look at Puppy with KDE Plasma desktop. I did a new frugal install on my internal Nvme drive.

After doing the above, I just did a restart X, rather than a reboot, which may have been better. When X restarted I got the KDE Spalsh screen, but still appeared as JWM desktop. I looked in /usr/share/applications which contained the kde apps, but they wouldn't run when clicked. I got a message that systemsettings was missing, so I launched synaptic and found and installed systemsettings. The kde config apps now ran.

For a few restarts of X after the KDE splash screen I still only saw the JWM desktop instead of Plasma. Some how I eventually ended up with it launching the Plasma desktop as shown in the screenshot below. I added the Latte dock.

There are still things that would need fixing to use regularly, but mainly functional on a modern laptop with plenty of RAM. For some reason the window buttons are missing, so applications are functional, but some windows have to be closed using lxtask or from a terminal to kill them.

[dimkr]

the distro's ability to boot its ISO directly

Support for booting directly from ISOs was implemented in woof-CE several years ago and untouched since then. Any Puppy built with woof-CE as-is or without init script changes should support this to the same degree as any other Puppy built like this, so there's no point in testing this for every Puppy and every version of each Puppy, especially when you have a changelog that doesn't mention anything remotely related. And nobody seems interested in working on this niche use case according to woof-CE's changelog and issue tracker.

[Clarity]

@dimkr AGREED!

But, recent issue has surfaced where @gyrog's SAVESPEC is not respected when ISO launched from Ventoy. Ventoy itself may be locking the boot partition. but this locking is NOT occurring in either FATDOGs/KL's. I do recognize these are families that do things differently in processing to desktop and beyond. Thus I am not comparing, rather reporting.

This locking of the boot partition and lack of apparent use of SAVESPEC does NOT occur when WoofCE PUPs ISO file launched from SG2D/ISObooter/QEMU as they ALL behave from INIT to SHUTDOWN as expected over the years. Thusly, the boot partition is not locked. Boot processing and session processing works with @gytog's SAVESPEC as intended. That fact includes this distro.

SAVESPEC for WoofCE PUPs since inception is a game changer as no user intervention of boot stanzas are necessary when booting directly from ISOs. Merely choose the boot desire from PUPs menu or allow default to occur and a desktop will emerge with sessions processing to occur as expected...without fail. A WoofCE exclusive and enormous benefit assuring any user will see a desktop, if present, with NO stanza changes while sessions will be saved without issues.

That is the issue I am reporting on.

Again, I agree with your comment "to-the-letter".

[Sofiya]

To install KDE:

Code: Select all

apt update
apt install plasma-workspace
echo false > /etc/desktop_app
echo startplasma-x11 > /etc/windowmanager

There are still things that would need fixing to use regularly, but mainly functional on a modern laptop with plenty of RAM. For some reason the window buttons are missing, so applications are functional, but some windows have to be closed using lxtask or from a terminal to kill them.

most likely you do not have a window manager installed " kwin "

sudo apt install kwin-x11

Code: Select all

echo startplasma-x11 > /etc/windowmanager
echo kwin > /etc/desktop_app   
restartwm

[r96chase]

Just a quick question: can I update my current install with apt upgrade or do I have to...y'know...download the iso and use FrugalPup to install anything new?

[TerryH]

To install KDE:

Code: Select all

apt update
apt install plasma-workspace
echo false > /etc/desktop_app
echo startplasma-x11 > /etc/windowmanager

There are still things that would need fixing to use regularly, but mainly functional on a modern laptop with plenty of RAM. For some reason the window buttons are missing, so applications are functional, but some windows have to be closed using lxtask or from a terminal to kill them.

most likely you do not have a window manager installed " kwin "

sudo apt install kwin-x11

Code: Select all

echo startplasma-x11 > /etc/windowmanager
echo kwin > /etc/desktop_app   
restartwm

Thanks Sofiya, I thought the answer would probably be something simple.

Edit: That fixed the missing window buttons. Thanks again.

[Feek]

Just a quick question: can I update my current install with apt upgrade or do I have to...y'know...download the iso and use FrugalPup to install anything new?

With apt update && apt upgrade you will only update the packages you installed with apt. Nothing more.

Updating the instalation itself is done by replacing the installation files in your instalation folder from the latest .iso.
I do it manually (just copying from the mounted .iso).

[dimkr]

But, recent issue has surfaced where @gyrog's SAVESPEC

Same thing here. He introduced this in 2020 and it's mostly untouched since then.

If you don't believe me, look at https://github.com/puppylinux-woof-CE/w ... itrd-progs. Most changes after 2021 have nothing to do with Ventoy, SG2D, SAVESPEC or whatever. When you test the same thing in different Puppy versions that use the same init script but get different results, this makes me question the testing methodology or the testing environment more than anything else, because it's the same code and this code doesn't change much and definitely not in a way relevant to the thing you're testing. And, according to the changelog, nobody seems to be interested in fixing the so-called problems with boot from ISOs, for at least 3 years. I really don't know what else to say to stop you from posting about the same topic in various threads.

[stevie pup]

Over the years there have been many-many posts by users discovering boot issues. A Forum thread dedicated to boot issues would centralize many user reports and developer/support guidance. In essence, everyone would benefit in the existence of such a location.

I agree entirely. There have been far more threads regarding boot issues and USB's than I can possibly keep track of. There is a section on Boot in the "Instructional How-To Section", but an awful lot of threads about booting and creating USB's are scattered about all over the place.I have started one or two myself, and attempted to make some useful contribution to others. About a year ago I started a thread with my own observations of Rufus, and which Puppies booted ok with it and which didn't.

Problem is of course other users wouldn't necessarily get the same results as I did, depending on what computer they were plugging the USB stick into, what brand of USB stick it was, etc, etc. Also, it's not just Puppies. I believe some people were having issues getting the latest version of MX to boot from Ventoy, although I think that's been fixed now.

[Marv]

Jumped through the second hoop to a fully usable (for me) BW64 on my Fujitsu S761 laptop. The first was LXDE. Thanks @peebee for that SFS. The second was getting lidsuspend working correctly so the wifi would be connected on resume and my preexisting work would be shown (no restartwm needed).

To do that, I modified /etc/acpi/actions/suspend.sh as follows:

To # process before suspend, Add [ "`pidof -s connmand`" ] && CONNMANRUN="true" && /etc/init.d/connman stop

To # process at recovery from suspend, I added [ CONNMANRUN != 'true' ] && /etc/init.d/connman restart
and psynclient_loadsettings. That is a workaround that calls an executable script in /root/my-applications/bin that just runs
psynclient -l to re-initialize the touchpad (psynclient -l would not run called directly from suspend.sh).

Not my first rodeo with lidsuspend. Hardware, kernel, and OS have to mesh just so and over time all three slither about

Happily using BW64 as my daily now. In it now, Posting from the Brave portable. Oh, and made my peace with the resident Claws Mail as a replacement for Sylpheed. It's working well and really quite configurable once I got used to it.

Thanks to all

[Null_ID]

I'm having an issue with Discord that might be related to this latest Bookworm 10.0.3-release specifically. It would seem that https://click.discord.com refuses my attempted connections that are coming from Bookworm Pup64 10.0.3. What happens is this:

1. I updated to Bookworm 10.0.3
2. Ran apt-get update, then installed latest Discord client from their official .deb available from their website.
3. Discord client started from terminal with discord --no-sandbox. Starts up and fetches updates as usual.
4. Client asks me to present my credentials, as usual. Once entered, it asks me to click the verification link sent to my Protonmail e-mail box. I do this like a good boy.
5. In Bookworm Pup64 10.0.3 https://click.discord.com simply refuses to open. I'm presented with a window saying that https://click.discord.com cannot be reached/unable to connect there and maybe try later, or possibly the server is unavailable right now. This is the gist of it, no triple digit error codes are presented. My choice of a web browser does not matter, Pale Moon, Librewolf, all exhibit the same behavior.
6. In order to troubleshoot this issue, I revert back to an earlier Pup, F96-CE_4, which immediately, unconditionally and without issues allows me to connect to https://click.discord.com upon clicking the e-mail verification link sent to my Protonmail box.
7. In both cases, with both Bookworm Pup64 10.0.3 and F96-CE_4, I ran a clean, pristine system from RAM with no prior pupsaves/persistence loaded/restored whatsoever.

So in a nutshell, https://click.discord.com allows connections from F96-CE_4, but refuses them from Bookworm Pup64 10.0.3. Earlier 10.0.2-version of Bookworm also didn't seem to exhibit this behavior. For Bookworm Pup64 10.0.3 Discord client's official .deb-package was used. For F96-CE_4 Discord client's official .tar.gz-package was used.

Requesting assistance.

EDIT: !Problem solved! You must edit /etc/hosts to remove all restrictions for Discord URLs.

[Marv]

Is there a link to the 10.0.2 iso anywhere? I was pondering why my suspend/resume required so much help in 10.0.3 when I vaguely remembered it working ok at some point earlier in BookWorm64. My 10.0.2 iso is lost but I reverted the install to 10.0 and the stock suspend works perfectly (kernel independence tested). No connman restart OR psmouse removal and reinstall, then psynclient -l required. I'd like to test it in 10.0.2.

Thanks,

[radky]

@Null_ID wrote:
It would seem that https://click.discord.com refuses my attempted connections that are coming from Bookworm Pup64 10.0.3.

@Null_ID

By default, BW64 utilizes a fully populated /etc/hosts file to block various advertising servers and tracking domains.

If I understand correctly, https://click.discord.com is a link which redirects to a tracking domain that is blacklisted and effectively blocked by BW64's /etc/hosts file. Multiple related discord URLs are also blocked.

To start or stop blocking of advertising servers and tracking domains, please go to:

Menu -> Internet -> Pup-Advert-Blocker

If this does not help, maybe other forum members will offer a better solution.

[radky]

Is there a link to the 10.0.2 iso anywhere?

@Marv

https://rockedge.org/kernels/data/ISO/B ... 10.0.2.iso

[Null_ID]

@Null_ID wrote:
It would seem that https://click.discord.com refuses my attempted connections that are coming from Bookworm Pup64 10.0.3.

@Null_ID

By default, BW64 utilizes a fully populated /etc/hosts file to block various advertising servers and tracking domains.

If I understand correctly, https://click.discord.com is a link which redirects to a tracking domain that is blacklisted and effectively blocked by BW64's /etc/hosts file. Multiple related discord URLs are also blocked.

To start or stop blocking of advertising servers and tracking domains, please go to:

Menu -> Internet -> Pup-Advert-Blocker

If this does not help, maybe other forum members will offer a better solution.

Thanks for the tip. I'll try this tomorrow, when I have more time. Will check back with results.

[Marv]

@radky, Thanks for the link to the 10.0.2 iso. I did run a quick test and whatever changes made the stock suspend/resume stop working occurred between 10.0 and 10.02. Both 10.0.2 and 10.0.3 require the connman stop/restart and the psmouse remove/reinstall and psynclient run in the suspend.sh script to work for me. 10.0 does not, suspend/resume works perfectly there OOTB. I used the same usrmerge kernel in all tests and checked both a pristine JWM install and my ydrv LXDE install. I'll ponder the changelogs but use 10.0 for now. The patches in suspend make resume pretty laggy as well as being puzzling. My WAG is that it is the Debian security updates.

Update: An interesting tidbit: In 10.0.3 (stock kernel) synclient "VertEdgeScroll"=1 or synclient "VertEdgeScroll"=0 will not run when called from a script (suspend.sh). In 10.0 (either 10.0 or 10.0.3 kernel) synclient will run and set properties correctly when called in exactly the same way.

[bigpup]

I used the same usrmerge kernel in all tests

Is this saying you are using a different kernel, than the one that comes in Bookworm Pup64 10.0.3?
If yes.
How is this testing Bookworm Pup64 10.0.3 as it was released.

How do we know the kernel you are using does not have a kernel config issue?

[Marv]

I used the same usrmerge kernel in all tests

Is this saying you are using a different kernel, than the one that comes in Bookworm Pup64 10.0.3?
If yes.
How is this testing Bookworm Pup64 10.0.3 as it was released.

How do we know the kernel you are using does not have a kernel config issue?

The first kernel used in all three was the stock 10.0.3 kernel. Then the test was run with the stock kernels for each (10.0, 10.2, 10.3). Then it was repeated with the usrmerge 6.4.0 kernel I use in jammypup64. The same results throughout. I am well aware of kernel config issues and it is one of the first things I try to rule out. Prior to this reversion test, 10.0.3 had already been thoroughly flogged for this issue, both pristine and LXDE'd and with 2 or 3 alternate kernels.

Posting from 10.0 with the 10.0.3 kernel. No suspend issues whatsoever, running it as my daily. Interestingly, it also will set touchpad parameters using synclient called from suspend.sh. 10.0.2 and 10.0.3 (stock kernels) will not.

OK??

[Null_ID]

@Null_ID wrote:
It would seem that https://click.discord.com refuses my attempted connections that are coming from Bookworm Pup64 10.0.3.

@Null_ID

By default, BW64 utilizes a fully populated /etc/hosts file to block various advertising servers and tracking domains.

If I understand correctly, https://click.discord.com is a link which redirects to a tracking domain that is blacklisted and effectively blocked by BW64's /etc/hosts file. Multiple related discord URLs are also blocked.

To start or stop blocking of advertising servers and tracking domains, please go to:

Menu -> Internet -> Pup-Advert-Blocker

If this does not help, maybe other forum members will offer a better solution.

Update regarding yesterday's Discord issue: Problem solved. https://click.discord.com was indeed blocked in the /etc/hosts file for this release of Bookworm. I updated the hosts-file with my own settings and the issue has been sorted out. Thanks for tipping me that there's now a comprehensive blocklist included in Bookworm, as I had no idea you've started doing that.

[radky]

Update regarding yesterday's Discord issue: Problem solved. https://click.discord.com was indeed blocked in the /etc/hosts file for this release of Bookworm. I updated the hosts-file with my own settings and the issue has been sorted out. Thanks for tipping me that there's now a comprehensive blocklist included in Bookworm, as I had no idea you've started doing that.

@Null_ID

Thanks for confirming Discord in now working for you.

Early releases of BW64 prior to 10.0.3 also utilized a comprehensive /etc/hosts file to block advertising servers and tracking domains.

However, click.discord.com is a recent addition to the default blacklist provided by Pup-Advert-Blocker. Consequently, https://click.discord.com was not blocked in early releases of BW64, but that IP address is now blocked by default in the recently updated /etc/hosts file.

As noted above, users can easily disable IP blocking by going to Menu -> Internet -> Pup-Advert-blocker.