iPXE, iSCSI and int13

[mr_jrt]

Just wondering...this is all very new to me, but do iPXE's int13 hooks mean that you would expect the sanhook'ed iSCSI target to show up as a browsable (hdx) device in GRUB4DOS (command line, (hd<tab to auto complete>), or indeed, any code that utilises int13?

...also, I tried starting a thread yesterday, but it still hasn't appeared? I ended up mostly answering my own questions, but as the thread is invisible, I can't edit or delete it...

[mcb30]

(2016-03-07 00:55)mr_jrt Wrote:  Just wondering...this is all very new to me, but do iPXE's int13 hooks mean that you would expect the sanhook'ed iSCSI target to show up as a browsable (hdx) device in GRUB4DOS (command line, (hd<tab to auto complete>), or indeed, any code that utilises int13?

The iPXE SAN disk will be visible to anything that was started from within iPXE.

If you allow iPXE to exit, then the SAN drive will (usually) be unhooked.

Michael

[mr_jrt]

Thanks for that, good to know. I copied G4D up to my web server and chained it from there (just using the command line to explore what it could access) as I suspected exiting might be a factor, but still no dice (well, no SAN disks, anyway!)

Not too sure how to explore what int13 handlers are in place. Any suggestions?

[mr_jrt]

Had another poke at this this evening.

Figuring that until I figure out how to control XP setup's disk ordering I needed to remove my USB stick from the equation, I built an iPXE floppy image and copied the image from my iPXE boot CD to it so I could boot from a floppy and then install XP from the optical drive - no USB HDD needed.

As suspected, it was successful - XP text mode completed correctly. However setup stage 2 will not start - NTLDR states that it cannot open the iSCSI target:

Code:

Couldn't open drive multi(0)disk(0)rdisk(0)partition(1)
NTLDR: Couldn't open drive multi(0)disk(0)rdisk(0)partition(1)

I've tried specifying the --keep option to sanboot, but it doesn't seem to do anything:

Code:

iPXE>dhcp
Configuring (net0 <mac>)....ok
iPXE>sanboot --keep iscsi:<spec>
Registered SAN device 0x80
Booting from SAN device 0x80

<NTLDR errors>

...so it's clearly returning the bootloader.

I appreciate this isn't the place to ask for help booting XP over a SAN (and I will ask elsewhere), but if there's anything relevant to iPXe it would be appreciated.

The instructions I've been looking at are found at:
http://ipxe.org/appnote/xp_2003_direct_install
http://labalec.fr/erwan/?cat=10

..both of which suggest it should probably just work.

[mr_jrt]

Right. Seems I left a test HDD connected whilst troubleshooting, and that's where my NTLDR was coming from, which explains how boot could be failing midway.

With that disk removed, it fails in a much more expected way:

Code:

Boot from SAN device 0x80 failed: Exec format error (http://ipxe.org/2e852001)
Unregistered SAN device 0x80

So I tried switching my iSCSI server software to identify any bugs there, (switched from http://iknowu.duckdns.org/files/public/I...onsole.htm to http://www.iscsicake.com/).

...but got the exact same result.

Now, I've opened up both my backing disks in a hex editor, and I can confirm that they contain valid MBRs, identical to those described here: http://thestarman.pcministry.com/asm/mbr...br.htm#CHS

So, next step is building iPXE with int13 debugging, yes? I've tried using the https://rom-o-matic.eu/ but it doesn't seem to like me much. What is the build config for the iPXE ISO made available to download on the website? That's the only one I've found that boots without failing.

[NiKiZe]

build ipxe with make bin/ipxe.pxe DEBUG=int13:3
(rom-o-matic does not always do the correct thing, so local build box is always best for debugging)

most likely you will hit the "drive %02x does not contain a valid MBR" line here : https://git.ipxe.org/ipxe.git/blob/maste...13.c#l1778

You might also want to do a packet capture to check out that the blocks that iPXE receives actually contains what you expect them to contain.

[mr_jrt]

Thanks, I've managed to get the R.o.M. working, so have lovely debug images to play with (with syslog - thanks for adding that!)

As expected, I'm getting back a valid MBR: http://pastebin.com/raw/NBe4cYtB

...so I'm a bit stumped!

EDIT: Here's a decoded packet trace from another run: http://pastebin.com/raw/e77zcigv

[mr_jrt]

So, I'm having a looksie at the source, (and learning AT&T ASM syntax, it seems), and I'm drawn to int13_load_mbr in int13.c.

Am I reading it correctly when I read that it calls interrupt 13 function 2 with a request for 1 sector from CHS 0,0,1 from the specified drive number (0) into the buffer address (0x7c00) passed in via the variable "address", and if that succeeds, we zero-out the AX register, otherwise leave it be and save it out into the variable "status"?

I ask because that would explain why I'm seeing status 01 reported - it's read one sector (and the iSCSI side of the logging and tracing suggests this is all fine as well), but for some reason the carry flag is being set, triggering reporting as an error. I'll have to dig into the iSCSI hook to see why that would be...

Code:

Mar 11 22:27:23 192.168.60.5 ipxe: Booting from SAN device 0x80
Mar 11 22:27:23 192.168.60.5 ipxe: INT13,02 (80): Read: C/H/S 0/0/1 = LBA 00000000 <-> 0000:7c00 (count 1)
Mar 11 22:27:23 192.168.60.5 ipxe: iSCSI 0xdf214 start 28:00:00:00:00:00:00:00:01:00:00:00:00:00:00:00 in 0x200
Mar 11 22:27:23 192.168.60.5 ipxe: iSCSI 0xdf214 received PDU opcode 0x25 len 0x200
Mar 11 22:27:23 192.168.60.5 ipxe: INT13 drive 80 could not read MBR (status 01)

[mcb30]

(2016-03-12 00:21)mr_jrt Wrote:  Am I reading it correctly when I read that it calls interrupt 13 function 2 with a request for 1 sector from CHS 0,0,1 from the specified drive number (0) into the buffer address (0x7c00) passed in via the variable "address", and if that succeeds, we zero-out the AX register, otherwise leave it be and save it out into the variable "status"?

Correct.

Quote:I ask because that would explain why I'm seeing status 01 reported - it's read one sector (and the iSCSI side of the logging and tracing suggests this is all fine as well), but for some reason the carry flag is being set, triggering reporting as an error. I'll have to dig into the iSCSI hook to see why that would be...

Try adding "scsi" to your DEBUG= list.

Michael

[mr_jrt]

(2016-03-12 03:17)mcb30 Wrote:  Try adding "scsi" to your DEBUG= list.

Ok, that adds the following at level 3 (with adjacent lines for context):

Code:

Mar 12 11:47:02 192.168.60.5 ipxe: iSCSI 0xe06e4 start 28:00:00:00:00:00:00:00:01:00:00:00:00:00:00:00 in 0x200
Mar 12 11:47:02 192.168.60.5 ipxe: SCSI 0xe0b04 tag 18ae0006 READ 28:00:00:00:00:00:00:00:01:00:00:00:00:00:00:00
Mar 12 11:47:02 192.168.60.5 ipxe: iSCSI 0xe06e4 received PDU opcode 0x25 len 0x200

...which I think is coming from here: https://github.com/ipxe/ipxe/blob/7b976d...si.c#L438, but I note it returns 0?

I'm struggling to follow the call graph from the int13 hooks into the iSCSI and down to the SCSI layer, TBH, which makes figuring out where that flag is coming from rather difficult!

[mcb30]

(2016-03-12 13:32)mr_jrt Wrote:  I'm struggling to follow the call graph from the int13 hooks into the iSCSI and down to the SCSI layer, TBH, which makes figuring out where that flag is coming from rather difficult!

Forget everything so far, and grab the latest commit that I just pushed: http://git.ipxe.org/ipxe.git/commitdiff/cc9f31e. There was a regression causing the flags as returned by int13() to be overwritten during the return from VIRT_CALL(). The net effect was that OF would never be set, and so int13_wrapper would always chain to the original INT13 handler, which would obviously then fail.

Sorry you've spent so long debugging what turns out to be a (rare) regression!

Michael

[mr_jrt]

No worries, it was certainly educational. I'm reliant on the R.o.M. as I don't have a working build machine at present, and I can't for the life f me seem to get it to show your new revision, so I'll just have to wait until it does whatever it does to refresh.

Thank you for you help on this, and indeed, all your great work on iPXE.

EDIT: It's always the way...you finally post and it finally refreshes. Thanks, it's passed that hurdle...more issues, but most likely not iPXE ones