Intel NUC iPXE stuck
-
Can you try a later version of fog? Possibly get into Debug mode as well?
-
Hi,
I have now upgraded to version 1.2.0 and the Intel NUC hangs on this screen… on the older version it continued past this but displayed an error. This is with kernel version 3.14.2 x86 - I can see it says i8042 no controller found on a previous screen and maybe that has something to do with it?
The NUC is using a 120GB Crucial SSD in the mSATA slot.
[ATTACH]1350[/ATTACH]
–
We are also having issues with this version joining our domain. The error in the log i’ve checked is ‘Unknown Error: Code 87’ on a different machine that previously worked.Thanks for your time, I hope the information provided helps…
[url=“/_imported_xf_attachments/1/1350_IMG_1121.JPG?:”]IMG_1121.JPG[/url]
-
At this screen.
Can you attempt to put the system into upload - debug. At the command prompt that comes up, type fixparts and confirm the changes.
Then run the command fog.
-
Hi,
I’ve ran fixparts and it complained that partitions were dodgy on dev/sda1 - it didn’t fix this.
Partitions #1 #2 #3 #4 were apparently too large which the tool then said it had deleted three times but the same warning cropped up. I ignored this in the end and tried to re-upload the image after doing fixparts and I am now getting a completely different error which i’m still at a loss on how to solve.
If i push return it then says task complete but I don’t think it actually does complete it as the web interface says no data still. These NUC’s are little troublemakers!
[ATTACH]1351[/ATTACH] [ATTACH]1352[/ATTACH]
Again, thanks for your time with this issue.
[url=“/_imported_xf_attachments/1/1351_IMG_1157.JPG?:”]IMG_1157.JPG[/url][url=“/_imported_xf_attachments/1/1352_IMG_1158.JPG?:”]IMG_1158.JPG[/url]
-
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.
