MX Linux Forum

Posted: **Wed Mar 20, 2019 10:51 pm**

I had been having trouble creating a live usb from my Thinkpad x230 running Antix 17.4. It announced that it was done. But upon booting from that usb was getting a "vmlinuz not found" error. ( I had posted on this earlier).

Then I moved on to trying to create a live usb on my other machine W520 (running MX linux 18.1 ) using the same antix image and same stick. Worked flawlessly. So I figured there must be some issue with the actual usb port on that x230.
I tried all manner of things - to no avail. The puzzling thing was the usb port was otherwise working fine.

Then, today, I installed MX linux 18.1 on that same x230 and tried the same thing again. Success!

( as an aside, I also installed Antix 17.4 , 32 bit on an old thinkpad X40 - and created a live usb which all worked flawlessly).

Conclusion - there is some issue with antix17.4 - the 64 bit version in creating a working live usb - on my x230. Maybe it is the particular laptop - dont know.

Posted: **Thu Mar 21, 2019 1:35 am**

I'd like to figure out what went wrong. Have you looked at the output of dmesg after making a live-usb that will end up not to work? Often when a problem is dependent on hardware + kernel then clues show up in dmesg. But it is unlikely live-usb-maker would report success if there were IO errors.

The other thing to try is to mount the broken live-usb, cd to its antiX/ directory and run:

Code: Select all

md5sum -c *.md5

When I run that here I get:

Code: Select all

initrd.gz: OK
linuxfs: OK
vmlinuz: OK

If that is successful and/or if you can boot UEFI but not legacy then the problem could be due to file fragmentation. Newer versions of live-usb-maker (such as the one in antiX-17.4) automatically run e4defrag on the vmlinuz file but we don't throw a fatal error if that program is not found. You could try running:

Code: Select all

sudo e4defrag -v vmlinuz

in that same directory.

Posted: **Thu Mar 21, 2019 11:16 am**

OK I tried all that.
initrd.gz: OK
linuxfs: OK
vmlinuz: OK

Then I ran the sudo e4defrag -v vmlinuz and it completed successfully

Then tried rebooting off that usb. Same error "/antiX/vmlinuz:read error @ 4514592"

Posted: **Thu Mar 21, 2019 11:18 am**

What are the differences in the live-usb program versions in the latest MX versus the latest antiX - 64 bit?
( because this is all working perfectly with MX)

Posted: **Thu Mar 21, 2019 11:22 am**

I am primarily using MX on my modern 64 bit machines ( works fantastic). And antiX on my old X40 ( which works great- 75 MB ram after boot!! live-usb works fine too on this 32 bit machine).

But I am now intrigued by why there is this issue with antiX 64 bit. After all live-usb is probably the biggest and best feature of antiX - and if that is failing, presumably remastering will fail too.

Posted: **Thu Mar 21, 2019 11:28 am**

Would it be possible to use the same version of live-usb in antiX ( as in MX) ?

Posted: **Thu Mar 21, 2019 11:39 am**

Is that UEFI or BIOS (legacy) booting you have trouble with?

Posted: **Thu Mar 21, 2019 11:52 am**

Posted: **Thu Mar 21, 2019 11:57 am**

I just repeated the whole process - this is a repeatable problem.
Using a snapshot of antix system, sandisk flash, one laptop x230( with MX and antix installed)
- use live-usb maker on MX : usb boots up fine
- use live-usb-maker on antiX: usb fails to boot with that vmlinuz error.

Posted: **Thu Mar 21, 2019 12:01 pm**

rs55 wrote: Thu Mar 21, 2019 11:28 am Would it be possible to use the same version of live-usb in antiX ( as in MX) ?

live-usb-maker is exactly the same version on MX and antiX.

***edit*** the kernels are different between antiX and MX though.

Posted: **Thu Mar 21, 2019 12:03 pm**

Have you tried different USB ports - different USB-sticks? (Hint: power-supply and consumption differs on sticks and ports)
Have you tried also with dd-live-usb?
Probably also a good idea to show Quick System Info ( inxi -Fxrz) from the problematic system.

Posted: **Thu Mar 21, 2019 12:08 pm**

I had already looked at the version in antiX-17.4 and it was up to date along with the cli-shell-utils library. That read error really looks like a fragmentation problem. Running e4defrag should have fixed it. The problem seems to be that we are getting fragmentation that can't be fixed which prevents syslinux from reading the vmlinuz file.

The only other trick I have is to try the --force=nofuse option with the command line live-usb-maker program. I

We started seeing fragmentation errors after we started using fuseiso to mount the iso file. We fixed this in two ways, first we used cpio to copy the files to the new live-usb and then we also run e4defrag on vmlinuz. This is a subtle error. The files are getting copied correctly but timing issues change where on the "physical" device they get written.

I chose to always use fuseiso, not just when we need it so we would be more likely to catch errors like this.

AHA! antiX and MX use different versions of fuseiso so I think using --force=nofuse may fix it.

AntiX uses fuseiso-20070708-3.2+b1 while MX uses fuseiso9660-0.3-1.1+b1

Posted: **Thu Mar 21, 2019 12:17 pm**

Turns out the executables in those two packages have different names "fuseiso" versus "fuseiso9660" but we were only looking for "fuseiso" so it was not being used at all in MX. Therefore the --force=nofuse should fix it in antiX.

Posted: **Thu Mar 21, 2019 12:29 pm**

kernels:
antix: 4.9.....
mx : liquorix 5.0........

Posted: **Thu Mar 21, 2019 12:46 pm**

You nailed it!
Running the cli version with --force=nofuse from antiX did the trick.

So- now I have a question:
If the only reason the live-usb was working in MX was because of a "bug" where it was asking for fuseio9660 rather than the correct name - just fuseio, is it likely this will get "fixed" in an mx update - which will cause that to also not work !!

I would like to bake this "nofuse" into the gui version - because I am now worried that using a live usb with persistence turned on and doing occasional remasters is going to fail in mx ??

Posted: **Thu Mar 21, 2019 1:13 pm**

In my antix, I uninstalled fuseiso and installed fuseiso9660. And now the gui works as well !!

So - now - I understand it is only working because the live-usb-maker is looking to run fuseio and failing to find it !

I dont understand all the details behind this fuseiso business, but live-iso is a critical part of mx and antix, so please dont run fuseiso just to experiment . At least not in the published versions of mx and antix.

Posted: **Thu Mar 21, 2019 1:13 pm**

rs55 wrote: Thu Mar 21, 2019 12:46 pm You nailed it!
Running the cli version with --force=nofuse from antiX did the trick.

So- now I have a question:
If the only reason the live-usb was working in MX was because of a "bug" where it was asking for fuseio9660 rather than the correct name - just fuseio, is it likely this will get "fixed" in an mx update - which will cause that to also not work !!

I would like to bake this "nofuse" into the gui version - because I am now worried that using a live usb with persistence turned on and doing occasional remasters is going to fail in mx ??

I'm seeing the same only with the gui live-usb-maker-gui-antix on antiX. The cli app (live-usb-maker) works ok without --force=nofuse

Posted: **Thu Mar 21, 2019 2:01 pm**

rs55 wrote: Thu Mar 21, 2019 12:46 pm I would like to bake this "nofuse" into the gui version - because I am now worried that using a live usb with persistence turned on and doing occasional remasters is going to fail in mx ??

Don't reacall fuseiso is used during remaster.

rs55 wrote: Thu Mar 21, 2019 1:13 pm I dont understand all the details behind this fuseiso business, but live-iso is a critical part of mx and antix, so please dont run fuseiso just to experiment . At least not in the published versions of mx and antix.

There was a reason to introduce additonaly fuseiso, as within other situations live-usb-maker would fail without fuseiso, related to issue of loop-mounts on overlays mounted filesystems.
So it was rarely reported that fuseiso fail, we might consider to default / preselect to most appropriate alternative, imho.

Posted: **Thu Mar 21, 2019 2:18 pm**

Other than live-usb-maker , what other apps are using fuseiso?
I ask, because , if I uninstall it ( which makes live-usb work for me), i wonder if something else is going to break?

Posted: **Thu Mar 21, 2019 2:23 pm**

rs55 wrote: Thu Mar 21, 2019 2:18 pm Other than live-usb-maker , what other apps are using fuseiso?
I ask, because , if I uninstall it ( which makes live-usb work for me), i wonder if something else is going to break?

If something breaks when you remove it, then that package should declare fuseiso as a dependency.

Posted: **Thu Mar 21, 2019 2:24 pm**

rs55 wrote: Thu Mar 21, 2019 2:18 pm .. i wonder if something else is going to break?

It will be fine to run without fuseiso. Don't think it will break anythink if you dont have fuseiso, unless you try to run live-usb-maker on a gvfs-fuse mounted network share, which might break loop-mounts...

Posted: **Thu Mar 21, 2019 2:28 pm**

Thanks - thats great .

Posted: **Thu Mar 21, 2019 2:55 pm**

anticapitalista wrote: Thu Mar 21, 2019 1:13 pm
rs55 wrote: Thu Mar 21, 2019 12:46 pm You nailed it!
Running the cli version with --force=nofuse from antiX did the trick.

So- now I have a question:
If the only reason the live-usb was working in MX was because of a "bug" where it was asking for fuseio9660 rather than the correct name - just fuseio, is it likely this will get "fixed" in an mx update - which will cause that to also not work !!

I would like to bake this "nofuse" into the gui version - because I am now worried that using a live usb with persistence turned on and doing occasional remasters is going to fail in mx ??
I'm seeing the same only with the gui live-usb-maker-gui-antix on antiX. The cli app (live-usb-maker) works ok without --force=nofuse

We use the "gui" command when calling lum from the gui. Maybe the defaults under that switch are different from those at the standard command line.

Posted: **Thu Mar 21, 2019 5:08 pm**

rs55 wrote: Thu Mar 21, 2019 2:18 pm Other than live-usb-maker , what other apps are using fuseiso?
I ask, because , if I uninstall it ( which makes live-usb work for me), i wonder if something else is going to break?

Remove it, nothing will break (as far as we know)
Next bugfix upgrade of live-usb-maker-gui-antix will force an install of fuseiso9660 and remove fuseiso.

Thanks for your report - and fix.

Posted: **Thu Mar 21, 2019 6:28 pm**

rs55 wrote: Thu Mar 21, 2019 1:13 pm In my antix, I uninstalled fuseiso and installed fuseiso9660. And now the gui works as well !!

So - now - I understand it is only working because the live-usb-maker is looking to run fuseio and failing to find it !

I dont understand all the details behind this fuseiso business, but live-iso is a critical part of mx and antix, so please dont run fuseiso just to experiment . At least not in the published versions of mx and antix.

@rs55 We have had many many more failures reported due to not using fuseiso. So far we have only your failure using it.

If you don't mind, please run a test for us to see if fuseiso9660 works. Please make the following change to /usr/local/lib/cli-shell-utils/cli-shell-utils.bash. Change line 2493 to:

Code: Select all

    local prog=fuseiso9660

IOW change "fuseiso" to "fuseiso9660". Make another live-usb without using "---force=nofuse" and see if it works. Also, please doublecheck in the /var/log/live-usb-maker.log file to make sure you session (near the end of the file) has a line that says something like:

Code: Select all

Mount some-iso-file with isofuse9660

I really want to know if this fixes the problem or not. I would also like to see the output of:

Code: Select all

sudo lspci -nvv

on the problem system. Perhaps attach it as a file or email it to me at <my-user-name>@gmail.com.

If using fuseiso9660 does not fix the problem then I have one other thing I would like to try.

We were VERY sure we had fixed the fragmentation problem. We had incorporated 3 different fixes even without the --force flag. But I added --force=nofuse just in case we were wrong. It is true that I also experimented by making using fuseiso the default. The reason for this was so we could catch rare problems like yours sooner.

If we had only used fuseiso when it was needed then:

1) It probably would have been several years before we found a problem, all the while assuming fuseiso was solid.

2) It would have been inconvenient for the user who had the problem to test solutions because they would not be able to read the iso file without fuseiso!

I am delighted you like our live system! I've spent the last 8 or 9 years developing it. We are really trying to do the greatest good for the greatest number of people. Also, as soon as you told us the actual error message we were quickly able to zero in on the problem and the solution. I'm sorry you had to go through this but your efforts will help many other people in the future. Thank you for you help! We depend upon users like you to help us improve our software. I personally have four different test machines and all told our development team probably tests on 50 to 100 machines. But we can't test on every possible system so we rely on help from the users. So thank you again.

Posted: **Thu Mar 21, 2019 7:26 pm**

BitJam:
Thanks. OK I did everything you suggested. I changed the /usr/local/lib/cli-shell-utils/cli-shell-utils.bash line to.fusiso9660. Ran lum (without the --force flag) -and the usb failed with the same error.
I did check the log file and indeed it had that mount line for fuseiso9660.
I have attached the output of lscpi -nvv to this response.

