Suggestion: How about a boot to isosel and record the time. Any boot in the next 60 seconds loads the selected ISO, after 60 seconds it loads isosel again?
Don't know your exact problems however that seems like a reasonable workaround that should be working without any hardware modifications (a button or something would be a better option).
Just one of many band-aid fixes I thought of. I do not see why you couldn't get SOMETHING to work by now.
The suggestion is appreciated, but there are a few problems here. I'm not very good at explaining the inner workings of isosel, but I'll give it a shot:
Since I am not aware of a consistently reliable and universally implemented way of chainloading from isosel to any ISO, isosel currently takes the safe route and does a reboot after instructing isostick to switch to the chosen ISO. So we cannot for example rely on isosel running, checking the system's real-time clock, then deciding whether to boot the last-chosen ISO or not. At least, not without an extra reboot shoved in there after checking the time.
I mention the real-time clock because in some cases the isostick may lose power during a reboot, so the time between successive boots may not be known in all cases. Also a number of customers use isostick on large servers which takes multiple minutes to boot. While the timeout period could be configurable, that doesn't solve the problem of systems which remove power briefly between boots.
Physical interaction such as a button was ruled out early in the design process because in many cases the isostick must be plugged in at an inconvenient location, such as around the back of a machine. Reaching back there after applying power (so isostick is running) but before the system boots to it was deemed too much hassle. While arguably the option could still have been included, hardware has a finite cost and mechanisms may fail over time.
However, the larger problem (and indeed the reason isosel sometimes does not show up, particularly on UEFI systems) is that isostick cannot reliably detect when the system is booting. The only thing isostick sees is sector reads, where a read has an LBA and a length in blocks.
The solution I came up with was to look at patterns of sector reads starting from when the isostick is enumerated over USB, and based on the patterns try to determine if it's talking to a BIOS/UEFI which is trying to boot it, or an already-running OS. The idea was: if it looks like the system is booting from isostick and isosel was not shown last boot, show isosel this time then set a flag so it won't run next time, and so on. In this way, isosel shows up every other boot. It must be every other boot because of the necessary reboot to reliably boot into the chosen ISO.
What happens with UEFI (and more rarely some BIOS) systems is that the pattern of sector reads looks nothing like a typical BIOS boot. UEFI indeed looks more like a running OS than something trying to boot the isostick. What happens in this case is the flag never gets reset, and so isosel is shown once and then never again (until booted in a system where it recognizes the boot reads). After messing with it for a while, it became clear that this would simply become a maintenance nightmare and would never be 100% reliable.
Given the above, I decided the best fix was as described here. This should be reliable, and function very similarly to what isostick has now. Implementing it indeed did not take very long, although some code clean-up was done simultaneously which extended things.
So, why isn't it released? Initial testing while writing the patch worked great. Going through a more complete test suite, things fell apart. It revealed a subtle bug in my USB stack, which made it unreliable in the majority of cases -- it wasn't even suitable as a beta release, it just did not work under most conditions.
The USB stack was hastily written in hopes of getting things done quickly, which was foolish and is the reason this bug exists. Upon looking at the code to try and fix the bug, it quickly became clear that my time is better spent rewriting parts of the USB stack. In the process I ran across numerous other modules that either needed to be thoroughly combed through and updated. While I could ignore most of this and just continue to apply quick fixes, this code is not standalone for isostick, it is a set of libraries which I will use in other products, and so I want to update it properly, which takes time.
As mentioned in passing above, the isostick has grown to much more than just some code to emulate a CDROM drive. A complete framework of portable, object-oriented code has been written to support its functionality: extensible USB, SCSI, and filesystem stacks, generic block- and stream-based device interfaces, a basic event system, and so on. Combined, this framework spans hundreds of files and tens of thousands of lines of code, so bringing it to a well-written and maintainable state is a complex task, one that I was not previously prepared for.
My primary goal is to bring this framework to maturity for the benefit of both isostick and future projects, including future hardware revisions of isostick. This would allow the majority of patches to be portable between products and thus reduce overall maintenance burden and accelerate future development.
Anyway, my intention here is not to excuse the delays, but simply to describe the situation in more detail. The reality is that, having worked on this product for around three years with no break, and not having experience in managing such a large codebase, I felt that I needed to work on something else for a while. As indicated by the activity on Trello, around September of 2013 my work on isostick dropped to almost zero. In late November / early December I started to dig into the code again with fresh eyes, and good progress was being made. Then we found out my father has a heart condition, and he has been in and out of the hospital since then. Again, none of this is an excuse. I could have managed my time better and avoided the burn-out late last year, and while my father being ill leaves less time and focus for work, it certainly does not prevent me from working altogether.
In conclusion, thanks for reading this. It was likely more than you expected, but I wanted to let you know what's going on other than just "I'm busy, sorry." Suggestions are still welcome of course, and I'll try to be less wordy next time
- Eric