Intel NUC iPXE stuck
-
if you reuploaded AFTER doing fixparts you shouldn’t be seeing anything about GPT headers and the like, unless you’re really trying to run a GPT partitioned layout?
-
I just attempted fixparts again in Upload Debug mode… here’s the images I grabbed. It complained about the partitions which is fine as it’s supposed to solve that? Then I wrote the changes and proceeded to start the fog upload.
[ATTACH]1353[/ATTACH] [ATTACH]1354[/ATTACH] [ATTACH]1355[/ATTACH]
[url=“/_imported_xf_attachments/1/1353_IMG_1160.JPG?:”]IMG_1160.JPG[/url][url=“/_imported_xf_attachments/1/1354_IMG_1161.JPG?:”]IMG_1161.JPG[/url][url=“/_imported_xf_attachments/1/1355_IMG_1162.JPG?:”]IMG_1162.JPG[/url]
-
Is this drive, perhaps, an SSD?
-
Yep it is a Crucial 120GB SSD in the mSATA slot which is what I think was causing the issues regarding communicating to it, but wanted to know if there was a fix. I did mention it in previous posts but it may have been overlooked… Sorry for not making the hardware setup clearer.
I appreciate your very timely responses with the issues I’m experiencing, and hope we can come to a resolution so we can roll out some NUC’s to our Library as the testing ground. =]
-
Hi,
Sorry to bother you guys again…
I would like to know if this is a Kernel issue regarding the use of SSD’s or would you know if there is anything else I can do to get the NUC’s working?
Thanks for your help in solving these niggly issues so far, you’ve been very helpful
-
i have used many ssd’s without issue and am unaware of any known issues with SSD’s, but a few people are reporting issues with the NUC systems. unfortunately, i don’t think any of the developers have access to a NUC themselves, so troubleshooting is tricky
-
I don’t think it’s SSD related. We’ve been using the same SSD’s in the NUC’s with manufacturing data 01/2014 and those work with fog. Only those with manufacturing data 05/2014 are having troubles. Intel switched mainboards, 05/14 only accepts 1.35V RAM while 01/14 accepts 1.5V. The NIC is differnt too, and probably the SATA controller.
-
After having another go at this with the latest svn build, I finally solved the problem. Or at least I hope I did.
I had the same problem as before with the latest svn release. I changed between different .kpxe and .kkpxe files countless times until I tried something I hadn’t done before. I always used symlink’s to switch between .kpxe and .kkpxe files, but instead of doing that I decided to change Option 67 in the DHCP settings for a change. And it worked!
I’ll try a different client later to see if it really is the fix I’ve been looking for.
Edit: Doesn’t seem to solve the Problem. But I found a workaround. Booting any OS (Live CD is enough) and rebooting solves the problem. I guess it has something to do with the NIC not being shut-down correctly by the manufacturer.
