deploy problem: no image found that would match the partition to be restored
-
Hi!
We have a working fog setup which we used with ease (v1.2.0). There come some new hardware and problems emerged which forced us to upgrade to 1.3.0 to test that it can be solved with new version maybe. The image is same, not changed, only hardware changed (new mainboards, etc).
Client loads and at the imaging start point it says that "no image found that would match the partiontion to be restored (perform restore).
Before update problem was same with that hardware we try now but colleague who found it says it was a bit less specific about reason.
The image is about a windows 10, single partition in reality OS type was set 8.1 and worked well actually. Now we even tried with OS set zo windows 10, it changes the error, so it must be a key to problem itself. I must admit that imageing is not my job, i only keep fog server working
but colleagues use it so i dont know why was os set to win 8.1. Maybe it had reason. (we use single partition deployed systems, ntfs, win7. and now started with windows 10 mass deployement; it worked properly then now stuck with new hardwared as a pain in the ass ofc)Does it have a clearly visible reason and we can solve fast or need more investigation or more information to find solution?
As extra information the image size in image list is 0b, ofc the files are not zero length.
I hope you guys can help as candle burns low in our deployment project
-
-
Is there actually an image with the path it’s describing? What actually exists?
Windows 8 was available in 1.2.0, windows 10 was not. 1.3.0 has the definition.
-
All file are there, like:
-rwxrwxrwx 1 root root 1nov 24 07:51 d1.fixed_size_partitions*
-rwxrwxrwx 1 root root 15 nov 24 07:51 d1.original.fstypes*
-rwxrwxrwx 1 root root 259 nov 24 07:51 d1.original.partitions*
-rwxrwxrwx 1 root root 0 nov 24 07:51 d1.original.swapuuids*
-rwxrwxrwx 1 root root 10911329117 nov 24 09:18 sys.img.000*(sry for formating fail)
-
@Foglalt what’s interesting is the message right before the failure displays. The seems like you’re trying to deploy to an empty disk. Any way to re capture the master? 1.2.0 used an assumptive style partitioning scheme while 1.3.0 is much more generic and robust. I believe the issue is something I could fix but would not be readily available for the binaries you currently have. I also am only guessing and maybe you could try a debug deploy so we could step into the events to get more detail on what the problem currently is.
-
Hm… I am actually not aware about a part you mention “empty disk” (new hw, so it must be empty, y. it is not a redo, it is cloning from the master image; is it somehow wrong? i will try to ask recapture the master, but it still is interesting as it was working for a long time and was ok till new hw (maybe this is not the clue to solve? i have zero things in my mind that something has changed in any way, 1.2.0 was up and running last issue was about multicast, ages ago. “i dont click if i dont need to”, so normal system updates was only what happened to fog system os.
the message before failure. i will try to check i only took a glimpse of it at last point when i saw no clue to solve otherwise on serverside. it was fastly taken away, scrolled up. actually other IRL problems burning our hands, so only tomorrow is when we can try to debug more detailed.
-
@Foglalt I’m not saying there is no problem in the code, in fact I suspect the exact opposite.
That said the code format changed almost completely in how we capture and deploy images. I did do my damnedest to try to maintain compatibility between versions. It seems, I think, I missed the case of single partition resizable in the most literal sense. Which is why I ask for the debug test to figure out. The capture will most likely work too as it would convert the image to what we are expecting as the new normal for 1.3.0.
-
I see no problem with code, all can have, it is normal. Why i am surprised that it was working, no upgrade, and it stopped working. THEN we did upgrade in hope that it will solve it cos of hw change (and why not use newer ofc). It only havent changed it
then i tried to find solution and up to now i did not found. as to be honest i dont want to downgrade, but i dont know if collegague has options to retake images.btw, where can i find info on other changes, like i found on gui (host settings are more detailed, some info i dont even know what are, etc). I maybe can find a solution if i read these all (actually documentation is the… hm… less super thing in fog, but take it no as offense pls
i hate to write mines; many times i try to find info i bump into old versions). -
@Foglalt if you can run the debug deploy I can probably find it much faster. I suspect I know where the issue is currently just have no viable way to verify my thoughts beyond use of other people’s issues. (Sorry it is the best route I can have )
-
Ok, thanks for the help and the super fast support response time! Hat risen before you!
as for debug, tomorrow we do it (i have to reread our posts as i forgot the steps
but i hope i can do it fast). will report tomorrow. -
We up to now could do debug with that image, as we did some else for gathering more information. We did test with other hw, other images of same kind (partiotioning, etc). Result: same error message. As here we are during a bit fiery schedule (1k+ pc reimaging) had less time for detailed tests, therefore i did a choice: keep or rollback. I kept so i needed more test: with new infrastructure (1.3.0) did a random win10 imaging (fully no care of details, just next-next finish setup of win10, upload image and redo image on different hws. all went well (resize, too, etc).
So, i can say 1.3.0 single target imaging works, it is not system failure that we had in general. As of time we had, we will remake the original image and use that (store and deploy in 1.3.0 environment). BUT, as always, there is a but. I did a multicast order from colleague with a bit of fear and it come out as i was right, nothing can be fully successful
multicast has some issue (well, actually run into some hw failure too, so not 100% sure it was multicast failure, will test later. Most urgent was at least a working imaging.Can you tell me, for debuging the original problem of this topic, what you mentioned about u guess what can be the problem? did it changed with info i am posting now? (if i have time i post the debug details ofc)
-
So looking over the code, all seems to be correct. So I guess we would need to get some more info (luckily not necessarily from the image itself.) – This does not mean there isn’t a problem within the inits, just I’m not seeing what/why/where.
Based on what I can see, however the problems could, possibly be:
- The image path is incorrect on the server within the GUI. (1.3.0 removed the checks if the files were present due to performance and inconsistencies).
- The partition table is not being correctly applied?
My thought on the most likely issue is the number 2 from above. I say this because of the “Seems like you are trying to restore to an empty disk.” This message should not present if the table layout was applied already.
-
What do you mean by maybe incorrect image path? images havent changed location. Those files are there since months. From creation up to now.
Please tell me about the second option. I must admit that maybe i am underinformed about the need of imaging. New disc comes in (unboxed, etc, installed into box, cables, etc etc). Does it need to have preset partiotion table to deploy images onto it? I mean up to now i was not aware if it is a must before new image come to deployed.
Please tell me what do you mean by that you told.
