@Sebastian-Roth said in Dell Latitude 3540:
@Zourous said in Dell Latitude 3540:
I’m on 1.5.5
Well then you might want to upgrade to 1.5.10 or manually download newer iPXE binaries here: https://github.com/FOGProject/fogproject/tree/master/packages/tftp
I tried to updater to 1.5.10 but ran into new issues so decided to try a newer IPXE binaries as you stated.
This I’m glad to say this worked, so thank you Sebastian.
@Sebastian-Roth said in Dell Latitude 3540:
@jgibson60 @Zourous As for a quick test you can rename the files. Make sure you remember the correct names to restore those later on.
May I ask which version of FOG you two use?
Hi @Sebastian-Roth, I’m on 1.5.5
I’ve just tried all the different efi files available and none of them work for this model.
@Tom-Elliott said in Dell Latitude 3540:
@Zourous The file is already available as part of the base install.
We build:
snp.efi
snponly.efi
ipxe.efi
realtek.efiProbably a few others, but it’s already in the tftp folder
Not knowing the proper way to do this I’ve renamed ipxe.efi to old and realtek.efi to ipxe.efi and then rebooted the server. Unfortunately it is the same result. Any other ideas please? I could have over 100 of these to image in the coming weeks so quite a big problem for me.
By some chance, I have just googled Dell Latitude 3540 on FOG and have ended up here. I can confirm I have the exact same issue. Where do you get the realtek.efi and where do you put it please?
@george1421 Many thanks that was along the lines that I was thinking but you’ve confirmed my thoughts are correct. I’ll go ahead now and set it up. Thanks again.
Hi George, thanks it was option 2 that fits what I need the best. Just wanted to know in theory that it works. I only need the internet connection to get fog updated on install really. I also wasn’t sure what static address to use for the Fog server if it’s just the server plus another PC. My home wifi uses a class C address and would hand the server an address to use for the internet access. At the same time the Fog server needs to be a DHCP for the one PC that is going to connect to it. I wasn’t sure if this type of configuration with two DHCP’s in use would cause issues.
Is this possible? I would like to have the Fog server on one PC and then image another PC. They would just be connected by a single network cable. The Fog server would have internet access through wireless on my home set-up.
@Sebastian-Roth said in Error on image upload:
@Zourous Did you notice the fixed init files I posted yesterday? See below.
Yes, I’ve just tried them. On a debug test it still shows as before when you type in parted -l /dev/sda, but on the upload I can’t see any issues like in the original screenshot I posted. Thanks for all your efforts.
@Zourous said in Error on image upload:
@Zourous said:
I noticed this and used a tool to take the extra USB partition away again from the image
I am not sure I get this. Which tool did you use to “take away” the USB partition? Do you mean you removed the partition from the USB key before actually uploading or after upload finished?
About the “doesn’t resize”… We need more information on this! Partition layout (
d1.partitionsfrom the image directory) and so on.I just used a tool outside of Windows to remove the inserted USB partition that had made it’s way onto the main image. By doing this I assume it has messed something up and that the partitions are not recalculated when I try to upload the image again because it seems to not shrink the image to the size of the data before upload or then resize it after deployment. Here is the d1.partitions file
label: dos label-id: 0x86308630 device: /dev/sda unit: sectors /dev/sda1 : start= 2048, size= 1024000, type=7, bootable /dev/sda2 : start= 1026048, size= 249043631, type=7I noticed there is a d1.fixed_size_partitions file and I tried taking the :2 out of this, but this didn’t solve it.
I think I found the fix on another thread. I just need to run chkdsk / f and it corrects it for the next upload
@Zourous said:
I noticed this and used a tool to take the extra USB partition away again from the image
I am not sure I get this. Which tool did you use to “take away” the USB partition? Do you mean you removed the partition from the USB key before actually uploading or after upload finished?
About the “doesn’t resize”… We need more information on this! Partition layout (
d1.partitionsfrom the image directory) and so on.
I just used a tool outside of Windows to remove the inserted USB partition that had made it’s way onto the main image. By doing this I assume it has messed something up and that the partitions are not recalculated when I try to upload the image again because it seems to not shrink the image to the size of the data before upload or then resize it after deployment. Here is the d1.partitions file
label: dos
label-id: 0x86308630
device: /dev/sda
unit: sectors
/dev/sda1 : start= 2048, size= 1024000, type=7, bootable
/dev/sda2 : start= 1026048, size= 249043631, type=7
I noticed there is a d1.fixed_size_partitions file and I tried taking the :2 out of this, but this didn’t solve it.
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.
@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
@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.
@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.
@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?
@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/sdbMy 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?
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.
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.! !
Yes, Yes, Maybe & Dell
Thanks for the info so far.
We don’t use the multi-casting as it hasn’t worked too well for us. In previous Fog versions (haven’t tried it recently) the clients wouldn’t start imaging, even though I have had it working before on specific versions. Secondly when it was working it was flooding the network and slowing general users down, so for this reason I stuck to unicast.
Is there a best OS in anyone’s opinion where the bonding will most likely work without issues. If you search on the net for Ubuntu and bonding there are various people that can’t get it working so I’m not sure if it’s a bug or just a mis-configuration thing. I’ve spend hours trying to get it working with no success.