fog.deploy image option in PXE boot not resizing disk
-
Well funny enough I just ran it again in order to capture screenshots and it worked properly. I think I know why though;
This time even though I used the “deploy Image” again, I didn’t remove the now already registered host from fog. I think fog does a quick reg even if you just pick “Deploy Image”, because now that I’m back in the PXE menu “quick reg” and “full reg” are missing and I only see “Quick Host Deletion”. For me this means that every imaging method I run works ONLY if I register the host first. It appears that trying to bypass this step causes the issue. I’ll confirm by running “Host Deletion” and trying “Deploy Image” again but I’m 99% certain it will have the disk size issue again.
Does anyone know why this is?
-
Hmm. Well in my case all my machines are identical 500 GB seagate drives in Optiplex 7060s. As far as I can tell there should be no difference between the machines in terms of hardware or drivers. Even so, I find it strange that deployment through all (1) register host -> (2) deploy image methods work. It seems like skipping the registration part is what causes my issue. I’m confirming now though.
Also is there anyway to change that for my image? I basically setup my “golden” machine and then did the register host -> capture task -> and then captured the image. I’m not sure how to change the partition starting points.
-
@androsszit said in fog.deploy image option in PXE boot not resizing disk:
For me this means that every imaging method I run works ONLY if I register the host first
I’m still looking into the Deploy image code. The parts that I traced out before is actually calling another script that I need to decode called fog.capone within FOS. Which appears to be another path than the deploy image question at the end of full registration.
I may be going down a rabbit hole here, but I want to understand the difference you say you are seeing (I haven’t been able to duplicate it with my fog server, it images and expands correctly no matter what path I choose).
Edit I started writing this and removed it, but I’ll ask it anyway. That disk layout, is that an OEM created image you are using for your golden image? That 4th partition is raising the question for me.
-
Well hopefully it’s an issue that may be addressed in the next update. Until then I will make sure to register my hosts before pushing the image.
To confirm, I just finished reimaging (via Deploy Image in PXE) after unregistering, and it once again did not properly resize the drive.
It’s bizarre, but thankfully for me doesn’t stop me from using fog, which outside of the occasional hiccup has been an awesome time saver. I hope that despite all the troubleshooting posts the devs know IT people like me really appreciate this tool!
-
@androsszit I’ll definitely look into this and do my own testing when I get a bit more time. Maybe tomorrow but can’t promise. From all you have tried so far it really looks like an odd bug in FOG/FOS but I have no idea yet. I’ll just try to replicate the steps you took and we’ll see.
I’d still be interested to see how this partition layout looks like when you say it’s “properly” expanded versus when it’s not expanded. Can you take pictures of disk management and post here?
Just doing some maths:
- 976773134 (last-lba = kind of the last usable sector that Linux would use on the original source disk) * 512 byte (sector size) = 465.76 GB ~ 500 GB drive, ok.
- 974745600 (last start sector, which FOG never moves AFAIK) * 512 byte = 464.79 GB -> this means that you won’t be able to deploy this image to a disk that is smaller than roughtly 466 GB (last start sector plus a ~ 990 MB sda4 partition)
- When you deploy to a much larger disk what happens is that sda3 will be as big as it has been on the source drive (because start of sda4 is not moved) and sda4 will be expanded to whatever is left on the drive.
Nevertheless there might be a bug that prevents expansion on unregistered deployments I’d still highly recommend you look into (re)moving the forth partition to make your partition layout work nicely for expansion.
-
Thanks for continuing to look into this! I’ll try to post the images when I can. I’ve got one for a “proper” install but I’m having to deploy machines right now so I haven’t had time to “break” one again!
I’ll definitely look into modifying my golden image. I have no qualms about reducing the number of partitions since we don’t plan on using Dell’s recovery partition or anything of that sort.
Edit:
Looks like messing with the partitions may have fixed it! I redid the golden image with reduced partitions and pushed it out (via the PXE boot Deploy Image) to a couple brand new machines that had never communicated with fog before. Seems like they imaged fine and the drives were the correct size! -
@androsszit said in fog.deploy image option in PXE boot not resizing disk:
Looks like messing with the partitions may have fixed it! I redid the golden image with reduced partitions and pushed it out (via the PXE boot Deploy Image) to a couple brand new machines that had never communicated with fog before. Seems like they imaged fine and the drives were the correct size!
That makes the whole story even more strange to me
I can’t see why it would make a difference in this case now when it would “fail” with the other partition layout?!Well, I’ll wait for your pictures now or we simply close this as fixed… up to you.
-
Problem is I overwrote my other image when I created the new one. I’ll look into creating another image and see if I can repeat the process. Thing is it doesn’t sound like the issue impacted anyone else and was pretty unique to me. I’m comfortable with closing it as fixed.
Thanks again to everyone for all your help! Very pleased with the friendliness and speed of replies on this board!
-
@androsszit Just as a quick note: Running a test because I had the test setup for another issue as well and for me it expanded perfectly fine on an unregistered host.
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
-
@Sebastian-Roth I also did testing of iPXE Deploy image vs the web ui Deploy image and the instructions (kernel parameters passed) to FOS are identical. So at least what FOS knows about there should be no difference in the way it deploys the image.
-
Hey not sure if it matters now since the issue is closed. But I finally got a chance to post the images. Here’s pics of the good (top) bad (bottom). Please ignore the samsung on the 2nd, that’s just a USB SSD I’m using.
When it works:
Lots of unallocated space:
-
@androsszit Well we can still open this thread again. Do you want us to look into this or are you happy with the modified partition layout you fixed it with?
It will be quite hard to replicate this issue as things are working great with my test machines/partition layout. I could try using the information you provided (
d1.partitions…) but I have a feeling that there is something else to it. Lately we have seen at least two posts where expand didn’t work properly and I still assume it was a very weird issue in the binary capturedd1.mbrwhich is very hard to come by (hex editing…).Edit: What partition layout is this really? From my point of view this doesn’t match the layout figures you posted above.
-
Well if they don’t match that may be part of the issue. The layout is from two identical Optiplex 7060 with 500GB drives. Top was one that imaged successfully, bottom is what I see when it doesn’t. All should match my golden image which is also an Optiplex 7060 with a 500 GB drive. I’m not sure where the disconnect would be from fogs settings, the image, and what ends up on the machine.
Again I’ve more or less gotten around this by modifying my image. So I figure if this issue is unique to me it’s probably safe to let it go. If it does start poking up from others at least my info would be a good starting point.
