Jump to content











Photo

Not booting to isosel


  • Please log in to reply
50 replies to this topic

#26 MohnJadden

MohnJadden
  • Members
  • 1 posts
  •  
    United States

Posted 14 January 2014 - 09:27 PM

I saw in the Trello board that the force isosel with poweron project is in testing.  I'm juggling a bunch of isos in an attempt to build an Ubuntu box and I really could use the ability to just select from a menu, which was the big reason I got the isostick.  At this rate it's not much of an improvement over just loading optical discs.

 

Can I jump in on the testing?



#27 elegantinvention

elegantinvention

    Frequent Member

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

Posted 14 January 2014 - 09:33 PM

I saw in the Trello board that the force isosel with poweron project is in testing.  I'm juggling a bunch of isos in an attempt to build an Ubuntu box and I really could use the ability to just select from a menu, which was the big reason I got the isostick.  At this rate it's not much of an improvement over just loading optical discs.

 

Can I jump in on the testing?

Unfortunately there are major issues with the latest firmware, which is why it's still not public.

As soon as it's working decently I'll release it as public beta, which will show up in the firmware updater if you have "Show beta firmware" checked.



#28 anon000

anon000
  • Members
  • 3 posts
  •  
    United States

Posted 27 January 2014 - 01:30 AM

The tech is already outdated. That combined with your inability to fix bugs says you should probably be done with this project and move on to another.

 

A bit harsh but I can't agree more with this comment. Cool idea but basically I feel like I bought a PITA flash drive at this point. Mostly unusable.



#29 falken

falken

    Newbie

  • Members
  • 12 posts
  •  
    United States

Posted 27 January 2014 - 02:51 PM

A bit harsh but I can't agree more with this comment. Cool idea but basically I feel like I bought a PITA flash drive at this point. Mostly unusable.

yes, a bit harsh.  However, when you report a bug (which has been reported by MANY users) that makes the primary advertised feature not work and over a YEAR later there has been no advancement toward resolution, well... you know.   

 

Honestly it goes above an annoying and toward false advertising.  He knows a major feature does not work on a majority of systems however makes no effort to communicate this before purchase.  It would be a slam dunk class action, of course the company is so small he would never be able to pay the attorney fees so no one would take the case.

 

It is a USB2.0 flash drive that can not even communicate at the speeds of today's high end micro sd-cards which is still pretty slow by current flash memory standards.  Since isosel does not work on MANY systems it is more of a PITA to switch ISO's than it would be to carry around multiple flash drives, which are faster and work better.

 

PS. I know you agree with me, was just expanding on my comment.

 

Edit: I am just thankful I sent mine back instead of taking his word for it that he was working on it.  I was on the fence as it seemed dumb to return it and rebuy it if he really did fix it a few weeks later.  I suggest anyone still in the return windows that has any problems to return it ASAP.


Edited by falken, 27 January 2014 - 02:53 PM.


#30 falken

falken

    Newbie

  • Members
  • 12 posts
  •  
    United States

Posted 27 January 2014 - 03:02 PM

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.



#31 elegantinvention

elegantinvention

    Frequent Member

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

Posted 27 January 2014 - 08:05 PM

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  :yammer:

 

- Eric



#32 falken

falken

    Newbie

  • Members
  • 12 posts
  •  
    United States

Posted 27 January 2014 - 08:35 PM

I actually really appreciate the more in depth explanation and thank you for taking the time to do so!

 

I do disagree with the lack of physical interaction.  Sure, some systems only have USB on the back, however this is mostly older systems which would not be using UEFI and would work with your current implementation.  Even then a cheap extension cord solves the issue.  Just because switches can wear out is not a reasonable concern either.  Millions of consumer electronic devices have physical buttons and switches.

 

Edit: A physical switch <down = boot isosel> <up = boot selected iso> could work with every system.  After selecting your ISO a message that says, "flip switch to ISO mode and press any key to reboot".  done and done.

 

Furthermore, a simple warning on the published specs that isosel does not work with UEFI is a reasonable thing that seems has still not been done.  As it is most people are not going to be aware of this until they purchase it and go investigating on why it is not working.

 

If your published specs said isosel does not function with UEFI machines then I never would have even said anything to start with.


Edited by falken, 27 January 2014 - 08:38 PM.


#33 Pest

Pest
  • Members
  • 6 posts
  •  
    New Zealand

Posted 27 January 2014 - 08:36 PM

Thanks Eric for describing the situation and I hope your Fathers condition improves.

 

