@sarge_212 said:
@george1421 Kernels do work on regular computer, yes.
OK, great. I was afraid we broke you FOG server.
So the root of the issue is that the current kernels and inits are panicking the kernel. I’m wondering if these devices have a weird hard drive structure/ definition that is causing this issue. With that said, it would be interesting to know if we could live boot linux on one of these devices…
@sarge_212 Just for clarity you are updating the bzImage as well as the inits at the same time?
[Edit] wait… do these kernels work on a regular computer and they are only blowing up on the surface? [/Edit]
@atarone Ok great. (sorry about the long way to get to this point, but sometimes there is no way to know what the poster has already done)
Now what I would like you to do is capture the error messages about the format. If you have a mobile phone snap a picture to capture the error and post it here so the devs can take a look at the exact spot where the error begins.
@atarone OK, understood you never upgraded. The reason why I ask is that the image format that is captured has changed a bit and that might be the cause of the error. But that is a non-issue now.
Its still not clear if you setup the management interface to use the images you copied over from the old fog server. Migrating to a new fog server requires a few steps. One is to move the files, the second is to either clone the database or recreate the configuration in the new server that will use these copied files.
@atarone Lets make sure I understand your setup.
You had a running and functioning FOG running on 1.2.0.
You created a new fog server on new hardware
You copied the files from the old server to the new server.
Now to be able to image a computer with the new fog server you need to create a image record using the FOG management gui right? From there you created a host and assigned it to an image and storage node, right?
@atarone you copied the files from the old server to the new server using the same version of fog. Did you recreate the image records with the same information?
This old server, was it an original install of FOG or was it ever upgraded from an earlier release.
OK lets get a bit more information because I think the answer is hidden in your post.
What version of fog did you just install?
Have you upgraded to the fog trunk (i,.e. pre 1.3.0 )?
What version of fog did you copy the images from (i.e. old server)?
If you moved from 0.30 to 1.2.0 the image format has changed between the releases. As well as between 1.2.0 and 1.3.0.
@anthonyglamis if you are using svn to manage the trunk package, you change into the trunk folder and run svn up that will download the latest code from the subversion repository. Then cd bin and then ./installfog.sh
If you are using git they have a comparable update command.
@sarge_212 No that would create bad karma.
The boot image from the trunk needs the trunk supporting code to function correctly. You need to stay with the kernels specific to 1.2.0.
Good catch, you must have very fast eyes.
That error means that this computer either did not receive dhcp address from inside the ipxe kernel or the ipxe kernel could not configure the network adapter.
I use fog on 790s and it works OK. Is your 390 using the latest (or current) BIOS?
I might recommend (if you can tolerate a few little bugs) that you upgrade to the trunk version (i.e. soon to be 1.3.0 version) so that you have the latest drivers and programs for FOG. Since this is new to your company having a little instability to get the current files may be beneficial for this test.
Don’t get sad with FOG. FOG does work rather well, you just have a unique environment that we need to work (around). Here are the instructions for upgrading to the current trunk build https://wiki.fogproject.org/wiki/index.php/Upgrade_to_trunk
This build will be updated almost daily as new fixes are released. If you find a bug, report it to the forum and it is usually addressed in one day.
@sarge_212 Yes these files need to be placed in /var/www/html/fog/service/ipxe You need to have bzImage bzImage32 init_32.xz and init.xz (taken from my trunk build production server 1.2.0 might be different)
@arnaudrigole Well in a way that is great so you have dhcp working since its now getting the ipxe boot file!! Debugging with wireshark is not a fun way to spend the afternoon.
The bad part is we need that message that goes by too quick. From the bios settings you mentioned, are you deploying to a Dell computer? Either way what make and model are you trying to deploy to?
Something else, if you use your mobile phone and video record the booting process, you may have a chance to review the video/stop the video to see the error.
We may need Tom’s feedback on this. But the kernels is actually 2 parts there is the bzImage and the inits. The root fs (root file system) is located in the inits. You need to ensure that you have the matching inits to go with the kernel you selected. There should be a 32 bit and 64 bit inits.
We may need the eyes of @Sebastian-Roth to decode the pcap file. But the filter you should use in wireshark is " bootp || tftp". That should pick up the dhcp requests as well as the tftp download from the fog server.
@sarge_212 For the kernel update, your steps are how it works in the trunk build, I can’t say for sure in 1.2.0 since its been almost a year since I’ve personally ran that version. I would assume the kernel update function will only let you install the kernels specific to 1.2.0.
As for the release date of 1.3.0. That is still in flux. There are no new features planned for 1.3.0 than what is in the current trunk build. The more people we can have test the trunk build and find the remaining bugs the faster the dev guys can finalize the system and then move on to fog (version next).
I think for the next part we will need to get a pcap file of what the target computer is communicating. This is a complex step that will require you to setup wireshark on a mirrored switch port and capture the packets as the target computer is requesting dhcp information from your dhcp server.
Before you go to this step, you may want to review your dhcp configuration to ensure you have the reservation setup correctly.
@arnaudrigole Well this is good and bad news.
Good: Your FOG server is supplying the required files.
Bad: Now the issue is down to dhcp.
The error message doesn’t mean that it is getting the wrong boot code (like for the phones), the error message says it is getting no boot code.
Sorry my fingers got crossed when I typed a few words in the last post.
What I want you to do is this. On a working windows computer that is attached to the same subnet (vlan) where you want to deploy the fog image too… On that functioning Windows computer I want you to install a MS Windows tftp client. You do this through the add features and functions. Once this software is installed I want you to open a command window on that working computer and attempt to pull the undionly.kpxe from your fog server. To do this open a command window (once tftp client is installed) and key in:
tftp 10.1.18.180 GET undionly.kpxe .
The file is not important, I want to know if the file transfer is success. If you can get the file no problem then we will have to dig into dhcp. But one step at a time.
The $osid is populated with the value you assign to the image from within the fog console. The integer number stored in $osid is the integer value listed in the drop down list for Operating System under image management.
To this point we need to first find out if it is a dhcp issue or a FOG server issue. If you can, if you have a functioning windows server on the same subnet as the target computer. You may have to add the tftp client to your windows build, but try to tftp the file from the fog computer to your workstation. I’m only interested if you can or can’t download the undionly.kpxe from the fog server.
If you can access this file, then we need to understand why dhcp is not working as expected. If the target can load the undionly.kpxe file you should see the FOG ipxe menu.