You have created a fabulous operating system- and I have been involved with computers since 1972 !! ( have'nt done any engineering work in three decades though ).

Let me know if you want me to try anything else. best regards.

Posted: **Thu Mar 21, 2019 7:35 pm**

Seems that the fix is to use fuseiso9660 and not fuseiso. (make sure fuseiso is removed)

I did this and both live-sub-maker (gui and cli) both work (on antiX)

Posted: **Thu Mar 21, 2019 7:42 pm**

fuseiso9660 failed in my machine - see post above.

Posted: **Thu Mar 21, 2019 7:49 pm**

Thanks rs55!

Can you tell me the output when you run:

Code: Select all

sudo e4defrag -v vmlinuz

on the live-usb?

I started coding professionally in the early 70s. This is one of the top 10 strangest problems I've seen. Some subtle change in timing is causing fragmentation when we copy from an iso that was mounted with fuseiso.

I'm working on another fix I would like you to test.

Posted: **Thu Mar 21, 2019 7:52 pm**

I had previously uninstalled fuseiso from the system. Now I also unistalled fuseiso9660. And now the lum works great again.

Posted: **Thu Mar 21, 2019 7:59 pm**

ran sudo e4defrag -v vmlinuz :
"success"

Posted: **Thu Mar 21, 2019 8:06 pm**

A I mentioned way back- lum was working fine with mxlinux ( which has the 9660 installed)- on the same machine. So clearly mx is doing something else that is allowing it to work fine with the fuseiso9660.

Posted: **Thu Mar 21, 2019 8:52 pm**

If you don't mind, please re-install one of those so you can test the fix I am preparing for you. Thanks!

Posted: **Thu Mar 21, 2019 8:57 pm**

ok reinstalling the 9660

Posted: **Fri Mar 22, 2019 1:47 am**

It's been a long day for me. I will try to get something for you to try tomorrow. I've got it working here but I want to tie it up nicely.

In the meantime, another little experiment to try is to comment out the line:

Code: Select all

    set_dirty_bytes

around line 2836 in /usr/local/lib/cli-shell-utils/cli-shell-utils.bash in the set_dirty_bytes() routine. This will cause the progress bar to rush to the end well before the files are all copied but it might have a positive effect on the fragmentation.

Posted: **Fri Mar 22, 2019 12:03 pm**

Oh - I'll try that. Which reminds me - I had changed a few parameters in sysctl relating to dirty bytes because my flash drive was taking extraordinarily long to unmount. This is what I changed:
vm.dirty_bytes= 600000000 ( 600MB)
vm.dirty_background_bytes=300000000 ( 300 MB)

I wonder if that was also playing into this lum issue.

I any event - last night I ran a dist-upgrade ( it installed over 1000 packages !) and it borked the machine ( I had originally chosen the testing branch at initial install of antix) . So I reinstalled from my live-usb and changed the repositories to stretch -( to avoid this upgrade in the future).
I had to temporarily re-enable debian-testing repo to get fuseiso9660 installed again. Now, lum is not even completing - it gives an error at creation time- with fuseiso9660 installed. ( works great with fuseiso9660 uinstalled)

It seems this fuseiso is not even there in the stretch branch .? ( only in debian-testing ?)

It seems the best strategy is to reinstall from scratch - choose the stretch install. Then only temporarily change the repo to debian-testing to install a handful of packages that are not in stretch. Is this safe? Or will those testing repo - apps have dependencies unmet in future upgrades from stretch.

Posted: **Fri Mar 22, 2019 1:12 pm**

rs55 wrote: Fri Mar 22, 2019 12:03 pm It seems this fuseiso is not even there in the stretch branch .? ( only in debian-testing ?)

Both are in stretch/stable:

Code: Select all

apt policy fuseiso*
fuseiso:
  Installed: 20070708-3.2+b1
  Candidate: 20070708-3.2+b1
  Version table:
 *** 20070708-3.2+b1 500
        500 http://ftp.de.debian.org/debian stretch/main amd64 Packages
        100 /var/lib/dpkg/status
fuseiso9660:
  Installed: (none)
  Candidate: 0.3-1.1+b1
  Version table:
     0.3-1.1+b1 500
        500 http://ftp.de.debian.org/debian stretch/main amd64 Packages

You would need to fix the recent keyring issue for antix like this:

Code: Select all

sudo apt update

You'll get some keyring expire warnings.

Code: Select all

apt download --print-uris antix-archive-keyring
'http://ftp.halifax.rwth-aachen.de/mxlinux/packages/antix/stretch/pool/main/a/antix-archive-keyring/antix-archive-keyring_20019.3.13_all.deb'
antix-archive-keyring_20019.3.13_all.deb 19074
SHA256:5aabdf90fb48643e168646e39999ab95ae4526ea43879a1e812b4d27283f537c

Youl copy the URL and fetch with wget the keyring package directly:

Code: Select all

wget http://ftp.halifax.rwth-aachen.de/mxlinux/packages/antix/stretch/pool/main/a/antix-archive-keyring/antix-archive-keyring_20019.3.13_all.deb
--2019-03-22 17:39:50--  http://ftp.halifax.rwth-aachen.de/mxlinux/packages/antix/stretch/pool/main/a/antix-archive-keyring/antix-archive-keyring_20019.3.13_all.deb
Resolving ftp.halifax.rwth-aachen.de (ftp.halifax.rwth-aachen.de)... 137.226.34.46, 2a00:8a60:e012:a00::21
Connecting to ftp.halifax.rwth-aachen.de (ftp.halifax.rwth-aachen.de)|137.226.34.46|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 19074 (19K) [application/octet-stream]
Saving to: ‘antix-archive-keyring_20019.3.13_all.deb’

You shall verfiy the SHA256SUM listed above with the output of this command:

Code: Select all

sha256sum antix-archive-keyring_20019.3.13_all.deb
5aabdf90fb48643e168646e39999ab95ae4526ea43879a1e812b4d27283f537c  antix-archive-keyring_20019.3.13_all.deb

You install the downloaded keyring:

Code: Select all

sudo apt install ./antix-archive-keyring_20019.3.13_all.deb

and refresh the apt-package list again:

Code: Select all

sudo apt update

HTH

Posted: **Fri Mar 22, 2019 2:16 pm**

BitJam wrote: Fri Mar 22, 2019 1:47 am It's been a long day for me. I will try to get something for you to try tomorrow. I've got it working here but I want to tie it up nicely.

In the meantime, another little experiment to try is to comment out the line:
Code: Select all
    set_dirty_bytes
around line 2836 in /usr/local/lib/cli-shell-utils/cli-shell-utils.bash in the set_dirty_bytes() routine. This will cause the progress bar to rush to the end well before the files are all copied but it might have a positive effect on the fragmentation.

OK - I did a clean install of antix, using stretch this time ! Checked that fuseiso was installed - it was. Then I installed a few apps. Then used lum to flash my usb flash device. Got that vmlinuz error on boot from usb.
Then I went back in and commented out the set-dirty-bytes line as you suggested. No luck - stil getting that same vmlinuz error on boot.
I will uninstall fuseiso for now - pending any further advice from you. Thanks.

Posted: **Fri Mar 22, 2019 2:32 pm**

On antiX, add the word dev to the /etc/apt/sources.list.d/antix.list so it reads

deb http://repo.antixlinux.com/stretch stretch main nosystemd nonfree dev

Code: Select all

apt-get update && apt-get dist-upgrade

This will install a bugfix version of lum (gui) and force removal of fuseiso (if installed) and it will install fuseiso9660

This creates a bootable live usb on my antiX-17 box.

Posted: **Fri Mar 22, 2019 2:48 pm**

Just to add - the problem app seems to be fuseiso.
With it installed, we get the vmlinuz error.
Without it (and also with or without fuseiso9660), both lum gui and lum cli work as they should.

Posted: **Fri Mar 22, 2019 3:16 pm**

anticapitalista wrote: Fri Mar 22, 2019 2:48 pm Just to add - the problem app seems to be fuseiso.
With it installed, we get the vmlinuz error.
Without it (and also with or without fuseiso9660), both lum gui and lum cli work as they should.

@anti, rs55's system has trouble with *both* fuseiso and fuseiso9660. I'm working on a fix in cli-shell-utils that will copy and defrag the vmlinuz file (and then initrd.gz) before anything else gets copied. If this still doesn't work then I may have to only use fuseiso (or fuseiso9660) when it is needed and accept that on a few systems (ones like rs55's that *also* need fuseiso to mount the iso file) we will be unable to make a working live-usb. The fuse mounting seems to work fine on most systems. AFAIK, rs55 has the only system we know of that has a problem with it.

@rs55, thank you for trying the dirty_bytes solutions. I would have been surprised if it worked. I plan to have a new version for you to test soon that has the fix I mentioned above.

Posted: **Fri Mar 22, 2019 3:21 pm**

my experience was that both fuseiso and fuseiso9660 cause the same problem.

Obviously if lum is invoking fuseiso and the system only has fuseiso9660 installed - it does'nt get executed - so it works.
But if you change lum to invoke fuseiso9660 , then the same problem occurs.

Posted: **Fri Mar 22, 2019 3:25 pm**

since my problem seems to be unique - maybe it would be helpful if I gave you the specs of my system:
thinkpad x230
core i5 processor, 8 GB ram
nothing else particularly unique about it. its a great machine - I have 2 of them, well actually three , if you count my beloved x220 !

Posted: **Fri Mar 22, 2019 3:28 pm**

BitJam wrote: Fri Mar 22, 2019 3:16 pm
anticapitalista wrote: Fri Mar 22, 2019 2:48 pm Just to add - the problem app seems to be fuseiso.
With it installed, we get the vmlinuz error.
Without it (and also with or without fuseiso9660), both lum gui and lum cli work as they should.
@anti, rs55's system has trouble with *both* fuseiso and fuseiso9660. I'm working on a fix in cli-shell-utils that will copy and defrag the vmlinuz file (and then initrd.gz) before anything else gets copied. If this still doesn't work then I may have to only use fuseiso (or fuseiso9660) when it is needed and accept that on a few systems (ones like rs55's that *also* need fuseiso to mount the iso file) we will be unable to make a working live-usb. The fuse mounting seems to work fine on most systems. AFAIK, rs55 has the only system we know of that has a problem with it.

@rs55, thank you for trying the dirty_bytes solutions. I would have been surprised if it worked. I plan to have a new version for you to test soon that has the fix I mentioned above.

BitJam: Really appreciate your spending so much effort on this issue. Is'nt the simple solution to simply unistall fuseiso , as I have done? Everything seems to work fine so far, without that installed.
Obviously, I would need to keep an eye out for any future upgrades that reinstall a version fo fuseiso - that would be a bit of a nuisance.

Posted: **Fri Mar 22, 2019 4:46 pm**

rs55 - please try what I posted further up ie bugfix because I had the exact same vmlinuz issue and the fix 'fixed' it.

Posted: **Fri Mar 22, 2019 5:04 pm**

rs55 wrote: Fri Mar 22, 2019 3:28 pmBitJam: Really appreciate your spending so much effort on this issue. Is'nt the simple solution to simply unistall fuseiso , as I have done? Everything seems to work fine so far, without that installed.

I realize that would work for you but previously we had more failures reported because we need to use fuseiso in order to mount the iso file when it resides on certain file systems. People had been complaining that live-usb-maker doesn't work because it can't mount the iso file. We fixed that by adding fuseiso. The ideal solution will be if I can fix your problem so everyone can use fuseiso and no one has the fragmentation issue. If I/we can't fix this then there will be some system where LUM simply does not work. That would make me sad. :(

Posted: **Fri Mar 22, 2019 5:28 pm**

I have attached rs55-test-LUM-01.tgz. It contains a modified live-usb-maker and a modifed cli-shell-utils.bash library. Instructions:

Code: Select all

tar xzf rs55-test-LUM-01.tgz
cd  rs55-test-LUM-01/live-usb-maker
./live-usb-maker --version

You should see:

Code: Select all

$ ./live-usb-maker --version                      
      live-usb-maker version 2.22.02 (Fri Mar 22 15:10:48 MDT 2019)
     cli-shell-utils version 2.20.05 (Fri Mar 22 15:13:14 MDT 2019)

This tells you the latest LUM and latest lib are both being used.

Please make sure fuseiso or fuseiso9660 is installed (so we can see if the problem has been fixed). Then use this version to make a live-usb and see if it boots. It will now tell you on the screen if fuseiso or fuseiso9660 was used. That information will also be in the log file.

The output of e4defrag will be in the log file too. Look for a line like this:

Code: Select all

[1/1][1/1]./antiX/vmlinuz:	  0%[1/1]./antiX/vmlinuz:	100%  extents: 2 -> 1	[ OK ]

The key thing is the "2 -> 1" which means the file was fixed and is now no longer fragmented.

If this doesn't fix the problem then I will be sad. :(

Posted: **Fri Mar 22, 2019 5:48 pm**

Thanks, I just downloaded and ran it. At the end of the creation process, it gave an error "could not find syslinux or isolinux directory"

Posted: **Fri Mar 22, 2019 5:53 pm**

FYI: I downloaded the tar file to my Downloads folder , extracted it there and ran it from there.

I dont know it it expects to be run from a different directory - and thats the reason for the error?

Posted: **Fri Mar 22, 2019 5:56 pm**

rs55 wrote: Fri Mar 22, 2019 5:48 pm Thanks, I just downloaded and ran it. At the end of the creation process, it gave an error "could not find syslinux or isolinux directory"

I got the same.

Posted: **Fri Mar 22, 2019 6:06 pm**

Thanks guys! Sorry for the problem. I'll look into it.

Posted: **Fri Mar 22, 2019 6:08 pm**

anticapitalista wrote: Fri Mar 22, 2019 4:46 pm rs55 - please try what I posted further up ie bugfix because I had the exact same vmlinuz issue and the fix 'fixed' it.

bump bump bump

Posted: **Fri Mar 22, 2019 6:17 pm**

anticapitalista wrote: Fri Mar 22, 2019 6:08 pm
anticapitalista wrote: Fri Mar 22, 2019 4:46 pm rs55 - please try what I posted further up ie bugfix because I had the exact same vmlinuz issue and the fix 'fixed' it.
bump bump bump

Sorry - I ve been trying so many things - losing track! Yes installing fuseiso9660 ( as you suggested) does fix the problem. But as discussed earlier in this thread, thats only because lum is looking for fuseiso , and when it does'nt find it, it does'nt run it - and so neither fuseiso or fuseiso9660 were getting run. So it worked.
I dont have an immediate issue - because simply uninstalling fuseiso does the trick. But I think BitJam is trying to figure out how to have lum run fuseiso and still work on my machine( because many other users seem to need fuseiso for lum to work).

Posted: **Fri Mar 22, 2019 6:22 pm**

Did you install the updated live-usb-maker-gui-antix db from the dev repo as I posted? If so, does the gui app now produce a bootable live usb? Same for cli lum?

If so, then the problem (as I have said many times) is the existence of fuseiso. (not fuseiso9660).

Therefore, we (Bitjam) need to remove fuseiso from our scripts and use fuseiso9660 instead.

Posted: **Fri Mar 22, 2019 6:38 pm**

anticapitalista wrote: Fri Mar 22, 2019 6:22 pm Did you install the updated live-usb-maker-gui-antix db from the dev repo as I posted? If so, does the gui app now produce a bootable live usb? Same for cli lum?

If so, then the problem (as I have said many times) is the existence of fuseiso. (not fuseiso9660).

Therefore, we (Bitjam) need to remove fuseiso from our scripts and use fuseiso9660 instead.

oh - I did'nt try your gui. I will. yesterday, I had installed fuseiso9660 and changed a line in the cli-shell-utils.bash to local prog = fuseiso9660. That failed. I dont know if your gui app essentially does that - or something else. I'll try it and report back.

Posted: **Fri Mar 22, 2019 7:00 pm**

anticapitalista wrote: Fri Mar 22, 2019 2:32 pm On antiX, add the word dev to the /etc/apt/sources.list.d/antix.list so it reads

deb http://repo.antixlinux.com/stretch stretch main nosystemd nonfree dev
Code: Select all
apt-get update && apt-get dist-upgrade
This will install a bugfix version of lum (gui) and force removal of fuseiso (if installed) and it will install fuseiso9660

This creates a bootable live usb on my antiX-17 box.

anticapitalista:
I got your gui package from dev. It ran great. produced a bootable usb. And I checked that fuseiso9660 continued to be installed ( I had already manually installed it earlier). Great! Nice work.
Hope this - or some variant of it makes it into the stable channel down the road.

Posted: **Fri Mar 22, 2019 7:02 pm**

actually - this fix needs to go into the stable channel with some urgency. because the current stable download fails - at least on my system. That is a pretty big bug - on the most amazing feature of antiX - the live-usb system.

Posted: **Fri Mar 22, 2019 7:10 pm**

Can you tell us what that gui does? is it calling the lum --force=nofuse ? Well, if you are actually installing fudeiso9660, it would'nt make much sense to then have it not called - I suppose !!
Quite curious how you fixed it.

Posted: **Fri Mar 22, 2019 7:15 pm**

I was unable to replicate the "could not find syslinux or isolinux directory" problem running on a live version of antiX-17.4. I also didn't have the problem on my development machine when I ran from the unpacked tarball. I tried it again inside an X-windows terminal in antiX-17.4 and it still worked even though the efi partition and sometimes the main partition got automounted while LUM was running.

If you are running in antiX, try using the --force=automount option to disable antiX automounting while the program runs.

I have no idea why the changes I made would affect the part of the code where you got the error message but it could be a timing issue that lets automount "steal" my partitions. While I was running LUM, in another terminal window I also ran:

Code: Select all

watch -n .2 df -Th

to see what was mounted and what was not. It appeared that without --force=automount, the mountpoint at /run/live-usb-maker/main could disappear which could cause a problem if I'm trying to install the bootloader.