While some of the comments above are quite scathing, please take this as an indication that what you have created is of great consequence to people (which is a good thing). I personally use the ISOStick regularly and when it works, it's a godsend (which is most of the time) but for the same reasons when it doesn't work, it can be ... extremely inconvenient.

 

I think the statement above, that without booting to ISOSEL the 'Stick is no better than a regular USB stick is invalid though. You still have all your ISO's available to you and changing which one boots can be achieved by plugging it into _any_ computer nearby and modifying the text file, or running iso-manager (which you have a copy of on the stick, right? of course you do, you're not an idiot). I've never yet been in a situation where this wasn't possible and it only takes a couple of minutes.

 

Keep plugging away, remember to keep your eyes on the prize (you can make the code as sexy as you like in the back end, but that's not what your customers see so they don't care about it, they care whether it works or not. Try to find a balance) your efforts are appreciated.

 

Luke.



#34 Pest

Pest
  • Members
  • 6 posts
  •  
    New Zealand

Posted 27 January 2014 - 08:42 PM

Err, one more thing though...

 

I never ever bother with the read-only switch on the side. Frankly it's never been an issue so I just leave it in write mode.

 

Could this switch be commandeered in firmware to instead be an "I want ISOSEL" switch? When red, boot ISOSEL, when not, boot the iso. No decision making neccesary. If this were possible, you could offer it as an alternative firmware download for those who need it. I'd use it.

 

Luke.



#35 timball

timball
  • Members
  • 1 posts
  •  
    United States

Posted 27 January 2014 - 09:52 PM

i also have borked my ISOSTICK via FreeDOS (should have read the thing before i hit the enter button) , just hoping for a fix soon . obvs reinstalling firmware didn't do anything . 

 

when it does tries to boot it says this: 

 

Loading code...

Launching main program...

 

Main program starting...

Copied isosel database.

Handshake 1 failed... 

DiskReadSector error in int13 function 2. Code: 0001

 

anyways cheers for trying to fix the bug . the isostick has really saved my bacon a bunch of times .

 

--timball



#36 elegantinvention

elegantinvention

    Frequent Member

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

Posted 28 January 2014 - 04:55 PM

Err, one more thing though...

 

I never ever bother with the read-only switch on the side. Frankly it's never been an issue so I just leave it in write mode.

 

Could this switch be commandeered in firmware to instead be an "I want ISOSEL" switch? When red, boot ISOSEL, when not, boot the iso. No decision making neccesary. If this were possible, you could offer it as an alternative firmware download for those who need it. I'd use it.

 

Luke.

That is a possibility, but I'm curious what your opinions are here: when "Force isosel after power on" is finally enabled in public firmware, you will always get isosel at least every other time, regardless of BIOS/UEFI/etc, without fail. While it's still every other time, I think this largely solves the problem without needing to poke at the switch. Unplugging then plugging the isostick back in serves almost the same purpose, in that case (or just doing a shutdown then power on of the PC).

 

The concern with overriding the switch behavior is in some companies the switch is used during virus scans for example, to protect the microSD card. While arguably they could make it corporate policy that employees should never activate options that override read-only switch behavior to avoid costly mishaps, the ability to change the switch behavior at all may blindside them. So, if I were to include this option, I would keep the read-only/read-write behavior the same, while piggy-backing the "force isosel" / "boot iso" functionality onto it. It seems a little complicated, but I think it might be a decent compromise.

 

Either way, certainly this problem can and will be solved. Looking forward to everyone's input on the above.

 

Furthermore, a simple warning on the published specs that isosel does not work with UEFI is a reasonable thing that seems has still not been done.  As it is most people are not going to be aware of this until they purchase it and go investigating on why it is not working.

While it is mentioned in the FAQ under "Why isn't isosel showing up?", I can see how that's more something you check after you have the device and are experiencing problems. So, I will make a blog post on isostick.com explaining the issue and link to it along with a note about the problems on the isostick.com landing page. Hopefully that will make potential buyers more aware of the issue.



#37 elegantinvention

elegantinvention

    Frequent Member

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

Posted 28 January 2014 - 05:00 PM

i also have borked my ISOSTICK via FreeDOS (should have read the thing before i hit the enter button) , just hoping for a fix soon . obvs reinstalling firmware didn't do anything . 

 

when it does tries to boot it says this: 

 

Loading code...

Launching main program...

 

Main program starting...

Copied isosel database.

Handshake 1 failed... 

DiskReadSector error in int13 function 2. Code: 0001

 

anyways cheers for trying to fix the bug . the isostick has really saved my bacon a bunch of times .

 

--timball

Strange, this could be caused by a corrupt ISO loaded into isostick's CDROM drive, or filesystem problems.

Try running a scandisk:

 - Right-click isostick flash drive in Windows Explorer

 - Click Properties

 - On the Tools tab, click "Check Now" (or simply "Check" in Windows 8)

 - Click Start

 - Wait for the test to finish

 - Right-click the isostick flash drive again and Eject it

 - Unplug and plug the isostick back in.

This ensures the filesystem is in a clean state.

Also try loading a different bootable ISO into isostick's CDROM and see if that fixes the problem. If not, open a ticket and we'll get this resolved.

:cheers:



#38 falken

falken

    Newbie

  • Members
  • 12 posts
  •  
    United States

Posted 28 January 2014 - 06:43 PM

I think the statement above, that without booting to ISOSEL the 'Stick is no better than a regular USB stick is invalid though. You still have all your ISO's available to you and changing which one boots can be achieved by plugging it into _any_ computer nearby and modifying the text file, or running iso-manager (which you have a copy of on the stick, right? of course you do, you're not an idiot). I've never yet been in a situation where this wasn't possible and it only takes a couple of minutes.

 

A modern USB3.0 flash drive can have an ISO written to it in a matter of seconds.  If I need to plug the stick in to my laptop, boot up, insert the stick, modify the txt file/run iso-manager, unplug it, plug it back in to the destination machine. I can just as quickly pick the ISO from my laptop and write it to the generic stick.  Or just carry around multiple 8GB sticks as I have obtained fast sticks for less than $15 on sale.

 

The point of this device is to not have to bother with another PC.  Just grab the stick, plop it in the destination system, pick the ISO and go.

 

As soon as ISOSEL will work on almost any machine(by any method that does not involve using another PC)  I will be the first to rebuy it.



#39 falken

falken

    Newbie

  • Members
  • 12 posts
  •  
    United States

Posted 28 January 2014 - 06:46 PM

That is a possibility, but I'm curious what your opinions are here: when "Force isosel after power on" is finally enabled in public firmware, you will always get isosel at least every other time, regardless of BIOS/UEFI/etc, without fail. While it's still every other time, I think this largely solves the problem without needing to poke at the switch. Unplugging then plugging the isostick back in serves almost the same purpose, in that case (or just doing a shutdown then power on of the PC).

 

The concern with overriding the switch behavior is in some companies the switch is used during virus scans for example, to protect the microSD card. While arguably they could make it corporate policy that employees should never activate options that override read-only switch behavior to avoid costly mishaps, the ability to change the switch behavior at all may blindside them. So, if I were to include this option, I would keep the read-only/read-write behavior the same, while piggy-backing the "force isosel" / "boot iso" functionality onto it. It seems a little complicated, but I think it might be a decent compromise.

 

Either way, certainly this problem can and will be solved. Looking forward to everyone's input on the above.

I did not recall.  The stick has a read/write switch!?  I would love to see that reprogrammed!  Perhaps a config file on the drive could say if you wanted to use the switch or the new power on/power off method?

 

Edit: And yes, Force ISOSEL could still be write protected mode as normal operation would be in boot mode(read/write).


Edited by falken, 28 January 2014 - 07:26 PM.


#40 Pest

Pest
  • Members
  • 6 posts
  •  
    New Zealand

Posted 28 January 2014 - 09:14 PM

That is a possibility, but I'm curious what your opinions are here: when "Force isosel after power on" is finally enabled in public firmware, you will always get isosel at least every other time, regardless of BIOS/UEFI/etc, without fail. While it's still every other time, I think this largely solves the problem without needing to poke at the switch. Unplugging then plugging the isostick back in serves almost the same purpose, in that case (or just doing a shutdown then power on of the PC).

 

The concern with overriding the switch behavior is in some companies the switch is used during virus scans for example, to protect the microSD card. While arguably they could make it corporate policy that employees should never activate options that override read-only switch behavior to avoid costly mishaps, the ability to change the switch behavior at all may blindside them. So, if I were to include this option, I would keep the read-only/read-write behavior the same, while piggy-backing the "force isosel" / "boot iso" functionality onto it. It seems a little complicated, but I think it might be a decent compromise.

 

Either way, certainly this problem can and will be solved. Looking forward to everyone's input on the above.

 

Having thought about it since I wrote that post, the idea of physically selecting isosel or not really appeals to me.

 

There have been several times when I've been using isostick with recovery tools like the gparted live CD and having to boot back to it several times. Make a change, boot to local disk, fail, boot to iso, make a change, boot to local disk, wash, rinse, repeat. With isosel coming up every other time that can make an already tedious process even more tiresome. In those situations I really only want to run isosel once at the start of the process and not again.

 

Regarding your concern over the switch, surely if they have access to change the options file, they also have the ability to physically change the switch? I don't see that you're losing any security there.

 

Alternatively, surely it would be pretty easy to alter your build process so that it's a compile time option and you automatically build an alternate firmware image each time you build? I see above that maintainability is important to you (as it should be) but I don't think having multiple binaries coming out of one source tree is a problem there, your build will just take a little longer.

 

Luke.


Edited by Pest, 28 January 2014 - 09:33 PM.


#41 Pest

Pest
  • Members
  • 6 posts
  •  
    New Zealand

Posted 28 January 2014 - 09:28 PM

Edit: And yes, Force ISOSEL could still be write protected mode as normal operation would be in boot mode(read/write).

 

Actually, perhaps the opposite would be more appropriate?

 

Let say you implement the switch as an isosel selector. When in isosel mode, the stick is read-write so you use this mode when you want to modify the flash contents. When you're doing this you don't care what's mounted and in fact it's safer since you can't accidentally delete the mounted iso. Then when it's in iso mode it's read only. For the anti-virus example you gave, this would be perfect. Once you've got your AV iso selected you can safely leave it in iso mode and plug it from machine to machine knowing it's read-only.

 

Switching modes while it's plugged in would be handled no differently than how it currently handles an iso selection change (I assume it fakes an eject/insert?) although I don't know if you can change the read-write state of the mass-storage device on the fly. Perhaps eject/insert that too?



#42 elegantinvention

elegantinvention

    Frequent Member

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

Posted 28 January 2014 - 11:02 PM

Actually, perhaps the opposite would be more appropriate?

 

Let say you implement the switch as an isosel selector. When in isosel mode, the stick is read-write so you use this mode when you want to modify the flash contents. When you're doing this you don't care what's mounted and in fact it's safer since you can't accidentally delete the mounted iso. Then when it's in iso mode it's read only. For the anti-virus example you gave, this would be perfect. Once you've got your AV iso selected you can safely leave it in iso mode and plug it from machine to machine knowing it's read-only.

 

Switching modes while it's plugged in would be handled no differently than how it currently handles an iso selection change (I assume it fakes an eject/insert?) although I don't know if you can change the read-write state of the mass-storage device on the fly. Perhaps eject/insert that too?

I think that arrangement makes perfect sense!

Indeed you can change read/write status on the fly, it's inconsequential at boot time anyway since the USB device will often be reset at least once before being booted again. Within an OS the story is a little different: Windows doesn't mind a sudden change and seems to handle it appropriately, whereas Linux and MacOS X require remounting so far as I know, but I don't think linux/osx require a full unplug/replug cycle, just remount. Though it may be easier to just cleanly eject and replug than to remount, depending on the environment  :whistling:

 

 

Regarding your concern over the switch, surely if they have access to change the options file, they also have the ability to physically change the switch? I don't see that you're losing any security there.

The concern is that employee A might change the setting for whatever reason, disabling the read-only capability. Then employee B would pick up employee A's isostick to work on a machine, not knowing the read-only functionality is changed/disabled. While this can be enforced in company policy or etc, I do think that since read-only / read-write is the "well known" functionality of the switch it shouldn't be changed, only added on to. That way there is no possibility of destructive mistakes.

 

Granted, this scenario is really unlikely outside of a corporate IT setting. I suppose if this or other features were conceived which would completely take over the switch, eliminating the read-only-ness, they could be a separate build as you suggest. To avoid problems as above, I suppose the firmware updater could have an option to show these firmwares, with a sufficiently obnoxious warning about switch behavior changes when you enable viewing of those builds. Of course they could also be (less conveniently) distributed as files, since the updater already accepts arbitrary firmware files. Just thinking out loud here.



#43 BrotherDust

BrotherDust
  • Members
  • 1 posts
  •  
    United States

Posted 20 February 2014 - 05:42 AM

I really love the idea of this product and I don't want to discourage the developer. My suggestion? Open-source the firmware and isosel. Seriously. If the developer does that, then the community will be able to take ownership and make a better product. Want support? Gotta have the official firmware. Want to fix a bug? Submit a push request to the repo. How can this be bad?



#44 bahansen.us

bahansen.us
  • Members
  • 1 posts
  •  
    United States

Posted 12 November 2014 - 11:14 PM

Are there any updates to this issue?  I purchased the ISOSTICK for Incident Response within my place of work.  It is important to have the write protect, and the ability to change ISO's on boot.  We currently use DELL laptops, and I’m unable to get isosel to ever come up.   Only the current ISO that is selected in the config file.



#45 Pest

Pest
  • Members
  • 6 posts
  •  
    New Zealand

Posted 13 November 2014 - 08:24 PM

I really love the idea of this product and I don't want to discourage the developer. My suggestion? Open-source the firmware and isosel. Seriously. If the developer does that, then the community will be able to take ownership and make a better product. Want support? Gotta have the official firmware. Want to fix a bug? Submit a push request to the repo. How can this be bad?

 

I have to agree with this, it's been almost 2 years since there was any kind of release and there are some of us which are capable and willing to make this better.

 

As a developer myself, I totally understand the "it's not ready/it's too ugly for the light of day" but I also know that odds are good it never will be! Take the plunge and set it free, what have you got to lose?


  • bahansen.us likes this

#46 sbromulo

sbromulo
  • Members
  • 5 posts
  •  
    Brazil

Posted 04 September 2015 - 06:02 PM

Hello all. My Isostick arrived 2 weeks ago, and I made some tests with different computers.

At my home, I have a macbook air. The isostick works very well with it.

At my work, I have only Dell desktops and notebooks. No one shows the isosel menu.

I have made some tests on Dell desktop Optiplex 9010, Dell notebook Latitude E6430, Dell workstation T5810... all of them do not show isosel.

At my notebook, if I use the isostick manager to load up the windows 7 iso, and after that if I connect the isostick on the Dell desktop, it can boot the windows 7 installation perfectly without show the isosel menu. But, I made the same test with other isos, and they don't work.

 

Is there some solution to that?

 

Thanks,

Romulo - Brazil



#47 elegantinvention

elegantinvention

    Frequent Member

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

Posted 11 September 2015 - 02:51 AM

Hello all. My Isostick arrived 2 weeks ago, and I made some tests with different computers.

At my home, I have a macbook air. The isostick works very well with it.

At my work, I have only Dell desktops and notebooks. No one shows the isosel menu.

I have made some tests on Dell desktop Optiplex 9010, Dell notebook Latitude E6430, Dell workstation T5810... all of them do not show isosel.

At my notebook, if I use the isostick manager to load up the windows 7 iso, and after that if I connect the isostick on the Dell desktop, it can boot the windows 7 installation perfectly without show the isosel menu. But, I made the same test with other isos, and they don't work.

 

Is there some solution to that?

 

Thanks,

Romulo - Brazil

The isosel menu not showing on Dells is a known issue, and I'm working on it :)

 

Regarding being unable to boot other isos, that should work fine even if isosel is not working. You could try disabling isosel to see if maybe there's some strange interaction there. To disable isosel, simply rename isosel.bin to something else, such as isosel-disabled.bin

What other isos did you test that didn't work?



#48 Sidewinder

Sidewinder

    Newbie

  • Members
  • 26 posts
  •  
    United States

Posted 13 September 2015 - 02:39 AM

UEFI has been out for some time.   I'm sure if he contacted and brought in someone else capable of doing that part of the job it would bring a new firmware update pretty damn quick.



#49 sbromulo

sbromulo
  • Members
  • 5 posts
  •  
    Brazil

Posted 18 September 2015 - 05:11 PM

The isosel menu not showing on Dells is a known issue, and I'm working on it :)

 

Regarding being unable to boot other isos, that should work fine even if isosel is not working. You could try disabling isosel to see if maybe there's some strange interaction there. To disable isosel, simply rename isosel.bin to something else, such as isosel-disabled.bin

What other isos did you test that didn't work?

 

Hi, so, I have made some tests, and the result is:

 

1) To make the isostick work on dell computers, I need to enable CD/DVD boot on bios and put this option on the first try of the BIOS. Before doing this, I need to plug the isostick on another computer, open the iso-manager app and load the .iso that I want to run on the computer. But the isocel do not work at any way, and I will wait for the correction.

 

2) With the procedure above, all the .iso works perfectly.

 

3) I buy a micro-sd from the brand Sony, model SR64UY2A/TQ, 64 GB, and works perfectly. If you wish, please, update the website http://wiki.isostick...le=Tested_Cardswith this information.

 

Thanks,

Romulo



#50 elegantinvention

elegantinvention

    Frequent Member

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

Posted 23 September 2015 - 09:19 PM

Thanks for the update! I've added the card you mentioned to the wiki  :good:






0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users