22 replies to this topic

[Magno]

Hi,

I got my isostick yesterday and started playing around with it.
However on my HP ProBook 4720s with win7 iso loaded in the config, it will not boot.
The bios does recognize the optical disk, but neither loads isosel nor win 7.
The iso_filename.txt is named correctly and does not have an extra .txt

I tried on the same machine with a VMWare machine, but that one only loads the win7 disk (so it is bootable)
I have the latest firmware applied already.

On another note, changing the ISO in iso_filename.txt changes immediatly, but clearing the file, still keeps the last iso mounted, until I unmount the isostick completely and reconnect it to my laptop. Is this normal behaviour?

Regards,
Magno

edit: created a microsoft virtual pc to try it there as well, that one also keeps booting the win7 iso.

Edited by Magno, 29 August 2012 - 10:20 AM.

[elegantinvention]

It is normal for the iso to stay mounted when you clear the file, it will however unmount automatically if the iso file

[Magno]

Hi,

It is as you said, with no isosel.bin, the selected iso loads correctly.

Maybe it is also worth mentioning that I need to explicitly choose boot options and select the USB CD-ROM Drive everytime again.

Regards

[xrobau]

Isostick tries to detect when it's being accessed from an OS instead of a BIOS, and disables isosel in that case. That's why VMs won't show isosel -- isostick has already detected that it's being accessed through an OS.

Ahha. I'm guessing THAT would be why I never get isosel when I try to boot a UEFI machine. 8-\

[elegantinvention]

@xrobau, most likely! Presently it looks at what sectors are being accessed on the disc and selectively returns isosel instead of the disc's normal boot image. That's why you also need a bootable image loaded for isosel to show up.

One of these days I need to whip up a firmware to log the first accesses to the disc, so I can get a better idea of the patterns for various machines. BIOSes almost universally read Sector 17 first, which contains the El Torito boot information. OSes almost always read Sector 16 first, which contains the list of volumes on the disc. Originally the code only looked at which sector was read first, but now it looks for specific, known patterns.

We're also playing with some sort of "chainloading," for example the idea of having isosel move itself "out of the way" in memory after delivering the ISO choice to isostick. Then isostick could stop replacing data on-the-fly for isosel, and isosel could read the original boot code into memory and jump to it.

We're also going to try creating a UEFI version of isosel which you could boot from isostick's flash drive. It would have more features, and solve the issue of detecting OS vs. BIOS in a UEFI environment.

All things to come, as soon as I'm done working out all this manufacturing stuff

[knightofoldcode]

Just an FYI, I had the same issue with a Panasonic Toughbook CF-29. Removing/renaming isosel.bin fixed the issue.

Knight.

[Lodovik]

Instead of a complex analysis of the reading patterns to determine what isoStick should do, you could use an unplug delay. Let's say you unplug isoStick in less than a second after you plugged it in, this could trigger the isosel menu mode the next time it is connected and once chosen, the iso would stay until this quick unplug is done again. I assume you can write some info into an unused space in the firmware memory. The LED could also be used to visually give a cue.

I too, have problems with the isosel menu. But I received my isoStick only yesterday so I must experiment a little with it. I haven't been able to load a Slax iso consistently with isosel activated.

[xrobau]

It would be better if there was a toggle stored in NVRam (or on the SD?) to determine which one to boot. All the new machines I've got are UEFI now, and none of them will load the selector. I have to manually change the file each time 8-(

[Lodovik]

It looks very complex to determine what to do when the isoStick is plugged. Also, I wonder if my idea of unplugging before a short delay could not damage the stick if some exchanges are already taking place between it and the computer on the USB port...

[elegantinvention]

I had the same issue with a Panasonic Toughbook CF-29

Thanks for the heads-up.

@Lodovik, that might work, but as you said it has the chance of causing problems if the computer is writing to it.

I have some ideas for fixing isosel, but have been too busy with production stuff to code them up

