EBR Signature Invalid
-
@StevenT My intuition is telling me that you should upgrade to the 1.2.0 trunk version since the devs have put a lot of work into this area. Do you have capabilities to spin up a new fog server to test out the 1.2.0 trunk version? While the trunk is pretty stable, understand it is still in beta so there may be a few bugs still. That is why I’m recommending that you use a new instance so you don’t break your production server if something goes sideways.
-
@george1421 I will try to work something out. Do you know where the procedure is to upgrade to the trunk version? I have not done that before.
-
@StevenT To answer your question: https://wiki.fogproject.org/wiki/index.php/Upgrade_to_trunk
It would be interesting to note if the new kernel and inits would have better luck without actually upgrading. Understand this is only for testing but I would be interesting to know if it addresses your specific issue. Understand this is not a recommended process, but it can easily be reverted back if it fails to produce useful results.
If you would like to try the new kernel and inits then do the following
- On your fog server console navigate to /var/www/html/fog/service/ipxe (it may be /var/html/fog/serv/ipxe on your distro)
- Rename bzImage, bzImage32, init.xz and init_32.xz to the name plus .old. We want to save these in case things don’t work out.
- Assuming you have direct internet access you can use the wget program to download the new stuff.
Use these commands (remember you still should be in the /var/www/html/fog/service/ipxe directory
sudo wget https://fogproject.org/inits/init.xz
sudo wget https://fogproject.org/inits/init_32.xz
sudo wget https://fogproject.org/kernels/bzImage
sudo wget https://fogproject.org/kernels/bzImage32
IF you have a proxy server between your FOG server and the internet you will need to either update the /etc/wgetrc file or set your environmental variables for the proxy settings. - Once that is done, then just pxe boot that device again and see if you can deploy a proper image.
- If things fail in a different part of deployment take a picture with your mobile of the error and post it here so the devs can look at it.
-
@george1421 I did as you suggested and received a new error with the new inits:
No partition type passed (performRestore)
-
@george1421 The fog compatibility test now works on the destination client however. I will try to upload the image from the master again and they deploy to the destination with the new inits in place.
-
@george1421 The upload from the master also failed:
No img part type passed (savePartitionTableAndBootLoaders)
-
@StevenT said:
@george1421 The upload from the master also failed:
No img part type passed (savePartitionTableAndBootLoaders)
That was my initial concern the current kernel and inits need the rest of 1.2.0 (trunk) to function correctly because the image information is not being passed to the kernels. The compatibility test works since the newer kernels have the hardware drivers for the newer hardware. Which is a positive.
I think spinning up a dev fog server is the next move. Move the original bzImage and ints back. Once you do that run the following command against bzImage
file bzImagethat should generate the kernel build number. The latest kernel for 1.2.0 is 3.19.(something). If your kernels are before that you might want to update them (on your production server) to ensure you have the latest hardware drivers. For fog 1.2.0 stable you must stay in the 3.x kernels. -
@george1421 I finished setting up a completely new install of Ubuntu / Fog 1.2.0. I used SVN to upgrade to 6175. I kept the empty database and just registered the two hosts to test with.
I upload the image from the master to FOG fine. I received an error trying to deploy the image however:
No drive number passed (restoreALLEBRs)
-
@StevenT said:
@george1421 I finished setting up a completely new install of Ubuntu / Fog 1.2.0. I used SVN to upgrade to 6175. I kept the empty database and just registered the two hosts to test with.
I upload the image from the master to FOG fine. I received an error trying to deploy the image however:
No drive number passed (restoreALLEBRs)
Ok now you are at a place were we need to bring in the @Developers Thank you for sticking with me during initial testing. Just to make sure I got everything answered, these Dell Optiplex XE2 do they only have a single hard drive? I assume this hard drive is a SSD or rotating media?
-
@george1421 SIngle disk - SATA non-SSD.
-
@StevenT Are you using 1.2.0 but current inits?
Please help us build the FOG community with everyone involved. It's not just about coding - way more we need people to test things, update documentation and most importantly work on uniting the community of people enjoying and working on FOG! Get in contact with me (chat bubble in the top right corner) if you want to join in.
Web GUI issue? Please check apache error (debian/ubuntu: /var/log/apache2/error.log, centos/fedora/rhel: /var/log/httpd/error_log) and php-fpm log (/var/log/php*-fpm.log)
Please support FOG if you like it: https://wiki.fogproject.org/wiki/index.php/Support_FOG
-
@Tom-Elliott I installed 1.2.0 and then ran the procedure to upgrade to trunk using the following instructions. I’m not sure if that updates the inits as well.
-
@Tom-Elliott said:
@StevenT Are you using 1.2.0 but current inits?
Tom, we tried to just upgrade the kernel and inits to current with the 1.2.0 build. But that resulted in “No img part type passed” being returned by the trunk version of the kernel and inits. So I asked him to roll back the changes in his production server and spin up a dev server running the latest trunk build. The trunk build is now throwing the error “No drive number passed” when he tries to deploy an image.
-
@george1421 While 1.2.0 and trunk init’s “should” work there were a lot of features added. For example, many error checks were implemented that were not in 1.2.0 at all.
Is there anyway to upgrade properly to trunk? What happens if they are on trunk?
Please help us build the FOG community with everyone involved. It's not just about coding - way more we need people to test things, update documentation and most importantly work on uniting the community of people enjoying and working on FOG! Get in contact with me (chat bubble in the top right corner) if you want to join in.
Web GUI issue? Please check apache error (debian/ubuntu: /var/log/apache2/error.log, centos/fedora/rhel: /var/log/httpd/error_log) and php-fpm log (/var/log/php*-fpm.log)
Please support FOG if you like it: https://wiki.fogproject.org/wiki/index.php/Support_FOG
-
@Tom-Elliott Unless I missed something that is exactly what the OP said:
@george1421 I finished setting up a completely new install of Ubuntu / Fog 1.2.0. I used SVN to upgrade to 6175. I kept the empty database and just registered the two hosts to test with.
I must have not been clear. First attempt was to “try” the new kernels and init. That failed so the OP spun up a new server with similar results. I have personally not had any experice with this new model Dell “Optiplex XE2” the release date is mid 2013 so it should be similar to the 7020/9020 but the chip set is listed as “Intel 8 Series Express” unless this is a type-o it is inconsistent with the other hardware of that era.
-
@Tom-Elliott To reiterate what @george1421 said our final attempt was with a brand new OS / FOG installation upgraded to trunk via SVN. I registered only the master / slave hosts, uploaded the image and then tried to deploy it. Even with the brand new upgraded install we were getting an error trying to deploy. That is where we left off.
-
Can we take a step back, and try to upload from other computers just to see if it works? Doesn’t need to be anything special, doesn’t matter what’s on the drive. We just need to test uploading to verify if the FOG server works for other hardware.
-
@Wayne-Workman Good idea. We are in the process now. The deploy just failed so we are trying to use alternative hardware for the entire process now - upload image from master HD in an alternative PC and deploy the image to slave HD in an alternative PC. The alternative PC we are using we know worked in the past.
-
@StevenT said:
upload image from master HD in an alternative PC and deploy the image to slave HD in an alternative PC
I’d disagree with that. It’s possible that the HDD itself is the issue.
I’d recommend just grabbing any other working computer and just uploading.
-
@Wayne-Workman We’ll try that next to make sure. It *appears the master disk is working ok. It boots, runs the OS, ect fine. We have also tried to deploy the image taken from the master to 3 different XE2 PCs with no luck. I wouldn’t think its a hard drive issue, but we will make sure.
Also I have been able to image and deploy other PCs on this FOG server. I’ll admit the image was taken from and restored to the exact same PC (backup/restore), but that at least proves the server is ABLE to take and deploy an image.
