@george1421 said in Error deploying an existing image to SSD drive:
If you look on the fog server in /images/aiov910 directory does d1.mbr exist?
Just to add a little bit here as some of the information is being exchanged in chat as well… The d1.mbr file is there. But from what I see so far it doesn’t seem to be an issue of disk being too small. Why am I saying this? Let’s do the calculations: ( 498069504 + 2048000 ) (nvme0n1p4 start + size is also roughly the value of last-lba in the header) * 512 (byte sector size) / 1024 / 1024 / 1024 = 238.5 GB -> I can’t imagine this image being taken from a 500 GB or 1 TB disk. While you can have the partitions not filling the disk we wouldn’t see the a similar last-lba value with the disk being much larger. The source disk being 4k sector size is possible but very little likely because of first-lba being 34 and nvme0n1p1 starting at 2048.
@Jim-Holcomb So then let’s see why it actually fails on nvme0n1 as well. Please schedule another debug deploy task, step through it till you hit the error and then manually run the printed command: sgdisk -gl /images/aiov019/d1.mbr /dev/nvme0n1 -> Take a picture of the messages on screen and post here!
Niether 0.10.9 nor 0.11.5 of the refind binaries made a difference (same exact error). Fog works, and the booting network UEFI and into Windows is 100% fine on the Lenovo m93p.
Turns out about 30% of our public machines are without a CSM module. Because of that, and because BIOS boot works, I have decided to fall back to BIOS boot deployment for my org’s public computers. The way my fog installation is now will still allow me to grow with the Lenovo’s without having to fight with it.
Thanks for looking into this with me, I have appreciated the help.
~ P.V.
@Real1987 What does this have to do with FOG imaging solution? Is this after deploying an image to the 3400? What version of FOG do you have? What OS is in the image? What type is it set to (resizable or non-resizable)? Is BIOS set to legacy mode or UEFI?
Many more questions arise, but we might start with those.
@Oleg said:
I don’t know if it has to do something with the timeout issue but in /etc/default/grub I added
We don’t use GRUB for PXE booting hosts usually! Seems like you have customized your setup a fair bit. I may ask you to tell us more about the customization to we are able to properly help you!
I changed manually the kernels in /var/www/html/fog/service/ipxe/ to the 4.15.2 Kernel.
With the older kernel the issue with the timeout is gone.
That’s interesting. So it seems like a Linux kernel network driver issue from what we know so far. Let’s start by trying to find out what driver is used. Please boot Windows on that machine, open device management and get us the device ID from there. Usually in the form 12c4:5f78.
@Norm said in Help with Mac imaging:
When I upgraded to Fog 1.5.8 it broke.
Can you please give us some more details on where it breaks. Please take a picture of the screen and post here.
@ZrytyADHD said in Booting accros networks:
You have a number of problems here.
FOG doesn’t like it when you change the fog server’s IP address after FOG is installed. There are several steps that you must do if you decide to change the FOG server IP address after fog is installed.
Why are you mixing WDS and FOG in your booting process? You can do manage it but I would go about it a bit differently.
Your section of the isc dhcp server is just wrong in my opinion.
if exists user-class and option user-class = "iPXE" {
filename "http://10.0.0.68/boot.php";
} else {
if option arch = 00:00 {
filename "undionly-mj2.kpxe";
} else {
#UEFI Bootujemy z WDS UEFI
next-server 10.249.4.20;
filename "boot\\x64\\wdsmgfw.efi"
}
}
a. I’m not aware of a user class in the dhcp discover packet. There is a vendor class
Vendor class identifier: PXEClient:Arch:00007:UNDI:003016
b. The following line is wrong for several reasons
filename "http://10.0.0.68/boot.php";
b.1 you are telling the PXE rom to load a http protocol. Almost all PXE roms use tftp not http.
b.2 The path to the boot.php is wrong if you are trying to call the boot.php on the fog server the path is <fog_server_ip>/fog/service/ipxe/boot.php
For this I would just use filename "default.ipxe"; but that still will not work because you don’t mention the boot loader (undionly.kpxe or ipxe.efu)
c. You are saying if the option is bios then load undionly-mj2.kpxe (not a fog supplied boot loader) but if everything else call WDS. But only do this if user-class == “iPXE”
d. uefi pxe booting into FOG is not supported
There are ways to fix this, dhcp booting, but please explain why you are mixing FOG and WDS. What is your goal of doing this? Will it be a for ever solution?