ISTM that in addition to being over-aggressive, the automounting is broken. I would often end up with mountpoints at both /media/antiX-uefi and /media-antiX-uefi-2 for the same partition.

If automounting is causing the problem I could fix it on antiX by reversing the sense of --force=automount but that won't fix it on other systems such as MX. But maybe it is not a problem on other system.

Another solution would be to add delays to give the automount programs a chance to steal my partition and then I could --bind mount from there. I could also try to stop using partprobe after I've changed the partitioning but that can confuse the system and prevent *me* from mounting the new partitions.

Posted: **Fri Mar 22, 2019 7:39 pm**

Once more unto the breach, dear friends, once more

This is the same as before but I changed the sense of --force=automount so automounting is disabled by default on antiX. I also added a 2 second delay (*sigh*) between when I create the new partitions and when I grab them back from the automounter. You could test this by using --force=automount which will now allow antiX automounting while we are running.

But the first priority is to see if this new code fixes the fragmentation problem on rs55's system when fuseiso and/or fuseiso9660 is used.

Posted: **Fri Mar 22, 2019 8:21 pm**

BitJam:
Sorry to report your new file did'nt work either. Same issue- "could not find a syslinux or isolinux directory".

Anticapitalista's gui program worked. Why not see how he did t? Iam curious too.

Posted: **Fri Mar 22, 2019 9:08 pm**

rs55 wrote: Fri Mar 22, 2019 8:21 pm BitJam:
Sorry to report your new file did'nt work either. Same issue- "could not find a syslinux or isolinux directory".

It runs here without an issue.
I have invoked it with giving parameter -f iso-file,
where iso-file is just symlink from my antiX-ISO folder somwhere else:
Extracted and run from command line: - and it boots also fine...
I've fuseiso installed.

Code: Select all

$ sudo ./live-usb-maker -f antiX-17.4_x64-full.iso
========================================================================
Starting live-usb-maker
========================================================================
Only one target usb device was found sdg
Will use target device sdg (28.9G USB DISK 3.0)

Please select what action to perform
  = Make a full-featured live-usb
  > Make an encrypted full-featured live-usb
  > Make a customized live-usb (includes encryption option)
  > Other options
Press <Enter> to select the highlighted entry
Use 'h' for help, 'r' to redraw, 'q' to quit
Mount antiX-17.4_x64-full.iso with fuseiso

Will use source file antiX-17.4_x64-full.iso
Distro: antiX-17.4_x64-full Helen Keller 6 March 2019
Found grub config 1.0

                  Total    Used   Extra
   entire drive  29,584  29,583       1  MiB
 main partition  29,533     996  28,537  MiB
 uefi partition      50      12      38  MiB

------------------------------------------------------------------------
Ready to make live-usb on device sdg
... by copying file antiX-17.4_x64-full.iso
------------------------------------------------------------------------

Shall we begin?
  = yes
  > no
  > pretend mode
Press <Enter> to select the highlighted entry
Use 'h' for help, 'r' to redraw, 'q' to quit
>> partition-clear
>> partition-make
Using msdos partitioning
Wait for automounting ...
>> makefs-bios
>> makefs-uefi

Filesystem     Type  Size  Used Avail Use% Mounted on
/dev/sdg1      ext4   29G   44M   29G   1% main
/dev/sdg2      vfat   50M     0   50M   0% uefi

>> copy-uefi
copy from iso to uefi partition
files: [Ee][Ff][Ii] boot/{grub,uefi-mt} version
Fix Dell uefi memtest bug
>> copy-main
copy from iso to main partition
copy ./antiX/vmlinuz
copy ./antiX/initrd.gz
Copy remaining files ...
|===================================================================>100%
>> uuids
>> install
extlinux version 6.03

Filesystem     Type  Size  Used Avail Use% Mounted on
/dev/sdg1      ext4   29G  996M   28G   4% main
/dev/sdg2      vfat   50M   13M   38M  26% uefi

>> done

live-usb-maker took one minute and 21 seconds.

Posted: **Fri Mar 22, 2019 9:19 pm**

rs55 wrote: Fri Mar 22, 2019 8:21 pmAnticapitalista's gui program worked. Why not see how he did t? Iam curious too.

His program just calls an earlier version of my program.

Posted: **Fri Mar 22, 2019 9:46 pm**

Another thing to try is to try to just redo the installation step after it fails:

Code: Select all

sudo ./live-usb-maker install

Whether this works or continues to fail, I'd really like to see /var/log/live-usb-maker.log from when it fails.

Posted: **Fri Mar 22, 2019 10:41 pm**

BitJam wrote: Fri Mar 22, 2019 7:39 pm Once more unto the breach, dear friends, once more

This is the same as before but I changed the sense of --force=automount so automounting is disabled by default on antiX. I also added a 2 second delay (*sigh*) between when I create the new partitions and when I grab them back from the automounter. You could test this by using --force=automount which will now allow antiX automounting while we are running.

But the first priority is to see if this new code fixes the fragmentation problem on rs55's system when fuseiso and/or fuseiso9660 is used.

I'm seeing this on my MX system with your version 2 code

Code: Select all


┌─[dolphin@mx]─[10:28:04 pm]─────────────────────────────[~/Desktop/rs55-test-LUM-02/live-usb-maker]
└─> sudo ./live-usb-maker 
[sudo] password for dolphin: 
===============================================================================
Starting live-usb-maker
===============================================================================
Only one target usb device was found sdc
Will use target device sdc (28.7G SanDisk Ultra)
                                                                                                  
Please select what action to perform                                                              
  = Make a full-featured live-usb                                                                 
  > Make an encrypted full-featured live-usb                                                      
  > Make a customized live-usb (includes encryption option)                                       
  > Other options                                                                                 
Press <Enter> to select the highlighted entry                                                     
Use 'h' for help, 'r' to redraw, 'q' to quit                                                      
                                                                                                  
Please select the source for the new live-usb                                                     
  = Copy from an ISO file                                                                         
Press <Enter> to select the highlighted entry                                                     
Use 'h' for help, 'r' to redraw, 'q' to quit                                                      
Please enter the filename                                                                         
(tab completion is enabled)
/home/dolphin/development/mx_release/MX-18.1_x64.iso
You entered: /home/dolphin/development/mx_release/MX-18.1_x64.iso                                                                                                                                     
Is this correct?                                                                                  
  = yes                                                                                           
  > no                                                                                            
Press <Enter> to select the highlighted entry                                                     
Use 'h' for help, 'r' to redraw, 'q' to quit                                                      
Mount /home/dolphin/development/mx_release/MX-18.1_x64.iso with fuseiso9660                       

                                                                                                  
Check md5 of the file ?                                                                           
  > yes                                                                                           
  = no                                                                                            
Press <Enter> to select the highlighted entry                                                     
Use 'h' for help, 'r' to redraw, 'q' to quit                                                      
Will use source file /home/dolphin/development/mx_release/MX-18.1_x64.iso                         
Distro: MX-18.1_x64 Continuum Feb 9, 2019
Found grub config 1.0

                  Total    Used   Extra
   entire drive  29,328  29,327       1  MiB
 main partition  29,277   1,421  27,856  MiB
 uefi partition      50      10      40  MiB

-------------------------------------------------------------------------------
Ready to make live-usb on device sdc
... by copying file /home/dolphin/development/mx_release/MX-18.1_x64.iso
-------------------------------------------------------------------------------
                                                                                                  
Shall we begin?                                                                                   
  = yes                                                                                           
  > no                                                                                            
  > pretend mode                                                                                  
Press <Enter> to select the highlighted entry                                                     
Use 'h' for help, 'r' to redraw, 'q' to quit                                                      
>> partition-clear                                                                                
>> partition-make
Using msdos partitioning
Wait for automounting ...
>> makefs-bios
>> makefs-uefi

Filesystem     Type  Size  Used Avail Use% Mounted on
/dev/sdc1      ext4   29G   44M   29G   1% main
/dev/sdc2      vfat   50M     0   50M   0% uefi

>> copy-uefi
copy from iso to uefi partition
files: [Ee][Ff][Ii] boot/{grub,uefi-mt} version
Fix Dell uefi memtest bug
>> copy-main
copy from iso to main partition
copy 
copy 
Copy remaining files ...
|=============================================================================================>100%
>> uuids
Warning: Could not find grub.cfg file on EFI
>> install
extlinux version 6.03
./live-usb-maker: line 2220: cd: /run/live-usb-maker/main/syslinux: No such file or directory
Error: Could not find a syslinux or isolinux directory

live-usb-maker took 2 minutes and 56 seconds.

and live-usb-maker.log

Code: Select all

=====================================================================
./live-usb-maker 
        program: live-usb-maker
        started: Fri Mar 22 22:28:13 EDT 2019
        version: 2.22.03 (Fri Mar 22 17:22:48 MDT 2019)
         kernel: 4.19.0-1-amd64
             OS: MX 18 (Continuum)
      found lib: /home/dolphin/Desktop/rs55-test-LUM-02/cli-shell-utils/cli-shell-utils.bash
    lib version: 2.20.05 (Fri Mar 22 15:13:14 MDT 2019)
---------------------------------------------------------------------

Found man page: live-usb-maker.1
Only one target usb device was found sdc
Will use target device sdc (28.7G SanDisk Ultra)
Mount /home/dolphin/development/mx_release/MX-18.1_x64.iso with fuseiso9660

Will use source file /home/dolphin/development/mx_release/MX-18.1_x64.iso
Distro: MX-18.1_x64 Continuum Feb 9, 2019
Found grub config 1.0
Estimated extfs overhead for 29277M is 44M

                  Total    Used   Extra
   entire drive  29,328  29,327       1  MiB
 main partition  29,277   1,421  27,856  MiB
 uefi partition      50      10      40  MiB


=====> Ready to make live-usb on device sdc
... by copying file /home/dolphin/development/mx_release/MX-18.1_x64.iso

>> partition-clear
 > dd status=none if=/dev/zero of=/dev/sdc bs=1K count=17
 > dd status=none if=/dev/zero of=/dev/sdc bs=1K count=17 seek=32
 > dd status=none conv=notrunc if=/dev/zero of=/dev/sdc bs=1K count=17 seek=30031855
 > partprobe /dev/sdc

>> partition-make
Using msdos partitioning
 > parted --script --align optimal /dev/sdc unit MiB mklabel msdos
 > dd status=none if=/dev/zero of=/dev/sdc seek=1024 bs=1K count=128
 > parted --script --align optimal /dev/sdc unit MiB mkpart primary ext4 1 29277
 > dd status=none if=/dev/zero of=/dev/sdc seek=29979648 bs=1K count=128
 > parted --script --align optimal /dev/sdc unit MiB mkpart primary fat32 29277 29327
 > parted --script --align optimal /dev/sdc unit MiB set 1 boot on set 2 esp on
 > partprobe /dev/sdc
Wait for automounting ...
 > wait_for_file /dev/sdc1

>> makefs-bios
 > mkfs.ext4 -O ^64bit -m0 -i100000 -J size=32 /dev/sdc1
mke2fs 1.43.4 (31-Jan-2017)
64-bit filesystem support is not enabled.  The larger fields afforded by this feature enable full-strength checksumming.  Pass -O 64bit to rectify.
Creating filesystem with 7494656 4k blocks and 307776 inodes
Filesystem UUID: 346bd3b2-58c9-40ca-9a56-02f67adfb278
Superblock backups stored on blocks: 
	32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
	4096000

Allocating group tables:   0/229       done                            
Writing inode tables:   0/229       done                            
Creating journal (8192 blocks): done
Writing superblocks and filesystem accounting information:   0/229       done

 > tune2fs -L MX-Live-usb /dev/sdc1
tune2fs 1.43.4 (31-Jan-2017)
 > wait_for_file /dev/sdc2

>> makefs-uefi
 > mkfs.vfat -n MX-uefi /dev/sdc2
mkfs.fat: warning - lowercase labels might not work properly with DOS or Windows
mkfs.fat 4.1 (2017-01-24)
 > partprobe /dev/sdc
 > wait_for_file /dev/sdc1
 > mkdir -p /run/live-usb-maker/main
 > mount -t ext4 /dev/sdc1 /run/live-usb-maker/main
 > wait_for_file /dev/sdc2
 > mkdir -p /run/live-usb-maker/uefi
 > mount -t vfat /dev/sdc2 /run/live-usb-maker/uefi

Filesystem     Type  Size  Used Avail Use% Mounted on
/dev/sdc1      ext4   29G   44M   29G   1% /run/live-usb-maker/main
/dev/sdc2      vfat   50M     0   50M   0% /run/live-usb-maker/uefi


>> copy-uefi
copy from iso to uefi partition
files: [Ee][Ff][Ii] boot/{grub,uefi-mt} version
 > mkdir -p /run/live-usb-maker/uefi/boot
 > cp --no-dereference --preserve=mode,links --recursive /run/live-usb-maker/iso/boot/grub /run/live-usb-maker/uefi/boot
 > cp --no-dereference --preserve=mode,links --recursive /run/live-usb-maker/iso/EFI /run/live-usb-maker/uefi/.
 > cp --no-dereference --preserve=mode,links --recursive /run/live-usb-maker/iso/version /run/live-usb-maker/uefi/.
Fix Dell uefi memtest bug

>> copy-main
 > rm -rf /run/live-usb-maker/main/boot.orig
copy from iso to main partition
Using progress function: text_progress_bar
vm.dirty_bytes = 20000000
copy 
 > cpio -pdm --quiet /run/live-usb-maker/main/
cpio: blank line ignored
copy 
 > cpio -pdm --quiet /run/live-usb-maker/main/
cpio: blank line ignored
Copy remaining files ...
 > cpio -pdm --quiet /run/live-usb-maker/main/
copy pids: 6434 6437
vm.dirty_bytes = 20000000
vm.dirty_ratio = 0
 > write_file /run/live-usb-maker/main/made-by-live-usb-maker   created: Fri Mar 22 22:31:42 EDT 2019
  program: live-usb-maker
  version: 2.22.03 (Fri Mar 22 17:22:48 MDT 2019)
 > dd status=none if=/dev/urandom of=/run/live-usb-maker/main/antiX/random-seed bs=512 count=1
dd: failed to open '/run/live-usb-maker/main/antiX/random-seed': No such file or directory
 > chmod 600 /run/live-usb-maker/main/antiX/random-seed
chmod: cannot access '/run/live-usb-maker/main/antiX/random-seed': No such file or directory

>> uuids
 > mkdir -p /run/live-usb-maker/main/antiX
 > write_file /run/live-usb-maker/main/antiX/esp-uuid 9E2D-A077
Warning: Could not find grub.cfg file on EFI

>> install
extlinux version 6.03
 > dd status=none bs=440 conv=notrunc count=1 if=/usr/lib/syslinux/mbr/mbr.bin of=/dev/sdc
 > cp /usr/lib/syslinux/modules/bios/chain.c32 /run/live-usb-maker/main/syslinux/
cp: cannot create regular file '/run/live-usb-maker/main/syslinux/': Not a directory
 > cp /usr/lib/syslinux/modules/bios/gfxboot.c32 /run/live-usb-maker/main/syslinux/
cp: cannot create regular file '/run/live-usb-maker/main/syslinux/': Not a directory
 > cp /usr/lib/syslinux/modules/bios/vesamenu.c32 /run/live-usb-maker/main/syslinux/
