BookwormPup64 10.0.6

[Marv]

Continuing to use Bookworm Pup64 as my daily. Set up with my customizations on ydrv, no fdrv, no adrv, bdrv as needed, all browsers etc. as portables. Savefile used temporarily as an easy conduit to the ydrv for major changes. Other than the multimedia hiccups reported by peebee, it is running superbly in daily use.

I just got around to checking the printer installs for my Brother HL-2170W laser run using HP PCL4/5 emulation and my old HP4500 all-in-one needing HPLIP. Both ethernet connected with static IPs. Both were detected correctly with the firewall off and the Brother Install was routine. The HP install using @rcrsn51s' hplip_print_scan_bionic_64bit-3.19.8-2.pet, which had worked for me up through another jammypup64, resulted in a 'failed filter', almost certainly due to the newer ghostscrupt in Bookworm. Using HPLIP installed with the APT package manager it worked perfectly. To my surprise, the HPLIP from that install was only 437KB.

While I was at it I checked an install of PCManFM using that package manner and that also went well (My usual is pet installed or resident in a repurposed ydrv).

A suggestion for the next release. The bdrv is really essential to the release as it contains the APT package installer and is only 13MB. Why not just incorporate that in the main SFS?

Again, thanks to @radky and @dimkr for this fine release

[dimkr]

A suggestion for the next release. The bdrv is really essential to the release as it contains the APT package installer and is only 13MB. Why not just incorporate that in the main SFS?

Definitely a good idea, but this is very hard to do without massive changes to woof-CE, especially if we want apt support to be an optional feature that can be disabled at Puppy build-time. For example, @peebee builds his Ubuntu-based Puppy without apt support. (I implemented bdrv->main SFS unification at some point but never merged this change because it was problematic, for various reasons.)

If anyone else volunteers to do this (more elegantly than I did) and wants to open a pull request to https://github.com/puppylinux-woof-CE/woof-CE - go ahead and do that. Puppy is a do-ocracy.

[peebee]

For information: LXDE by ydrv works.............

Screenshot.png (227.75 KiB) Viewed 4436 times

[Marv]

@peebee, Which ydrv did you use? I've run F96-CE and another jammypup64 with your LXDE ydrvs but never succeeded in getting drives-on-desktop to work in LXDE in those. The last success I had with it was in VoidPup64. That's kind of a sticking point for me so I went back to the JWM desktop/PCManFM file manager for those -and for Bookworm. It takes some kind of wonky work-arounds to integrate the trash cans and get shortcuts to start uniformly with PCManFM instead of ROX etc. I am used to those but I don't have any users on those flavors mostly because the Desktop/Pinboard duality and the work-arounds confuse them. Still on the workhorse LxPupSC64 for them.

[peebee]

@peebee, Which ydrv did you use?

Hi - it's a new usrmerge ydrv specifically for BookwormPup64 - not yet uploaded.....

[nilsonmorales]

I can confirm that Fusilli also runs on Bookworm

[radky]

@Clarity

RE: audio distortion in the QEMU environment

If I understand correctly, when released in August. the upcoming QEMU 8.1 will introduce a native Pipewire audio back-end.

If interested, you could test at that time.

Possibly, QEMU 8.1 may address the audio distortion you have experienced in the Pipewire environment of BW64 and Vanilla Dpup.

https://www.phoronix.com/news/QEMU-8.1-Adds-PipeWire

[dimkr]

But this is support for PipeWire on the host, not in the guest inside the VM. It won't change anything.

[Geek3579]

@Clarity

RE: audio distortion in the QEMU environment

If I understand correctly, when released in August. the upcoming QEMU 8.1 will introduce a native Pipewire audio back-end.

If interested, you could test at that time.

Possibly, QEMU 8.1 may address the audio distortion you have experienced in the Pipewire environment of BW64 and Vanilla Dpup.

https://www.phoronix.com/news/QEMU-8.1-Adds-PipeWire

Using QEMU 8.1 may help, thanks. I changed the QEMU load script by using -soundhw hda instead of -soundhw ac97. That helped a lot, but the audio was very choppy. I also tried a USB sound card output but the result was the same, choppy. .

But audio works well in a "normal" frugal install, so it does look like QEMU is the issue.

[radky]

@dimkr

Several QEMU issues are noted below in recent PipeWire commits at github.com.

Are any of the fixes pertinent to PipeWire in Puppy ?

Thanks

---

https://github.com/PipeWire/pipewire/bl ... e0ff2/NEWS

