Could not open mnt/casper/filesystem.squashfs, because No such file or directory
changchichung opened this issue · 21 comments
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 ??
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.
/tmp is always open read/write for everyone!
try another location that is owned by the current user. Your /tmp directory may have some issues.
@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.
As @DwarfFighterCleric pointed out, it may have been due to 1000. I have updated the code to use SUDO_USER instead. It should work.
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.
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.
That printf is supposed to convert the path string to octal (we can not put spaces in /etc/fstab file)
"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.
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.
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
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.
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.
I have updated the wiki page: https://github.com/neurobin/JLIVECD/wiki/Graphical-customization
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
Cool.
Yeah, I'm not sure what's happening here with this DBus stuff. Really annoying how most "updates" in the linux world for the past 4 years focused on "security" but they break functionality. (talking about system in general, not about your app here...) And not only that, this crap gets in the way of talented volunteer programmers like you. For me, 2016 distros were the peak of Linux functionality and simplicity. Nowadays, not so much.
Plan B, possible alternative: initializing the Chroot from a TTY terminal (Ctrl Alt F2 for example) while X server has not been initialized yet. That way the Chroot should have total control over the X session, shouldn't it?
gksu dbus-run-session <name-of-the-app>
is not a perfect permanent solution either, when I run xfce4-panel with this, a separate "fresh" panel opens up (default settings, vertical panel) but it has my Host System apps on the panel (for example, Chromium windows appear there, Wine explorer window appears there too... it's getting mixed up...)
To keep xfce4-panel running while you do other things on the terminal, use nohup:
nohup xfce4-panel &
<then, press Ctrl C once to be back on the terminal, while the previous app is still running>
edit:
using " nohup & " will require you manually kill the command later on using sudo killall, it will not be automatically interrupted using Ctrl C... killing the panel inside the chroot will also kill the panel on your host machine as well, you will have to restart the panel on your host machine again, using nohup xfce4-panel &
Yeah, so it seems to cause things to become even more complicated, so I don't recommend using it.
It's weird too, when I open TaskManager inside the chroot, it displays processes running in my Host machine (like Chromium browser for example) I'm not sure this is the intended behavior of chroot, wasn't is supposed to be completely shielded/isolated? (one more time: not JLiveCD's fault...) One of the many ways linux has introduced regressions over the past 5 years or so, breaking features that worked in the past.
OK I'm happy to announce that I succesfully created an MX Linux custom ISO using JLiveCD and all the Xfce graphical settings that I copied over to /etc/skel are working. (meaning: panel appearance, panel plugins, custom keyboard layout, custom keyboard hotkeys, Thunar settings, Task Manager settings, terminal appearance, etc)
There's one strange thing that I wasn't able to track down the cause for yet: my Live Session user that is created at boot doesn't come with the Downloads/Documents/Pictures/etc directories created at boot. (I think this is more of a bug with Xfce itself... like I said previously, try avoiding using latest versions 4.14.xx, try using 4.12 if you can)
Just to avoid problems, I had created an additional user for me, just in case the stock Live Session user would not work, that user works fine too, but there's no Downloads/Documents/Pictures directories there either.
Any suggestions to workaround that would be welcomed.
That printf is supposed to convert the path string to octal (we can not put spaces in
/etc/fstabfile)
Line 388
Ok, so is there any consequence to not having that particular function working?
I was able to create a custom ISO with these errors and there doesn't seem to be any problems with it.
Or is that just to avoid problems DURING the process of creating the Chroot in the Host system? (and being able to RELEASE it back when you're done...)
Or is that just to avoid problems DURING the process of creating the Chroot in the Host system? (and being able to RELEASE it back when you're done...)
yes. It's necessary to create the chroot environment.
Well I don't understand, I was able to fully utilize the app and create the final ISO file even though there were errors with line 388. Okay then.
The program is working, as long as people reading this manually patch it or the author updates the files.
Manual patches depend on specific username of the distro you want to use, use with caution.
Here's the link again.
https://www.dropbox.com/sh/s61370wofadlny5/AAA6s0rjAz1QW9N1fJihYhBia?dl=0&lst=