cp: cannot create regular file '/run/live-usb-maker/main/syslinux/': Not a directory
 > cp /usr/lib/syslinux/modules/bios/ldlinux.c32 /run/live-usb-maker/main/syslinux/
cp: cannot create regular file '/run/live-usb-maker/main/syslinux/': Not a directory
 > cp /usr/lib/syslinux/modules/bios/libcom32.c32 /run/live-usb-maker/main/syslinux/
cp: cannot create regular file '/run/live-usb-maker/main/syslinux/': Not a directory
 > cp /usr/lib/syslinux/modules/bios/libmenu.c32 /run/live-usb-maker/main/syslinux/
cp: cannot create regular file '/run/live-usb-maker/main/syslinux/': Not a directory
 > cp /usr/lib/syslinux/modules/bios/libutil.c32 /run/live-usb-maker/main/syslinux/
cp: cannot create regular file '/run/live-usb-maker/main/syslinux/': Not a directory
 > cp /usr/lib/syslinux/modules/bios/linux.c32 /run/live-usb-maker/main/syslinux/
cp: cannot create regular file '/run/live-usb-maker/main/syslinux/': Not a directory
 > cp /usr/lib/syslinux/modules/bios/menu.c32 /run/live-usb-maker/main/syslinux/
cp: cannot create regular file '/run/live-usb-maker/main/syslinux/': Not a directory
 > write_file /run/live-usb-maker/main/syslinux/version 6.03
Error: Could not find a syslinux or isolinux directory
Last 20 lines of the dmesg output:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
[18963.050944] usb 3-1: Manufacturer: SanDisk
[18963.050946] usb 3-1: SerialNumber: 4C530001181108122114
[18963.052009] usb-storage 3-1:1.0: USB Mass Storage device detected
[18963.052164] scsi host6: usb-storage 3-1:1.0
[18964.092536] scsi 6:0:0:0: Direct-Access     SanDisk  Ultra            1.00 PQ: 0 ANSI: 6
[18964.093074] sd 6:0:0:0: Attached scsi generic sg2 type 0
[18964.093246] sd 6:0:0:0: [sdc] 60063744 512-byte logical blocks: (30.8 GB/28.6 GiB)
[18964.094318] sd 6:0:0:0: [sdc] Write Protect is off
[18964.094324] sd 6:0:0:0: [sdc] Mode Sense: 43 00 00 00
[18964.094626] sd 6:0:0:0: [sdc] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[18964.100549]  sdc: sdc1 sdc2
[18964.102353] sd 6:0:0:0: [sdc] Attached SCSI removable disk
[18974.663093] EXT4-fs (sdc1): mounted filesystem with ordered data mode. Opts: (null)
[19001.405845]  sdc:
[19001.566688]  sdc: sdc1
[19001.776312]  sdc: sdc1 sdc2
[19001.941347]  sdc: sdc1 sdc2
[19002.122455]  sdc: sdc1 sdc2
[19004.916717]  sdc: sdc1 sdc2
[19005.107408] EXT4-fs (sdc1): mounted filesystem with ordered data mode. Opts: (null)
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

live-usb-maker took 2 minutes and 56 seconds.

and then the live-usb-maker install command

Code: Select all

=====================================================================
./live-usb-maker install
        program: live-usb-maker
        started: Fri Mar 22 22:37:11 EDT 2019
        version: 2.22.03 (Fri Mar 22 17:22:48 MDT 2019)
         kernel: 4.19.0-1-amd64
             OS: MX 18 (Continuum)
      found lib: /home/dolphin/Desktop/rs55-test-LUM-02/cli-shell-utils/cli-shell-utils.bash
    lib version: 2.20.05 (Fri Mar 22 15:13:14 MDT 2019)
---------------------------------------------------------------------

Found man page: live-usb-maker.1
Only one target usb device was found sdc
Will use target device sdc (28.7G SanDisk Ultra)
Will use source  null
Found grub config 1.0

=====> Ready to perform install action on sdc
Wait for automounting ...
 > wait_for_file /dev/sdc1
 > wait_for_file /dev/sdc2
Found msdos partitioning
 > partprobe /dev/sdc
 > wait_for_file /dev/sdc1
 > mkdir -p /run/live-usb-maker/main
 > mount -t ext4 /dev/sdc1 /run/live-usb-maker/main
 > wait_for_file /dev/sdc2
 > mkdir -p /run/live-usb-maker/uefi
 > mount -t vfat /dev/sdc2 /run/live-usb-maker/uefi

Filesystem     Type  Size  Used Avail Use% Mounted on
/dev/sdc1      ext4   29G  1.4G   28G   5% /run/live-usb-maker/main
/dev/sdc2      vfat   50M  9.8M   41M  20% /run/live-usb-maker/uefi


>> install
extlinux version 6.03
 > dd status=none bs=440 conv=notrunc count=1 if=/usr/lib/syslinux/mbr/mbr.bin of=/dev/sdc
 > rm -f /run/live-usb-maker/main/syslinux/version
 > cp /usr/lib/syslinux/modules/bios/chain.c32 /run/live-usb-maker/main/syslinux/
 > cp /usr/lib/syslinux/modules/bios/gfxboot.c32 /run/live-usb-maker/main/syslinux/
 > cp /usr/lib/syslinux/modules/bios/vesamenu.c32 /run/live-usb-maker/main/syslinux/
 > cp /usr/lib/syslinux/modules/bios/ldlinux.c32 /run/live-usb-maker/main/syslinux/
 > cp /usr/lib/syslinux/modules/bios/libcom32.c32 /run/live-usb-maker/main/syslinux/
 > cp /usr/lib/syslinux/modules/bios/libmenu.c32 /run/live-usb-maker/main/syslinux/
 > cp /usr/lib/syslinux/modules/bios/libutil.c32 /run/live-usb-maker/main/syslinux/
 > cp /usr/lib/syslinux/modules/bios/linux.c32 /run/live-usb-maker/main/syslinux/
 > cp /usr/lib/syslinux/modules/bios/menu.c32 /run/live-usb-maker/main/syslinux/
 > write_file /run/live-usb-maker/main/syslinux/version 6.03
 > extlinux -i /run/live-usb-maker/main/syslinux
/run/live-usb-maker/main/syslinux is device /dev/sdc1
>> done

the stick is not bootable at least on 2 UEFI systems.

Posted: **Sat Mar 23, 2019 12:08 am**

Thanks dolphin_oracle! Strange things start happening during the early part of copy-main and then after that it appears that the partitions of the live-usb may no longer be mounted because there are bunch of errors. Those early errors in copy-main mean the vmlinuz and initrd.gz files may be missing which means it will be hard to boot no matter what happens after that.

FWIW, here are the first lines where I see something wrong:

Code: Select all

    local files=$(cd $from && find . -type f | grep -v delete_this_file)

    local vmlinuz_files=$(echo "$files" | grep "/vmlinuz[1-9]\?$")
    local   initrd_file=$(echo "$files" | grep "/initrd.gz$")

I first get a list of all the files in the iso file. Then I grep to get the /vmlinuz files (with possible trailing 1, 2, 3) and the initrd.gz file. Yet when you run, both $vmlinuz_files and $initrd_files are empty strings. But then I use that same list of files to copy all of the other files to the live-usb. I imagine that copy takes the normal amount of time so the list of files is non-empty and most of the files exist on the iso and get copied over.

I have a few more ideas now. Thanks again! You were a BIG help!

Edit: I can't figure out why it works fine here and for fehlix but not for anti, d.o., or rs55. I tried it on a nearly virgin antiX-17.4 live system both in the console and in X-windows. Worked fine. I've tried it with cloning and from an iso file. It worked fine. Then I downloaded the new keys and did a dist-upgrade and remaster and it still worked fine. The errors in d.o.'s log file are very strange yet I imagine they are consistent on the systems where it fails to work.

Posted: **Sat Mar 23, 2019 2:47 am**

I'm still baffled. I've attached a 3rd tarball. The only difference is I changed the directory name live-usb-maker/ to new-LUM/ and I added an old-LUM/ directory with live-usb-maker from antiX-17.4. If you run this version of LUM it will still use the new library and the changes there are almost entirely dealing with fuseiso and fragmentation. If that works then it will mean the strange new problem comes from my other changes to LUM. Otherwise, they will be due to the changes I made in the lib so we cut the search space in half. As a bonus, if the old LUM works with the new lib for rs55 then we will know if I solved the fragmentation problem or not.

Maybe my brain will be more clear after I get some rest. ATM I cannot image what could cause this cascade of strange problems and I have even less of an idea of why they happen the same way (I imagine) on some systems but don't show up at all for me or fehlix.

Posted: **Sat Mar 23, 2019 2:52 pm**

I was able to reproduce the error! The problem is the fuesiso9660 program. If you uninstall this package and reinstall fuseiso then we should be back on track. I will change my code back so it only looks for fuseiso but the new LUM should work fine with fuseiso. Again, I want to thank fehlix for his help and useful discussions.

Posted: **Sat Mar 23, 2019 3:05 pm**

Hi BitJam:
Glad you have figured this out. Will your changes make it into updates for the basic "stable" release? At the moment, my system is working fine with the gui that anticapitalista provided and fuseiso9660. So I will leave that alone until a new LUM is released.
Thanks for including me in your process.

Posted: **Sat Mar 23, 2019 3:47 pm**

rs55 wrote: Sat Mar 23, 2019 3:05 pm Glad you have figured this out. Will your changes make it into updates for the basic "stable" release? At the moment, my system is working fine with the gui that anticapitalista provided and fuseiso9660. So I will leave that alone until a new LUM is released.
Thanks for including me in your process.

I need your help rs55. There was nothing wrong with my code. The problem is in fuseiso9660. Please uninstall fuseiso9660 and reinstall fuseiso and try my new code and see if it fixes your fragmentation problem.

The reason anticapitalista's "solution" worked is he was calling my old code that doesn't use fuseiso9660. The fuseiso9660 program is broken and does not work. It was causing all of those strange problems you and anticapitialista and d.o. had when using my new code. One change I made in the new code is I used fuseiso9660 if it was available. I will certainly fix this but we still need to see if my new code fixed your fragmentation problem. The reason my new code worked for me and for fehlix is we both knew fuseiso works so neither one of us tried changing to fuseiso9660. I was able to reproduce the plethora of strange problems when I used fuseiso9660 instead of fuseiso.

Since yours is the only system we know of that has the fragmentation problem please uninstall fuseiso9660, reinstall fuseiso and try my new code again. All of the new problems were caused by fuseiso9660.

Posted: **Sat Mar 23, 2019 4:32 pm**

BitJam wrote: Sat Mar 23, 2019 3:47 pm The problem is in fuseiso9660.

The issue with fuseiso9660 is reproducable and results in lot of errors during the run of live-usb-maker.
The main reason is: fuseiso9660 converts all file names into uppercase filenames,
hence those filenames like "isolinux.cfg" in lower case are not found anymore
as linux is case sensitive with filenames. So BitJam is right and identified the culprit correctly.

Posted: **Sat Mar 23, 2019 4:36 pm**

fehlix wrote: Sat Mar 23, 2019 4:32 pm
BitJam wrote: Sat Mar 23, 2019 3:47 pm The problem is in fuseiso9660.
The issue with fuseiso9660 is reproducable and results in lot of errors during the run of live-usb-maker.
The main reason is: fuseiso9660 converts all file names into uppercase filenames,
hence those filenames like "isolinux.cfg" in lower case are not found anymore
as linux is case sensitive with filenames. So BitJam is right and identified the culprit correctly.

So why does it work in MX with the old lum and MX uses fuseiso9660?

Posted: **Sat Mar 23, 2019 4:40 pm**

BitJam wrote: Sat Mar 23, 2019 3:47 pm
rs55 wrote: Sat Mar 23, 2019 3:05 pm Glad you have figured this out. Will your changes make it into updates for the basic "stable" release? At the moment, my system is working fine with the gui that anticapitalista provided and fuseiso9660. So I will leave that alone until a new LUM is released.
Thanks for including me in your process.
I need your help rs55. There was nothing wrong with my code. The problem is in fuseiso9660. Please uninstall fuseiso9660 and reinstall fuseiso and try my new code and see if it fixes your fragmentation problem.

The reason anticapitalista's "solution" worked is he was calling my old code that doesn't use fuseiso9660. The fuseiso9660 program is broken and does not work. It was causing all of those strange problems you and anticapitialista and d.o. had when using my new code. One change I made in the new code is I used fuseiso9660 if it was available. I will certainly fix this but we still need to see if my new code fixed your fragmentation problem. The reason my new code worked for me and for fehlix is we both knew fuseiso works so neither one of us tried changing to fuseiso9660. I was able to reproduce the plethora of strange problems when I used fuseiso9660 instead of fuseiso.

Since yours is the only system we know of that has the fragmentation problem please uninstall fuseiso9660, reinstall fuseiso and try my new code again. All of the new problems were caused by fuseiso9660.

SUCCESS !! I downloaded you latest version : LUM 2.22.03 . Uninstalled fuseiso9660, Installed fuseiso and ran it. And it made the usb and the usb booted up properly !
Congratulations!
Question: What is the process by which this fix will make it into the "Stable" updates channel? When can we expect to see that?

Posted: **Sat Mar 23, 2019 4:48 pm**

anticapitalista wrote: Sat Mar 23, 2019 4:36 pm So why does it work in MX with the old lum and MX uses fuseiso9660?

The new code is different, which includes some new filehandling.

Posted: **Sat Mar 23, 2019 4:59 pm**

fehlix wrote: Sat Mar 23, 2019 4:48 pm
anticapitalista wrote: Sat Mar 23, 2019 4:36 pm So why does it work in MX with the old lum and MX uses fuseiso9660?
The new code is different, which includes some new filehandling.

My understanding is old LUM calls fuseiso. MX has fuseiso9660 installed. So - no fuse.. is called at all. Thats why it works.
The new code from BitJam calls fuseiso, but he has made some fixes. So with fuseiso installed it works.

Posted: **Sat Mar 23, 2019 5:16 pm**

anticapitalista wrote: Sat Mar 23, 2019 4:36 pm So why does it work in MX with the old lum and MX uses fuseiso9660?

My old code doesn't try to use fuseiso9660. It only tries fuseiso. The fragmentation problem only occurs if fuseiso* is used. So if you uninstall fuseiso then the old code will work because fuse mounting is not used. It is possible I knew there was a problem with fuseiso9660 when we first added fuseiso. That would explain why my old code doesn't even try fuseiso9660.

As fehlix figured out, the problem with fuseiso9660 is it converts all filenames to uppercase. This is why it created so many strange problems and why my program couldn't find files it was looking for.

You were right to include fuseiso and not fuseiso9660 in antiX-17.4. The only problem was that rs55 had a system where we needed to work harder to defrag vmlinuz. But the fuseiso9660 red herring caused you and rs55 and d.o. to have a bunch of mysterious problems while fehlix and I had no problems because we knew fuseiso worked and we didn't bother installing fuseiso9660.

@rs55 thank you for persevering through the chaos and trying my fix once more!

I think we are all back on track. The new code works. The fragmentation problem that rs55 had is fixed. I will have my code only use fuseiso and not fuseiso9660. AND we have learned that we don't want to have fuesiso9660 on our systems but we do want fuseiso.

