Replies: 3 comments 5 replies
-
|
You can not use #define in iPXE scripts. Not an issue just a note. Have you read the error message, especially followed the link https://ipxe.org/1d704098 and read that full page? Once you get your iSCSI working by reading that page... The next issues you will have is BSODs due to windows kernel not being able to reach iSCSI. |
Beta Was this translation helpful? Give feedback.
5 replies
-
I've removed the #define references in my autoexec.ipxe script and have uncommented the CONSOLE_SYSLOG console type in /src/config/console.h . Thanks for pointing that out. SYSLOG is working well.
That page was one of the first I read while writing my script and subsequent debugging efforts. I have re-read the sub-link https://ipxe.org/sanuri as well as the linked post regarding the OP having ISCSI read errors during iPXE boot. This post was in particularly insightful and I'm glad the OP got it resolved in the end. SAN URI's The above-mentioned link on SAN URI's was referenced when I was writing my autoexec script, and as per the format of the SAN URI: This resolves to, in my case as: Technically I could leave the iscsi connection string as this and it would still work (and it does), as the protocol is ignored, the default port is 3260 and if no LUN is specified it defaults to 0 anyway: I am sure that the LUN is 0, as my NAS only has one ISCSI target, and it references it as LUN 0 as well. Leaving no stone unturned, if I change the LUN from 0 to any other number as a test, the log output indicates that a successful connection to the ISCSI target is never made and I get no successful "Registered SAN device 0x80". Instead you will get this:
In my case, I am achieving a successfully registered SAN device by using LUN 0 and it appears to actually start booting from the EFI block according my original posts debug messages. One last thing I'll mention, if I use the same iscsi URI and paste it into Microsoft's ISCSI Initiator, it makes a successful connection to the ISCSI target and I can view the partitions and access each individual drive if needed. This provides me with additional confidence that LUN 0 is correct. Could there be anything else I may not be aware of or considered with regards to my defined ISCSI SAN URI and perhaps how IPXE parses the string? If I could at least get past this point, then the numerous BSOD's that Windows will throw at me can be resolved through the literature I've read. I would of course publish my troubleshooting effort here for prosperity. Thanks for the help thus far @NiKiZe ! :-) |
Beta Was this translation helpful? Give feedback.
-
|
We can see from the debug log that the partition table is read correctly and the (correct) candidate bootable partition is identified. This definitely proves that a read from sector 0 is successful, and so we are definitely talking to the correct LUN. I would suggest enabling Michael |
Beta Was this translation helpful? Give feedback.
-
|
All the best for the new year ahead everyone! :-) I have recompiled with I've gone through it with a fine tooth comb (hopefully fine enough!), and there's nothing that obviously jumps out at me until lines 335 and 336: After this, there are several more IO errors reported with an eventual termination at line 387 onward: Looking at line 388, it would seem to me that Any thoughts on what this might mean? I'll do some additional research in the meanwhile. As promised, here is the full syslog: |
Beta Was this translation helpful? Give feedback.
-
|
So, we see a large number of successful reads prior to the error. The first failing request is: This is notably the first request for such a large data block (0x170000 bytes =~ 1.5MB): the previous requests were all for 64kB or less. It's also notable that this size exceeds the As a quick test, could you try hacking --- a/src/drivers/block/scsi.c
+++ b/src/drivers/block/scsi.c
@@ -643,7 +643,7 @@ static void scsicmd_read_capacity_done ( struct scsi_command *scsicmd,
return;
}
}
- capacity.max_count = -1U;
+ capacity.max_count = ( 262144 / capacity.blksize );
/* Return capacity to caller */
block_capacity ( &scsicmd->block, &capacity );That should cause iPXE to break the read requests down into chunks of 262144 bytes or less. |
Beta Was this translation helpful? Give feedback.
-
|
That certainly did the trick! :-) Once the boot process goes out of scope and Windows takes over, I get the expected BSOD with regards to: I've been expecting and preparing for this and my first step is to unbind the lightweight filter I will keep this thread updated with my progress and try to document what I did (and which order I did it in) to get a proper OS boot. If there are any other resources, you can point me to or any gotcha's or general information you think I should know then please let me know. |
Beta Was this translation helpful? Give feedback.
-
|
@ZiggyIPXE I have just pushed commit 2733c4763 which fixes the issue with |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
I have similar setup and I got same error, seems like iPXE doesn't support Line 624 in dc118c5 |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Hi all, as the title suggests, I would like to use a thumb drive to boot my diskless PC to its cloned hard drive that is residing on an ISCSI target, being hosted by my NAS. I would like to do this so that I can run Windows 10 Pro from my NAS where I have redundancy and a UPS.
I believe iPXE can help me do this, and I feel that I am close to achieving my goal, but I've run into a stumbling block during the boot process, specifically during the EFIBLK stage. I am hoping someone can shed some light on this or point me in the right direction as to what I might be doing wrong. Any assistance would be appreciated.
So what have I achieved so far? :
make bin-x86_64-efi/ipxe.usb EMBED=autoexec.ipxe DEBUG=iscsi:1,efi_blockThe usb image compiles and I can use it to boot off my thumb-drive successfully.
I've included the syslog output of the boot process in the hope that someone can shed some light on why I receive these errors towards the end:
Here is the full syslog output with debugging messages:
Beta Was this translation helpful? Give feedback.
All reactions