Switch Discs (ISO's) 'On-the-fly' / Triggered - After Initial Boot
#1
Posted 12 January 2012 - 09:04 PM
A bit of a side question though is, is it possible to switch disc images on the fly? ie: emulate eject, switch image, and re-insertion of disc? - after the initial boot that is.
The reasoning behind the question is related to multi disc install sets. I work in a laptop service centre and as a matter of course we have to re-install alot of laptops, for most units we keep physical cd's which are prone to getting scratched/damaged over the course of time. Most of the install sets range between 2 and 4 discs. The disc change always occurs after boot, so isosel wouldn't really be feasible in this situation.
For the most part, most recovery systems will trigger an eject and prompt for the next disc to be inserted, so in theory it would be possible to honour the eject request, read a sequence list (txt file), and load the next disc in the set with an insert notification.
Ideally it would be awesome if there was an option to push button force a rotation to the next disc in the set (and loop around if you miss one/have to insert 1st disc again), but lacking a physical button, or abusing the read/write switch as a trigger, a list file would be the next best option.
edit: as an addendum a sequence/next image in list could also be useful if you implement virtual cd->iso writing functionality i've seen mentioned a few times. particularly to set the notify disc type/atip data, single layer, dual layer, ?blu-ray?, etc.
Your thoughts?
Also I see the kickstart pledges has already topped out, is there any indication of sale price yet, or if i sign up to the kickstart with a donation would i be able to get access to a unit? Thx.
#2
Posted 13 January 2012 - 07:14 AM
Great idea! I don't see any reason it can't be implemented.A bit of a side question though is, is it possible to switch disc images on the fly? ie: emulate eject, switch image, and re-insertion of disc? - after the initial boot that is.
...
For the most part, most recovery systems will trigger an eject and prompt for the next disc to be inserted, so in theory it would be possible to honour the eject request, read a sequence list (txt file), and load the next disc in the set with an insert notification.
At a glance the only thing I'm not sure of is how to specify the sequence file to use. I suppose it could be specified instead of an image file. It could also be done "implicitly" by naming the files for example image1.iso, image2.iso, etc, all in the same folder, then mounting any one of them, though that may be undesirable in some situations (don't want them named sequentially like that, don't want it done implicitly but DO want them named like that, ...). Just tossing some ideas out there.
Regardless, the code to actually load the next image file after an eject operation is trivial, as is parsing the sequence, whatever method is chosen. So, I've put it on the to-do list.
Good pointedit: as an addendum a sequence/next image in list could also be useful if you implement virtual cd->iso writing functionality i've seen mentioned a few times. particularly to set the notify disc type/atip data, single layer, dual layer, ?blu-ray?, etc.
Once a Kickstarter project reaches its deadline, funded or not, it can't receive any more funding via Kickstarter.Also I see the kickstart pledges has already topped out, is there any indication of sale price yet, or if i sign up to the kickstart with a donation would i be able to get access to a unit? Thx.
No retail price / availability yet, still working on the Kickstarter units, but things are moving along. Once they're available for sale I'll be sure to post here on the forums, the blog, twitter, and isostick.com will have information on buying them (for now it just redirects to the Kickstarter).
Thanks for the interest and the suggestion, I like it!
#3
Posted 13 January 2012 - 11:50 PM
In terms of specifying the image file since you've already got isosel tied in, it would probably be easiest to specify the sequence list file with isosel as a starting point. Are the isosel selections persistent? as in do the selections remain through powerdowns/unplugging etc? It might not ever be an issue but if an install set requires rebooting part way through install, and then resuming the presented iso will need to remain constant, even if it's part of a set.
Also for the writing side, the option to set it to a blank disc(s) would need to be available to either the os, or still have to be set at boot time. If you're writing to a virtual disc the requirement option in burning software to verify can probably be safely turned off, but any eject/re-insert events would still need to be handled correctly.
Otherwise I've already followed your twitter, so will keep an eye on how things go.
#4
Posted 14 January 2012 - 12:08 AM
Even if you have it set read-only -- but in that case it writes to the CPU's internal flash, instead of the microSD card, so it still honors the read-only switch. In that case isosel warns you that your selection won't show up in the config file / software, but that it will still persist.
I'll be whipping up an application for osx/win/nix which can be run within an OS to switch images and do other setup. Ultimately isostick gets all its setup information from files on the microSD card, and the software will just be a nice GUI to make modifying them trivial, so adding that to the software shouldn't be a problem
Thanks for the follow
#5
Posted 14 January 2012 - 07:42 AM
#6
Posted 14 January 2012 - 10:02 AM
#7
Posted 14 January 2012 - 07:54 PM
isostick doesn't keep a list of ISOs, it rebuilds the list on the fly whenever it's needed.
Here's some details on the process:
Normally isostick reads a config file to determine which image to load and isosel writes to this config file if the stick is not read-only.
At present, the config file is /config/iso_filename.txt and it only contains the filename with full path of the chosen image.
When isosel is used and the isostick is read-only, forcing it to store data outside the microSD card, what it actually stores is:
- The location (LBA and byte offset) of the directory entry of the image chosen by isosel.
To reduce wear on the CPU's internal flash, a circular buffer is used. The LBA and offset are small and fixed-size, and hence easy to use in such a circular buffer. This is also designed to withstand partial (failed) writes, in the unlikely event that the isostick gets unplugged suddenly before the write is complete -- in such a case it will fall back whatever image was previously chosen, as if the failed choice had never happened. - A checksum of the filename in the chosen directory entry.
- A checksum of the config file's modification date/time and the image filename it contains, if any.
Filename is stored because, if you want to return to the same image stored in the config file it cannot just compare the filenames because the previous and current filename would be the same (config file couldn't be changed by isosel because stick was read-only); in this case the modification date/time difference changes the checksum. On the other hand, it is unlikely but possible the config file can be changed and result in the same modification date/time, so that is included as a backup.
In any event if the config file is not present it defaults to an empty optical drive.
No worries about the speed of rebuilding the image list, either. It's been thoroughly tested with a 7-level deep directory structure full of several dozen image files and the time required to populate the list is not noticeable. Currently the only time the list is needed is when entering isosel, so the isostick can pass the list on to isosel. Any other time the image name in the config file is used and no list is necessary.
#8
Posted 13 September 2012 - 08:29 PM
Great idea! I don't see any reason it can't be implemented. At a glance the only thing I'm not sure of is how to specify the sequence file to use. I suppose it could be specified instead of an image file. It could also be done "implicitly" by naming the files for example image1.iso, image2.iso, etc, all in the same folder, then mounting any one of them, though that may be undesirable in some situations (don't want them named sequentially like that, don't want it done implicitly but DO want them named like that, ...). Just tossing some ideas out there. Regardless, the code to actually load the next image file after an eject operation is trivial, as is parsing the sequence, whatever method is chosen. So, I've put it on the to-do list.
Maybe you can set it up with a list file, namely with an extension of *.lst or simply *.list or anything ending with *.list.txt.
To load the next disk, flip the switch to unlock to eject and lock to load the next disk image? Actually this can be a built-in feature? To mount any disk, the isostick have to be in a locked state?
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users