I sympathize with you anti. I imagine you thought "*I* did something wrong by including fuseiso instead of fuseiso9660". I got caught in this same trap. I though "I did something wrong in my code that caused these problems". We both blamed ourselves first.

Posted: **Sat Mar 23, 2019 5:57 pm**

So - now, what is the best way to get your new code to be called by the antix control center gui?

Posted: **Sat Mar 23, 2019 6:17 pm**

rs55 wrote: Sat Mar 23, 2019 5:57 pm So - now, what is the best way to get your new code to be called by the antix control center gui?

Please give me a day (or more). For now you could manually copy two files from the tarball, but I want to change cli-shiell-utils so it DOES NOT try to use fuseiso9660. If you want to do it now then change to the new-LUM directory and run:

Code: Select all

sudo cp -i live-usb-maker /usr/local/bin
sudo cp -i ../cli-shell-utils/cli-shell-utils.bash /usr/local/lib/cli-shell-utils/

I added -i to the cp commands so it will warn you if you want to overwrite a file. You do want to overwrite but I use this warning to make sure I'm copying to the right place. These versions will get clobbered if cli-shell-utils or live-usb-maker get updated.

An alternative is to edit /usr/local/bin/antixcc.sh (the control centre) and change it so the LUM entry points to the version of LUM in your new-LUM/ directory. That location is important because LUM will look for ../cli-shell-utils/cli-shell-utils.bash (relative to the location of LUM, not your current directory). If it exists then LUM will use that version of the library instead of the version from the standard location. The key thing is the new library.

I *hope* we can get debs of the new versions into a buster or testing repo but that may take a week or so. We are trying to get a bunch of new code ready for antiX-19 (and then MX-19) so we are all very busy now. This problem put me off schedule but I am glad you reported it and worked with us so we could fix it.

Posted: **Sat Mar 23, 2019 7:02 pm**

rs55 wrote: Sat Mar 23, 2019 5:57 pm So - now, what is the best way to get your new code to be called by the antix control center gui?

For now, I would suggest you stick to the working antiX lum-gui that got recently updated and the cli-shell-utils in the repo.

Bitjam's new fixes will require new cli-shell-utils, live-usb-maker-gui-antix (and possibly live-usb-maker) debs.

Posted: **Sat Mar 23, 2019 7:41 pm**

anticapitalista wrote: Sat Mar 23, 2019 7:02 pm
rs55 wrote: Sat Mar 23, 2019 5:57 pm So - now, what is the best way to get your new code to be called by the antix control center gui?
For now, I would suggest you stick to the working antiX lum-gui that got recently updated and the cli-shell-utils in the repo.

Bitjam's new fixes will require new cli-shell-utils, live-usb-maker-gui-antix (and possibly live-usb-maker) debs.

Yes , that makes sense, thats what I will do. Thanks for providing that gui.

Posted: **Sat Mar 23, 2019 7:51 pm**

rs55 wrote: Sat Mar 23, 2019 7:41 pm
anticapitalista wrote: Sat Mar 23, 2019 7:02 pm
rs55 wrote: Sat Mar 23, 2019 5:57 pm So - now, what is the best way to get your new code to be called by the antix control center gui?
For now, I would suggest you stick to the working antiX lum-gui that got recently updated and the cli-shell-utils in the repo.

Bitjam's new fixes will require new cli-shell-utils, live-usb-maker-gui-antix (and possibly live-usb-maker) debs.
Yes , that makes sense, thats what I will do. Thanks for providing that gui.

Can you confirm that the cli version still works (live-usb-maker in a terminal). It does in my tests (antiX)

Posted: **Sun Mar 24, 2019 3:49 pm**

anticapitalista wrote: Sat Mar 23, 2019 7:51 pm
rs55 wrote: Sat Mar 23, 2019 7:41 pm
anticapitalista wrote: Sat Mar 23, 2019 7:02 pm

For now, I would suggest you stick to the working antiX lum-gui that got recently updated and the cli-shell-utils in the repo.

Bitjam's new fixes will require new cli-shell-utils, live-usb-maker-gui-antix (and possibly live-usb-maker) debs.
Yes , that makes sense, thats what I will do. Thanks for providing that gui.
Can you confirm that the cli version still works (live-usb-maker in a terminal). It does in my tests (antiX)

I just discovered that after installing your gui version - the antix-control center disappeared ! Yesterday , I was just looking to see if it booted up- which it does, but it seems to have uninstalled the cc . I am looking in synapic and re-installed the cc, but the cc is missing several items as well - the entire "maintenance" section is now missing.

Posted: **Sun Mar 24, 2019 4:17 pm**

I think I know what happened. I ran an updat, upgrade after installing your gui. I think you set it up so if fuseiso9660 is uninstalled, it also automatically uninstalls the control center.
I need to uninstall your version of the gui and get back to the vanilla version. possible?

Posted: **Tue Mar 26, 2019 12:55 pm**

Urgent!!
In MX, I noticed the updater had updates for LUM and associated files including fuseiso and cli-..

I updated, created a new live usb and attempted to boot. Got a fatal error:
"Error: mount: mounting /dev/loop0 on /live/linux failed: Invalid argument"

Posted: **Tue Mar 26, 2019 1:29 pm**

rs55 wrote: Tue Mar 26, 2019 12:55 pm Urgent!!
In MX, I noticed the updater had updates for LUM and associated files including fuseiso and cli-..

I updated, created a new live usb and attempted to boot. Got a fatal error:
"Error: mount: mounting /dev/loop0 on /live/linux failed: Invalid argument"

Please do also let us know "Quick System Info" (inxi -Fxrz)
what ISO was used and BIOS or UEFI booting mode
Thanks
EDIT: ALso: Did you used MX Live Usb Maker GUI or the command line tool live-usb-maker?

Posted: **Tue Mar 26, 2019 1:37 pm**

Code: Select all

inxi -Fxrz 

System:    Host: x230-2 Kernel: 5.0.0-2.1-liquorix-amd64 x86_64 bits: 64 compiler: gcc v: 6.3.0 
           Desktop: Xfce 4.12.3 Distro: MX-18.1_x64 Continuum Feb 9  2019 
           base: Debian GNU/Linux 9 (stretch) 
Machine:   Type: Laptop System: LENOVO product: 2320JPU v: ThinkPad X230 serial: <filter> 
           Mobo: LENOVO model: 2320JPU v: 0B98401 Pro serial: <filter> UEFI [Legacy]: LENOVO 
           v: G2ETB4WW (2.74 ) date: 11/14/2018 
Battery:   ID-1: BAT0 charge: 36.5 Wh condition: 43.1/57.2 Wh (75%) model: SANYO 45N1172 
           status: Discharging 
CPU:       Topology: Dual Core model: Intel Core i5-3230M bits: 64 type: MT MCP arch: Ivy Bridge 
           rev: 9 L2 cache: 3072 KiB 
           flags: lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx bogomips: 20751 
           Speed: 1197 MHz min/max: 1200/3200 MHz Core speeds (MHz): 1: 1198 2: 1197 3: 1197 
           4: 1198 
Graphics:  Device-1: Intel 3rd Gen Core processor Graphics vendor: Lenovo driver: i915 v: kernel 
           bus ID: 00:02.0 
           Display: x11 server: X.Org 1.19.2 driver: intel resolution: 1366x768~60Hz 
           OpenGL: renderer: Mesa DRI Intel Ivybridge Mobile v: 4.2 Mesa 18.2.6 direct render: Yes 
Audio:     Device-1: Intel 7 Series/C216 Family High Definition Audio vendor: Lenovo 
           driver: snd_hda_intel v: kernel bus ID: 00:1b.0 
           Sound Server: ALSA v: k5.0.0-2.1-liquorix-amd64 
Network:   Device-1: Intel 82579LM Gigabit Network vendor: Lenovo driver: e1000e v: 3.2.6-k 
           port: 6080 bus ID: 00:19.0 
           IF: eth0 state: down mac: <filter> 
           Device-2: Intel Centrino Ultimate-N 6300 driver: iwlwifi v: kernel port: efa0 
           bus ID: 03:00.0 
           IF: wlan0 state: up mac: <filter> 
Drives:    Local Storage: total: 238.47 GiB used: 15.52 GiB (6.5%) 
           ID-1: /dev/sda vendor: LITE-ON IT model: LCS-256L9S-11 2.5 7mm 256GB size: 238.47 GiB 
Partition: ID-1: / size: 38.20 GiB used: 15.52 GiB (40.6%) fs: ext4 dev: /dev/sda5 
           ID-2: swap-1 size: 3.90 GiB used: 0 KiB (0.0%) fs: swap dev: /dev/sda7 
Sensors:   System Temperatures: cpu: 42.0 C mobo: N/A 
           Fan Speeds (RPM): cpu: 2994 
Repos:     Active apt repos in: /etc/apt/sources.list 
           1: deb http://security.debian.org/debian-security stretch/updates main contrib non-free
           Active apt repos in: /etc/apt/sources.list.d/antix.list 
           1: deb http://mirrors.rit.edu/mxlinux/mx-packages/antix/stretch/ stretch main
           Active apt repos in: /etc/apt/sources.list.d/debian-stable-updates.list 
           1: deb http://ftp.us.debian.org/debian/ stretch-updates main contrib non-free
           Active apt repos in: /etc/apt/sources.list.d/debian.list 
           1: deb http://ftp.us.debian.org/debian/ stretch main contrib non-free
           2: deb http://security.debian.org/ stretch/updates main contrib non-free
           3: deb http://deb.debian.org/debian stretch-backports main
           Active apt repos in: /etc/apt/sources.list.d/google-chrome.list 
           1: deb [arch=amd64] http://dl.google.com/linux/chrome/deb/ stable main
           Active apt repos in: /etc/apt/sources.list.d/mx.list 
           1: deb http://mirrors.rit.edu/mxlinux/mx-packages/mx/repo/ stretch main non-free
           No active apt repos in: /etc/apt/sources.list.d/various.list 
Info:      Processes: 241 Uptime: 2m Memory: 7.47 GiB used: 1.25 GiB (16.7%) Init: SysVinit 
           runlevel: 5 Compilers: gcc: 6.3.0 Shell: bash v: 4.4.12 inxi: 3.0.29

***
Mod note: inxi-output between code-tags: [code] text goes here [/code] .
To insert code-tags press </>-icon above the editor window.
"Quick System Info" (from Whisker-Menu) will wrap code-tags to clipboard-copied system-info automatically.

Posted: **Tue Mar 26, 2019 1:43 pm**

Also - I am booting legacy with MBR partitions.
Please refer back to this thread. BitJam and I had etensive discussions on this LUM issue.

The previous version of LUM 0.3.6 was working fine in MX because fuseiso was not installed , only fuseiso9660 was installed. The LUM was invoking fuseiso, so was not executing any fuseiso*.

( It was failing in Antix , because Antix had fuseiso installed)

Now with the upgrade to LUM 0.3.7, it is installing fuseiso and invoking it.
This fuseiso* is the culprit. The LUM works fine without it. Unfortunately version 0.3.7 wont allow you to uninstall fuseiso, without uninstalling all the live usb files.

Posted: **Tue Mar 26, 2019 1:51 pm**

rs55 wrote: Tue Mar 26, 2019 1:43 pm Also - I am booting legacy with MBR partitions.
Please refer back to this thread.

Undesrstand, but also let us know, how you run lum, via cli or mx-gui?

Posted: **Tue Mar 26, 2019 1:58 pm**

fehlix wrote: Tue Mar 26, 2019 1:51 pm
rs55 wrote: Tue Mar 26, 2019 1:43 pm Also - I am booting legacy with MBR partitions.
Please refer back to this thread.
Undesrstand, but also let us know, how you run lum, via cli or mx-gui?

mx-gui

Posted: **Tue Mar 26, 2019 2:01 pm**

Are you sure the issue is lum etc and not your bleeding edge liquorix kernel?

Posted: **Tue Mar 26, 2019 2:05 pm**

A suggestion:
If fuseiso* is only causing a problem for a certain subset of machines ( like mine), but necessary for other machines, then perhaps you could make fuseiso* optional, or at least allow users to uninstall it.(as it used to be prior to this latest version).

Posted: **Tue Mar 26, 2019 2:06 pm**

anticapitalista wrote: Tue Mar 26, 2019 2:01 pm Are you sure the issue is lum etc and not your bleeding edge liquorix kernel?

I dont think its the liquorix kernel, because the problem also occurs in my Antix installation which is on 4.9 kernel.

Posted: **Tue Mar 26, 2019 2:10 pm**

have you tested on thinkpads circa 2011-2012 models? ( x220, x230, t420, w520 etc)? These are my favorite machines and I think they are quite popular with linux enthusiasts in general.

Posted: **Tue Mar 26, 2019 2:11 pm**

rs55 wrote: Tue Mar 26, 2019 2:10 pm have you tested on thinkpads circa 2011-2012 models? ( x220, x230, t420, w520 etc)? These are my favorite machines and I think they are quite popular with linux enthusiasts in general.

I have a Thinkpad L412

Posted: **Tue Mar 26, 2019 2:18 pm**

running LUM from the command line with the "--force=nofuse" switch should then work if fuse is the problem. We can add that option to the gui easy enough.

Posted: **Tue Mar 26, 2019 2:22 pm**

rs55 wrote: Tue Mar 26, 2019 2:05 pm If fuseiso* is only causing a problem for a certain subset of machines ( like mine), but necessary for other machines, then perhaps you could make fuseiso* optional, or at least allow users to uninstall it.(as it used to be prior to this latest version).

Please verify that it works for you with disabling fuseiso from command line like this:

Code: Select all

sudo live-usb-maker  --force=nofuse

Probably this can also be set permanently into the saved configfile.

Posted: **Tue Mar 26, 2019 2:42 pm**

rs55 wrote: Tue Mar 26, 2019 12:55 pm Urgent!!
In MX, I noticed the updater had updates for LUM and associated files including fuseiso and cli-..

I updated, created a new live usb and attempted to boot. Got a fatal error:
"Error: mount: mounting /dev/loop0 on /live/linux failed: Invalid argument"

This may not be a fuse problem. This error will occur when the kernel does not support the type of squashfs compression used to make the linuxfs file (but there could be other issues as well).

Please try again with the "bp=e" option. This will get you to a shell when the error occurs. Then run "dmesg | tail -n20". This will likely tell us more about what is going on.

Once the bootloader has run (and read the vmlinuz and initrd.gz files) then our fragmentation woes are over. The Linux kernel has no problem reading fragmented files so I suspect the problem is the compression method.

Posted: **Tue Mar 26, 2019 2:51 pm**

fehlix wrote: Tue Mar 26, 2019 2:22 pm
rs55 wrote: Tue Mar 26, 2019 2:05 pm If fuseiso* is only causing a problem for a certain subset of machines ( like mine), but necessary for other machines, then perhaps you could make fuseiso* optional, or at least allow users to uninstall it.(as it used to be prior to this latest version).
Please verify that it works for you with disabling fuseiso from command line like this:
Code: Select all
sudo live-usb-maker  --force=nofuse 
Probably this can also be set permanently into the saved configfile.

Yes - it works with the command line and force=nofuse.
It would be great if the gui for LUM had a checkbox for fuse/nofuse. I dont think Iam the only one this issue with fuse- I believe dolphin was also having the same issue.

Where is the config file for LUM and how do I change it?

Posted: **Tue Mar 26, 2019 3:15 pm**

