• Recent
  • Unsolved
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Register
  • Login
  • Recent
  • Unsolved
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Register
  • Login

Seems like you are trying to restore to an empty disk. Be aware this will most probably cause trouble.

Scheduled Pinned Locked Moved Solved
FOG Problems
5
13
1.7k
Loading More Posts
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • Q
    Quazz Moderator
    last edited by Oct 19, 2018, 9:38 AM

    Can you take a picture of the error? A picture of someone else’s environment doesn’t really help us since their problem seemed to be related to a specific system.

    Double check host settings primary disk field. Possibly the primary disk for the SSD is not the same and thus the disk can’t be found on deployment.

    1 Reply Last reply Reply Quote 1
    • W
      Wayne Workman
      last edited by Oct 19, 2018, 6:55 PM

      In addition to what Quazz has suggested, you could also take a snapshot of your VM (for backup), and then upgrade to the working branch. There’s a lot of fixes in there. Here’s instructions: https://wiki.fogproject.org/wiki/index.php?title=Getting_FOG If this doesn’t work out for you, you can always revert to the snapshot and it’ll be like it never was done.

      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!
      Daily Clean Installation Results:
      https://fogtesting.fogproject.us/
      FOG Reporting:
      https://fog-external-reporting-results.fogproject.us/

      B 1 Reply Last reply Oct 19, 2018, 11:39 PM Reply Quote 0
      • B
        benc @Wayne Workman
        last edited by Oct 19, 2018, 11:39 PM

        @Quazz Here is a picture of the error.

        0_1539992142278_IMG_20181019_153136462.jpg

        @Wayne-Workman I will snapshot the VM now and get Fog upgraded to the working branch. I’ve never done that but I remember reading about it. Shouldn’t be too hard to figure out. Would you suggest doing anything to Ubuntu as far as upgrading or updating? It’s been a few months since any OS updates have been applied.

        W 1 Reply Last reply Oct 20, 2018, 12:49 AM Reply Quote 0
        • W
          Wayne Workman @benc
          last edited by Oct 20, 2018, 12:49 AM

          @benc said in Seems like you are trying to restore to an empty disk. Be aware this will most probably cause trouble.:

          Would you suggest doing anything to Ubuntu as far as upgrading or updating?

          The fog installer ensures the packages it uses gets updated, so you don’t need to worry about updates. But - if you want an updated OS, you could absolutely update the system (after you snapshot). The one-liner I use for updating Ubuntu and Debian is:
          apt-get update;apt-get -y dist-upgrade;apt-get -y autoclean;apt-get -y autoremove;reboot
          Updating doesn’t hurt anything, and it’s good practice, as long as you have a healthy snapshot to go back to should something go wrong.

          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!
          Daily Clean Installation Results:
          https://fogtesting.fogproject.us/
          FOG Reporting:
          https://fog-external-reporting-results.fogproject.us/

          1 Reply Last reply Reply Quote 0
          • S
            Sebastian Roth Moderator
            last edited by Oct 21, 2018, 6:28 AM

            @benc I’d suggest looking into a debug deploy task (tick the debug checkbox just before you click the button to create the deploy task in the web UI). Step through the task till you hit the error and when you get back to the command line run gdisk -l /dev/sda

            One thing that could cause this is if you try to deploy an image that came from a source disk larger than the destination SSD. Even if the image is set to resizable there are situations where the partition layout does not allow to resize to fit onto the smaller disk.

            Please post the contents of d1.partitions and if available d1.original.partitions and d1.fixed_size_partitions (from /images/PiearcyLaptopNoResize).

            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

            B 1 Reply Last reply Oct 22, 2018, 2:48 AM Reply Quote 0
            • B
              benc @Sebastian Roth
              last edited by benc Oct 21, 2018, 8:49 PM Oct 22, 2018, 2:48 AM

              @Sebastian-Roth I’m building a server that has to be ready first thing tomorrow morning so I haven’t been able to put as much time into this as I would like. Based on your suggestion, I tried using a hard drive that was => the original source drive. This worked perfectly, just like pretty much every time I’ve tried to do this type of thing before. Looks like something to do with where the partitions were on the original drive not being properly mapped to the new SSD…? I’m going to take a closer look at all the partitions and where they are located on the drive. It might be as simple as getting rid of a little recovery partition at the end of the drive or something like that. I’ve never had to use a drive that was => the original drive. It has always captured the images and as long as total contents of each partition is less than the capacity of the destination drive it works fine.

              1 Reply Last reply Reply Quote 0
              • B
                benc
                last edited by Oct 22, 2018, 10:40 PM

                Success! The issue all along appears to have been the fact that the original 1TB hard drive had two small partitions at the end of the drive. I know one of the partitions was a 20GB recovery partition, and the other was 2GB and I don’t know what it was for. The last things I did was delete the partitions using gparted, make sure the drive still booted windows, then manually resize the main partition and start a capture. I believe it will work just fine the way I’m used to it working now that the two partitions at the end are gone. I normally look at the size of the data on the drive and chose an SSD based on that, even if the original hard drive was 1TB, 2TB, or more.

                In short, if you run into this issue, make sure there are no partitions hanging around at the end of the drive after the main partition. It would be helpful if Fog / PartClone could see that and give a slightly more detailed error. I appreciate everyone’s help on this.

                1 Reply Last reply Reply Quote 0
                • P
                  Padcotton
                  last edited by Oct 23, 2018, 1:14 PM

                  So interesting, but would like to get more info about the issue !

                  Q 1 Reply Last reply Oct 23, 2018, 2:31 PM Reply Quote 0
                  • Q
                    Quazz Moderator @Padcotton
                    last edited by Quazz Oct 24, 2018, 1:31 AM Oct 23, 2018, 2:31 PM

                    @Padcotton FOG saves the starting positions of partitions to a file which it then uses in deployment.

                    FOG does not change the order of partitions, which means that ideally you want all of your partitions that won’t be resized (such as OEM and recovery) to come before the partitions that will get resized. (since then all the start markers are early on on the disk)

                    This should produce far better results overall.

                    Not sure why you got the empty disk error in this context, I’d rather expect the bootloader error or such…

                    But I’m assuming your target disk is smaller than the origin disk, thus causing the issue (eg 1TB HDD -> 960GB (“1TB”) SSD)

                    B 1 Reply Last reply Oct 23, 2018, 7:35 PM Reply Quote 0
                    • B
                      benc @Quazz
                      last edited by Oct 23, 2018, 7:35 PM

                      @Quazz Nice explanation of the issues regarding the order of the partitions and the starting positions. I think that’s exactly what was going on. Since the actual usage of the original 1TB drive was only ~150GB, I went with a 240GB SSD which has always worked for me before. It gave me that “Seems like you are trying to restore to an empty disk…” error every time I tried to deploy that image to anything smaller than 2TB. Now that the two little partitions at the end of the original drive are gone, I recaptured it and it deployed just fine to a 240GB SSD.

                      1 Reply Last reply Reply Quote 0
                      • 1 / 1
                      1 / 1
                      • First post
                        13/13
                        Last post

                      162

                      Online

                      12.0k

                      Users

                      17.3k

                      Topics

                      155.2k

                      Posts
                      Copyright © 2012-2024 FOG Project