Could not open mnt/casper/filesystem.squashfs, because No such file or directory

[changchichung]

just clone the repo and run it , then get an error message

Could not open mnt/casper/filesystem.squashfs, because No such file or directory

chchang@hqdc039:~/git/JLIVECD$ sudo JLstart 

**************** JLIVECD ******************
*Tips:
*   1. Paths must be absolute. (~ allowed)
*   2. Inputs are literal
*   3. Do not use NTFS partition
*******************************************


=== Is this a new project: (y/n)?: y

=== Where do you want to save your project ? Choose a directory where you have full permission. Enter path: /tmp/jlive
=== Enter the path to your base iso image: /home/chchang/Downloads/ubuntu-20.04.1-legacy-server-amd64.iso

*** Found iso: /home/chchang/Downloads/ubuntu-20.04.1-legacy-server-amd64.iso

***********************************************
*** Default value for (Y/n) prompts is 'n'  ***
*** unless specified otherwise.             ***
*** If you just hit enter without giving    ***
*** anything to a prompt, it will take the  ***
*** default (previous) value.               ***
***********************************************

***************** MODE SELECT *****************
* For Ubuntu family & Linux Mint: ubuntu mode *
* For Debian:                     debian mode *
* For archlinux:               archlinux mode *
***********************************************
1) Ubuntu
2) Debian
3) ArchLinux
Please select a mode (#?): 1
mount: /tmp/jlive/mnt: WARNING: device write-protected, mounted read-only.
Could not open mnt/casper/filesystem.squashfs, because No such file or directory

E: unsquashfs failed

*** END ***

any suggestions ??

[neurobin]

mount: /tmp/jlive/mnt: WARNING: device write-protected, mounted read-only

If it is write protected then the iso can not be extracted. Use another location where u have write permission.

[changchichung]

/tmp is always open read/write for everyone!

[neurobin]

try another location that is owned by the current user. Your /tmp directory may have some issues.

[DwarfFighterCleric]

@changchichung
It's not your fault. The script Funcs.sh has flaws, mainly it assigns the app to run under user 1000 group 1000 (I don't see any specific reason for that and the creator refuses to reply why would that be the case...) and also chmod the directory, I had to manually change all instances of chmod to 777 so the program can run succesfully.
I had provided updated versions of the file both for Xubuntu 20.10 and also for MX Linux (Debian base)
Download here:
https://www.dropbox.com/sh/s61370wofadlny5/AAA6s0rjAz1QW9N1fJihYhBia?dl=0
Change username and group name according to your user inside of Funcs.sh, that's the only file that needs to be changed. The default values I've used are the ones for the Live Session user of each distro.
There is also a problem where GUI apps will not run from the Chroot, you will not be able to customize your panel for example. That was an issue that did not exist on early versions of JLiveCD, but the author of the project removed old versions from the site, so there's no way for us to look into it. It's a mystery to me why some people behave like that. Puts your own reputation at risk. The program itself is excellent, but not sure why is the guy acting this defensive about it.

[neurobin]

As @DwarfFighterCleric pointed out, it may have been due to 1000. I have updated the code to use SUDO_USER instead. It should work.

[neurobin]

but the author of the project removed old versions from the site, so there's no way for us to look into it. It's a mystery to me why some people behave like that. Puts your own reputation at risk. The program itself is excellent, but not sure why is the guy acting this defensive about it.

😄 The old versions were insecure and could cause damage to the system if used improperly.

This repository contains all the previous versions from version 1.0. Anything that was before 1.0, you should not use it, they are insecure and can cause system damage.

If any version was removed after 1.0, it was due to serious bugs that could cause system damage.

[DwarfFighterCleric]

Also, I remember existing a step-by-step PDF manual here for download. Was that manual removed?
When I execute the Chroot in JLstart, I'm having these error messages on the terminal:

=== Enable access control (prevent GUI apps to run) (Y/n)? (default 'n'): 
*** access control disabled

*** installing updarp in chroot ...
./funcs.sh: line 388: printf: /: invalid number
./funcs.sh: line 388: printf: m: invalid number
./funcs.sh: line 388: printf: e: invalid number
./funcs.sh: line 388: printf: d: invalid number
./funcs.sh: line 388: printf: i: invalid number
./funcs.sh: line 388: printf: a: invalid number
./funcs.sh: line 388: printf: /: invalid number

