Post Reply 
Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
sanboot -d switch
2015-01-02, 15:04
Post: #1
sanboot -d switch
Happy new year, community!

Before I fall into a trap, I'll present the actual problem instead of the question I hope to get answered.

I have a floppy disk image which cannot boot with memdisk in any permutations I have tried. It originally came on a multi-boot disc, and used some rather proprietary methods to boot the OS. It would fail if the disc were removed from system, and would not be able to run. This reads to me that a sanboot is more the way to go. I have:
sanboot -d 0x00 http://my.server/path/diskimage.ima ||

Which works ... sometimes. I have a total of two computers out of a dozen which successfully boot this. If I remove the -d switch no systems can launch the image successfully.

I'll define a failure of boot however, as it is a bit peculiar. I CAN get into the OS itself, but sometimes it will give me the following error. BTW, this is a program that runs off of a DOS clone.
Int 13h/Fun 4b01h intercept enabled. (Not emulated)

At this point, the OS looks in A: and B: for its .exe files, but cannot find them, and prompts user for a reboot.

I'm wondering if changing the -d argument gives different results depending on the motherboard. What other arguments can be passed to the -d switch? I'd Google this problem away, but I don't know what to search for. I know this has something to do with which disk it tries to boot, but what is this relative to? Is it geometry in the image, or related to the BIOS? If it's geometry, why do I get radically different results? If it is variations in board manufacturers, what other arguments should I be trying? I want a large range of compatibility for this utility.

Find all posts by this user
Quote this message in a reply
2015-01-03, 16:23
Post: #2
RE: sanboot -d switch
The argument to -d (short for --drive) is the "BIOS drive number". The first traditional floppy is 0x00, the first HDD is 0x80 and the first CD-ROM is (I believe) 0xe0. To me it seems like the OS is not accepting the sort of method iPXE is using to provide the virtual drive via Int 13h. On the problematic machines you might have luck if you try to disable any other storage controllers enabled in the BIOS. This might make the utility unusable (because it is for the storage controllers), but at least it should tell you if that is your problem area or not.

You might also be running into the issue that sanboot provides a read-only virtual drive, while memdisk gives you a read-write virtual drive. Depending on your OS/utility that might make a difference.
Visit this user's website Find all posts by this user
Quote this message in a reply
Post Reply 

User(s) browsing this thread: 1 Guest(s)