QuickPup64 25.01 RC6

[Clarity]

Restarted the testing. This time, I booted the ISO file via Ventoy taking the Wayland option changing pfix=ram,fsck while adding the PSAVE parm as before. My intent is to boot to create a Wayland session completely separate from the prior X11 session tests for your 2025 version. Upon desktop, same steps as before starting with Update Manager updating packages.

After update, I tried to install btop and tldr via the package manager; but not available.

I opened QuickSetup to tailor use:

1. New, Keyboard layout is grayed-out

2. I get a Puppy Input Wizard notification message "This settings is of X11 session only" when completing QuickSetup

3. And the time setting problems persist

Screenshot_2025-02-24_12-46-16.jpg (52.94 KiB) Viewed 3686 times

[Clarity]

As reported earlier,

1. SFS files were copied onto my Persistence partition even though I chose the "NO" options at shutdown.

2. The actual 'save' was placed correctly within the Sessions folder

3. On this Wayland session, it has done the same thing, again.

Am I misunderstanding that screen's request OR Is this a bug?

[mistfire]

Restarted the testing. This time, I booted the ISO file via Ventoy taking the Wayland option changing pfix=ram,fsck while adding the PSAVE parm as before. My intent is to boot to create a Wayland session completely separate from the prior X11 session tests for your 2025 version. Upon desktop, same steps as before starting with Update Manager updating packages.

After update, I tried to install btop and tldr via the package manager; but not available.

I opened QuickSetup to tailor use:

1. New, Keyboard layout is grayed-out

2. I get a Puppy Input Wizard notification message "This settings is of X11 session only" when completing QuickSetup

3. And the time setting problems persist

Screenshot_2025-02-24_12-46-16.jpg

Keyboard layout on Wayland is actually depends on the wayland compositor. Just go to xfce desktop settings. and select keyboard settings. And it will redirected to labwc settings gui

[mistfire]

QuickPup64 25.01 RC3 released

Changes:
* Fixes on initrd, Improvements for odd numbered pupmodes (still disabled by default, required to enable)
* linux kernel 6.13.5-lxpup64
* Added brlaser and bcachefs-tools
* Disk Image Creator now supports BTRFS and bcachefs

Download: https://1drv.ms/u/c/349c4d7a5f9d78cd/EQ ... g?e=3zAnfF
MD5 Checksum: ead40d46ddd085318d79837ec4308c51

[Clarity]

Hello @mistfire

Testing launching vRC3 via Ventoy. These can be verified with your own USB that you've tested from before.

Few issues
Selecting GRUB2 option from Ventoy when launching the ISO, there are several error messages, too fast to capture, that flash quickly before the QP64 boot-menu is displayed. To test, at the QP64 boot-menu each case of booting with and without PSAVE is shown below.

1. Attempts with PSAVE parm

   • When 1st stanza is selected and the PSAVE= parm is added for Persistence, the boot will display the Puppy grub image, but will not progress the boot to a prompt or to a desktop. It just hangs at the image.

   • The same thing occurs when attempting to boot using the Wayland stanza with a PSAVE parm.

