Kernel for Ubuntu 64 bit

george1421

@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

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:

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.

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.

Wayne Workman

@Tom Well I mean, if the lease time is short enough or if you have a large enough pool of addresses on the 30% range DHCP Server - or a mixture of those two things - then you might never have problems.

But I say what I say because the potential is there. It’s happened here where I work.

We have a DHCP server that serves 100% of a range, and we had an old mac server - we used it for OpenDirectory for our Macs and for Deploy studio. It was configured to run DHCP for a very small subset of our range, and at the very end of our range - and we always kept that turned off unless we were using Deploy Studio. Well one day it was turned on somehow accidentally (not by me) and because the range was so small (256), it ran out of IPs quickly, and then our entire building suddenly started not getting addresses and auto-configuring with APIPA. Keep in mind that thousands and thousands of addresses were still available from our actual DHCP server - and it was even responding to requests, it’s just that the old mac server was beating it and serving addresses faster… or in this case, serving “no more addresses available” messages faster.

Kernel for Ubuntu 64 bit

277

11.7k

17.1k

154.7k