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!
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"?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)
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.
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.