I have modified line 388 removing some parts of that printf command and even then it's still showing errors.
Could you detail for us what's line 388 is supposed to do in terms of functionality? Maybe if I know what it's trying to do, I can modify it in a way that it will work.

In regards to
'parts of the program were not secure'
part,
Well, any linux user could potentially damage the system in any way using sudo commands and deleting entire root directory.
You can't base the entire premise of an app focusing on stupid users, making changes that break the app. Most people that are using this know what to do, people that use this are not linux newbies.
Besides, the previous version of the program I have used in February 2018 WORKED, there weren't any error messages, in Xubuntu 16.04
Either linux distros changed dramatically since 2016 (potentially SystemD's fault... again...) or the changes you made to the app broke it entirely. I could have left this last bit here out of the message, but you didn't hesitate to use the "older versions were unsafe" flawed argument, so I'm not hesitating to write this either. The treatment you're getting from me is according to your own. So make your choices wisely.

[neurobin]

That printf is supposed to convert the path string to octal (we can not put spaces in /etc/fstab file)

[neurobin]

"older versions were unsafe" flawed argument

If I have deleted any older version, it was definitely unsafe. There is no paid version of this tool, so It's entirely pointless for me to remove any version. I have no idea why you think I may have deleted older version for some other reasons.

[DwarfFighterCleric]

OK, let's focus on the problem at hand. This app is 98% ready. We just need to figure out the last 2% to make it run without errors. No silly distractions.
I have another huge update: for the 1st time (using this new version) I was able to initialize a GUI app inside of chroot, I have googled this for hours before and wasn't able to find it.
This did it:

gksu dbus-run-session <name-of-the-app>
gksu dbus-run-session xfce4-settings-manager  

I was able to succesfully change xfce4 settings, in this case I modified mouse settings to provide a quick test.
When I hop back to the root system and I check my mouse settings, they are different, they were not changed. So this proves that indeed the Chroot is making changes only inside of Chroot, right? (that wasn't the case before... some changes would be made to the host system, like initializing a panel for example...)
To provide a 2nd layer of verification: I hop back into the Chroot and I opened the mouse settings again. The "new" settings I set for the mouse were there. So the changes are being saved. COOL!!!! This is exactly what I needed in order to change xfce4 and panel changes inside of the Chroot system, like I have done back in early 2018.

(to be fair, this seems to be a problem caused by newer versions of Xfce4 and the way it is intrinsically connected to DBus addresses... version 4.14 specifically... back in 2016, major distros used Xfce 4.12, and that version worked differently, it didn't had any of these issues... for this same exact reason a few "alternative" distros out there like Devuan are ditching Xfce 4.14 in favor of older 4.12, to not having to deal with this... current version of Xfce 4.14 being shipped out there is broken, settings are not saved across reboots, root settings are not saved, etc etc)

OK, I found how to "solve" the problem (in a manual hack way, it's definitely not a "permanent" solution by any means)
My question is: what do we have to change in Funcs.sh to address this and make GUI apps work again? (well, it's not really a big deal having to type that small command everytime the user needs to run a GUI app... majority of changes are made in the terminal anyway...)

Another question that I have: is Xterm strictly required to make JLiveCD work 100%? Or is it optional, like in past versions? Maybe that's the problem, because I haven't used Xterm this entire time.

[DwarfFighterCleric]

The terminal says to me that

A connection to the bus can't be made  

But that doesn't prevent GUI apps from working the way they are intended to work.
Being able to change keyboard layouts and mouse settings is a HUGE progress =D So happy it's working

[neurobin]

gksu dbus-run-session <name-of-the-app>
gksu dbus-run-session xfce4-settings-manager  

This info can be included in the wiki on How to run GUI apps in JLiveCD chroot.

[neurobin]

what do we have to change in Funcs.sh to address this and make GUI apps work again?

Unfortunately there's no known way to me to add this in JLiveCD, just like you have to run commands for other softwares, you will have to type those extra bits to run the GUI apps.

[neurobin]

I have updated the wiki page: https://github.com/neurobin/JLIVECD/wiki/Graphical-customization

[neurobin]

Xterm strictly required to make JLiveCD work 100%

No. It's a fallback terminal. I have added another page to the wiki: https://github.com/neurobin/JLIVECD/wiki/Using-specific-terminal