2. Attempts without the PSAVE parm - A different behavior

   • Allowing the boot-menu to timeout at the default stanza the boot starts. After a 60sec wait, the boot will progress and stop with the following information locked on-screen

     Code: Select all

     QuickPup64
     Linux 6.13.5-1xpup64 [x86_64 arch]
     puppypc22926 login: root (automatic login)
     
     Welcome to Puppy Linux!
     /usr/lib/puppy/bin/start-display-server: line 50: /usr/sbin/pm13: No such file or directory 
     [puppy::root]# ModemManager [10009]: <msg> ModemManager (version 1.22.0) starting in system bus...
     
     acpid: starting up with netlink and the input layer
     acpid: 1 rule loaded
     acpid: waiting for events: event logging is off
     crond[10167]: /usr/sbin/crond 4.5 dillon's cron daemon, started with loglevel notice
     
     haveged: haveged starting up
     haveged: haveged: ver: 1.9.19; arch: x86; vend: GenuineIntel; build: (gcc 14.2.0 ITV); collect: 128K
     
     haveged: haveged: cpu: (L4 VC); data: 32K (L2 L4 V); inst: 32K (L2 L4 V); idx: 24/40; sz: 32156/54021
     
     haveged: haveged: tot tests(BAB): A:1/1 B:1/1 continuous tests(B): last entropy estimate 7.99764
     
     haveged: haveged: fills: 0, generated: 0
     
     ModemManager [10009]: <msg> [base-manager] couldn't check support for device'/sys/devices/pci0000:00/00000:00:1c.5/0000:06:00.0': not supported by any plugin
     

     There is nothing more...no prompt...nothing to indicate some user actions is needed. Using Cntrl-Alt-Delete starts a Shutdown asking if I want to save???

   • Taking the Wayland stanza the same behavior occurs. This time at the last message I waited, then hit the Enter-key. I got a prompt. At the prompt, I entered "xwin" and the desktop started. But as is the case for all WoofCEs launched from ventoy, session saving is impossible without a beginning PSAVE parm.

[Clarity]

Booting from SG2D not changing any boot stanza allowing the boot-menu to default on its topmost stanza. It boots to its desktop.

[Clarity]

ALL tests launches from both Ventoy AND from SG2D are on bare-metal. Prior post report is from Ventoy while this post is SG2D results.

SG2D - Upon session end, cannot save. SAVESPEC is not honored by distro.

Shutdown report.jpg (44.2 KiB) Viewed 3280 times

Code: Select all

[    0.000000] Linux version 6.13.5-lxpup64 (root@puppypc28762) (gcc-14.2.0 (GCC) 14.2.0, GNU ld version 2.42-slack151) #1 SMP PREEMPT_DYNAMIC Thu Feb 27 15:25:09 GMT 2025
[    0.000000] Command line: BOOT_IMAGE=/vmlinuz pfix=fsck pmedia=cd find_iso=/BOOTISOS/quickpup64_25.01-rc3.iso rdinit=/vtoy/vtoy
[    0.000000] KERNEL supported cpus:
[    0.000000]   Intel GenuineIntel
[    0.000000]   AMD AuthenticAMD
[    0.000000]   Centaur CentaurHauls
[    0.000000] BIOS-provided physical RAM map:

[Clarity]

Summary: ISO file booting on bare-metal does not follow save-session expectations once on the desktop.

[mistfire]

QuickPup64 25.01 RC4 released

Changes:
* package management is now fully aligned to the slackware current upstream repo. Slackel repo will now handle the package dependency instead
* Improved PPM and PKG2. Now supports slackware deps files (located /var/packages/repo/slack-deps) and automatically updates the package repo when needed.
* linux kernel 6.13.7-lxpup64
* updated linux firmware drivers
* reco replaced audio-recorder as sound recording app
* more bugfixes

Download: https://1drv.ms/u/c/349c4d7a5f9d78cd/EX ... A?e=wG4n7H
MD5 Checksum: b44eadea85b11f80a9d9e511b505f97e

[Clarity]

Launched to desktop on bare-metal via Ventoy and also SG2D without issues. This was done taking the default QP64 boot-menu stanza. Using that stanza, SG2D using SAVESPEC locates all prior QP64 sessions offering the option to select or 'none' to boot. I chose none for a pristine boot of this version RC4.

Problems, thus far

• My arrow keys and other keys between the keyboard letters and numbers-keys are NOT behaving as they normally would. Not sure how to resolve. I did review the
  desktop menu>Desktop>Keyboard Shortcuts, but nothing stands out on how to activate normal operations of those keys. The keyboard is set in FirstRun as US English.

• USing Firstrun, I choose the UTC clock option, but it is NOT respected. When Firstrun is reopened, the UTC option is unchecked.

• My PrtScrn key does not work. This may be related to the other keyboard behavior reported.