rs55 wrote: Tue Mar 26, 2019 2:51 pm Where is the config file for LUM and how do I change it?

I havn't tested the save config settings feature. But if you run live-usb-maker --help
such an option is mentioned. Need to check...

Posted: **Tue Mar 26, 2019 4:05 pm**

@rs55, please run LUM again with fuse enabled. When you boot, please add these two options:

Code: Select all

checkmd5  bp=e

The first will check the integrity of the linuxfs file before we try to mount it. The 2nd will get you to a shell when the error occurs. In the shell run the command:

Code: Select all

dmesg | tail -n20

This should tell us why the mount failed. You could possible take a picture of the output if that is easy for you and it seems warranted.

If we are still getting fragmentation problems and we can't fix them then we may have to change our strategy and only use fuse when normal mounting fails. If I do give up then that will mean there will be some (rare) systems that LUM will not work on which is not a desirable outcome.

I want to first find out exactly what the problem is and then deal with it.

Posted: **Tue Mar 26, 2019 4:25 pm**

BitJam wrote: Tue Mar 26, 2019 4:05 pm @rs55, please run LUM again with fuse enabled. When you boot, please add these two options:
Code: Select all
checkmd5  bp=e
The first will check the integrity of the linuxfs file before we try to mount it. The 2nd will get you to a shell when the error occurs. In the shell run the command:
Code: Select all
dmesg | tail -n20
This should tell us why the mount failed. You could possible take a picture of the output if that is easy for you and it seems warranted.

If we are still getting fragmentation problems and we can't fix them then we may have to change our strategy and only use fuse when normal mounting fails. If I do give up then that will mean there will be some (rare) systems that LUM will not work on which is not a desirable outcome.

I want to first find out exactly what the problem is and then deal with it.

The error message from dmesg was SQUASHFS error: .... lz4 compression not supported.

Posted: **Tue Mar 26, 2019 4:29 pm**

also said:
"random: 7 urandom warning(s) missed due to ratelimiting" , after that lz4 compression error

Posted: **Tue Mar 26, 2019 4:35 pm**

rs55 wrote: Tue Mar 26, 2019 4:25 pmThe error message from dmesg was SQUASHFS error: .... lz4 compression not supported.

Excellent! Thank you!

This is what I suspected. It is totally UNRELATED to fragmentation. The problem is the kernel does not support lz4 compression. I don't see how --force=nofuse would fix this problem if you start with the same iso file.

I've already made changes to live-remaster and live-kernel-updater to prevent this. We also need to make similar changes to the snapshot programs.

If you downloaded this iso file from us then please tell us so we can take it down at once.

I am very sorry that you keep bumping into problems. All I can say is that we are on the case and we are trying to fix them as best and as fast as we can.

Posted: **Tue Mar 26, 2019 4:40 pm**

BitJam wrote: Tue Mar 26, 2019 4:35 pm
rs55 wrote: Tue Mar 26, 2019 4:25 pmThe error message from dmesg was SQUASHFS error: .... lz4 compression not supported.
Excellent! Thank you!

This is what I suspected. It is totally UNRELATED to fragmentation. The problem is the kernel does not support lz4 compression. I don't see how --force=nofuse would fix this problem if you start with the same iso file.

I've already made changes to live-remaster and live-kernel-updater to prevent this. We also need to make similar changes to the snapshot programs.

If you downloaded this iso file from us then please tell us so we can take it down at once.

I am very sorry that you keep bumping into problems. All I can say is that we are on the case and we are trying to fix them as best and as fast as we can.

No problem at all. Thanks for working away at this. Important to make LUM perfect!!
By the way, I am now running kernel 4.9.0-8 and I created the iso and ran LUM under this kernel. No this was not a downloaded iso - this was an iso I created off the system.
This may not be relevant - but about a month or so ago - when I first started using MX, I had problems with lz4, which went away when I used lzo . But then more recently lz4 has been working fine. And it does work with nofuse.

Posted: **Tue Mar 26, 2019 4:50 pm**

Is the new LUM using a different version of squashfs ?

Posted: **Tue Mar 26, 2019 5:09 pm**

rs55 wrote: Tue Mar 26, 2019 4:50 pm Is the new LUM using a different version of squashfs ?

LUM does not use mksquashfs.

AFAIK, it is only used in snapshot, live-remaster, and our build-iso system. I've already added safe-guards to live-remaster and live-kernel-updater (but have not tested them yet due to a spate of emergencies) and I just sent an email to other devs suggesting the same change/fixes be made to the snapshot programs.

My fix is to check which forms of squashfs compression the current kernel supports and only offer the forms of compression that are supported.

Posted: **Tue Mar 26, 2019 5:16 pm**

It does seem it is kernel related.

Posted: **Tue Mar 26, 2019 5:37 pm**

BitJam wrote: Tue Mar 26, 2019 5:09 pm
rs55 wrote: Tue Mar 26, 2019 4:50 pm Is the new LUM using a different version of squashfs ?
LUM does not use mksquashfs.

AFAIK, it is only used in snapshot, live-remaster, and our build-iso system. I've already added safe-guards to live-remaster and live-kernel-updater (but have not tested them yet due to a spate of emergencies) and I just sent an email to other devs suggesting the same change/fixes be made to the snapshot programs.

My fix is to check which forms of squashfs compression the current kernel supports and only offer the forms of compression that are supported.

I did another experiment. I created a new iso file using lzo compression. Then created a live usb with the new lum. That failed as well .

Posted: **Tue Mar 26, 2019 5:50 pm**

rs55 wrote: Tue Mar 26, 2019 5:37 pm I did another experiment. I created a new iso file using lzo compression. Then created a live usb with the new lum. That failed as well .

@rs55, please do report exactly what you did which program you used, and under what condition it failed.
what kernel. You already reported today and I asked which ISO, you used, and you didn't answer.
It doesn't help much if just report in an emergency style something failed with a certain option used.
If you don't provide exact information, you just creating confusion, as partly seen within this thread, already.
Thanks
fehlix

Posted: **Tue Mar 26, 2019 5:56 pm**

And - just now, I created a usb from the command line with force=nofuse. Same iso, same everything. It worked like a charm.
Sooo - this fuse is the culprit.
I am willing to bet I am not alone in this - because I am not using anything weird, or home brewed. Iam using a plain old standard thinkpad from when thinkpads were great.
You have perhaps not seen many complaints yet - because with the old LUM ( in the repo until this morning) , fuseiso was never actually getting invoked, because the standard installation installs fuseiso9660.
But - with todays' update - I bet you see a lot of folks who have problems with the lum.

Posted: **Tue Mar 26, 2019 7:38 pm**

I've been running some tests, with different compression schemes and kernels, and so far I cannot reproduce the issue rs55 is having with the latest LUM tools.

I've been using MX-18 with the liquourix 5.0.3 kernel, as well as the stock MX 4.19 kernel, and lz4, lzo, and default snapshot compression options.

is there another variable to test?

This is all with stretch repos. Should I try the testing ones?

Posted: **Tue Mar 26, 2019 8:02 pm**

dolphin_oracle wrote: Tue Mar 26, 2019 7:38 pm I've been running some tests, with different compression schemes and kernels, and so far I cannot reproduce the issue rs55 is having with the latest LUM tools.

I've been using MX-18 with the liquourix 5.0.3 kernel, as well as the stock MX 4.19 kernel, and lz4, lzo, and default snapshot compression options.

is there another variable to test?

This is all with stretch repos. Should I try the testing ones?

Hi Dolphin: Did you upgrade the LUM today? If so , both fuseiso and fuseiso9660 should be installed and the latest versions of lum.
Looks like you are also using thinkpads from my generation! If it all works for you - then I am indeed an outlier and maybe folks can stop worrying about my specific issue. I have gone back to yesterday's version of things that works on my machines - and will avoid upgrading anything for now. I am also on liquorix 5.0.1 and use lz4. My systems are stable - so I am off to do my taxes!

Posted: **Wed Mar 27, 2019 12:09 am**

rs55 wrote: Tue Mar 26, 2019 8:02 pmLooks like you are also using thinkpads from my generation! If it all works for you - then I am indeed an outlier and maybe folks can stop worrying about my specific issue. I have gone back to yesterday's version of things that works on my machines - and will avoid upgrading anything for now. I am also on liquorix 5.0.1 and use lz4. My systems are stable - so I am off to do my taxes!

It seems like you are tired of working on this and I don't blame you. I'd be tired of it too. Thank you so much for all the help you have provided us. You've gone over and above the call of duty. It is users like you who help us improve MX and antiX! Thank you!

Even if the problem is only on your system, I'd still like to track it down and figure out what is going on. If you ever want to return to this someday, the first thing I would suggest is to make sure only one live-usb is plugged in when you boot. If you have two live-usbs plugged in then the kernel from one could be trying to read the linuxfs file from the other and cause the lz4 problem.

In hindsight, when I asked you to run "dmesg | tail" after the live-usb failed to boot, I should have also asked you to run "uname -r" to be sure of what kernel was running. If you can create live-usbs that gives that lz4 error with a kernel that has lz4 support, especially if they can do it reliably when booted on a variety of systems then I would dearly love to get my hands on one.

Again, thank you for all of your help.

Posted: **Thu Mar 28, 2019 4:20 pm**

BitJam wrote: Wed Mar 27, 2019 12:09 am
rs55 wrote: Tue Mar 26, 2019 8:02 pmLooks like you are also using thinkpads from my generation! If it all works for you - then I am indeed an outlier and maybe folks can stop worrying about my specific issue. I have gone back to yesterday's version of things that works on my machines - and will avoid upgrading anything for now. I am also on liquorix 5.0.1 and use lz4. My systems are stable - so I am off to do my taxes!
It seems like you are tired of working on this and I don't blame you. I'd be tired of it too. Thank you so much for all the help you have provided us. You've gone over and above the call of duty. It is users like you who help us improve MX and antiX! Thank you!

Even if the problem is only on your system, I'd still like to track it down and figure out what is going on. If you ever want to return to this someday, the first thing I would suggest is to make sure only one live-usb is plugged in when you boot. If you have two live-usbs plugged in then the kernel from one could be trying to read the linuxfs file from the other and cause the lz4 problem.

In hindsight, when I asked you to run "dmesg | tail" after the live-usb failed to boot, I should have also asked you to run "uname -r" to be sure of what kernel was running. If you can create live-usbs that gives that lz4 error with a kernel that has lz4 support, especially if they can do it reliably when booted on a variety of systems then I would dearly love to get my hands on one.

Again, thank you for all of your help.

Iam back! OK , here is the situation with the new lum. It works on my Antix17.4 with kernel 4.20... .
On MX18.1 : with kernel 4.9... - it failed with the lz4 error. I guess kernel 4.9 cannot do lz4.
Yesterday I also tried liquorix 5.0... - that failed with Error: mount: mounting /dev/loop0 on live/linux failed: Invalid argument

So- today, after success with Antix, I decided to install that same antix4.20... kernel in MX , created a new snapshot and created a live-usb. Failed , with the same error message.

So- since the kernels are the same, there is something else about MX18.1 that causes the new LUM to fail , while it works on Antix17.4.
The other difference is the antix snapshot was about 2 GB, while the MX snapshot was 8GB. Dont know if the size matters.

Posted: **Thu Mar 28, 2019 4:32 pm**

I'm glad you're back!

Again, make sure only one live-usb is plugged into the machine you are booting. Then use the option bp=e when you boot. This will drop you to a shell if there is an error. When this happens run:

Code: Select all

dmesg | tail
uname -r

The first command should show us what caused the problem. Maybe it is the lz4 error message again or maybe it is something different. The second command verifies which kernel is running so we can check the kernel config and see what features are enabled and disabled.

Also, if you make a live-usb that fails to boot only when you don't use "--force=nofuse" then in addition to the above, I also want to see the portion of the live-usb.log file for the session that created the broken live-usb.

From a user's perspective the important thing is simply whether it failed or not but for those of us trying to fix it, we need to know the exact situation and the reason why it failed.

Posted: **Thu Mar 28, 2019 5:12 pm**

BitJam wrote: Thu Mar 28, 2019 4:32 pm I'm glad you're back!

Again, make sure only one live-usb is plugged into the machine you are booting. Then use the option bp=e when you boot. This will drop you to a shell if there is an error. When this happens run:
Code: Select all
dmesg | tail
uname -r
The first command should show us what caused the problem. Maybe it is the lz4 error message again or maybe it is something different. The second command verifies which kernel is running so we can check the kernel config and see what features are enabled and disabled.

Also, if you make a live-usb that fails to boot only when you don't use "--force=nofuse" then in addition to the above, I also want to see the portion of the live-usb.log file for the session that created the broken live-usb.

From a user's perspective the important thing is simply whether it failed or not but for those of us trying to fix it, we need to know the exact situation and the reason why it failed.

dmesg : FAT-fs (sdb2): utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive!
( thats the only line that seemed like an error msg)
unmae -r : 4.20.12-antix.1-amd64-snp

(I dont know how to copy all the messages from dmesg to paste here- its on another laptop)

Posted: **Thu Mar 28, 2019 5:33 pm**

rs55 wrote: Thu Mar 28, 2019 5:12 pm
BitJam wrote: Thu Mar 28, 2019 4:32 pm I'm glad you're back!

Again, make sure only one live-usb is plugged into the machine you are booting. Then use the option bp=e when you boot. This will drop you to a shell if there is an error. When this happens run:
Code: Select all
dmesg | tail
uname -r
The first command should show us what caused the problem. Maybe it is the lz4 error message again or maybe it is something different. The second command verifies which kernel is running so we can check the kernel config and see what features are enabled and disabled.

Also, if you make a live-usb that fails to boot only when you don't use "--force=nofuse" then in addition to the above, I also want to see the portion of the live-usb.log file for the session that created the broken live-usb.

From a user's perspective the important thing is simply whether it failed or not but for those of us trying to fix it, we need to know the exact situation and the reason why it failed.
dmesg : FAT-fs (sdb2): utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive!
( thats the only line that seemed like an error msg)
unmae -r : 4.20.12-antix.1-amd64-snp

(I dont know how to copy all the messages from dmesg to paste here- its on another laptop)

where would I find the log file for the failed lum ?

Posted: **Thu Mar 28, 2019 6:05 pm**

/var/log/live-usb-maker.log

Posted: **Thu Mar 28, 2019 6:14 pm**

dolphin_oracle wrote: Thu Mar 28, 2019 6:05 pm /var/log/live-usb-maker.log

see attached. Also - to confirm: uname -r : 4.20.12-antix.1-amd64-smp
Also: with --force=nofuse , the usb boots up fine
This log is for the failed usb creation ( without the --nofuse)

live usb log.txt

Posted: **Thu Mar 28, 2019 6:17 pm**

rs55 wrote: Thu Mar 28, 2019 6:14 pm
dolphin_oracle wrote: Thu Mar 28, 2019 6:05 pm /var/log/live-usb-maker.log
see attached. Also - to confirm: uname -r : 4.20.12-antix.1-amd64-smp
Also: with --force=nofuse , the usb boots up fine
This log is for the failed usb creation ( without the --nofuse)live usb log.txt

The mystery ( at least to me) is - this exact same kernel, running this exact same version of lum, works fine from the antix17.4 install ( Control Center - gui).

Posted: **Thu Mar 28, 2019 7:07 pm**

