Puppy Linux Discussion Forum

It appears editing /sbin out of line 1499 is correct. New version: 1499 cp -a /init* /README.txt /pup_new/initrd/

However, what about lines 1503-1504?
1503 [ -f /bin/cryptsetup ] && cp -af /bin/cryptsetup /pup_new/initrd/bin/
1504 [ -f /sbin/cryptsetup ] && cp -af /sbin/cryptsetup /pup_new/initrd/sbin/

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

Rizalmart's github request had me thinking 'yes' & making /bin or /sbin folder (as needed) in /pup_new/initrd/ , thus:
1503 [ -f /bin/cryptsetup ] && mkdir /pup_new/initrd/bin && cp -af /bin/cryptsetup /pup_new/initrd/bin/ # mkdir bin
1504 [ -f /sbin/cryptsetup ] && mkdir /pup_new/initrd/sbin && cp -af /sbin/cryptsetup /pup_new/initrd/sbin/ # mkdir sbin

Earlier comments had me thinking 'no' & commenting them out.

@Dry Falls @dimkr

ALL options (including doing nothing OR commenting out all 3 lines) appear to work, but I've no idea which is best to implement.

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.

@Dry Falls - thanks for that. 1 issue - crypsetup is in /sbin - see pic below. ldd says 'not a dynamic executable', whereas /initrd/bin version says 'static', as you said. I note that the initrd version was not installed in previous iterations of this pup, as the lines 1503-1504 didn't do anything. Now what to do? Maybe remove /sbin from line 1499 & comment out lines 1503-1504 to avoid a clash?

LATER: I did as I suggested above & made a savefile with luks - which uses cryptsetup - is fine.

I just checked over several puppies - pretty much every puppy released in the last 2 years has in initrd.gz, (in the last 30 or so lines of init), these 6 lines (can view init file in /initrd):

cp -a /init* /sbin /README.txt /pup_new/initrd/
chmod -x /pup_new/initrd/init
dmesg > /tmp/dmesg.txt

[ -f /bin/cryptsetup ] && cp -af /bin/cryptsetup /pup_new/initrd/bin/
[ -f /sbin/cryptsetup ] && cp -af /sbin/cryptsetup /pup_new/initrd/sbin/

This is obviously due to woof-ce. Some of it doesn't work. My rework, replacing the blank 4th line & editing the 5th line, will (I think) enact the code's intention:

cp -a /init* /sbin /README.txt /pup_new/initrd/
chmod -x /pup_new/initrd/init
dmesg > /tmp/dmesg.txt
cp -f /etc/rc.d/functions_x /pup_new/initrd/sbin/ #copy real file over dead link
[ -f /bin/cryptsetup ] && mkdir /pup_new/initrd/bin && cp -af /bin/cryptsetup /pup_new/initrd/bin/ #must create dir
[ -f /sbin/cryptsetup ] && cp -af /sbin/cryptsetup /pup_new/initrd/sbin/

In the original, the value of /sbin in the first line is questionable after boot, since it's contents shouldn't thereafter execute. Ditto the last line. The 2nd last line does not appear to do anything. Earlier, I tried taking /sbin out of first line & commenting out last 2 lines (of original) & ran it for a day - seems fine, BUT

as last week's Vanilla Dpup (10.0.47) has the 6 lines in first code box above, I feel that if @dimkr hasn't changed them, I don't feel like being (& making those who download my pup) pioneers in this.

So, I'll wait a couple of days for more comments, then release v4.

ozsouth wrote: ↑Wed Feb 21, 2024 11:09 pm

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.

V4 released - see 1st post.

Don't know if it's peebee's builds or woofCE, but xerrs logging is blocked by default. Makes troubleshooting kinda hard.

Boot parameter fsck is not handled by init script unless the device is f2fs sdd card, even though the binaries are present in the initrd (busybox applets). Error is reported in bootinit log.

@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.

This is where xerrs.log is called in xwin (line 26):

if [ -f /var/local/xwin_disable_xerrs_log_flag ] ; then
	LOGFILE_X='/dev/null'
else
	LOGFILE_X='/tmp/xerrs.log'
fi

then line 346:

/usr/bin/xinit ${XINITRC} -- -br -nolisten tcp > $LOGFILE_X 2>&1

remove /var/local/xwin_disable_xerrs_log_flag to enable logging.
Slackware startup scripts (for certain DE/WM's) log to $HOME/.xsession-errors. I symlink that to /tmp and /var/log in Lighthouse. Of course, Puppy Linux uses its own method but it has historically been accomplished by xwin/startx.

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.

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.
.

Dry Falls wrote: ↑Wed Feb 21, 2024 8:21 am

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

Dry Falls wrote: ↑Wed Feb 21, 2024 8:21 am

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.

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

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

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

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

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

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

@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).

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

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

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?

@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).

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)

@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):

Thanks ozsouth, the problem is solved.

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

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

v7f released. After bugfix, changed to new base 20240717. (v7s, less firmware, 6.1 kernel, released later). See 1st post.