Jump to content











Photo

Switch Discs (ISO's) 'On-the-fly' / Triggered - After Initial Boot


  • Please log in to reply
7 replies to this topic

#1 jpwise

jpwise

    Newbie

  • Members
  • 12 posts
  •  
    New Zealand

Posted 12 January 2012 - 09:04 PM

Just came across your project a little while ago and looks really interesting.

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 elegantinvention

elegantinvention

    Frequent Member

  • Developer
  • 310 posts
  • Location:South Bend, Indiana, USA
  •  
    United States

Posted 13 January 2012 - 07:14 AM

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.

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. :good:

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.

Good point :cheers:

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.

Once a Kickstarter project reaches its deadline, funded or not, it can't receive any more funding via Kickstarter.
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 jpwise

jpwise

    Newbie

  • Members
  • 12 posts
  •  
    New Zealand

Posted 13 January 2012 - 11:50 PM

Glad you like the idea. :)

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 elegantinvention

elegantinvention

    Frequent Member

  • Developer
  • 310 posts
  • Location:South Bend, Indiana, USA
  •  
    United States

Posted 14 January 2012 - 12:08 AM

Yep, isosel selections are persistent through power loss / unplugging and such.
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 :cheers:

#5 TheHive

TheHive

    Platinum Member

  • .script developer
  • 4198 posts

Posted 14 January 2012 - 07:42 AM

Good Ideas.

#6 steve6375

steve6375

    Platinum Member

  • Developer
  • 7566 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films
  •  
    United Kingdom

Posted 14 January 2012 - 10:02 AM

If a file in the list is not found, then it should try the next file in the list. If the end of the list is reached it should go back to the beginning. If all entries in the list have been tried and failed, it should exit out of the loop. The ZalMan has a few issues when you plug another HDD into a controller that is already set to load an iso - it had to be reset. It is worth checking what happens when you place a freshly formatted or unformatted SD card into a controller that has already been set up with a previous SD card containing ISOs and a file load list...

#7 elegantinvention

elegantinvention

    Frequent Member

  • Developer
  • 310 posts
  • Location:South Bend, Indiana, USA
  •  
    United States

Posted 14 January 2012 - 07:54 PM

Switching cards is no problem :)
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.
At power-on, after a USB reset, or any time a card change is detected, isostick checks if isosel had previously stored a choice in internal flash. If not, the config file is used as usual. Otherwise it first compares the checksum of the config file's modification date and image filename. If this does not match then we're done, it uses the config file which has been modified since the isosel choice. If they do match then the isosel choice may still be valid, so it compares the checksum of the chosen image filename to the one in the directory entry on the microSD card. If they match then it uses that image file. If they don't match then the microSD card is different or the file is gone/moved, either way the isosel choice isn't valid so it gives up and falls back to the config file.

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 jlee928

jlee928
  • Members
  • 3 posts
  •  
    United States

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