Kernel for Ubuntu 64 bit

[Tom Elliott]

@Tom How are you calling installfog.sh?

[Tom]

@Tom-Elliott
Navigating to svn/trunk/bin
sudo installfog.sh

[Tom Elliott]

@Tom you need to use:

sudo ./installfog.sh

[Tom]

@Tom-Elliott Thank you, successfully updated to 6237. The issue is not resolved.

Should I start over from scratch? will it make any difference?

Thanks,
Tom

[Tom]

@Tom-Elliott

Also, ran this again:
sudo ls -al /var/www/html/fog/service/ipxe/init* ; ls -al /var/www/html/fog/service/ipxe/bzImage*

Results:
-rw-r–r-- 1 fog www-data 17611576 Feb 8 13:08 /var/www/html/fog/service/ipxe/init_32.xz
-rw-r–r-- 1 fog www-data 18786192 Feb 4 13:08 /var/www/html/fog/service/ipxe/initxz
-rw-r–r-- 1 fog www-data 6957536 Feb 4 13:08 /var/www/html/fog/service/ipxe/bzImage
-rw-r–r-- 1 fog www-data 6856848 Feb 4 13:09 /var/www/html/fog/service/ipxe/bzImage32

[Sebastian Roth]

@Tom I see different dates in that output. One says “Feb 8” and the others “Feb 4”?? I guess this is just a copy/paste typo? File sizes look good to me. Do you try booting different client models? Always getting the same error?

[Tom]

@Sebastian-Roth Yes, the dates are copy/paste typo. My client’s are the OptiPlex 990 and Latitude E7240.
They both shows the same error.

Thanks,

Tom

[Sebastian Roth]

@Tom Other machines that you could test?

[Tom]

@Sebastian-Roth Yes, just tested Latitude E6330 - Same results.

[george1421]

I have a 7240 on my workbench. Let me see if I can pxe boot it. I just rebuilt our production server last friday with the latest build at that time. I need to do this for image qualification anyway. Give me a few minutes to get things setup.

[edit] Looking back through this thread, I don’t see what mode we are booting into BIOS or EFI? I’ll test both for the qualification just in case [/edit]

[george1421]

OK here is my setup.

Dell e7420 bios A08 configured in EFI mode with UEFI network stack and pxe booting enabled on built in NIC. The legacy roms were tested being enabled and disabled with no change in the booting process.

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

Kernels and inits:

# ls -al init* ; ls -al bzImage*
-rw-r--r-- 1 fog apache 17611536 Feb  5 18:56 init_32.xz
-rw-r--r-- 1 fog apache 18780256 Feb  5 18:56 init.xz
-rw-r--r-- 1 fog apache 6957536 Feb  5 18:56 bzImage
-rw-r--r-- 1 fog apache 6856848 Feb  5 18:56 bzImage32

bzImage Info:

# file bzImage
bzImage: Linux kernel x86 boot executable bzImage, version 4.4.1 (root@debian64) #1 SMP Fri Feb 5 17:13:14 EST 2016, RO-rootFS, swap_dev 0x6, Normal VGA

UEFI boot:
I was able to boot and quick register the 7420 after several concerning pauses during the boot. But the boot process did run to completion and the device did quick register and deregister in uefi mode.

BIOS boot:
Again I was able to boot, quick register, and deregister without issue on the e7440 in both bios and uefi modes.

[Wayne Workman]

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

[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.