PipeWire 0.3.67 (2023-03-09)
- The ALSA plugin now handles some impossible cases better. This fixes
recording in QEMU again. (#2971)

PipeWire 0.3.61 (2022-11-24)
- Fix sound in QEMU, deadbeef and openal again.

PipeWire 0.3.61 (2022-11-24)
- Force playback start when the ALSA buffer is full. This fixes sound
in QEMU. (#2830)

PipeWire 0.3.42 (2021-12-16)
- Fixes a bug in pulse-server underrun handling that broke qemu and orca.

[dimkr]

@radky I'd stick with Debian's PipeWire. You can introduce more issues, break applications and introduce incompatibility with Debian packages if you force a newer PipeWire version, one that's newer than the one that goes into Debian 12. Maybe you'll fix a bug or two, maybe you'll introduce five more. Trust the Debian maintainers to backport critical bug fixes and not to introduce new issues.

And again, I don't think the problem is PipeWire or a problem with Bookworm Pup64 itself. Those who replied here and run Bookworm Pup64 inside QEMU, do they run Bookworm Pup64 via QEMU running on top of Bookworm Pup64, or running Bookworm Pup64 inside QEMU on some other distro? Does this problem reproduce with other distros running under QEMU?

[Clarity]

...Does this problem reproduce with other distros running under QEMU?

Reported the answer to this, earlier.

NO.

First noticed this in Vanillas.

I,like others, have a production PC we use with the ability to fire up a Virtual PC to quickly test and report. My HOST environments tested are FossaPUP64 and FATDOG using the same stanzas across the board for all ISO/IMG files i've tested. The ONLY variations I have used over the past years is with video as some forum distros will struggle when using cirrus versus std.

Not sure what you are getting at, please explain.

[dancytron]

I have an HP 15 Laptop https://support.hp.com/us-en/product/hp ... ku=N5Y09UA

It has a Radeon Display chip/card/whatever.

When booting, it boots with the 800x600 vesa display and freezes hard on the 1st setup screen.

When booting to the console with pfix=nox, that works. When I run the xorg wizard and try anything but the default, X fails and goes back to the command prompt. The default freezes the same way as before. edit: also tried manually entering "radeon" and "radeon_b10" in the xorgwizard. /edit

My guess is a missing display driver or some kind of mesa.dri related file.

edit: This is the handwritten grub2 entry I am using to boot it on my manual frugal install with "pfix=nox" added for troubleshooting.

Code: Select all

menuentry "BookwormPup64_beta1 on sda6" {
  echo "Booting BookwormPup64_beta1 on sda6..."
  search --no-floppy --fs-uuid --set=root 2618304c-b5be-4cdc-bcc4-5eee05256f09
  linux /BookwormPuppy/vmlinuz pmedia=ataflash psubdir=BookwormPuppy pfix=nox
  initrd /BookwormPuppy/initrd.gz
}

/edit

Here is the lspci and lsusb.

Is there any other info that will help troubleshoot it? I used md5sum to check the download was good.

Code: Select all

 root@LaptopDog:~/Desktop# lspci
00:00.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 16h (Models 30h-3fh) Processor Root Complex
00:01.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Mullins [Radeon R4/R5 Graphics] (rev 45)
00:01.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Kabini HDMI/DP Audio
00:02.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 16h (Models 30h-3fh) Host Bridge
00:02.2 PCI bridge: Advanced Micro Devices, Inc. [AMD] Family 16h Processor Functions 5:1
00:02.3 PCI bridge: Advanced Micro Devices, Inc. [AMD] Family 16h Processor Functions 5:1
00:02.5 PCI bridge: Advanced Micro Devices, Inc. [AMD] Family 16h Processor Functions 5:1
00:08.0 Encryption controller: Advanced Micro Devices, Inc. [AMD] Kabini/Mullins PSP-Platform Security Processor
00:10.0 USB controller: Advanced Micro Devices, Inc. [AMD] FCH USB XHCI Controller (rev 11)
00:11.0 SATA controller: Advanced Micro Devices, Inc. [AMD] FCH SATA Controller [AHCI mode] (rev 39)
00:12.0 USB controller: Advanced Micro Devices, Inc. [AMD] FCH USB EHCI Controller (rev 39)
00:13.0 USB controller: Advanced Micro Devices, Inc. [AMD] FCH USB EHCI Controller (rev 39)
00:14.0 SMBus: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller (rev 42)
00:14.2 Audio device: Advanced Micro Devices, Inc. [AMD] FCH Azalia Controller (rev 02)
00:14.3 ISA bridge: Advanced Micro Devices, Inc. [AMD] FCH LPC Bridge (rev 11)
00:18.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 16h (Models 30h-3fh) Processor Function 0
00:18.1 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 16h (Models 30h-3fh) Processor Function 1
00:18.2 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 16h (Models 30h-3fh) Processor Function 2
00:18.3 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 16h (Models 30h-3fh) Processor Function 3
00:18.4 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 16h (Models 30h-3fh) Processor Function 4
00:18.5 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 16h (Models 30h-3fh) Processor Function 5
01:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8188EE Wireless Network Adapter (rev 01)
02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL810xE PCI Express Fast Ethernet controller (rev 07)
03:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTS5229 PCI Express Card Reader (rev 01)
root@LaptopDog:~/Desktop# lsusb
Bus 002 Device 003: ID 0c45:651b Microdia HP Webcam
Bus 002 Device 002: ID 0438:7900 Advanced Micro Devices, Inc. Root Hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 003: ID 0eef:c04d D-WAV Scientific Co., Ltd eGalaxTouch EXC3000-0367-44.01.00
Bus 001 Device 002: ID 0438:7900 Advanced Micro Devices, Inc. Root Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 002: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

[dimkr]

Not sure what you are getting at, please explain.

Does this happen with Debian or Ubuntu? Any recent non-Puppy distro running under QEMU. You need to understand that VMs don't run at native speed: some things are virtualized and some things are emulated (sound cards, OpenGL ...). The host OS scheduler, among other factors, can slow down the guest under certain workloads, because this emulation is CPU-intensive.

[Clarity]

@dimkr

Let me see if you and I are on the same page. I have provided the QEMU stanza AND I have request the one you might be using.

Questions which might be helpful to us, who are reporting

• Have you tried the stanza I provided with YOUR Vanillas?

• Are you getting different results?

• Is YOUR personal stanza providing audio that is what you expect for your Vanilla by clear audio via your host's speakers?

I am getting an awful impression.

[dimkr]

• Have you tried the stanza I provided with YOUR Vanillas?

• Are you getting different results?

• Is YOUR personal stanza providing audio that is what you expect for your Vanilla by clear audio via your host's speakers?

I am getting an awful impression.

Everything works well here with any stanza I tried, and any Puppy I tried, plus Fedora, Ubuntu and other "heavyweight" distros. Browsers can be slow sometimes, but especially when rendering WebGL content. Audio playback is smooth even in a complex scenario like USB passthrough of a Bluetooth dongle so the VM can connect to Bluetooth speakers.

(Your setup is probably very different from mine: this is a Thinkpad X220 with 8 GB of RAM, running in PUPMODE 13, the ISO sits in RAM, the host OS is Vanilla Dpup 10.0.x, my CPU microcode is fully updated, I'm running Debian's QEMU - apt install qemu-system-gui, and the VM runs with 2 GB of RAM)

[Clarity]

Thanks @dimkr

Could I see your QEMU stanza, please.

Your host is expectedly different. I want to rule out the QEMU stanza we are using by comparing what happens when we run your stanza.

This is why I have repeatedly ask if you would show your VM.

[dimkr]

Could I see your QEMU stanza, please.

Code: Select all

qemu-system-x86_64 -enable-kvm -m 2048 -cdrom whatever.iso -audio driver=alsa,model=hda -smp 2

I'm not exactly sure what it is that you're testing, but bear in mind it's very CPU intensive, with all the emulation going on. Reducing the nice level of QEMU and making PipeWire/PulseAudio in both the host and the guest a realtime process (chrt -rr -p `pidof pipewire-pulse`, etc') will probably reduce latency for you.

EDIT: forgot to mention, audio works so much better when there's no browser running. GPU acceleration is all emulated and extremely slow. Audio works much better in a video downloaded from YouTube using yt-dlp and played with mpv, compared to a browser.

[radky]

viewtopic.php?p=89536#p89536

I have an HP 15 Laptop https://support.hp.com/us-en/product/hp ... ku=N5Y09UA

It has a Radeon Display chip/card/whatever.

00:01.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Mullins [Radeon R4/R5 Graphics] (rev 45)

When booting, it boots with the 800x600 vesa display and freezes hard on the 1st setup screen.

When booting to the console with pfix=nox, that works. When I run the xorg wizard and try anything but the default, X fails and goes back to the command prompt. The default freezes the same way as before. edit: also tried manually entering "radeon" and "radeon_b10" in the xorgwizard. /edit

My guess is a missing display driver or some kind of mesa.dri related file...

@dancytron

If I understand correctly, the Woof-CE generated firmware and 6.1.X kernel of BW64 (and Vanilla Dpup) are based on the content and configuration parameters currently employed by mainstream Debian 12 (Bookworm).

Debian Bookworm will be at 'Full Freeze' status on 24 May 2023, at which time software/firmware updates are essentially complete for the official release of Debian-12 on 10 Jun 2023.

A quick check of the fdrv of BW64-Beta1 suggests it already contains the Mullins iteration of Radeon firmware for the R4/R5 Graphics chipsets, but I don't know about specific support for revision 45. Even so, the next release of BW64 (Beta2) will contain any potential firmware updates concurrent with the official release of mainstream Debian Bookworm.

Maybe @dimkr will also reply.

[dancytron]

It works with 6.1.0-7 in Debian Dog Bookworm.

Fred has a display freezing issue with his laptop with kernels after that too.

I'll build a new DD Bookworm with the latest kernel (-9 I think) and see if I get the same error, which I should if it's the same kernel issue.

Might take a day or so.

[radky]

@dancytron

BW64 features the same kernel as Vanilla Dpup 10 (currently 6.1.25).

If I understand correctly, Linux kernel 6.1.25 was released 20 Apr 2023.

In the changelog of 6.1.29 I see multiple updates/fixes in May 2023 pertaining to drm/amdgpu.

Hopefully, the next release of the Dpup kernel will address your booting issue with Radeon Graphics.

[fredx181]

My issue seems different from @dancytron's
On BookwormPup64 I can change resolution without problems.
But DD Bookworm uses xrandr (lxrandr) (no xorg.conf by default) and I believe that BWpup64 does that different (by xorg.conf).

As a test I installed lxrandr on BWpup64 and used it to change resolution, same thing happens as on DD Bookworm with latest kernel.
(also tested with xrandr through commandline, same freeze).
What happens is that it shows for a few seconds colored vertical stripes, then the screen goes black and keyboard unresponsive, so can only do a hard shutdown

BTW, on my very old HP laptop (from 2007) all is fine with the newest kernel ! No problem setting resolution with xrandr (above is with my very new laptop).

[Clarity]

Code: Select all

qemu-system-x86_64 -enable-kvm -m 2048 -cdrom whatever.iso -audio driver=alsa,model=hda -smp 2

Thanks, I'll report back tomorrow.

On the desktop VanDPup64-v11+, on its terminal, in the VM I have tried aplay /usr/share/audio/2barks.au and aplay /usr/share/audio/2barks.wav. I get nothing. Is there a recommended way to use the terminal to quickly play some audio in v11+?

Tomorrow...

[dancytron]

To follow up, the -9 kernel doesn't work right in DD Bookworm either. It doesn't freeze, but it only sees 800x600. The -7 kernel worked correctly.

viewtopic.php?p=89596#p89596

[dimkr]

On the desktop VanDPup64-v11+

It's an early development build, it's very very different from Bookworm Pup64 (because it uses Wayland, among other differences) and the final release will be based on Debian 13, not 12.

I don't think this is the right thread to discuss recurring issues with QEMU, especially if they're not limited to Bookworm Pup64.

[dimkr]

Merged two PipeWire-related fixes into woof-CE:

https://github.com/puppylinux-woof-CE/w ... 7731620428
https://github.com/puppylinux-woof-CE/w ... afdcb83ba4

If ALSA is configured to use PipeWire via the pipewire plugin and not via the pulse plugin plus pipewire-pulse, maybe this can reduce latency, because fewer processes are involved. And dropping the (now unused) pulse plugin saves space.

[Clarity]

The QEMU discussion started here when the ability to boot the ISO file via a boot-helper fails. This was just verified that the USB will not boot BWP64 beta on bare-metal.

Reports
I just completed tests of the F96 ISO file validating its ability to boot in a VM as well as on bare-metal with the same USB. Those test were reported on the F96CE v4 thread.

I just ALSO found that unlike other past WoofCE distros and most forum distros up to F96, boot via their ISO file boot-loader USBs. Today, I downloaded all 3 Vanillas from yesterday to the BOOTISOS folder. NONE of them will boot via the USBs I have; namely Ventoy and SG2D. So these, now 4, appear to be generated from the same WoofCE generator and have some issues that does not allow them to boot to desktop.

In all cases, this distro, and the current Vanillas, I do have the offer to allow "debugsave" to create a log leading to the problem. Would any developer want to see it? If so, I can upload the log somewhere for you to access. Of course, its reasonably simple to create either bootable ISO File boot-loader as they are basically foolproof to do to validate my reports.

It I can help with any info or further tests, I am happy to do so.

[radky]

@Clarity

Your reports concerning booting issues with QEMU and Ventoy are multiple and duly noted. However, BW64 will provide only the boot capabilities defined upstream by Woof-CE. If you or other forum members have specific viable solutions for any Puppy boot issues, I'm sure @dimkr will be happy to address those recommendations.

[dimkr]

I'm sure @dimkr will be happy to address those recommendations.

Nope

[TerryH]

This was the first opportunity to install this BookwormPup64. I did a manual install to an existing USB Flash drive. This is running on my Asus Ryzen 7 5800H laptop. Out of the box everything tested so far is working very well. Function keys for Volume/Mute, screen brightness and keyboard backlight work correctly. Bluetooth (Audio) worked without issue. No changes were required to the touchpad, sensitivity was not an issue, as frequently is with this laptop. Save File created and no issues with booting/rebooting. Everything running very smoothly, so far without issues.

This is an excellent addition to the Puppy kennel. @radky Thank you for your development work on this release, and also to others who have assisted in producing this release.