TL;DR: I really think the problem is at least partly caused by the usb stick perhaps in combination with certain hardware. If you can create a live-usb stick that reliably fails in this strange way (especially the lz4 error) when booted an a variety of hardware, especially a newish machine, then I'd love to get you to send one to me so I can see it fail here and examine the failure in great detail.

But even if we can pin the problem down to a booting on a particular machine or with a particular live-usb or both in combination, I think I need to relent now and change it so we only try fuseiso if normal mounting fails. I still want to wait and see if anyone else reports a similar problem but I will post an easy solution for you that should fix all of the versions of live-usb-maker for you and won't go away when things get updated.

I'm sorry to have put you through so much bother. I'm really glad we were able to fix some of the fragmentation problems due to your help.

If you can create a live-usb that reliably fails on many different machines due to not using --force=nofuse then I would like to arrange to buy one from you or trade for one.

Way too many notes!

rs55 wrote: Thu Mar 28, 2019 5:12 pm dmesg : FAT-fs (sdb2): utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive!
( thats the only line that seemed like an error msg)
uname -r : 4.20.12-antix.1-amd64-snp

(I dont know how to copy all the messages from dmesg to paste here- its on another laptop)

That's fine. So there was no lz4 message in the log. Good to know. So the original error message was what? Was it "Error: mount: mounting /dev/loop0 on live/linux failed: Invalid argument"?

It is helpful if you can gather the information from one incident all together: the kernel, the original error message, the extra dmesg error message (if any), and maybe even the session from the LUM log file.

You seem to be having a variety of different problems. Just from this thread there was the first the issue with reading the vmlinuz file. Then there was the lz4 error when mounting linuxfs and now you have yet a different kind of error when we try to mount linuxfs.

I still want to see the output of "uname -r" when dmesg tells you there is an lz4 error. If the kernel version supports lz4 then that would be a very bizarre situation. Very bizarre.

Do these errors still only happen when you make a live-usb on one particular machine and not any others?

Do the bad live-usbs fail to boot on different machines or just one?

Do the problems all go away when you use --force=nofuse?

Do they go away when you use brand of usb stick?

If you happen to be using SanDisk Ultra Fit, then stop doing that, at least for live-usbs. We know they cause a variety of strange hardware problems.

rs55 wrote: Thu Mar 28, 2019 5:33 pmwhere would I find the log file for the failed lum ?

Almost all log files are under /var/log/. This is no exception. The log file is at /var/log/live-usb-maker.log. The most recent recent session gets added to the bottom of the file. There is a ton of information for each session about when it was made and what the distro was made, what the command line options were and so on so it should not be too hard to find a particular session. Of course the most recent session is always at the bottom of the file.

I'm fairly confident the vmlinuz file is not fragmented. The log file would tell us for sure. It may be good to continue to use "checkmd5" to be sure there is no file corruption but you have never found any. Passing the md5 test tells us that 3 key fails are perfectly intact and it tells us further that Linux can read them perfectly.

Since the vmlinuz file loads and is likely not fragmented then I don't think there is a problem with the kernel. It would be an astronomical coincidence that the kernel was somehow corrupted and that corruption only affected attempts to mount the linuxfs file (now in two different ways!).

But I don't understand why Linux can read the file when we do the md5 test but then has trouble reading it (or something???) when we try to mount it. Normally, I would expect to see IO errors in the dmesg output when there is a hardware problem. But very occasionally, the hardware can give you the wrong numbers without throwing an error. I've seen it just once before.

There seems no doubt that you have a system that generates much more fragmentation than most systems when fuseiso is used. Yet we fixed the problem with reading vmlinuz and the md5 check tells us Linux can read the 3 files fine despite fragmentation and they are all intact.

My best guess now is there is a problem with the system you are booting or with the usb-stick or both that is sensitive in some strange way to the extra fragmentation. For example the SanDisk Ultra Fit seems to gulp too much power in some situations that can cause hardware glitches on some systems. This could be accentuated on a older system because the electrolytic capacitors that are used to prevent such power glitches are usually the first part to wear out.

Posted: **Thu Mar 28, 2019 7:20 pm**

rs55 wrote: Thu Mar 28, 2019 6:17 pm
rs55 wrote: Thu Mar 28, 2019 6:14 pm
dolphin_oracle wrote: Thu Mar 28, 2019 6:05 pm /var/log/live-usb-maker.log
see attached. Also - to confirm: uname -r : 4.20.12-antix.1-amd64-smp
Also: with --force=nofuse , the usb boots up fine
This log is for the failed usb creation ( without the --nofuse)live usb log.txt
The mystery ( at least to me) is - this exact same kernel, running this exact same version of lum, works fine from the antix17.4 install ( Control Center - gui).

Ran another experiment - this time using the same exact iso. ( its a 7.8 GB iso). Both MX and Antix fail. So the issue is with this particular iso. It works fine with --nofuse. But fails otherwise.
Is it the size? ( my other iso, the antix iso is 1.7 GB - and works fine without --nofuse).

Posted: **Thu Mar 28, 2019 7:39 pm**

The iso size is important clue. Perhaps fuseiso has a problem with isos outside a given size. Dvd would be around 4.2 GB max

Posted: **Thu Mar 28, 2019 7:47 pm**

rs55 wrote: Thu Mar 28, 2019 7:20 pmRan another experiment - this time using the same exact iso. ( its a 7.8 GB iso). Both MX and Antix fail. So the issue is with this particular iso. It works fine with --nofuse. But fails otherwise.
Is it the size? ( my other iso, the antix iso is 1.7 GB - and works fine without --nofuse).

Yes! It could be the size. One more thing to try is to mount the broken live-usb and then run:

Code: Select all

sudo e4defrag $MOUNT_POINT/antiX/linuxfs

This will take a while to run but it will try to defrag the linuxfs file.

I still think there is a problem with the usb stick and or the hardware. If I'm wrong and you can get different brands of usb-sticks to fail on a variety of hardware, especially newish hardware (less than 4 years old) then I would like to get one of those sticks from you.

dolphin_oracle wrote: Thu Mar 28, 2019 7:39 pm The iso size is important clue. Perhaps fuseiso has a problem with isos outside a given size. Dvd would be around 4.2 GB max

I don't think so because the md5 check said the linuxfs file was fine. We have never seen fuseiso give us the wrong files. The md5 checks and diffs always said everything was identical. With a larger file there will be more fragmentation and perhaps greater jumps in where the fragments are and I believe this is triggering a problem on the hardware rs55 is using. Remember rs55 had a problem even when the vmlinuz file was slightly fragmented.

Posted: **Thu Mar 28, 2019 7:53 pm**

BitJam wrote: Thu Mar 28, 2019 7:07 pm TL;DR: I really think the problem is at least partly caused by the usb stick perhaps in combination with certain hardware. If you can create a live-usb stick that reliably fails in this strange way (especially the lz4 error) when booted an a variety of hardware, especially a newish machine, then I'd love to get you to send one to me so I can see it fail here and examine the failure in great detail.

But even if we can pin the problem down to a booting on a particular machine or with a particular live-usb or both in combination, I think I need to relent now and change it so we only try fuseiso if normal mounting fails. I still want to wait and see if anyone else reports a similar problem but I will post an easy solution for you that should fix all of the versions of live-usb-maker for you and won't go away when things get updated.

I'm sorry to have put you through so much bother. I'm really glad we were able to fix some of the fragmentation problems due to your help.

If you can create a live-usb that reliably fails on many different machines due to not using --force=nofuse then I would like to arrange to buy one from you or trade for one.

Way too many notes!

rs55 wrote: Thu Mar 28, 2019 5:12 pm dmesg : FAT-fs (sdb2): utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive!
( thats the only line that seemed like an error msg)
uname -r : 4.20.12-antix.1-amd64-snp

(I dont know how to copy all the messages from dmesg to paste here- its on another laptop)
That's fine. So there was no lz4 message in the log. Good to know. So the original error message was what? Was it "Error: mount: mounting /dev/loop0 on live/linux failed: Invalid argument"?

It is helpful if you can gather the information from one incident all together: the kernel, the original error message, the extra dmesg error message (if any), and maybe even the session from the LUM log file.

You seem to be having a variety of different problems. Just from this thread there was the first the issue with reading the vmlinuz file. Then there was the lz4 error when mounting linuxfs and now you have yet a different kind of error when we try to mount linuxfs.

I still want to see the output of "uname -r" when dmesg tells you there is an lz4 error. If the kernel version supports lz4 then that would be a very bizarre situation. Very bizarre.

Do these errors still only happen when you make a live-usb on one particular machine and not any others?

Do the bad live-usbs fail to boot on different machines or just one?

Do the problems all go away when you use --force=nofuse?

Do they go away when you use brand of usb stick?

If you happen to be using SanDisk Ultra Fit, then stop doing that, at least for live-usbs. We know they cause a variety of strange hardware problems.

rs55 wrote: Thu Mar 28, 2019 5:33 pmwhere would I find the log file for the failed lum ?
Almost all log files are under /var/log/. This is no exception. The log file is at /var/log/live-usb-maker.log. The most recent recent session gets added to the bottom of the file. There is a ton of information for each session about when it was made and what the distro was made, what the command line options were and so on so it should not be too hard to find a particular session. Of course the most recent session is always at the bottom of the file.

I'm fairly confident the vmlinuz file is not fragmented. The log file would tell us for sure. It may be good to continue to use "checkmd5" to be sure there is no file corruption but you have never found any. Passing the md5 test tells us that 3 key fails are perfectly intact and it tells us further that Linux can read them perfectly.

Since the vmlinuz file loads and is likely not fragmented then I don't think there is a problem with the kernel. It would be an astronomical coincidence that the kernel was somehow corrupted and that corruption only affected attempts to mount the linuxfs file (now in two different ways!).

But I don't understand why Linux can read the file when we do the md5 test but then has trouble reading it (or something???) when we try to mount it. Normally, I would expect to see IO errors in the dmesg output when there is a hardware problem. But very occasionally, the hardware can give you the wrong numbers without throwing an error. I've seen it just once before.

There seems no doubt that you have a system that generates much more fragmentation than most systems when fuseiso is used. Yet we fixed the problem with reading vmlinuz and the md5 check tells us Linux can read the 3 files fine despite fragmentation and they are all intact.

My best guess now is there is a problem with the system you are booting or with the usb-stick or both that is sensitive in some strange way to the extra fragmentation. For example the SanDisk Ultra Fit seems to gulp too much power in some situations that can cause hardware glitches on some systems. This could be accentuated on a older system because the electrolytic capacitors that are used to prevent such power glitches are usually the first part to wear out.

lets back up a bit:
- I already posted earlier that the lz4 error yesterday was when I was using kernel 4.9. That is no longer an issue with kernel 4.20
- I am confident its not the flash drive. i just tried a brand new Samsung flash drive - same error upon boot.
- The error is also repeatable from both the Antix system and the MX system - no difference.
- There is no problem when I use my 1.7GB iso image.
- The problem occurs when I use my 7.8 GB iso image.
- The problem with the usb boot with the 7.8 GB image goes away if I use LUM with --force==nofuse
- I was not having a single issue until the latest lum upgrade( which is using fuseiso), so I have had to revert back and stop all upgrades.
- i would like to upgrade normally at some point - so any advice from you would be helpful. Or maybe I have to be resigned to always running lum from the terminal and using --force=nofuse.

Posted: **Thu Mar 28, 2019 8:07 pm**

rs55 wrote: Thu Mar 28, 2019 7:20 pmRan another experiment - this time using the same exact iso. ( its a 7.8 GB iso). Both MX and Antix fail. So the issue is with this particular iso. It works fine with --nofuse. But fails otherwise.
Is it the size? ( my other iso, the antix iso is 1.7 GB - and works fine without --nofuse).

I quoted to get your attention. As promised, I've attached a fix for you. If you put the tarball in your home directory then you can install it like this:

Code: Select all

cd /usr/local
sudo tar xzf ~/rs55-lum-fix-01.tgz

You can test if it is installed correctly by running:

Code: Select all

live-usb-maker --version

It should show you something like:

Code: Select all

      live-usb-maker version 2.30.00 (Sun Mar 24 12:37:30 MDT 2019)
     cli-shell-utils version 2.31.00 (Thu Mar 28 17:50:32 MDT 2019)

The crucial thing is that the lib is version 2.31.00.

The tarball contains a cli-shell-utils/ directory that contains the modified cli-shell-utils.bash library and a few helper apps. Oh, translations will be disabled. If you need that then I can give you a bigger tarball.

The normal version of live-usb-maker that is used by the guis and when you call "live-usb-maker" on the command line lives in /usr/local/bin. It will look in /usr/local/cli-shell-utils/ first for the library and if it finds it there it won't look in the standard location.

If you want to continue to experiment with this wacky fragmentation issues then copy /usr/local/bin/live-usb-maker to your home directory and run it as:

Code: Select all

sudo ~/live-usb-maker

You can test this with the --version option and it should show you the older library version.

Again, if you install this fix and copy live-usb-maker to your home directory then "live-usb-maker" and "/usr/local/bin/live-usb-maker" will use the fixed library while "~/live-usb-maker" will use the standard library that tries "fuseiso" first.

HTH

Posted: **Thu Mar 28, 2019 8:11 pm**

You may not get many others who complain of this. Mostly because if the size of the iso is the issue, most people probably have small iso files <2GB. ( more than enough for the standard suite of apps - libreoffice, firefox etc).
I happen to have a lot of heavy programs loaded like Ananconda, tensorflow , rstudio etc, which makes the iso large.

Posted: **Thu Mar 28, 2019 8:22 pm**

rs55 wrote: Thu Mar 28, 2019 7:53 pmlets back up a bit:
- I already posted earlier that the lz4 error yesterday was when I was using kernel 4.9. That is no longer an issue with kernel 4.20
- I am confident its not the flash drive. i just tried a brand new Samsung flash drive - same error upon boot.
- The error is also repeatable from both the Antix system and the MX system - no difference.
- There is no problem when I use my 1.7GB iso image.
- The problem occurs when I use my 7.8 GB iso image.
- The problem with the usb boot with the 7.8 GB image goes away if I use LUM with --force==nofuse
- I was not having a single issue until the latest lum upgrade( which is using fuseiso), so I have had to revert back and stop all upgrades.
- i would like to upgrade normally at some point - so any advice from you would be helpful. Or maybe I have to be resigned to always running lum from the terminal and using --force=nofuse.

Thank you for the concise summary! I'm sorry if I was not following everything you said closely enough. I am buried in work to get antiX-19 (and then MX-19) out the door. At this rate I am about to start missing deadlines.

Anyway, the fix in my previous post should fix the problem for you and should survive updates.

