Kernel for Ubuntu 64 bit

[Sebastian Roth]

@george1421 Thanks heaps for testing on the E7420 so quickly! I am really confused about Tom having really big trouble pxe booting his machines. From the video he posted some days ago it says “bzImage… ok, init.xz… ok” so I guess transferring the kernel and initrd files to the client is fine. But why would it fail on all his clients then?

[george1421]

@Wayne-Workman said:

@george1421 What boot files for each mode? This is for wiki purposes.

Nuts, I missed that. I meant to include it but then found something shiny and got distracted.

For EFI it was snponly.efi
For BIOS it was undionly.kpxe

[george1421]

@Sebastian-Roth said:

But why would it fail on all his clients then?

He didn’t mention the mode of the system (at least where I found) so it could be efi or bios. Since we were having a difficult time with efi I might suspect that. Or secure boot is turned on (just a guess). This is the first time I efi booted this device, so I can’t say if it worked before this latest kernel or not. I can say the kernels and inits from last friday boot in my ESXi VM running in efi mode, where kernels earlier in the week did not. The vm would crash with a similar error that Tom posted.

[Tom]

@george1421 George,

As I mentioned earlier in this thread, the mode is bios. My DHCP 67 option set to:undionly.kpxe

Maybe the issue lies in the VM settings.

The first FOG was physical machine with Ubuntu 10.1 and Fog 0.31. Then I P2V it and it was tested successfully.

When trying to upgrade, all issues started.

Maybe the recent version of Fog/Ubuntu require certain settings to be set on the VM in order to work properly.

Thank you all for the help and patience.

[george1421]

@Tom Sorry about missing the mode being bios.

(don’t get hung up on my words) I can’t see how being on a vm is relevant to this issue. It appears that the inits are not being sent to the target computer so its hanging.

I see that you upgraded to 6237 (newer than my build from last friday). But the date on the kernel and inits are from before the dates of my build. This is inconsistent. I would expect the dates to match since the kernels and inits are typically built at the same time.

And going back to a previous post. What would happen (the cost to you) if you did just start over with a fresh OS build and trunk install of FOG? What will you loose by doing this? In can say you will loose your device registrations (which can be exported and imported). You will need to move your images (files and registrations), any snapins you might have. But will spinning up a new vm and OS be quicker than trying to upgrade/fix this VM. Its only a question.

[Tom]

@george1421 George, at this point I will do it, I need it working. The questions are:

1. will it most likely to resolved the issue? After the P2V I ran into updating the schema issue.
   so, I installed 14.04 fresh and (at the time) fog 6028 and since then I have kernel panic issue

In any case, I’ll build new VM, really have nothing to lose.

2. How easy it will be to export the images files and setting from my 0.31 machine?

Thanks a lot,

Tom

[Wayne Workman]

@george1421 said:

FOG Server r6215 (built from bare metal [actually is virtual] last friday 05-Feb)

For the kernels, maybe we all should start posting kernel versions instead of dates…

[george1421]

@Wayne-Workman said:

@george1421 said:

FOG Server r6215 (built from bare metal [actually is virtual] last friday 05-Feb)

For the kernels, maybe we all should start posting kernel versions instead of dates…

This would assume that the kernel versions are incremented for each build. I can’t say one way or the other if this is true (never really paid attention). The other issue is that the inits don’t have a version number that is externally readable. We might be able to identify both the kernels and inits with an md5sum or similar. But then we would need an accurate way to record the md5 value for each release.

[Wayne Workman]

@george1421 said:

But then we would need an accurate way to record the md5 value for each release.

I can probably rig a vm to do just that every day for the inits. However, now, the checksums are being hosted somewhere (I haven’t looked where) because the installer now checks the inits, kernel and client’s checksums to make sure they download properly. I don’t know if the checksum is for all three or one for each. Either way I could rig something to make a MD5 checksum for each.

The kernels are labeled properly. Normally you can see exactly the version you’re using on the FOG Configuration page in fog trunk. It will list the 32 bit and 64 bit kernel versions you’re currently serving.

[Sebastian Roth]

@Tom said:

How easy it will be to export the images files and setting from my 0.31 machine?

I am sorry but 0.31 was long before I started looking into FOG. I hope @Tom-Elliott can give you some advice on ex/importing hosts, settings and images from 0.31 to trunk.

