Imaging Issue
-
Where is this new r2961 build located, physically? Building “A” or the troubled building “B”
-
[QUOTE]Where is this new r2961 build located, physically? Building “A” or the troubled building “B”[/QUOTE]
The new server is physically located in building A. All of our virtual infrastructure is there.So I do have good news - it’s working, with some recovered files. Undionly.kpxe appears to have nothing to do it. The problem appears no matter which version of that I have.
The culprits seem to be init.xz and bzImage. I restored both of them from a backup from 2 weeks ago. When those restored files are in place, everything works happily on both r2961 and r3278. As Tom pointed out earlier, it looks like the revision version of FOG does not apply to these 2 files. It’s worth noting that replacing one or the other didn’t fix the problem - I had to replace both of them for it to work.
I see one major difference in debug mode, I attached a picture for clarity. The difference is I see the sending discover. It sends one discover, then the link comes up, another discover, and bingo - it gets an IP. That sending discover process does not show up in the bzImage/init.xz file combination that the installer script is currently downloading.
[url=“/_imported_xf_attachments/1/1920_Debug.JPG?:”]Debug.JPG[/url]
-
Ok now we’re getting somewhere, good job! It’s not your network after all.
From here, it’s up to Tom.
I’d recommend making a copy of those two files and put them in a safe spot for the future…
-
While on that prompt, what’s the output of uname -rm?
-
Yep! - finally making progress haha
uname -rm returns this: 3.18.5 x86_64
-
That number seems… familiar.
-
[quote=“Ben Warfield, post: 46163, member: 17746”]Yep! - finally making progress haha
uname -rm returns this: 3.18.5 x86_64[/quote]
From a previous post:
[quote=“sudburr, post: 44203, member: 4706”]I rolled the kernel back through successive older versions.
– svn: 3127
[B]-- Kernel: 3.18.5[/B]
– iPXE: 1.0.0+ (acc27)[FONT=Tahoma][COLOR=#141414]… works.[/COLOR][/FONT][/quote]
[FONT=Tahoma][COLOR=#141414]Just tying these two things together because there’s clearly an issue.[/COLOR][/FONT]
-
[quote=“Ben Warfield, post: 46158, member: 17746”]
The culprits seem to be init.xz and bzImage.[/quote]Can you post the the two files that are working for you?
I’d like to try them.
-
Sure, these are the files currently working for me:
bzImage: [url]https://www.dropbox.com/s/m9ti2dieab1eqn9/bzImage?dl=0[/url]
init.xz: [url]https://www.dropbox.com/s/r3lsc4301h58jwx/init.xz?dl=0[/url] -
[FONT=arial][COLOR=#222222]Can you try 3.19.2, and then set the USB nic flag and see if it works?
If that does, can you do the same with the next till we find where things go wrong?
This was Tom’s idea, btw.[/COLOR][/FONT] -
Hmmm… you lost me there. Or I’m having a brain moment. How do I set the USB nic flag?
-
On a host under kernel args add has_usb_nic=1
-
Finally got a chance to get back to this!
Setting the usb nic flag doesn’t make a difference.