SOLVED EBR Signature Invalid


  • @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?

  • Moderator

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


  • @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.

    https://wiki.fogproject.org/wiki/index.php?title=SVN


  • @StevenT Are you using 1.2.0 but current inits?


  • @george1421 SIngle disk - SATA non-SSD.

  • Moderator

    @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 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)

  • Moderator

    @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 bzImage that 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 The upload from the master also failed:

    No img part type passed (savePartitionTableAndBootLoaders)


  • @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 I did as you suggested and received a new error with the new inits:

    No partition type passed (performRestore)

  • Moderator

    @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

    1. On your fog server console navigate to /var/www/html/fog/service/ipxe (it may be /var/html/fog/serv/ipxe on your distro)
    2. 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.
    3. 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.
    4. Once that is done, then just pxe boot that device again and see if you can deploy a proper image.
    5. 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 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.

  • Moderator

    @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
    Sorry I did not reply to you properly before. I posted the information you requested.

    In addition I found something else interesting. When I ran the Fog compatibility test on the destination client I received a similar error:

    Error: Invalid partition table on /dev/sda – wrong signature b5f8



  • Thank you for your quick response.

    We have been using Fog for awhile but we have recently upgrade to 1.2.0 (new fresh OS and Fog install / restore fog data). I have been able to backup and restore to the SAME PC, but to my knowledge this is the first time we have attempted to restore to a different machine.

    The backup image was created with the NEW version of Fog 1.2.0 using partclone.

    This is a new hardware platform we are working with. The source and destination workstations are both Dell Optiplex XE2. The OS is Windows 7. They are both in BIOS mode.

  • Moderator

    Lets collect a little background data here.

    Is this a new FOG install or has this server been running OK for a while?

    Is this a new hardware platform you are trying to deploy to?

    What is the make and model of this target computer?

    Is this target computer in BIOS mode or UEFI?

    What OS did you capture and are now trying to deploy.

    These are leading questions since 1.2.0 doesn’t do a real good job with GPT disks. The fog trunk version (i.e. 1.3.0 beta) does much better with GPT disks.

343
Online

9.0k
Users

15.6k
Topics

145.1k
Posts