• On pristine use, opening the Drawing graphic utility offers a guide, but when checked, no manual/user-guide is presented.

Next will be tests booting QP64 using its Wayland boot menu stanza. Wayland was not present in this report's findings.

[Clarity]

Wayland Tests

On a pristine boot on bare-metal, I have a problem getting to desktop. The boot hangs before I gain control of desktop and startx as shown below:

Code: Select all

QuickPup64
Linux 6.13.7-1xpup64 [x86_64 arch]
puppурс17895 login: root (automatic login)
Welcome to Puppy Linux!
/usr/lib/puppy/bin/start-display-server: line 50: /usr/sbin/pm13: No such file or directory
[puppy: :root]# ModemManager [10581]: <msg> ModemManager (version 1.22.0) starting in system bus...

acpid: starting up with netlink and the input layer
acpid: 1 rule loaded
acpid: waiting for events: event logging is off
crond[10728]: /usr/sbin/crond 4.5 dillon's cron daemon, started with loglevel notice

haveged: haveged starting up
haveged: haveged: ver: 1.9.19; arch: x86; vend: GenuineIntel; build: (gcc 14.2.0 ITU); collect: 128K
haveged: haveged: cpu: (L4 UC); data: 32K (L2 L4 V); inst: 32K (L2 L4 V); idx: 24/40; sz: 32156/54021
haveged: haveged: tot tests (BAB): A:1/1 B:1/1 continuous tests(B): last entropy estimate 7.99838
haveged: haveged: fills: 0, generated: 0
ModemManager [10581]: <msg> [base-manager] couldn't check support for device '/sys/devices/pci0000:00/0000:00:1c.5/0000:06.00.0': not supported by any plugin
^C
[puppy:root]# echo "Interrupted after waiting 5 minutes for ModemManger result/completion that never happened"
Interrupted after waiting 5 minutes for ModemManger result/completion that never happened
[puppy:root]# startx  # required to get a desktop

.
Question
What would you have done, at this point, for this attempted boot of the Wayland boot-menu option?

Screenshot.jpg (68.23 KiB) Viewed 2303 times

[Clarity]

Wayland Tests

@mistfire as you have noticed from the above issue I report, I rebooted in SG2D taking the Wayland option. It is KNOWN that if a SAVESPEC is present the booting WoofCE will respect its contents for session inclusion as well as to know where to find-save the session.

Selecting the Wayland boot option the boot fails allowing a debugsave to create useful information to the developer. Here it is ...

pupdebug-0324250135.tar.gz

DebugSave from boot-time failure when Wayland selected

(91.85 KiB) Downloaded 3 times

[Clarity]

Advise on these vRC4 issues, above post and below in this post.

Screenshot_admin apps needed.jpg (91.06 KiB) Viewed 2287 times

Screenshot_admin app needed2.jpg (35.25 KiB) Viewed 2287 times

[mistfire]

Wayland Tests

@mistfire as you have noticed from the above issue I report, I rebooted in SG2D taking the Wayland option. It is KNOWN that if a SAVESPEC is present the booting WoofCE will respect its contents for session inclusion as well as to know where to find-save the session.

Selecting the Wayland boot option the boot fails allowing a debugsave to create useful information to the developer. Here it is ...pupdebug-0324250135.tar.gz

I noticed to the debug file that there is /dev/sr0 detected by probepart. Did you try to use find_iso boot parameter to locate the iso file?

[Clarity]

Did you see the kernel in the "Command line" of the log files; BOOT_IMAGE=/vmlinux pfix=fsck ... find_iso=/BOOTISOS/quickpup64_25.01-rc4.iso ...

Or is it missing in the logs I sent?

Can I send you a 2GB USB "IMG" file that you can use for your tests where you can mimic the problems which surface in booting. Its merely Ventoy USB with an SG2D ISO and a QP64 ISO. Its a replica of what I use it to test booting everything for last 6 years. I launch directly from Ventoy or I boot SG2D and launch from there ... same USB for all ISO file boot testing and reporting. This would give you ability to see what I see in booting tests, from time to time. If this would be helpful, PM me.