But I’d say before getting into this just setup a complete new test VM, install trunk, register three test hosts via the web interface by hand and see if you are still running into the kernel panic (e.g. try uploading an image)…

[Tom Elliott]

@Tom just trying to think I notice you’re chai loading through pxelinux.0 in your setup. What’s the fog settings for bzImage and init.xz? Can you set the bootfile parameter to look at undionly.kpxe or undionly.kkpxe?

[Tom]

@Tom-Elliott Tom, if you referring DHCP option 67 than the value is undionly.kpxe , I will try undionly.kkpxe and let you know.
Other than that I will need more clarification where to look.

Thanks,

Tom

[Tom Elliott]

@Tom the YouTube video you posted shows the file is going through pxelinux.0. Are you sure there is only one dhcp server handing out things?

[Tom]

@Tom-Elliott You are right, I checked the 3 domain controllers that hold DHCP, 2 had pxelinux.0 and the other had undionly.kpxe.
did not pay attention. (so sorry)
so, after correcting it, my client cannot boot from pxe at all. I tried undionly.kkpxe as well.
I get “selected boot device failed”.
I also updated to 6257.
Thanks,

Tom

[Sebastian Roth]

@Tom Looks like this: https://static.spiceworks.com/shared/post/0012/0090/image1.JPG

Either you are pointing it to the wrong TFTP server (check next-server/option 66) or your TFTP service on the FOG server is down (restart and test the service: https://wiki.fogproject.org/wiki/index.php/Troubleshoot_TFTP)

[Tom Elliott]

I’m confused what’s going on. You have three dhcp servers? All handing out Option 66/67?

Can all three DHCP servers actually reach the FOG Server? If so, maybe this is the issue? I think the old saying: “Too many chiefs, not enough indians” is potentially one of the truest statements in this scenario?

(PS, I’m not intending my statement to offend, just simply using an old idiom I’ve heard as far as when I was a kid.)

[Tom]

@Tom-Elliott Let me explain, I have 2 domain controllers in one subnet providing DHCP to workstations (70/30 rule). The 3rd is DHCP server on different subnet, which does not play any role in this scenario.
I build new VM from scratch, Ubuntu 14.04.3 and fog 6257.
From DCs I was able to ping fog successfully.
Options 66 set with ip address correctly
Option 67 set to undionly.kpxe. I tried kkpxe and pxe - I got “selected boot device failed”. When it was incorrectly set to prelinux.0 I got the kernel panic-not syncing error.
Installed tftp on my windows station, tried to do tfpt -I x.x.x.x get undioly.kpxe and received the following error:
Timeout occurred, connect request failed.
On the fog machine: Ran tftp -v x.x.x.x -c get undionly.kpxe and got:
Connected to x.x.x.x (x.x.x.x), port 69
getting from x.x.x.x:undionly.kpxe to undionly.kpxe [netascii]
Received 92617 bytes in 0.3 seconds [2762316 bit/s]
Then, ran service tftp-hpa status and received tftp-gpa:unrecognized service
Ran cat /etc/xinetd.d/tftp results looks correct.
Ran cat /etc/default/tftpd-hpa and got "cat: /etc/default/tftp-hpa: No such file or directory

I hope it will give you a better insight,

Thanks for all the help

Tom

[Wayne Workman]

@Tom said:

I have 2 domain controllers in one subnet providing DHCP to workstations (70/30 rule)

that rule will cause clients to sometimes not get an IP.

70/30 means 70% of your available range is given out by one server, 30% by the other.

However, the load is 50/50. Both DHCP servers hear all DHCP Discoveries, both attempt to hand out an address. Whichever one is first wins normally unless you have one set as authoritative (which nobody does it seems).

When the one that has 30% of the range assigned to it runs out of available addresses, it’ll respond to clients that no addresses are available and the client will then auto-configure with APIPA.

Anything other than 50/50 is almost always not a good idea - and is easy to mess up and break.

[MRCUR]

@Tom If you’re going to run multiple DHCP servers (I assume you’re trying to get some HA out of it), then you really should be using the built in DHCP Failover setup that Windows provides. It’s far easier to manage than what you’ve got now.

I’ll also note that you should really consider moving DHCP services off of a DC.

[Tom]

@Wayne-Workman as much as I agree with you, that decision was made above me. Also, I have never encountered any issue with this setup.
In terms od fog, I never had any issue while running 0.31.