Another Jammy64pup

[jrb]

The next release will be using @dimkr 's latest 5.15.78 kernel, maybe that will help?

This kernel is old and has several known issues. https://github.com/puppylinux-woof-CE/w ... kernel.yml should be up to date and nearly identical to the Ubuntu 22.04 kernel.

That's the one I'm talkin about.

[Marv]

The next release will be using @dimkr 's latest 5.15.78 kernel, maybe that will help?

This kernel is old and has several known issues. https://github.com/puppylinux-woof-CE/w ... kernel.yml should be up to date and nearly identical to the Ubuntu 22.04 kernel.

That's the one I'm talkin about.

I've failed in several attempts to boot upup B3 with that kernel downloaded from github. vmlinuz and kernel modules renamed correctly and the structure in kernel modules looks OK. Tried from my usual FAT32 boot partition set up with Grub4Dos, from a USB 3.0 flashdrive with the boot partition set up as FAT32 and using Grub4Dos, and with the boot partition set up as EXT2 and using Grub2. In all cases, F96-CE_2 and upup B3 with the 6.1.13 and 6.1.14 kernels booted OK. The debugsave directory is gzipped and attached.

[Clarity]

... In all cases, F96-CE_2 and upup B3 with the 6.1.13 and 6.1.14 kernels booted OK. ...

+1

Also booting from ISO files directly with those kernels

[proebler]

Oh, that'n is a real stinker.

Try two quick things in stock jammypup if you will. 1: Prior to shutdown, use the task manager to kill connmand and connman-ui-gtk.bin.
and 2: Use the task manager to kill bluex, blueman, python3 and a related daemon roughly o??d. I am not running any bluez so I can't check the spelling of that daemon right now but it is related to bluez, sorry.

'stinker' allright
I killed connmand and connman-ui-gtk.bin , it had no effect.
bluex, blueman, python3 were not active

I try and describe what I see at reboot/shutdown:
Upup 22..04 is now shutting down > this hangs and I use ctrl+alt+del >
Upup 22..04 is now shutting down > the option dialogue to save/not save is displayed > after selecting not to save or letting it time out >
session not saved
root@puppypc23557: $ > no other input accepted > use of power button.

(probably) enough from me, regards,
proebler

[Marv]

@proebler, Sorry for making you the test mule on this. What cents I had are spent, at least for the moment.
Thanks, Jim

[LateAdopter]

Hello jrb

A minor issue... XArchiver is associated with .deb packages but says : "Sorry format not supported" but in fossapup64 it's the other way round. It's not associated with .deb but will open them. I noticed it because I was using Xarchiver to check ad hock packages before installing them to make sure they wouldn't break the savefile.

[jrb]

Hi guys, Well I had a new ISO to upload, but it seems to have broken chromium, both my portable and peebee's SFS. It's using WoofCE-testing as of 2 days ago. Oh well, something else to figure out. Helps build strong brain cells, right? Be patient please.

[jrb]

Hello jrb

A minor issue... XArchiver is associated with .deb packages but says : "Sorry format not supported" but in fossapup64 it's the other way round. It's not associated with .deb but will open them. I noticed it because I was using Xarchiver to check ad hock packages before installing them to make sure they wouldn't break the savefile.

I just tried it on a .deb in this latest build, the one that has broken chromium, and its like foosapup64. "It's not associated with .deb but will open them. " Try Downloading xarchiver in PPM, go to /root, click on it and see if it will work then. Let me know if it works.

Good Luck, J

[jrb]

No luck with changing rc.shutdown however.
I had tried that before. The system always ends up at a command prompt that does not accept any commands.

The USB I am using has a number of puppies available, I tried the reboot sequence with Bionic64, BusterPup_8, SCpup32, Vanila Dpup_9.2.0 and CloudPup64 (Fossa). For all of them I get correct shutdown/reboot.
... so I guess the problem is with Jammy64pup on this particular hardware:

Edit: Did you try upup-22.04-jrb-A3.iso? It used peebee's 5.15.80 kernel with aufs and should be compatible with the zdrv's from the other puppies you mentioned. Just rename them to zdrv_upup_22.04.sfs and copy over their vmlinuz as well. Might be worth a try.

@proebler - I really would like to know if you have this problem with upup-22.04-jrb-A3.iso. If it works for you it might give us some clues as where to look. Who knows, if it works I might have to build a upup-22.04-retro for difficult hardware.

[jrb]

OK, New ISO at page 1 post 1

Latest WoofCE which dimkr tells me has some good improvements. Encrypted Savefiles work. Xarchiver extracts works on .debs.

Try it and let me know what you think.

Cheers, J