[taa]

Isostick tries to detect when it's being accessed from an OS instead of a BIOS, and disables isosel in that case. That's why VMs won't show isosel -- isostick has already detected that it's being accessed through an OS.

 

This is probably the reason I'm not able to get isosel to come up when booting under Virtualbox. I was attempting to test the Stick with several .iso files.

 

Is there a way to change this behavior and force isosel to come up under an OS (or VM)?

[elegantinvention]

Is there a way to change this behavior and force isosel to come up under an OS (or VM)?

 

Not at the moment. It could be added as an option, however it could only be implemented one of two ways:

1. Always boot isosel until the option is disabled: Picking an ISO from isosel would cause the chosen ISO to be loaded into the optical drive, but successive boots would still only see isosel until the option were disabled.

2. Force isosel to show up on the next boot: After enabling this then booting in a VM for example, isosel would show up. Upon choosing an ISO, the VM would reboot and from then on the chosen ISO would be booted until it is changed or isosel is forced on for the next boot by some other means.

 

UPDATE: There could be a third option where isosel is forced on no matter what for the first boot after power is applied. Unplugging then plugging back in would force isosel again on the next boot, but successive boots would behave as they do now. Just a matter of storing the fact that isosel was already forced in volatile memory on the stick so it gets reset next boot. This could potentially have issues on machines that fully remove power from USB ports during a reboot, though, if any of those still exist.

 

That said, you can always change the loaded ISO from ISO Manager on Windows (soon to also be on Linux and MacOS X), or by editing iso_filename.txt. But I suppose a "force isosel on next boot" option could be useful. I will toss it on the todo list.

[taa]

Of the three options listed, I would vote for "1. Always boot isosel until the option is disabled".

 

Thanks for listening to my suggestion. And, I really like my Stick!

[jpwise]

I've got a number of suggestions for improvements, (albeit site unseen since i've only just had a chance to order mine), but where they'd fit into the planned roadmap, and how much time you have to implement is another matter.

 

Personally i'd also lean towards always load isosel at boot, although i'm assuming the code would only be x86 compatible?  Second thought would be to put a second button/switch on it - probably programmable from config file. Default action - if triggered when powered up, launch isosel at load, if not perhaps last loaded iso.

 

Another thought i had which could be of some use, although it's implementation could be debatable, would be a rudimentary scripting option in config file for automaticing eject/insertion events - perhaps even including a rudimentary usb keyboard emulator to return a keystroke (ie: 'enter' to OK next disc has been inserted) to automate multi disc install sets.

 

It's probably easiest to wait until i physically have one in my hands to play with, but are there any plans for a feature request thread, and are you interested in hearing my ideas for suggestions to improve?  I dont' doubt not all of them will be practical to implement  with hardware capabilities, user demand, and your own time limitations, but hopefully enough of them will warrant looking into.

 

Edit: I could also find the requests sub forum after having posted that. :/

Edited by jpwise, 10 January 2013 - 10:23 AM.

[elegantinvention]

Personally i'd also lean towards always load isosel at boot, although i'm assuming the code would only be x86 compatible?

Correct @ x86 compatible only.

 

To clarify that, however: when I say always boot isosel, I mean it will never boot the selected ISO. It would *load* the selected ISO into the optical drive, but it would not let you boot from it. The reason for this is isosel must, after loading the ISO, reboot the computer. At which point it would boot isosel again. This limitation is frustrating and may be lifted in the future -- I'm still hacking on that one

Anyway that's why I listed the third option, but maybe you knew that and the first option is really what you wanted!

 

In any case I plan to add options 1 (always boot isosel, never boot iso) and 3 (boot isosel after a power cycle, still work as it does now after that) in the near future.

 

Second thought would be to put a second button/switch on it ...

Perhaps in a future hardware revision...

 

but are there any plans for a feature request thread

Looks like you found it already

