There was one annoying problem that I wanted to solve myself while playing with the MXLinux live installer.
There are various good reasons why the SquashFS is used.
I got odd error messages after a while with that file system, as it resided on a USB stick, which has of course its own file system which is not EXT4. The reason why explicitly state that is EXT4 is robust when it comes down to unclosed file systems / unfinished journaling writes, when your Computing system crashes for whatever reasons.
Extended Four just rolls back and then your file system is intact
The file system which is on the USB stick does not roll back when it is unmounted uncleanly.
It's the latter that damaged the ISO, in which of course the squash file system resides. The reason why the squash file system errors picked up later is because the files that I needed which were in the damage part of the ISO, only were accessed hours later after the initial boot
I got an interesting chicken egg situation, where I wanted to copy a new intact version of the ISO to the USB stick but was refused access to it by MX Linux Live.
For a reason still unclear to me I didn't think about booting from one of the other ISOs that I have there, which are tiny and also reside on the same USB stick.
Yesterday I had the logical idea to boot from one of those other ISOs.
That one is designed in a much friendlier manner, you are still allowed to access the boot USB stick. Then it was a matter of copying another version of the MX Linux ISO from another USB stick to the one where I boot from. This time I left the errored version of the ISO on the stick so that the fresh version was written to another area of the target USB stick, which obviously has file system errors that I cannot fix until it's totally unmounted. For that I need another stick which is not in the building.
The other ISO I used is Slitaz, a tiny Linux distribution which can reside totally in RAM