@dimkr - I'm afraid there is something wrong with https://github.com/puppylinux-woof-CE/w ... kernel.yml . It wouldn't boot for @Marv on his two machines, see above. I had to revert to the old fdrv to get wifi, details if you want them. And worst, it wouldn't allow FireFox or Chomium running as spot to access /home/spot, giving permission errors. When I reverted to the old kernel everything worked. Using it now.

[ally]

@jrb

files do not have a "." before the file extensions making them invalid

[Marv]

C1 ISO renamed with "." and md5sum checked -correct- Up and running, standard grub4dos frugal install to SSD on the 2nd generation i5 all intel Fujitsu S761 (this one with a good BIOS ).

Running with no savefile, no fdrv, my custom ydrv, and right now, with @ozsouth 6.1.14 kernel, path adjusted. punionfs=overlay passed as a kernel parameter as usual. Stock and 6.1.13 kernels also boot cleanly, run just a bit.

All the latest chromium portables are fine, Brave, Slimjet, and un-googled. Both Sylpheed, run as a portable, and Claws Mail are working with gmail imap.

I don't Bluetooth and it's a pain to get Bluetooth/bluez/python3/oexd to stay off. Setting the relevant permissions to execute-nobody in /etc/init.d, /root/.config/autostart, /root/Startup, and /etc/xdg/autostart turns off bluexxxx but python3 and obexd still start. I finally put all the bluestuff in my "hide" directory in /usr/bin and that seems to do it. Shouldn't be that clumsy.

Sound fine, Posting from Brave now, I'll check multimedia and savefile creation/shutdown later.

Default video information on this hardware is (glxgears FPS=8500):
Display Specifications
• Screen Name LVDS-1
• Screen VertRefresh 60.00 times/s
• Screen Resolution 1366x768 pixels (361x203 millimeters)
• Screen Depth 24 bits (planes)

Xorg Startup Log (/var/log/Xorg.0.log)
• Xorg Driver in use modesetting
• Loaded Modules dbe evdev fb fbdevhw glamoregl glx libinput
• X.Org version 1.21.1.3

OpenGL 2D/3D Rendering
• Direct Rendering Yes
• Vendor Intel
• Renderer Mesa Intel(R) HD Graphics 3000 (SNB GT2)
• Version 3.3 (Compatibility Profile) Mesa 22.2.5

VGA device [0300] Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller [8086:0126] (rev 09)
• Kernel Driver i915
• Memory Used by Driver 2072.00 KB
• Path /lib/modules/6.1.13/kernel/drivers/gpu/drm/i915/i915.ko
• Description Intel Graphics
• Video RAM 1536M total, 256M prefetchable

So far what I have tried in PupControl has worked, a fairly small subset of what's available there.

Thanks,

Update: Small savefiles created and tested. 64MB EXT2. One unencrypted and one encrypted. Both show testfolders and files correctly on reboot. Just followed the instructions for the encrypted one, never had done it before. Set up PW and asked for PW correctly.

A little later: Both CD and DVD autoplay correctly with the default settings, Pmusic and mpv.

[jrb]

@jrb

files do not have a "." before the file extensions making them invalid

All fixed. But it took me an embarrassingly long time to figure out what you were talking about. Just glad I didn't have to do another build.

[ally]

my bad, I should have typed out an example!

[jrb]

@dimkr - I just tried your March 1 dpup kernels, Bullseye, Bookworm and Sid, in Jammy64pup. Bullseye worked nicely, Bookworm wouldn't allow browsers to use /home/spot (like the latest Upup kernel) and Sid crashed as soon as the zdrv was loaded. (Sounds a bit like Goldilocks and the 3 bears.) Perhaps this is due to structural differences within the different Puppy versions? In any case I'm fine with using the Bullseye kernel if you think that is better than the old Upup kernel that I'm using now.

[dimkr]

Bullseye worked nicely

Makes sense, that's the kernel from Debian Stable.

Bookworm wouldn't allow browsers to use /home/spot (like the latest Upup kernel)

What do you mean by "use"? Does this problem go away if you delete /usr/bin/spot-sandbox?

(The Debian Bookworm kernel still changes from build to build, it will stabilize soon, as we get closer to the Debian Bookworm release.)

Sid crashed as soon as the zdrv was loaded.

Sid is unstable, this can happen.

EDIT: I'll change to CONFIG_NLS_ISO8859_1=y, that seems to be @Marv's problem. Ubuntu's kernel uses CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1" but CONFIG_NLS_ISO8859_1=m.

[jrb]

What do you mean by "use"? Does this problem go away if you delete /usr/bin/spot-sandbox?

Another good call on your part. Eliminating (renaming) /usr/bin/spot-sandbox appears to have fixed the problem. Chromium and Firefox are both working with the latest upup kernel and the latest bookworm kernel. Must confess I don't understand.
Am attaching the errors report, although it seems unneeded now. False .gz

