[Solved] The generic Linux installer is incompatible with Ubuntu + fixing LILO/exFAT

[jjr]

Why not use Grub for BIOS [...]
LD

[1, 2, 3, 4, 5]

I remembered another reason, edited to add as 1B + clarified why I'm sticking to Porteus' "unmarked ESP."

[ncmprhnsbl]

Looks good! It works for me unless there's a space in the volume label, per issue #4. Lots of people use spaces nowadays.

try this one, some quoting added , untested here, because my device names are names not sentences :p
Porteus-installer-for-Linux.com md5sum: 10b8580d87f929a829f30fa5c9f2a26b
i noticed there's a variable: $USER_PWD the makeself exports at extraction that is the launch directory, so i just added PWD="$USER_PWD" to the installer.com script and so no arg passing needed.

there's no plans to change the default bootloader any time soon, i was just pointing out that there's many ways to boot porteus that people are free to use and the docs could/should reflect that.

[jjr]

try this one, some quoting added , untested here, because my device names are names not sentences :p

lol
me too normally, i'm just probing edge cases.

All working now.
No need to change anything!

Thank you for working on this.

I'm struggling because I feel guilty if I leave ignoring errors (like I have a responsibility to say something), even if they don't currently have an effect. (pathological perfectionism)
You can ignore the rest of this message.
-------------------------------

• Your defined targetdir is being ignored here. For example, if I replace it with targetdir="/tmp2blablabla", it still extracts to /tmp/..., because the MakeSelf logic actually ignores the targetdir and extracts to /tmp unless it's "." or (edit: if keep="y" such as when) re-assigned by the user with --target. Seems like a MakeSelf bug.
• A warning about /tmp getting deleted.

  Code: Select all

  bash Porteus-installer-for-Linux.com --info
  

  It warns that "/tmp will be removed after extraction", but it doesn't seem to be. Probably a wrong message.
• Unquoted rm -rf $bin on installer.com line 10, so in theory this could happen:

  Code: Select all

  $ mkdir /home/bob/myfiles
  $ touch /home/bob/myfiles/super_important_stuff
  $ bash Porteus-installer-for-Linux.com --target "/home/bob/myfiles 2"
  ...
  Installer needs roots privileges to run
  # Then this happens: rm -rf /home/bob/myfiles 2/...
  # super_important_stuff got deleted
  

• But $bin was used uninitialized there, so rm -rf just deletes air.
• $bin is also used uninitialized on line 34, so failing to cleanup.

The last 2 are OK because MakeSelf is deleting the enclosing folder (selfgz..) on its own.
OK I'm done
It's fine the way it is.

Thank you again

:bricks_falling_on_head:

[ncmprhnsbl]

You can ignore the rest of this message.

apparently i didn't ..
Porteus-installer-for-Linux.com md5sum: 2acc0428f66ce7bcd2a002d1493bd490 (all the previous links are the same file)

• updated my makeself.sh to the latest for good measure

• removed the rm -rf $bin s because as you say they're not needed, makeself handles this itself

• removed setting PWD=$USER_PWD and used $USER_PWD directly in the two instances it's called

and yeah the output of --info is confusing(or do i mean confused?):

Code: Select all

Identification: Porteus Installer
Target directory: build
Uncompressed size: 512 KB
Compression: gzip
Encryption: n
Date of packaging: Wed Feb 21 16:01:58 AEST 2024
Built with Makeself version 2.5.0
Build command was: ./makeself.sh \
    "build" \
    "Porteus-installer-for-Linux.com" \
    "Porteus Installer" \
    "./.porteus_installer/installer.com"
Script run after extraction:
     ./.porteus_installer/installer.com
build will be removed after extraction