[mistfire]

Can I send you a 2GB USB "IMG" file that you can use for your tests where you can mimic the problems which surface in booting. Its merely Ventoy USB with an SG2D ISO and a QP64 ISO. Its a replica of what I use it to test booting everything for last 6 years. I launch directly from Ventoy or I boot SG2D and launch from there ... same USB for all ISO file boot testing and reporting. This would give you ability to see what I see in booting tests, from time to time. If this would be helpful, PM me.

sure why not?

[Clarity]

Check your PM.

@mistfire, completed.

[Clarity]

On booting the vRC4 ISO file via SG2D, it finds and lists the Session files on the attached partitions. BUT ...

1. The PC has 2 SCSI drives. One is exclusively Windows and Linux Swap, while the other is used for Linux.

2. Recently, the 80GB SCSI approaches full. This drive contains the Persistence partition.

3. I renamed this partition Persist from its original Persistence label.

4. I installed a SATA HDD drive attached to the motherboard, created a partition and named it "Persistence" adding a

5. Sessions folder to become a mirror of the SCSI's "Persist".

6. I copied ALL of the sessions and its SAVESPEC file from the Persist partition to the new Persistence partition.

7. No other changes are done to the PC

8. Each of the partitions are formatted EXT4

9. Upon completion of the Persistence updates, I booted the PC.

What happens next...
Booting SG2D, I launched QP64 vRC4 allowing the 'default' stanza in its boot-menu. To my surprise the boot-process pause to ask me which of the session files for prior QP64 uses I preferred...or None. (there are 6 priors from 2024 on this PC)
"Surprise?" you may ask: YES because it is listing prior sessions for QP64 from BOTH the old Persist partition AND the new Persistence partition.

I believe (aka KNOW from prior WoofCE distros over the years) that the system, at boot time, it to use the directions contained within SAVESPEC when present, so I enclosed it here for your review:

Code: Select all

# Partition where Sessions to go
SS_ID='Persistence'
# Folder where Sessions to go
SS_DIR='/Sessions'
# Media where Sessions to go
SS_MEDIA='atahd'

I am reluctant to call this a bug because, I am unsure if there is any documentation that exist indicating that the system has no ability to determine the difference between disks labeled Persist versus Persistence?
AND, I am unsure if there is boot system intelligence to have multiple 'session' locations to be used or specified?

I know @gyrog is the architect and I know you and he are on WoofCE Github so I am asking either to comment by correcting my understanding of SAVESPEC operations as it pertains to this phenomenon.

Thoughts?

[mistfire]

QuickPup64 25.01 RC5 released

Changes:
* linux kernel 6.14-lxpup64 (with ntsync added)
* added dkms, swaybg, wl-randr, and gst-plugins-ugly
* added workarounds for XFCE wayland session
* fixed system clock type settings on puppy quick setup
* removed duplicate package entries and obsolete packages
* more updated non-slackware packages

Download: https://1drv.ms/u/c/349c4d7a5f9d78cd/ER ... g?e=8lgY7t
MD5 Checksum: c00af89f230c50dfbd6a28160bd47990

[Clarity]

Success in booting to Wayland desktop ONLY via QEMU booting the ISO file directly

Code: Select all

# qemu-system-x86_64 -name "SG2D ISO from Ventoy USB" -enable-kvm -vga cirrus -m 2G -smp 2 -device AC97 -net nic -net user -rtc base=localtime -cdrom /mnt/sdb1/BOOTISOS/quickpup64_25.01-rc5.iso 
# 

This required a change from -vga std to -vga cirrus to get to the desktop. Test results reported on the forum, here

Ventoy to SG2D.jpg (36.59 KiB) Viewed 1735 times

[Clarity]

Booting the USB for Wayland desktop via QEMU is as follows. Ventoy was used to launch the ISO file.

Code: Select all