Thanks once again, J

Jammy64pup_kernel-reports.gz

browser problem report

(3.9 KiB) Downloaded 274 times

[dimkr]

spot-sandbox is a security feature that uses Landlock (a kernel feature introduced in 5.15.x but disabled in many Puppy kernels, see https://github.com/puppylinux-woof-CE/woof-CE/pull/3419) to prevent spot from reading and writing files under /root and other places, in order to prevent malicious or compromised applications that run as spot from gaining root privileges. If this sandbox is missing, run-as-spot runs applications without this sandbox.

See if https://github.com/puppylinux-woof-CE/woof-CE/pull/3971 solves the problem: it allows spot to write not just to /home/spot and /tmp, but to /mnt as well.

[Marv]

EDIT: I'll change to CONFIG_NLS_ISO8859_1=y, that seems to be @Marv's problem. Ubuntu's kernel uses CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1" but CONFIG_NLS_ISO8859_1=m.

Thanks, your latest 5.15.85 build now boots correctly for me in upup C1.

[LateAdopter]

Hello jrb

There's something amiss with lxterminal: When I am entering text from the keyboard it wraps round about 2/3 of the way across the screen back to the beginning of the same line. If I then do "back" it goes to the right margin.
Text output from programs is displayed correctly.

[Marv]

Hello jrb

There's something amiss with lxterminal: When I am entering text from the keyboard it wraps round about 2/3 of the way across the screen back to the beginning of the same line. If I then do "back" it goes to the right margin.
Text output from programs is displayed correctly.

Confirmed. I see the same behavior in urxvt. For me, "backspace" kind of leaves me in midscreen with no prompt. It occurs both windowed and fullscreen. I've played a bit with preferences and fonts in lxtask to no avail. I have used lxtask in all of my pups for years and have never seen this before. I kind of put it on the back burner/chalked it up to my hardware but it's a bit of an irk.

Update: I changed the prompt and the odd behavior went away in both lxtask and urxvt. I created a file /etc/profile.local if one did not exist with the contents:

Code: Select all

PS1="\$PWD > "
export  PS1

I don't see why the prompt and breakline behavior would be linked but give it a go.

[jrb]

Hello jrb

There's something amiss with lxterminal: When I am entering text from the keyboard it wraps round about 2/3 of the way across the screen back to the beginning of the same line. If I then do "back" it goes to the right margin.
Text output from programs is displayed correctly.

Confirmed. I see the same behavior in urxvt. For me, "backspace" kind of leaves me in midscreen with no prompt. It occurs both windowed and fullscreen. I've played a bit with preferences and fonts in lxtask to no avail. I have used lxtask in all of my pups for years and have never seen this before. I kind of put it on the back burner/chalked it up to my hardware but it's a bit of an irk.

Update: I changed the prompt and the odd behavior went away in both lxtask and urxvt. I created a file /etc/profile.local if one did not exist with the contents:

Code: Select all

PS1="\$PWD > "
export  PS1

I don't see why the prompt and breakline behavior would be linked but give it a go.

Thanks for pointing that out @LateAdopter, I had noticed it but as you say "I kind of put it on the back burner."

And thanks @Marv for figuring the fix. I tried putting your lines in /etc/profile and it didn't change anything but when I created your /etc/profile.local it was fixed after reboot. Will be in the next build for sure.

Cheers, J

[Marv]

@jrb , This was kind of like chasing how bluetooth and its clan were started.

In the beginning, the prompt was set in /etc/profile. Then /etc/profile.local was set up so that its contents were included in /etc/profile, at the end so they would override. Worked. Then profile.d was introduced and a file in that, /etc/profile.d/ps1.sh, overrides the prompt set early in /etc/profile, and in my non-savefile ydrv driven install, also overrides /etc/profile.local on reboot. Simple, right??????

At any rate, the simplest fix is to go to /etc/profile.d/ps1.sh and comment out the offender and put in your chosen prompt, like so:

Code: Select all

#PS1="\e[1;32m\u@\H\e[0m:\e[1;34m\w\e[0m\$"
PS1="\$PWD > "

Jim

[jrb]

@jrb , This was kind of like chasing how bluetooth and its clan were started.

In the beginning, the prompt was set in /etc/profile. Then /etc/profile.local was set up so that its contents were included in /etc/profile, at the end so they would override. Worked. Then profile.d was introduced and a file in that, /etc/profile.d/ps1.sh, overrides the prompt set early in /etc/profile, and in my non-savefile ydrv driven install, also overrides /etc/profile.local on reboot. Simple, right??????

At any rate, the simplest fix is to go to /etc/profile.d/ps1.sh and comment out the offender and put in your chosen prompt, like so:

Code: Select all

#PS1="\e[1;32m\u@\H\e[0m:\e[1;34m\w\e[0m\$"
PS1="\$PWD > "

Jim

Thanks again Jim. I think "micron by micron" was quite appropriate.

[proebler]

@proebler - I really would like to know if you have this problem with upup-22.04-jrb-A3.iso. If it works for you it might give us some clues as where to look. Who knows, if it works I might have to build a upup-22.04-retro for difficult hardware.

I did fresh, separate frugal installs for "A" with kernel 5.15.80, "B" and "C1" with kernel 5.15.56.

For 'A" and "B" only: Before creating the encrypted save-file(s) cryptsetup-1.7.5-musl_static_x86_64.pet was installed. Without that, LUKS encrypted save-files are not created.

With "A", the encrypted save-file gets created correctly, but booting with it fails because the password is not accepted.
The "A" system with kernel 5.15.80 shuts down properly (no hanging).

"A" encrypted savefile mounts under "B" but as if it was EMPTY!
...aah, I see: the one from "A" has a 'familiar' Rox directory structure, the on from "B" contains the directories 'upper' and 'work'. Different beasts!

I confirmed that with "B" and "C1", the encrypted save-file works, but the system never shuts down properly, as I have described before:
Upup 22..04 is now shutting downn. > this hangs and I use ctrl+alt+del >
Upup 22..04 is now shutting down > the option dialogue to save/not save is displayed > after selecting not to save or letting it time out >
session not saved
root@puppypc23557: $ > no other input accepted > use of power button
For computer details see previous post.

@Marv no need to say sorry for making me 'test mule'; it is self-inflicted
regards
proebler

[LateAdopter]

The X11/GTK default compose key has been Shift+AltGr for a long time. It works in Bionicpup, Fossapup and Imppup, but Ubuntu have disabled it in Jammy and later.
In case you don't know what you are missing, there is a detailed explanation of what you could do with AltGr before they broke it, here: https://help.ubuntu.com/community/ComposeKey

There are instructions on how to reinstate it here: https://linux.codidact.com/posts/287064
But I didn't do that because I don't like configurations scattered everywhere.

I worked out that the files that had been changed were in /usr/share/X11/xkb/symbols and come from the xkb-data package. I copied gb over from fossapup64 and it now works as before.

[dimkr]

"A" encrypted savefile mounts under "B" but as if it was EMPTY!

This can happen if one kernel includes aufs while the other doesn't. woof-CE's init now use aufs if present, otherwise overlay. If you don't look at the boot log, you won't notice that things "just work" with overlay. However, the save file structure is different between aufs and overlay, so a save file created under one will appear empty under the other.

If the save file was created when using overlay but now you're using aufs, you'll see /upper and /work directories. If t he save file was created while using aufs but now you're using overlay, you won't see the save file contents under /.

[jrb]

I did fresh, separate frugal installs for "A" with kernel 5.15.80, "B" and "C1" with kernel 5.15.56.

For 'A" and "B" only: Before creating the encrypted save-file(s) cryptsetup-1.7.5-musl_static_x86_64.pet was installed. Without that, LUKS encrypted save-files are not created.

With "A", the encrypted save-file gets created correctly, but booting with it fails because the password is not accepted.
The "A" system with kernel 5.15.80 shuts down properly (no hanging).

That's what I wanted to hear! It sounds like a differnet kernel did the job. I'll be releasing a new build sometime today with dimkr's latest huge-5.15.85-kernel-kit.tar.bz2. It's performing well on all my hardware and Marv says its working for him, so hopefully for you too. There are other kernel options as well so I expect we can get a build for you that will work on that hardware.

[dimkr]

My first guess would be https://github.com/puppylinux-woof-CE/w ... d5b2643a1e, but if I understand correctly, A should be old enough to include this fix.

[jrb]

My first guess would be https://github.com/puppylinux-woof-CE/w ... d5b2643a1e, but if I understand correctly, A should be old enough to include this fix.

I really need to work on being more clear about what I'm talking about, or perhaps what I'm understanding.

"B3" frugal install on ext4 HDD partition, on core2 HP Elitebook.

First shutdown creating an unencrypted (normal) save-file hangs > alt+ctrl+del > console prompt > reboot > hangs , making hard shutdown with power button necessary.

On second reading perhaps it was just the savefile that was the problem. I thought by trying A3 with different kernel the hanging shutdown might disappear.

I managed to cure the encryption problem by reverting to cryptsetup-1.7.5-musl_static_x86_64.pet which was used in Fossa64 and Bionic64.

I'm just about to post a new build using huge-5.15.85-kernel-kit.tar.bz2, so we'll see if that helps.