Error on image upload

Zourous · Jun 26, 2019, 8:16 PM

Anyone know what is happening here? Obviously something to do with partitions, but this just started happening out of the blue on an image I have uploaded many times successfully. It will still upload, but then a reimage with this image will result in an unbootable PC. I tried other previous good images and the same thing. I tried another device and the same thing, so I suspect something has happened to the server. I have already rebooted the server. Thanks for any help.! !

Sebastian Roth · Jun 26, 2019, 8:42 PM

@Zourous said in Error on image upload:

I tried other previous good images and the same thing.

What do you mean by that? Sounds like you tried deploying a different image. I suspect you don’t get the exact same error message as the process of deploy is different to upload. Just wondering what you meant here.

but this just started happening out of the blue

I suspect you have updated your FOG server or maybe the init files itself. But anyhow, let’s try to track this down.

Please cancel the current upload task and schedule a new one as debug for the same host machine (as you would normally schedule a task but just click the checkbox for debug before you actually create the task). Boot it up and hit ENTER till you get to the shell. Now run parted -l /dev/sda, take a picture of the output on screen and post here.

Sebastian Roth · Jun 26, 2019, 8:57 PM

@Zourous Re-reading this I think we had this exact same issue a couple of weeks ago and it was fixed already. Please download the most current init files available here: 32 bit and 64 bit and put in /var/www/html/fog/service/ipxe/ on your FOG server. Best if you rename the original ones just to have a backup copy at hand.

With the new init files you also have to manually change a setting in the FOG web UI: FOG Configuration -> FOG Settings -> FTP Server and increase KERNEL RAMDISK SIZE from 127000 to 275000.

Zourous · Jun 27, 2019, 8:13 AM

Hi Sebastian,

Many thanks for your speedy reply at such short notice. Much appreciated as I’m on a short timescale to get a task completed. I think I might have solved it, but your post gave me a clue. Firstly I tried the fix in your follow up post about updating the init files and ramdisk size but this didn’t solve it. I then had a look at the partitions with the debug task. It showed up a USB stick I had connected as well as the fixed drive I wanted to image and this is where the issue is. I tried again with the USB out and it worked fine and as expected. I even ran the task again with the USB inserted just to prove it and yes the issue was back again. This is most strange as I swear I’ve uploaded before with a USB stick in and assumed the process would see it and just ignore it. I quite often use the USB stick just before upload to run my sysprep answer file from. Anyhow I’m happy I know the answer. Thanks again.

Sebastian Roth · Jun 27, 2019, 9:01 AM

@Zourous Thanks heaps for letting us know. Definitely something I wouldn’t have thought of!

Would you do me a favor? Please run another debug upload task with the USB key plugged in and when you get to the shell run the following commands, take pictures and post here:

parted -l /dev/sda
parted -l /dev/sdb

My guess is that the USB key is first in the list (sda) and therefor we run into an issue.

@Quazz Maybe we should add a check for removable drives and warn the user about this.

Quazz · Jun 27, 2019, 9:31 AM

@Sebastian-Roth Good idea in general, though, not entirely sure how to go about that at the moment.

Sebastian Roth · Jun 27, 2019, 11:31 AM

@Quazz I think there is a flag for removable devices in /proc or /sys… Will have to look that up though.

Zourous · Jun 28, 2019, 10:55 AM

@Sebastian-Roth said in Error on image upload:

@Zourous Thanks heaps for letting us know. Definitely something I wouldn’t have thought of!

Would you do me a favor? Please run another debug upload task with the USB key plugged in and when you get to the shell run the following commands, take pictures and post here:
parted -l /dev/sda
parted -l /dev/sdb
My guess is that the USB key is first in the list (sda) and therefor we run into an issue.

@Quazz Maybe we should add a check for removable drives and warn the user about this.

This is after the command parted -l /dev/sda. You see the USB stick at the bottom. If I run parted-l /dev/sdb I just get the USB information on it’s own.

It looks like the USB stick was bootable at some point in a previous use (I didn’t realise this before) so maybe that it where the confusion is and Fog automatcially adds it to the image to upload?

Sebastian Roth · Jun 28, 2019, 11:47 AM

