s15pup64-ovrly - closed

[dimkr]

I feel that if @dimkr hasn't changed them

As I said, if and when https://github.com/puppylinux-woof-CE/woof-CE/pull/3824 is merged.

But these lines are harmless, what works doesn't do anything useful but also doesn't do anything bad, and what doesn't work doesn't have bad side effects either because it doesn't do anything.

[ozsouth]

V4 released - see 1st post.

[ozsouth]

@Dry Falls - I checked original - same result. Tried different inits & kernels to no avail. May have been changes in last 11 weeks, but probably not that. Xerrs may have gone the way of atime - where some linux dev decided it caused too many disk writes. On fsck, strange (my ext3 partition has fsckme.flg when s15 ovrly pup running, gone when not, both as expected) - but the init needs a rewrite & folk have either not got the expertise or are time poor.
Fun Fact: running dmesg in a small window doesn't give the full output - need fullscreen & to wait about 30 sec after desktop up.
That also is not new. No wonder some folk have run dmesg & got weird results.
Fortunately, none of these things badly impact the basic operation of this pup.

[ozsouth]

Found 2 interesting bugs in original /usr/sbin/filemnt - fix for first should work in any recent pup.

1. It allows filenames containing spaces. This causes queueing to fail. Best fix is to have each entry in EXTRASFSLIST in double-quotes. I put a note on 1st post forbidding spaces in filenames, but my fix is to bar it with my new code inserted after line 76 (is in red):

