Your last post stated clearly that for you LaunchELF v3.46 was completely incapable of launching any ELF. Now you say that it sometimes can, but is not consistent about it.
To me that would mean either that LaunchELF itself is damaged, which it seems you have tested for, or that the ELFs you want it to run are damaged, or that some hardware is so bugged/broken that nothing can operate properly.
NB: No one else has reported v3.46 as refusing to run ELFs, so it is an error unique to your setup. This means that we must question the validity of that setup, and the most suspect item of those you mention is your 64MB MC.
Please try the following:
Originally Posted by cmal1492
Install BOOTc.ELF of "uLaunchELF v3.46", together with its default LAUNCHELF.CNF to a folder on your 8MB MC. (But not the folder where you have v3.41r working, and not to /SYS-CONF/).
Do NOT take either of those two files from the 64MB MC, but unpack fresh copies from the ZIP, and use those.
After this, reboot with the 8MB card and use v3.41r to start v3.46.
Finally test if v3.46 now also can start ELFs (like itself for example :)).
That should work, both consistently and reliably.
Just so you know:
Leads me to look a little deeper... perhaps corruption/fragmentation on the memory card is a problem (I have know this type of thing to slow down game saves before, and break infinities application manager entirely)
Such problems are extremely rare on proper MCs that are used properly.
Wrong. uLaunchELF has no problem dealing with subfolders. That is not the cause of the problem.
The problem appears to be me breaking the "golden rule" of not having directories within directories. Older version of uL seem OK with running files inside of these directories but not in these latest revisions.
It is a good idea to avoid subfolders on MC, but once you have real corruption there is NO way to cure it other than to reformat. Just eliminating subfolders will not remove corruption that has already occurred.
My bad, I will move my files up a level and suffer having to find some more icons to get rid of the corruption.
The drivers can access subfolders, but that is not the problem. The real problem is the official PS2 browser, and possibly some other commercial software using similar routines.
Thanks for looking into it dlanor. I wish I had a better explanation for why its not a good idea to have folders inside of folders than my assumption that the MC access drivers dont like it, and why it seems to be getting pushed out slowly as the program advances.
Those routines simply assume that no subfolders exist, and don't use the generic fileio methods to access them (which would work). Instead they dig directly into the raw directory sectors, still with the assumption that folders can only exist at top level, so they treat anything inside top level folders as files, which is not a good thing to do with folders...
When such methods are used to copy a folder with subfolder content, then the wrong amount of MC space may be allocated for the copy, which will in any case be incomplete. The miscalculated amount of space is simply lost, and can only be regained by reformat.
When those methods are used to erase a folder with subfolder content, then all space used by those subfolders and their content will also be lost until the MC is reformatted. By lost I don't mean erased, as erased items have their space released, but subfolder content will in these cases simply be ignored, and never released.
Some tests also indicate that the operation of the 'remaining' space on such an MC becomes unreliable, possibly because drivers become confused by conflicting information in some directory sectors after such mismanagement.
Good, do that for the future then, but be aware that it doesn't cure present corruption (like I said above).
No biggie though, Im sure I can scam some icons somewhere... or suffer a mass of duplicates.
Sure, it should be able to do that.
On another interesting note: the mcPaste function backed up my 64MB memory card to host completely, subfolders and all ;)
But if you really have corruption on that MC, then the value of the backup is dubious. 'mcPaste can only save what is present, and if that was corrupted already, then the backup will be so too.
I repeat. If both LaunchELF and the other ELFs are undamaged, then LaunchELF should be able to launch them regardless of the folder level they are stored in. Those routines have no known problems with subfolders.
edit:/ I can launch alot more of the nested files after reupping the BOOT.elf (the compressed one) using flashfxp instead of windows explorer. Not sure what difference that makes but..
Sorry, but to me that seems typical of failing hardware.
edit2:/ well, Im really at a loss now, I formatted the entire card and put the files on with no subfolders and I am still getting alot of problems. For example, I can run the file mc0://BOOT/BOOT.ELF (which is uL, but it crashes when it runs) but I cannot run the file mc0://MATRIXTEAM/MANAGER.ELF (which is the same uL, but it gives the "not an elf file" message and promptly halts/crashes) - after multiple tries I am indeed able to run the file some of the time, occasionally it even boots up uL again. Im figuring its running it instead of giving an error about it not being an elf 1 in 10 reboots
I mean, a digital program running the same test on the same digital file repeatedly should give the same result EVERY time, not just 9 out of 10.
I suspect that MC is 'dying', though it may be some less fatal problem too.
(Bad/dirty/oxidized connectors, for example.)
Sorry, but I disagree. What you say would be true if others had the same error, but you are the only one who has reported anything like this.
I think the ELF "detection" needs to be looked at again with the latest changes that were done to increase bootrates and such.
The fact that all the tests are erratic in their results may in itself be a clue, at least I take it as such. And to me that clue hints at a hardware problem of some kind. And if it is the MC that is failing, then LaunchELF can also be expected to show weird bugs, as it was loaded from a failing device, and may have been corrupted in that process.
It really should not be crashing if it gives the error "this is not an elf" on an elf file (and it seems to be pretty erratic as to when this happens for me).
Please do the tests I asked you to, near the top of this post, to see if v3.46 works better on another MC of the standard 8MB type.
Best regards: dlanor