@Zourous I am not exactly sure I understand this yet. My guess was that maybe the USB key turns up as sda. Maybe that happens randomly but it’s very unlikely (now that I think a bit more about it) as SCSI/ATA disk subsystem devices usually get enumerated before the USB stuff. But if you have a couple of minutes you could do the whole test for maybe 10 times (reboot into debug task again and run both parted commands to see if at some point the USB drive shows up as sda).

It looks like the USB stick was bootable at some point in a previous use (I didn’t realise this before) so maybe that it where the confusion is and Fog automatcially adds it to the image to upload?

If the image is set to “single disk…” then FOG simply grabs the first disk. So if it’s randomly changing (tests mentioned above) that might explain things. The boot flag shouldn’t play a role as far as I know.

Looking at the first picture you posted again I see that it tries sda1 and sda2 and so it’s very unlikely the USB key. But still we are very sure this was causing it. So possibly some command we use in the scripts is just being confused by the USB key.

Quazz · Jun 28, 2019, 6:22 AM

@Sebastian-Roth Perhaps it’s not so much that the USB stick is first, but rather that the command that check the partition flags fails when it’s plugged in for some reason.

Although, I’d have no clue how that would even possible since the parted command explicitly is ran against a single disk, which doesn’t appear to be the USB stick anyway.

And the command shouldn’t fail on it regardless as far as I can tell.

edit: Given the line throwing the error, I can only assume he’s using older init files (since there’s no test command at line 109 at latest)

I can see this line throwing such an error under certain conditions:

if [[ $(parted -l "$hd" | grep boot | awk '{print $1}') -eq $part_number || $(parted -l "$hd" | grep msftres | awk '{print $1}') -eq $part_number || $(parted -l "$hd" | grep hidden | awk '{print $1}') -eq $part_number ]]; then

which was changed at https://github.com/FOGProject/fos/commit/693a4f74d81fad5eba09799768c53f25b7c50e3c#diff-9c3fc2c5bb45d13976e29f477b8e67d4

Quazz · Jul 2, 2019, 8:42 AM

@Zourous What FOG version are you running?

Zourous · Jul 2, 2019, 8:42 AM

@Quazz said in Error on image upload:

@Zourous What FOG version are you running?

I am running FOG version 1.5.5

Let me know if there is anything else you want me to test?

Quazz · Jul 2, 2019, 8:44 AM

@Zourous Try updating to 1.5.6, it should include the newer init files which I believe should not run into this error, but should be tested of course.

Sebastian Roth · Jul 2, 2019, 3:35 PM

@Zourous Would you mind doing the test I suggested (10 times in row to see if USB key is always sdb)?

Zourous · Jul 3, 2019, 10:41 AM

@Sebastian-Roth said in Error on image upload:

@Zourous Would you mind doing the test I suggested (10 times in row to see if USB key is always sdb)?

I tried it 10 times and it was the same each time. I even tried an 11th time with another stick and it was the same. I’m guessing you could probably replicate this on a similar set-up.

Zourous · Jul 3, 2019, 10:45 AM

@Quazz said in Error on image upload:

@Zourous Try updating to 1.5.6, it should include the newer init files which I believe should not run into this error, but should be tested of course.

Sorry Quazz, it’s not something I have time for or want to do at the moment. I did test some newer init files that were posted earlier in this thread and I assumed these were the newest ones.

Quazz · Jul 3, 2019, 11:03 AM

@Zourous Did anything change with the newer init? Different line number or slightly different error?

Sebastian Roth · Jul 3, 2019, 11:27 AM

@Zourous said in Error on image upload:

I tried it 10 times and it was the same each time. I even tried an 11th time with another stick and it was the same. I’m guessing you could probably replicate this on a similar set-up.

Thanks! I’ll definitely look into this when I have a bit more time.

Zourous · Jul 5, 2019, 10:56 AM

@Quazz said in Error on image upload:

@Zourous Did anything change with the newer init? Different line number or slightly different error?

I will try and test when I have a chance maybe next week

Zourous · Jul 5, 2019, 11:02 AM

Also I have just noticed a new problem off the back of this problem. The USB stick got uploaded into the image at some point. I noticed this and used a tool to take the extra USB partition away again from the image, but after this the images uploads and shows the size as the full space of the fixed disk and also doesn’t resize to a bigger disk when it is deployed to a bigger disk. I’m not sure how I can correct this issue now.

Error on image upload

158

12.0k

17.3k

155.1k