# qemu-system-x86_64 -name "SG2D ISO from Ventoy USB" -enable-kvm -vga cirrus -m 2G -smp 2 -device AC97 -net nic -net user -rtc base=localtime /dev/USB

Ventoy to SG2D(12).jpg (56.04 KiB) Viewed 1734 times

.
"USB for Wayland" means that when the ISO file is launched to its boot menu, the "Wayland" option in the boot menu is selected with NO changes.

[Clarity]

<SOLVED> ... see next post
Booting the USB for Wayland desktop via QEMU is as follows. SG2D was used to launch the ISO file. (same QEMU stanza as above)

Ventoy to SG2D(13).jpg (36 KiB) Viewed 1729 times

[Clarity]

The above problem shown in the above post occurs when the boot menu stanza for Wayland is NOT changed. This means to select the Wayland stanza and merely hit the enter-key will lead to the failure shown, above.

BUT, if the Wayland stanza is edited at boot-time to add this parm: find_iso=${iso_path} the PC will not fail.

The parm affords the distro to boot with the same behavior and user requirement to get to desktop, as shown here.

@mistfire will you consider updating your OP to show this parm versus what you have? This is a more accurate depiction for the distro's ability to find the ISO file and its "puppy_quickpup64_25.01.sfs"

In other words this parm I show, "unchanged", exactly as is will allow the QP64's boot subsystem to locate the ISO file and boot the PC. Thus no user research is required. Just enter the parm as shown and the boot subsystem will handle the needs with this complete parm.

Hope this helps.

P.S. Test Results for booting QP64 ISO is shown in the table here.

[mistfire]

QuickPup64 25.01 RC6 released

Changes:
* Fixed broken applications (gnome-search-tool and gnome-font-viewer)

Download: https://1drv.ms/u/c/349c4d7a5f9d78cd/Ec ... w?e=wXA4Rz
MD5 Checksum: 4f76651e01f0076116c22f9398cb5d26

[Clarity]

Hello @mistfire
I dont have a BTRFS partition as of yet. But thought to ask: Does the distro allow saving/use to a session-folder versus a file?

Curious before attempts. Also see my post on the Manjaro thread.

[mistfire]

Does the distro allow saving/use to a session-folder versus a file?

Yes it is as long as the target partition is a linux filesystem (such as ext2/3/4, btrfs, bcachefs)

[Clarity]

Booted this distro's ISO file via SG2D on bare metal. The default stanza was taken; no changes as there is a SAVESPEC for save-session management. Thus, this is the X11 path taken.

The distro, stops as expected, showing all prior sessions in the "Sessions" folder. I selected None and distro proceeded to a pristine desktop.

Quicksetup was run making appropriate desktop changes. It was rerun, and the changes selected were maintained. Glad that prior bug is gone. Clock and hostname is maintained, as it should.

Updates and PETs I have work as expected.

BUG

• This PUP is NOT using/respecting SAVESPEC. Instead it is OOTB trying to save to the root of the Persistence drive???

  • I needed to 'force' the path to guide saving the session.

  I think this bug is due to a mis-understanding and "MAY" need a review by @gyrog the creator or a correction in understanding. Namely, the WoofCE distro is using SAVESPEC on booting as it finds and list the prior sessions that are in the Sessions folder. When "0 None" is chosen to proceed to a pristine desktop, it appears that the directions in SAVESPEC and/or psave parm are discarded.
  .

  IIRC when there are no sessions in the Sessions folder at boot time and the SAVESPEC is present, when saving, the distro knows where to place a new session. That being the case, the same logic should be being employed when it pauses during booting and there are prior session found in the Sessions folder when the user chooses the NONE option to boot.

Next, I will SG2D boot taking the Wayland path.

Question

• When I save this X11 Session, On a REBOOT when choosing the Wayland boot path and this x11 session is offered in the list of prior sessions saved during boot, should a NEW session for this wayland boot be made that is separate from the X11 prior session that was created?

[Clarity]

