Intel NUC iPXE stuck

[Sodden]

iPXE seems to work fine now. The “Published Kernels” work till 3.6.9. The Unofficial Kernel [FONT=Ubuntu][COLOR=#555555]3.15.4 dose this:[/COLOR][/FONT]

P.S. All working kernels skip partimage.

[FONT=Ubuntu][COLOR=#555555][ATTACH]1304[/ATTACH][/COLOR][/FONT]

[url=“/_imported_xf_attachments/1/1304_IMG_20140821_144609.jpg?:”]IMG_20140821_144609.jpg[/url]

[KOA-IT]

Hi, I am attempting to use Intel NUC’s on our network as well.

Does anyone know of a working setup that I can test out, I currently have ~30 of the new style Intel i5 NUC and a working method for FOG would be very beneficial. Would be great if someone could enlighten me so I can image these.

Thanks in advance

[Tom Elliott]

[quote=“KOA-IT, post: 36378, member: 25995”]Hi, I am attempting to use Intel NUC’s on our network as well.

Does anyone know of a working setup that I can test out, I currently have ~30 of the new style Intel i5 NUC and a working method for FOG would be very beneficial. Would be great if someone could enlighten me so I can image these.

Thanks in advance :)[/quote]

Have you simply tried using the latest fog stuff? From my reading I could recommend, possibly, SVN trunk of fog rather than one of the “stable” builds.

[KOA-IT]

Hi,

Currently we are using FOG 0.32 with the latest kernel 3.14.2 depending on the architecture of the kernel we are getting two different errors…

The NUC that we are using are the i5 model with a 120GB SSD. I am trying to upload the image from the device so that it can then be deployed to the rest of them.

I am getting this error with 3.14.2 x64

[ATTACH]1342[/ATTACH]

And this one for x86 - it is as if there is no communication between the drive in the device.

[ATTACH]1344[/ATTACH] [ATTACH]1345[/ATTACH] [ATTACH]1343[/ATTACH]

I have tried this with Fog v1.1.2 on a separate physical box and had the same result (With the addition that I couldn’t add machines to the domain, probably a setup issue my end though) so reverted to our old already set-up 0.32 version.

Thanks for your help and very speedy reply earlier

[url=“/_imported_xf_attachments/1/1342_IMG_1111.JPG?:”]IMG_1111.JPG[/url][url=“/_imported_xf_attachments/1/1343_IMG_1114.JPG?:”]IMG_1114.JPG[/url][url=“/_imported_xf_attachments/1/1344_IMG_1115.JPG?:”]IMG_1115.JPG[/url][url=“/_imported_xf_attachments/1/1345_IMG_1116.JPG?:”]IMG_1116.JPG[/url]

[Sodden]

Try a different kernel, 3.8.8 or something like that worked. You still won’t be able to image correctly though.

[KOA-IT]

I tried kernel version 3.8.8 and still get “no partitions found” after being presented with a screen displaying at a higher resolution with text.

[ATTACH]1347[/ATTACH] [ATTACH]1348[/ATTACH] [ATTACH]1349[/ATTACH]

Thanks for your response, but the original issue remains. I’m sure more people will start using these NUC’s as they are very cost effective and are perfect for educational establishments and will probably encounter our issues if using FOG… It’s a great solution for everything else we have but these NUC’s are troublemakers!

[url=“/_imported_xf_attachments/1/1346_IMG_1117.JPG?:”]IMG_1117.JPG[/url][url=“/_imported_xf_attachments/1/1347_IMG_1118.JPG?:”]IMG_1118.JPG[/url][url=“/_imported_xf_attachments/1/1348_IMG_1119.JPG?:”]IMG_1119.JPG[/url][url=“/_imported_xf_attachments/1/1349_IMG_1120.JPG?:”]IMG_1120.JPG[/url]

[Tom Elliott]

Can you try a later version of fog? Possibly get into Debug mode as well?

[KOA-IT]

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]

[Tom Elliott]

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.

[KOA-IT]

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]

[Tom Elliott]

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?

[KOA-IT]

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]

[Tom Elliott]

Is this drive, perhaps, an SSD?

[KOA-IT]

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. =]

[KOA-IT]

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

[Junkhacker]

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

[Sodden]

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.

[Sodden]

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.