------------------------------------------------------
imgFile="$1"
if ( echo "$1" | grep " " ); then
Xdialog --title "" --no-cancel --msgbox "NO SPACES ALLOWED IN FILENAMES - RENAME AND TRY AGAIN" 0 0
exit 1
fi
[ ! -f "$imgFile" ] && echo "No regular file: $imgFile" && exit 1
imgFileBASE=${imgFile##*/} ## imgFileBASE="`basename "$imgFile"`" #BK
[ "$(dirname "$imgFile")" = "." ] && imgFile=$(pwd)/${imgFileBASE}
------------------------------------------------------

Use at own risk. This impacts all mountable files, so better solutions to follow.

.
------------------------------------------------------

2. Imagine if you queued puppy .sfs from another puppy. Next bootup would trash your install. Avoiding queueing inappropriate SFS is the simplest answer, but other mitigations are possible.

.
Of course, we can't completely stop someone making a bad queueing choice unless queueing function is totally removed.

[ozsouth]

A better approach - regarding 2 interesting queueing bugs in original & my v4 (& earlier) /usr/sbin/filemnt :

Bug1. Allows filenames containing spaces to be queued. This causes Queueing to fail & needs manual repair.

Bug2. Allows Puppy system SFS's to be queued. This will likely corrupt your system on next bootup.

The following code fixes those issues in s15ovrly PUP v4 ONLY - my line 146 is deleted & my inserts (in red) follow:

---------------------------------------------------
[ $RETVAL -eq 1 ] && sfs_load "$1"
if [ $RETVAL -eq 1 ];then
if ( echo "$LABELINSTALL" | grep -i "Queue" ) && ( echo "$1" | grep -i "\.sfs" );then
if ( echo "$1" | grep -i "drv_" ) || ( echo "$1" | grep -i "puppy_" );then
Xdialog --title "ERROR" --no-cancel --msgbox "QUEUEING A PUPPY SYSTEM SFS CAUSES CORRUPTION. VIEW OR RENAME" 0 0
exit 1
fi
fi
if ( echo "$LABELINSTALL" | grep -i "Queue" ) && ( echo "$1" | grep " " );then
Xdialog --title "ERROR" --no-cancel --msgbox "NO SPACES ALLOWED IN QUEUED SFS FILENAMES. RENAME AND TRY AGAIN" 0 0
exit 1
else
exec sfs_load "$1"
fi
fi
[ $RETVAL -ne 0 ] && exit #120527
---------------------------------------------

The fixes should be in next s15ovrly update. (Later: updated, a bit different, fixes in v4t)

Of course, we can't completely stop someone making a bad queueing choice unless queueing function totally removed.
.

[tosunpasha]

Does cryptsetup NEED to be copied to /pup_new/initrd?

/initrd is not in the path after switchroot so no binaries in there will be influential after rc.sysinit starts unless it asks for them specifically (which it doesn't). My concern is that the cryptsetup in the initrd is statically compiled and if you have Slackware's cryptsetup installed, it could present problems for other applications which call on it, especially after a package upgrade. Just checked and cryptsetup is not installed in this puppy, so I assume this was done on purpose. But it should be copied to /pup_new/sbin which is where slackware expects to find it. Personally, I'd leave it out and install the official package in a remaster.

Thanks a lot for information

[dimkr]

Just checked and cryptsetup is not installed in this puppy, so I assume this was done on purpose.

It was done on purpose until https://github.com/puppylinux-woof-CE/woof-CE/pull/3823. Before this PR was merged, shutdownconfig and rc.shutdown assumed that cryptsetup is the ancient static executable used by initrd. It doesn't support luks2 (the default in newer versions) and therefore always uses luks1. After this PR, shutdownconfig asks non-ancient cryptsetup outside of initrd (if detected) to use luks1, to make the save file readable by the ancient cryptsetup in initrd.

TL;DR you can install a more recent cryptsetup instead of copying the ancient one from initrd to /sbin, it should work just fine and you'll get support for LUKS2.

[ozsouth]

As of v1, cryptsetup is in /sbin in the puppy .sfs & as of v4 (v3 & v4 based on s15pup64-231209), we don't copy the initrd version over at startup. Regardless, both cryptsetup versions are 1.7.5, so luks2 isn't currently an option.

cryptsetup 1.7.5

Default compiled-in device cipher parameters:
loop-AES: aes, Key 256 bits
plain: aes-cbc-essiv:sha256, Key: 256 bits, Password hashing: ripemd160
LUKS1: aes-xts-plain64, Key: 256 bits, LUKS header hashing: sha256, RNG: /dev/urandom

[ozsouth]

v4t - bugfix released. Eliminates most bad choices for install/queue. (I've abandoned graphical sfs_load 4e development - too many issues). See 1st post.

[ozsouth]

v5 released. 408mb - small bugfix, updated firefox, increased compression. If happy with v4t, you need not update. See 1st post.

[ozsouth]

Version 6 released - new base (20240323) & new concept (changes that make it 'ovrly' are all in bdrv). See 1st post.

[ozsouth]

v6c released. New base (240602), new kernel, updated Firefox, less firmware, downgraded libx265. See 1st post.

[esos]

The s15pup64-22.12-240602-ovrly-6c system crashed if I want to watch youtube video in full screen mode.

[ozsouth]

@esos - what video are you having crash? I've played many, both in fullscreen & not, without problems.
That said, the libx265 fix was a hack - v6c now withdrawn.
If you'd like, I have an experimental version of the 20240612 release for you to try (v6t - 425mb - it has peebee's ffmpeg fix & more firmware).

[esos]

Thanks for quick reply,
Any youtube video using brave browser in full screen mode will crash the whole system, but no issue with S15Pup64-22.12-240602.
Where I can download v. 20240612?
Thanks

[ozsouth]

@esos - I haven't tested Brave browser. See experimental v6t link 2 posts back. Will be withdrawn in a couple of weeks.

[esos]

s15pup64-22.12-240612-ovrly-6t tested but the same problem.
My grafic card:: Intel Corporation Core Processor Integrated Graphics Controller [8086:0046] (rev 02)
S15 is still using X.Org 1.20.14 which Voidpup: X.Org 21.1.13. Is that maybe the problem?

[ozsouth]

@esos - did you try using the Firefox that came with this pup? If that was also a problem, then possibly hardware is an issue. Otherwise it may be a clash with Brave.

(edit: v6f not helpful).

[esos]

Thanks ozsouth, the problem is only brave browser with s15pup64-22.12-240612-ovrly-6 the new kernel.
Brave browser works fine on S15Pup64-22.12-240602 old kernel and VoidPup64-22.02-240602(Kernel 6.6.32)

[ozsouth]

@esos - thanks for testing. I made an sfs of the latest Brave (137mb). (link expired).
Here's screeny of Elvis (brave, youtube, fullscreen, ovrly-6t):

elvis_myway_brave_fullscreen.jpg (23.48 KiB) Viewed 3015 times

[esos]

Thanks ozsouth, the problem is solved.

[ozsouth]

I'm happier with the stability of 240323 base, so have made updated version of that - 6u. See 1st post.

[ozsouth]

v7 & delta released (link corrected). See 1st post.

[ozsouth]

v8 released. 399mb. See 1st post.

[ozsouth]

As this base is 6 months old, have added the basic bdrv sfs, which contains conversion files, to bottom of first post.
I don't intend to develop this pup any further, but will focus on the 'easier to maintain' sovly pup.

[Clarity]

"sovly PUP"???

Curious

[Clarity]

OK, found it on the forum here. <=== Is this correct?

[ozsouth]

@Clarity - yes, that's the sovly link.

Update 01mar25 - this thread now closed.