If we can't replicate your problem using a large linuxfs and fuseiso then I would really like to buy or trade for that live-usb that you can get to fail reliably. Let's first see if we can replicate the problem and also please use "checkmd5" (if you haven't already). If checkmd5 fails then it is a bug in fuseiso, plain and simple. If it passes then the problem is more subtle.

Posted: **Thu Mar 28, 2019 9:10 pm**

YES! YOU ARE ABSOLUTELY RIGHT rs55!

You have found another problem with fuseiso. I made a 10G or so file and put it into an iso file and mounted it normally and with fuse iso. Here is the normal mount:

Code: Select all

-rw-r--r-- 1 juser juser 9.9G Mar 28 18:42 other.sqfs

Here is the mount with fuseiso:

Code: Select all

-rw-r--r-- 1 juser juser 4.0G Mar 29  2019 other.sqfs
-rw-r--r-- 1 juser juser 4.0G Mar 29  2019 other.sqfs
-rw-r--r-- 1 juser juser 4.0G Mar 29  2019 other.sqfs

Clearly we cannot use fuseiso with linuxfs files over 4.0G.

OTOH, The md5sums do not match. If you had done that simple test like I asked then it might have saved us all a lot of grief.

Posted: **Thu Mar 28, 2019 9:25 pm**

BitJam wrote: Thu Mar 28, 2019 9:10 pm YES! YOU ARE ABSOLUTELY RIGHT rs55!

You have found another problem with fuseiso. I made a 10G or so file and put it into an iso file and mounted it normally and with fuse iso. Here is the normal mount:
Code: Select all
-rw-r--r-- 1 juser juser 9.9G Mar 28 18:42 other.sqfs
Here is the mount with fuseiso:
Code: Select all
-rw-r--r-- 1 juser juser 4.0G Mar 29  2019 other.sqfs
-rw-r--r-- 1 juser juser 4.0G Mar 29  2019 other.sqfs
-rw-r--r-- 1 juser juser 4.0G Mar 29  2019 other.sqfs
Clearly we cannot use fuseiso with linuxfs files over 4.0G.

OTOH, The md5sums do not match. If you had done that simple test like I asked then it might have saved us all a lot of grief.

Excellent Commander!!! So the issue all along was the large size ( 7.8GB ) of the troublesome iso. Thank you so much for the fix you provided - worked like a charm. I installed the fix first, then upgraded to the new lum. And the fix survived - which was my prayer! Brilliant!!
Again, thank you so much for taking time from your busy schedule to attend to this issue. Made my day! Sorry if I was not fully attentive to your debugging instructions - still very new to this linux business.
So - now that you know the size limitation - will you be fixing it - for the "normal version"? a 4GB+ iso would not seem all that unusual - that is if one is using the computer to do something other than web browsing !!

Posted: **Fri Mar 29, 2019 12:38 am**

Okay, the trick is that fuseiso gives crazy file sizes so if I am only able to mount with fuseiso then I can't use the reported sizes to see if a file is too large. I don't want to use the overall size of the iso file because that could easily get large with remasters, persistence, and other stuff without one file being 4Gig. So I am relying on the quirk (always a mistake) that fuseiso reports oversized files more than once. Someone might want to check that this works for files exactly one 4 Gig and one byte more and one byte less.

@rs55, Welcome to the wonderful world of Linux! You've had one heck of an introduction and I'm a little surprised (but delighted) that you stuck it out.

In the new code, in addition to trying 'mount" first before "fuseiso", if fuseiso was used then I look for duplicate file names. If I find any then I error out saying there are files too large for fuseiso to handle. This is probably not a great message but oh well for now.

In case you want to test this I attached rs55-test-LUM-05.tgz. It is the old game where you:

Code: Select all

tar xzf rs55-test-LUM-05.tgz.
cd rs55-test-LUM-05/LUM 
  ./live-usb-maker --version

You should get:

Code: Select all

      live-usb-maker version 2.32.00 (Thu Mar 28 21:55:53 MDT 2019)
     cli-shell-utils version 2.32.00 (Thu Mar 28 21:57:51 MDT 2019)

Then to test it on one of your large iso files, use the --force=fuse option (I'll bet you never imagined you would be using that). This will cause it to only try fuseiso and when it does it should error out. So this test is quick and painless compared to the mountain of previous testing you were doing. It seemed to work here.

I'm not planning to push these changes tonight because I am very tired and I may not be thinking clearly. If it still seems like a good idea in the morning then I will push the changes tomorrow. It is unfortunate that this is happening just hours after anticapitalista released eight new iso files. Really bad timing seems to be this year's theme. We do the best we can. I suspect that even now fehlix is trying to figure out how to get it to fuseiso mounting work anyway. That would be really something.

I'm really grateful to you rs55 for hanging in and helping us track down these problems even when I was doubting you. It is very strange that one person ran into both fuseiso issues and also ran into the lz4 issue for good measure. How likely was that? Thank you once again.

Han Solo wrote:
Never tell me the odds!

Posted: **Mon Apr 01, 2019 7:42 am**

Any ETA on when this fix might be pushed out? Just encountered the same "Error: mount: mounting /dev/loop0 on /live/linux failed: Invalid argument" on a 4.6GB iso. Similarly to rs55, i am using a Thinkpad X220 (don't know if that's just a coincidence or not?). Happy to wait it out until the fix comes through, but just wanted to confirm whether the solution was indeed on its way to the regular update channel? Thanks

Posted: **Mon Apr 01, 2019 2:07 pm**

redsparro wrote: Mon Apr 01, 2019 7:42 am Any ETA on when this fix might be pushed out? Just encountered the same "Error: mount: mounting /dev/loop0 on /live/linux failed: Invalid argument" on a 4.6GB iso. Similarly to rs55, i am using a Thinkpad X220 (don't know if that's just a coincidence or not?). Happy to wait it out until the fix comes through, but just wanted to confirm whether the solution was indeed on its way to the regular update channel? Thanks

New debs should be released today. Or so.

In the meantime you can use the command line version of live-usb-maker to get around this problem with the --force=nofuse option. Try using:

Code: Select all

sudo live-usb-maker --force=nofuse --from $YOUR_ISO_FILE

Thanks to the great work by fehlix, we were able to actually solve the problem even for people who need to use fuseiso. In addition, we built in an md5 check to the live-usb-maker programs so if there is a problem then you will be able to catch it when live-usb-maker runs. We originally wanted to release a fix a few days ago but there were a couple of snags, then we added the fehlix fix and then we added the md5 check. We fixed the problem (we think) and then we added a check just in case there is some other snag we did not expect.

I'm sorry for the delay. It took longer than we expected and we didn't want to release fixes in dribs and drabs.

Posted: **Mon Apr 01, 2019 2:37 pm**

I added a "Don't use fuseiso to mount iso files" option in Advanced Option that runs the script with "--force=nofuse" in our GUI program, it should show up shortly in the repo.

Posted: **Mon Apr 01, 2019 2:51 pm**

Adrian wrote: Mon Apr 01, 2019 2:37 pm I added a "Don't use fuseiso to mount iso files" option in Advanced Option that runs the script with "--force=nofuse" in our GUI program, it should show up shortly in the repo.

When the new lib and LUM arrive then that option should no longer be needed. We now try "mount" first and only fall back to "fuseiso" if mount fails. In addition, due to the wizardry of fehlix, we are now able to to handle large files even if we are forced to mount with fuseiso.

So with the new code, --force=nofuse is not really needed, we left it in for compatibility and it will cause the program to error out rather than use fuseiso when it is needed. Again, I'm sorry our changes were a few days late.

Posted: **Mon Apr 01, 2019 2:52 pm**

Oh, sorry, I misunderstood, should I pull the change then?

Posted: **Mon Apr 01, 2019 2:54 pm**

Adrian wrote: Mon Apr 01, 2019 2:52 pm Oh, sorry, I misunderstood, should I pull the change then?

Please wait for the new LUM and new lib. ATM that is a great option to have.

Posted: **Mon Apr 01, 2019 6:01 pm**

BitJam wrote: Mon Apr 01, 2019 2:07 pmI'm sorry for the delay. It took longer than we expected and we didn't want to release fixes in dribs and drabs.

No need to apologise, I completely understand. In fact, reading through the topic I'm impressed at how rapidly you resolved it!

Thanks for responding, and the heads up on the fix!

Posted: **Tue Apr 02, 2019 9:59 am**

BitJam wrote: Mon Apr 01, 2019 2:54 pm
Adrian wrote: Mon Apr 01, 2019 2:52 pm Oh, sorry, I misunderstood, should I pull the change then?
Please wait for the new LUM and new lib. ATM that is a great option to have.

I noticed a new LUM in the MX updater ( LUM 19.4). Is this the final version or Adrian's interim version?

Posted: **Tue Apr 02, 2019 12:02 pm**

rs55 wrote: Tue Apr 02, 2019 9:59 am I noticed a new LUM in the MX updater ( LUM 19.4). Is this the final version or Adrian's interim version?

I'm not sure. The timing is right for either. Here is a quick test:

Code: Select all

$ cd
$ cp /usr/local/bin/live-usb-maker .
$ ./live-usb-maker --version
      live-usb-maker version 2.23.04 (Mon Apr  1 01:00:41 MDT 2019)
     cli-shell-utils version 2.33.05 (Mon Apr  1 10:34:42 MDT 2019)

(change to your home directory copy live-usb-maker from /usr/local/bin and then print out the versions using this local copy of live-usb-maker.)

This new version should work with your large files even if you use --force=fuse (thanks to the wizardry of fehlix). You may also notice that we are now checking the md5 files within LUM. If you are still over-riding the library then you will need to disable that to get access to the new library that contains the fixes:

Code: Select all

cd /usr/local/
sudo mv cli-shell-utils/ cli-shell-utils.old/

The new version should also be being called from the GUI versions (once you disable the over-ride). We try "mount" first and only fall back to "fuseiso" if mount fails. This is because I believe you, rs55, have already found all the problems with fuseiso and we were able to fix them. But if not, the error should show up in the md5 check while LUM is running which should save us all some grief.

This is not the final version. This has the fixes backported to the version from antiX-17.4. A newer version is on the way for antiX-19.

Posted: **Tue Apr 02, 2019 12:37 pm**

BitJam wrote: Tue Apr 02, 2019 12:02 pm
rs55 wrote: Tue Apr 02, 2019 9:59 am I noticed a new LUM in the MX updater ( LUM 19.4). Is this the final version or Adrian's interim version?
I'm not sure. The timing is right for either. Here is a quick test:
Code: Select all
$ cd
$ cp /usr/local/bin/live-usb-maker .
$ ./live-usb-maker --version
      live-usb-maker version 2.23.04 (Mon Apr  1 01:00:41 MDT 2019)
     cli-shell-utils version 2.33.05 (Mon Apr  1 10:34:42 MDT 2019)
(change to your home directory copy live-usb-maker from /usr/local/bin and then print out the versions using this local copy of live-usb-maker.)

This new version should work with your large files even if you use --force=fuse (thanks to the wizardry of fehlix). You may also notice that we are now checking the md5 files within LUM. If you are still over-riding the library then you will need to disable that to get access to the new library that contains the fixes:
Code: Select all
cd /usr/local/
sudo mv cli-shell-utils/ cli-shell-utils.old/
The new version should also be being called from the GUI versions (once you disable the over-ride). We try "mount" first and only fall back to "fuseiso" if mount fails. This is because I believe you, rs55, have already found all the problems with fuseiso and we were able to fix them. But if not, the error should show up in the md5 check while LUM is running which should save us all some grief.

This is not the final version. This has the fixes backported to the version from antiX-17.4. A newer version is on the way for antiX-19.

Thanks. I renamed the /usr/local/cli-shell-utils directory to ....old
Then I ran update/upgrade to get the new version of lum.
Then I ran live-usb-maker --version
It showed: lum 2.20.
cli-shell-utils 2.30

Hmm.. wonder what Iam doing wrong here.

Posted: **Tue Apr 02, 2019 12:39 pm**

Oh - now I see the gui of LUM in "advanced" has the option to disable fuseiso.

Posted: **Tue Apr 02, 2019 1:16 pm**

My current versions of LUM and cli-shell-utils seem to be working fine ( with fuseiso disabled). i just tried burning a usb , with the fuseiso disable option in the gui - and it booted up fine. ( no surprise I suppose !)

Posted: **Wed Apr 03, 2019 11:42 am**

Update:
I installed the lum update from the MX updater this morning:
live-usb-maker --version
live-usb-maker version 2.23.04 (Mon Apr 1 01:00:41 MDT 2019)
cli-shell-utils version 2.33.05 (Mon Apr 1 10:34:42 MDT 2019)

Created a usb with this new lum ( without checking the box to disable fuseiso). Everything worked great - and the usb booted up without any errors.
Well done guys !!

Posted: **Wed Apr 03, 2019 11:43 am**

rs55 wrote: Wed Apr 03, 2019 11:42 am Update:
I installed the lum update from the MX updater this morning:
live-usb-maker --version
live-usb-maker version 2.23.04 (Mon Apr 1 01:00:41 MDT 2019)
cli-shell-utils version 2.33.05 (Mon Apr 1 10:34:42 MDT 2019)

Created a usb with this new lum ( without checking the box to disable fuseiso). Everything worked great - and the usb booted up without any errors.
Well done guys !!

Oh - forgot to mention - my iso was 7.8 GB.

Posted: **Wed Apr 03, 2019 1:31 pm**

rs55 wrote: Wed Apr 03, 2019 11:42 am Created a usb with this new lum ( without checking the box to disable fuseiso). Everything worked great - and the usb booted up without any errors.
Well done guys !!

I'm delighted it's working for you. If you want to take a walk on the wild side, try running it from the command line with --force=fuse.

MX Linux Forum

antiX live usb issue

antiX live usb issue

Re: antiX live usb issue

Re: antiX live usb issue

Re: antiX live usb issue

Re: antiX live usb issue

Re: antiX live usb issue

Re: antiX live usb issue

Re: antiX live usb issue

Re: antiX live usb issue

Re: antiX live usb issue

Re: antiX live usb issue

Re: antiX live usb issue

Re: antiX live usb issue

Re: antiX live usb issue

Re: antiX live usb issue

Re: antiX live usb issue

Re: antiX live usb issue

Re: antiX live usb issue

Re: antiX live usb issue

Re: antiX live usb issue

Re: antiX live usb issue

Re: antiX live usb issue

Re: antiX live usb issue

Re: antiX live usb issue

Re: antiX live usb issue

Re: antiX live usb issue

Re: antiX live usb issue

Re: antiX live usb issue

Re: antiX live usb issue

Re: antiX live usb issue

Re: antiX live usb issue

Re: antiX live usb issue

Re: antiX live usb issue

Re: antiX live usb issue

Re: antiX live usb issue

Re: antiX live usb issue

Re: antiX live usb issue

Re: antiX live usb issue

Re: antiX live usb issue

Re: antiX live usb issue

Re: antiX live usb issue

Re: antiX live usb issue

Re: antiX live usb issue

Re: antiX live usb issue

Re: antiX live usb issue

Re: antiX live usb issue

Re: antiX live usb issue

Re: antiX live usb issue

Re: antiX live usb issue

Re: antiX live usb issue

Re: antiX live usb issue

Re: antiX live usb issue

Re: antiX live usb issue

Re: antiX live usb issue

Re: antiX live usb issue

Re: antiX live usb issue

Re: antiX live usb issue

Re: antiX live usb issue

Re: antiX live usb issue

Re: antiX live usb issue

Re: antiX live usb issue

Re: antiX live usb issue

Re: antiX live usb issue

Re: antiX live usb issue

Re: antiX live usb issue

Re: antiX live usb issue

Re: antiX live usb issue

Re: antiX live usb issue

Re: antiX live usb issue

Re: antiX live usb issue

Re: antiX live usb issue

Re: antiX live usb issue

Re: antiX live usb issue

Re: antiX live usb issue

Re: antiX live usb issue

Re: antiX live usb issue

Re: antiX live usb issue

Re: antiX live usb issue