s15pup64-ovrly - overlayfs-only pup

[ozsouth]

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.

[Dry Falls]

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.

[ozsouth]

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

cryptsetup.jpg (40.02 KiB) Viewed 763 times

[ozsouth]

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

Code: Select all

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:

Code: Select all

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.

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

[Dry Falls]

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.

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

[Dry Falls]

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

Code: Select all

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

then line 346:

Code: Select all

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

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