Wayland options taken when booting from SG2D on bare metal.

AS before, to get the ISO to boot, find_iso parm must be present, otherwise the boot will trap. The behavior, on boot, is the same as reported with my earlier RC5 post; EXCEPT this time, I cannot hit Enter or Cntrl-C to get a prompt to continue to a desktop. Thus, this Wayland boot effort of the ISO file is a failure.

After a 5 minute interval, the PUP clears the screen an stops with the following message (yet still no way to get a console prompt) INIT: iD "1" respawning too fast: disabled for 5 minutes

One interesting observation, when Cntrl-Alt-Del, the expected reboot puts up a save-session window in the console...even though it never made it to DE's desktop.

Advise, please.

Next will test ISO file booting via Ventoy (X11 and Wayland) followed by KVM ISO file booting.

[geo_c]

One interesting observation, when Cntrl-Alt-Del, the expected reboot puts up a save-session window in the console...even though it never made it to DE's desktop.

I ran into that recently booting Studio1337, and yes, you can make a save without booting to desktop. I did it, but I had a console prompt, so I actually installled a package using apt while at the prompt. I also copied files around the filesystem with no desktop. Then I used the poweroff or shutdown command (don't remember which) to shutdown and got the save-session option, which I chose yes, and it successfully saved my changes to a pupsave. The copied files and newly installed application were all there on next boot after I swapped kernels and got a desktop on the second try.

[Clarity]

Update finding booting this RC6.

Pristine QP64 vRC6 Desktop.jpg (234.96 KiB) Viewed 1428 times

@mistfire, you've done something a little different from other WoofCEs I've tested.

Scenario

• Booted Ventoy, launched QP64 vRC6. Did NOT select Ventoy's option for GRUB2. Thus ISO file booted to GRUB4DOS Menu instead of its GRUB2 Menu.

• Changed NOTHING on the ISO boot menu. This allows distro to boot at timeout using its default menu stanza
  Surprise!!! Boot paused showing all prior SAVES in the Sessions folder on the drive indicated in SAVESPEC file.

  • If I did nothing it would boot pristine to desktop without a prior session.

  • If I choose one of the prior sessions, it uses that prior session to boot to desktop.

This is the first time since FossaPup64 that a WoofCE distro has booted with this normal, expected, behavior in booting via Ventoy and finding the session in exactly the same way SG2D behaves.

So, what is occurring is the following

• If Ventoy's "normal" launch of the ISO file is chosen, the distro will boot, use SAVESPEC to find its session folder presenting the session options for user choice. Choosing then proceeds to desktop.

• If Ventoy's GRUB2 launch of the ISO file is chosen, the distro will NOT show contents of the session's folder as it is ignore proceeding to desktop.
  This is a welcomed advancement, not discovered before.

I am not in any position to point to "why" the booting behavior is different from the ISO file using its GRUB4DOS approach versus using its GRUB2 approach. I have not had this booting problem in the non-WoofCE distros on the forum as they behave the same way no matter which boot selection chosen for its Ventoy launch.

I can share that BOTH the default topmost bootmenu stanza is identical no matter if launched from Ventoy USB or SG2D. Each has ONLY a pfix and a pmedia parms for the default stanza used. As is shown in the above desktop capture, the ISO file when booted from "normal" Ventoy launch, adds the find_iso=... parm to the GRUB4DOS stanza during boot.

The same GRUB2 ISO menu stanza does NOT add that to the booting stanza. Instead, the default entry arrives at desktop using this:

GRUB2 QP64 boot.jpg (79.26 KiB) Viewed 1412 times

Again, a developer, like yourself or @gyrog, will need to review why GRUB4DOS boot is finding and listing sessions while GRUB2 v2.04 is not.

P.S. All of this is tested on bare-metal.

• I have seen that you have added QEMU v9.2+ to the selectable PPM solutions.

• And I hope you noticed from the terminal entry in the photo, above, that the PPM installed MtPaint v3.40 is missing a lib dependency.