"Target directory: build" ... in this case build is the directory that contains .porteus_installer/* from which the makeself is constructed.
and if a --target (.ie an extraction point) is specified, as you say, if it isn't "." , it's ignored.. but info will then put that as the "Target directory"
"build will be removed after extraction" seems meaningless, or just plain wrong if it's meant to refer to the extraction point.
so yeah, seems like a bug, harmless or i'm doing it wrong

[jjr]

md5sum: 2acc0428f66ce7bcd2a002d1493bd490 (all the previous links are the same file)

Checked √

> targetdir="build"
Yeah, that fixes the info report.
But not sure I'd rely on MakeSelf ignoring the targetdir, since if they change that behavior, their fix will break the installer now (i.e. extracting to "boot/build" = owner/perm issues on FAT).

I would just put targetdir="/tmp/porteus_temp", myself.

[rm] not needed, makeself handles this itself

Their cleanup was different when targetdir was "." (including at one point erroring trying to remove "." )
Man, I give up trying to understand their semantics... nyf

[jjr]

So sorry to bother you.
One major regression, plus something odd.

1. This issue affects only the LILO part of installer.com, which gets used if Porteus is located on an exFAT drive.

You caught something, I totally missed:

Code: Select all

# would have installed extlinux to user's system drive ("df -P /tmp" -> /dev/sda3)
"$bin"/$extlinux -i "$IPT"/syslinux >/dev/null 2>&1

...you appropriately changed to this:

Code: Select all

"$bin"/$extlinux -i "$USER_PWD"/syslinux >/dev/null 2>&1

However, there are a bunch of other "$IPT"/syslinux in the LILO section, which are now looking for syslinux in the /tmp subdir.
It's probably also installing LILO to the user's system drive too (if that's where /tmp is located)

2. MakeSelf apparently has a 'copy' mode (not currently user-accessible??), where USER_PWD gets borked (see line ~560):

Code: Select all

    cd "$TMPROOT"
    export USER_PWD="$tmpdir"
    exec "$SCRIPT_COPY" --phase2 -- $initargs

In --phase2 pass, USER_PWD gets re-re-exported as $PWD again, but the cd "$TMPROOT" above ensured that it's screwed anyway.
(Very very confused as to why they are doing this...)

---------------
edit: If 'copy' mode is never touched, then I think these definitions should work:

Code: Select all

IPT="$USER_PWD"
bin="$PWD/.porteus_installer"

Thanks for your patience,

[jjr]

critical edit at end above

-------------------------------------
Also a key difference between the official Porteus installer and @ncmprhnsbl's's update threw me off, and I said something misleading earlier.

• Official Porteus has keep="y" in the Makeself script, which honors the targetdir but doesn't clean up. Requires the rm -rf "$bin" ...
• @ncmprhnsbl's uploads have keep="n" in the Makeself script, which ignores the targetdir but cleans up.

The keep variable is also set when the user specifies --target, thus also causing the targetdir to be honored.
..

[ncmprhnsbl]

This issue affects only the LILO part of installer.com, which gets used if Porteus is located on an exFAT drive.

good catch ..
Porteus-installer-for-Linux.com md5sum: 6775063fd7eff3030e8285dfaabb886a (all the previous links are the same file)
now fixed, hopefully
i rearranged the whole section defining things:

Code: Select all

IPT="$USER_PWD"
PWD="$(pwd)"
bin="$PWD/.porteus_installer"
extlinux_conf="$IPT/syslinux/porteus.cfg"
lilo_menu="$IPT/syslinux/lilo.menu"
log="/tmp/debug.txt"
PRT=$(df -P "$IPT" | grep -o '^/dev/[^ ]\+')
MPT=$(grep "^$PRT" /proc/mounts | cut -d' ' -f2)
DEV=/dev/$(lsblk -ndo pkname "$PRT")
PRTN=$(echo ${PRT#"$DEV"} | sed 's/[^0-9]*//g')
FS=$(grep -w "$PRT" /proc/mounts | head -n1 | cut -d" " -f3)