and are you interested in hearing my ideas for suggestions to improve?

Absolutely! 

 

Thanks

[bblaauw]

Is ISOSEL a binary that you could load from Syslinux and/or GRUB4DOS? Plenty of ISO files use these as bootloaders, adding ISOSEL inside the ISO (or rather rebuild the entire ISO) could be an option for homemade ISO files.

(not public ISOs as your software is closed source)

[elegantinvention]

Hmm... 

 

If the iso uses a floppy image to boot then it might work. It should work from syslinux and/or grub4dos as far as I know. When used currently, isostick just returns isosel.bin instead of the first 8KB of the boot floppy image inside the iso (it will also return a different boot catalog than what is in the iso, if the current boot catalog doesn't specify virtual floppy mode).

A requirement is the iso must use a floppy image to boot, because isosel will read patterns of sectors from the floppy to signal to isostick that it is running. Then isostick will generate a list of isos on the microSD card etc etc.

I haven't given that a huge amount of thought but I think it would work. I'm not that opposed to open-sourcing isosel in the very near future, but please understand the code is not the prettiest

 

Alternatively, and more open-source friendly, though it wouldn't be as fast: something small could be written to find the isostick's flash drive via its vendor and product ID for example, then find all the .iso and .iso.0 files, presenting them to the user. Then it could write the chosen iso filename+path to /config/iso_filename.txt and reboot or otherwise somehow chainload the disc that is now loaded into the isostick's optical drive.

This could even be setup on the microSD card itself, so booting from isostick's flash drive gave you that -- the only down side to that is BIOSes that don't recognize the flash drive. Similarly the EFI version of isosel will likely boot from the isostick's flash drive, because EFI machines always seem to see the flash drive.

 

[assarbad]

It would be better if there was a toggle stored in NVRam (or on the SD?) to determine which one to boot. All the new machines I've got are UEFI now, and none of them will load the selector. I have to manually change the file each time 8-(

xrobau: can you explain what exactly you are changing? Supposedly I am running into exactly the same problem, so it would be cool if you would share your method. Thanks in advance.

[xrobau]

xrobau: can you explain what exactly you are changing? Supposedly I am running into exactly the same problem, so it would be cool if you would share your method. Thanks in advance.

 

I'm editing the iso_filename.txt to reference the ISO I wish to use. So I boot the machine, then remove the isostick, stick it in another pc, edit the iso_filename, save it, stick it back in the first machine, reboot. Annoying, but still better than DVDs. 

[xrobau]

UPDATE: There could be a third option where isosel is forced on no matter what for the first boot after power is applied. Unplugging then plugging back in would force isosel again on the next boot, but successive boots would behave as they do now. Just a matter of storing the fact that isosel was already forced in volatile memory on the stick so it gets reset next boot. This could potentially have issues on machines that fully remove power from USB ports during a reboot, though, if any of those still exist.

 

This would be best, and easiest. Just unplug/replug to get back to isosel.

[assarbad]

I'm editing the iso_filename.txt to reference the ISO I wish to use. So I boot the machine, then remove the isostick, stick it in another pc, edit the iso_filename, save it, stick it back in the first machine, reboot. Annoying, but still better than DVDs. 

Thanks for the response, but it seems in this case we're looking at separate issues. The Elitebook 8770w I have also has a UEFI, but at boot time doesn't recognize the ISOstick at all. I thought you were modifying the firmware. Btw: is that already available in source form or only as a binary? I saw there is the intention to publish it some time this year, but that could take another long 11.5 months :-|

[elegantinvention]

@assarbad, the firmware is not open source at the moment, sorry. Regarding your Elitebook 8770w, try disabling or unplugging (if possible) the internal optical drive. Many laptops, HP in particular, can only recognize one optical drive at a time.

 

EDIT: Discussion about the Elitebook 8770w will be continued here.

[assarbad]

Thanks for the response. I'll try both methods and report back in the other topic.