and called pwd for PWD just to make sure, and reverted the $USER_PWD instances back to $IPT
also: replaced all `` with $() and added some [ ] to a couple if/then sections that appear to be tests...
don't appear to broken anything for basic operation, at least.

so yeah, --copy is a build time arg, so it shouldn't come into play..
for reference, my current [build command is:

Code: Select all

./makeself.sh build Porteus-installer-for-Linux.com 'Porteus Installer' './.porteus_installer/installer.com'

translating to

Code: Select all

./makeself.sh <directory_containing_.porteus_installer_tree> <name_of_makeself_archive> <label> <script_executed_on_extraction>

But not sure I'd rely on MakeSelf ignoring the targetdir, since if they change that behavior, their fix will break the installer now (i.e. extracting to "boot/build" = owner/perm issues on FAT).

well, the breakage would only occur on building with a new version makeself with changed behavior and should become apparent at that time..
if i get keen i'll open an issue on their github querying the meaning of it..

[Ed_P]

Will we be seeing a Porteus Update for this fix and the save-session one in the near future?

[jjr]

rearranged the whole section defining things

I like this

querying the meaning of it..

Maybe the thought behind it is: "If you aren't keep="y"'ing the files, then why should you care where it extracts? No place can be better than /tmp."
But I can think of cases where targetdir still matters, and it's not clear, self-documenting code..

[jjr]

Porteus-installer-for-Linux.com md5sum: 6775063fd7eff3030e8285dfaabb886a (all the previous links are the same file)

OK, I got Porteus to fully boot from exFAT on LILO, but it required a few more fixes.
Considering FAT and NTFS, having exFAT as a real option is nice.

This is now outside the scope of the OP. Maybe I should make a new thread for searchers. But I would feel like that 'guy who leaves the room while talking and expects you to follow him'.

LILO Issue #1: Suppressed interactivity

So I run the installer on an exFAT drive, enter 'ok' and it freezes. I hit enter again, and it exits and nothing was done to the drive.
This is because lilo.com was giving a warning for the exFAT volume and prompting for confirmation, but the user cannot see the prompt, because it is >/dev/null.

I would remove ">/dev/null 2>&1" from this line to allow the interactivity:

Code: Select all

"$bin"/lilo.com -P ignore -C "$lilo_menu" -S "$IPT"/syslinux -m "$IPT"/syslinux/lilo.map >/dev/null 2>&1

LILO Issue #2: Wrong default mode

If you bypass the warning it is giving, it corrupts the drive, because the default install mode is apparently wrong.

Once you remove the >/dev/null, you see this:

Code: Select all

Warning: /media/josh/Porteus/boot/syslinux/lilo.menu should be owned by root
Warning: /dev/sdd1 is not on the first disk
Warning: partition type 0x07 on device 0x0831 is a dangerous place for
    a boot sector.  A DOS/Windows system may be rendered unbootable.
  The backup copy of this boot sector should be retained.

Proceed? [N/y]

(Note the prompt at end.)

This is the installer.com's default mode of installing to the partition boot sector instead of to the MBR.
If you enter "y" and force it to proceed, it corrupts the drive (no longer mountable). See #3 below for easy fix.

LILO Issue #3: Three bad if's

To workaround issue #2 (above), installer.com was designed to let the user override the mode with -f (undocumented I guess):

Code: Select all

	if [ $(echo $* | grep -Eqo "\-f( |\$)") ]; then
		LILO=MBR
	else

But in the uploaded version, that conditional is wrong. grep -q doesn't write to stdout, so the value of $(...) is always the empty string, and so the conditional [...] is always false.

You can test this in a shell:

Code: Select all

[ $(echo "hi" | grep -q "hi") ] && echo "this will never print"
[ $(echo "bye" | grep -q "hi") ] && echo "this will never print"

This replacement will evaluate the exit code of grep, which is what we want:

Code: Select all

	if echo $* | grep -Eqo "\-f( |\$)"; then
		LILO=MBR
	else

Similarly this..

Code: Select all

if [ $(echo "$FS" | grep -q xfs) ]; then

...can be fixed with this:

Code: Select all

if echo "$FS" | grep -q xfs; then

And a third one here:

Code: Select all

echo "Installing Porteus to $PRT"
if [ ! $(echo $* | grep -Eqo "\-a( |\$)") ]; then

...with this:

Code: Select all

echo "Installing Porteus to $PRT"
if ! echo $* | grep -Eqo "\-a( |\$)"; then

(You can enclose the pipe in a plain subshell () if you want, but ! will work either way.)


At this point, you can now get LILO to install by running:

Code: Select all

sudo bash Porteus-installer-for-Linux.com -- -f

Per issue #2, to make this the default for exFAT, you could use this for the first conditional:

Code: Select all

if echo $* | grep -Eqo "\-f( |\$)" || echo "$FS" | grep -q exfat; then

I don't know what's sane for other filesystems. (I don't know much about bootloader stages rly.)

LILO Issue #4: Spaces again

LILO fails loading the config if there are spaces in the volume label (through $IPT).

To fix this, you can edit the template "boot/syslinux/lilo.conf", changing all occurrences of this:

Code: Select all

image=DO_NOT_CHANGE/vmlinuz
initrd=DO_NOT_CHANGE/initrd.xz

...to this instead:

Code: Select all

image="DO_NOT_CHANGE/vmlinuz"
initrd="DO_NOT_CHANGE/initrd.xz"

edit: also the plpbt line

RESULT

Applying all 4 fixes, the script successfully installed Porteus to an MBR/exFAT volume with spaces in the label, and it boots to desktop.

[jjr]

LILO Issue #3: Two bad if's

Ah, this applies only to @ncmprhnsbl's upload.
In the official version, those 2 conditionals are different and they actually work. (The `` was also passing grep's exit code to if.)
You could enclose the pipes in $() or () if you wanted, just not in [$()].

edit: there's a 3rd broken if in the upload - edited main post.
edit 2: the 4th affected condition if [ ! $(which $1) ] does work with brackets, because the ! can be used to test for an empty string -- and it's testing the stdout of which, instead of its exit code.

[ncmprhnsbl]

Ah, this applies only to @ncmprhnsbl's upload.
In the official version, those 2 conditionals are different and they actually work.

heh, i made the fatal error of thinking i knew what i was doing.. :p ..here's an update i hopefully havn't broken some other way..
Porteus-installer-for-Linux.com md5sum: d2f6c6e01d4319c4999fc3d553d4aafe (all the previous links are the same file)

I would remove ">/dev/null 2>&1" from this line to allow the interactivity:

done, and this:

Code: Select all

if echo $* | grep -Eqo "\-f( |\$)" || echo "$FS" | grep -q exfat; then

i think xfs is now supposed to be supported syslinux anyway.. does anyone actually used xfs any more? (apart from in a porteus save.dat)
also: ran shellcheck over it and adjusted as per it's suggestions, so everything that can be double quoted is now double quoted, and [test1] && [test2] used instead of [test1 -a test2] (not a big deal, but why not?)

[jjr]

hopefully havn't broken some other way..

I don't know how Shellcheck misses this (it does!),
but this isn't valid-- it prints a shell error (which gets quickly hidden by clear later) and will never execute the inner block, thus allowing non-root to run:

Code: Select all

if $(whoami) != root; then

Outside of []/[[]], the tokens (josh, !=, root) get treated as a command to run, not a logical statement.
! by itself can be used outside of brackets, because it has 2 meanings

System shells are the most jerry-rigged languages, always curveballs. (you too, PowerShell.)

Anyway, do:

Code: Select all

if [ $(whoami) != root ]; then

------------------
I didn't see any other errors, and both bootloaders are working now.

[jjr]

fixed explanation