Posts made by Sebastian Roth

@cyrmoon said in NBP file downloaded succesfully:

i downloaded from “https://github.com/FOGProject/fogproject/tree/1.4.4/packages/tftp” the “ipxe7156.efi” , i put it in /tftpboot; i rerun the install fog script and it seems to work.

This seems to reverse the logic a bit. iPXE binaries you put into /tftpboot are in the correct place. If you re-run the installer after that you will have those in /tftpboot being overwritten again by whatever installer you have.

By the way, why did you use the way older 1.4.4 binaries??

@Quazz While I am not exactly sure till we see the error message I would assume this is not the issue here (see my size calculations).

@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!

@Jamaal What’s your actual aim when you consider adding another storage node? Sometimes the concept of this is being misunderstood and so it’s better to talk about this before you head into it. As well I may ask you what your FOG setup looks like as of now? Installed Linux directly on hardware or in a VM?

@kyokushin Please schedule a debug task and boot the machine again. Then when you get to the shell run the following commands:

ip a s
dhclient -v -r enp0s1
ip a s

@cyrmoon said in NBP file downloaded succesfully:

I tried to change for a older kernel in fog but nothing at all.

This issues seems to be caused by iPXE not the Linux kernel we use in FOS to do the actual imaging.

Is there a solution or it will be fixed in next versions?

FOG is open source and so we rely on people like you to test things and let us know what works and what not. We don’t have all the hardware to test on our own.

So let’s get into this and see what is actually causing the failure after “NBP file downloaded succesfully”. Before you updated from 1.5.7 did you see the FOG boot menu after the “NBP file downloaded succesfully”? I just want to make sure we hunt down the right path. I am asking because you can setup FOG to hide the menu and just run a default menu item. If that is the case we’d need to look further than iPXE…

Here is the code tree of FOG 1.5.7 iPXE binaries. Just download the iPXE binary that you are using in you DHCP server and put that in /tftpboot directory on your FOG server. See if the fujitsu esprimo g558 works correctly again.

Now I see, this is just a copy&paste from an old topic… https://forums.fogproject.org/topic/988/fog_disable_chkdsk-setting

@Bienxanh Why do you waste our time I wonder?

@Bienxanh said:

Seems like the “FOG_DISABLE_CHKDSK” setting in .32 is not set correctly…

Do you really mean FOG 0.32 or is this a joke? That version is roughly a decade old and we surely can’t backport any fixes to such an old version.

@brakcounty Over all the details about GRUB I lost sight on what this topic is all about… The USB method uses GRUB as boot loader because it can be installed into MBR on the USB to be used to boot legacy machines. As I said before, the alternative USB boot method is not part of the official FOG stuff and has not had enough attention to be fully integrated yet. Not because it’s impossible to do but because we have way to many things on the list.

Now that you use UEFI only in your setup you could skip GRUB altogether and directly boot using iPXE from the hard drive’s UEFI boot partition and should be able to use FOG exactly the way you would if it does PXE boot. For that you just grab one of the iPXE .efi binaries from your FOG server (e.g. /tftpboot/ipxe.efi) and but that on your disk’s EFI boot partition as \BOOT\EFI\BOOTX64.EFI (case doesn’t matter here as Windows will ignor it). When booting the iPXE binary will run its embedded script to get an IP from DHCP and chainload to the FOG boot menu.

@jmvela2x Thanks very much for sticking with us on this and doing the tests!

@brakcounty Don’t think there is a GPT partition layout on any of those three disks. While hd2 doesn’t even seem to have partitions at all. Maybe this is the USB key? Can you boot to Windows and post a picture of the disk management view? Shall see if it’s MBR or GPT there.

@Jamaal From the error message I would imagine that this last call is failing because an earlier query also failed and variables are not being set correctly because of the earlier error. So you need to post the full error you see!

I am not a PowerShell wiz but from what I know the read-host stuff you added should work.

@brakcounty Sorry, just updated my post again.

The windows partition I’m trying to boot from is a GPT-EFI bootable system.

On the GRUB command line run the following commands, take a picture of the screen and post that here:

set pager=1
insmod part_gpt
insmod part_msdos
ls

Is that “+1” always supposed to follow the chainloader entry?

Yes, as far as I know.

@brakcounty said in Boot FOG on client PC using a special partition?:

The ls command shows hd0 hd0,msdos hd1 hd1,msdos, hd2 hd2, msdos.

Well then you have a legacy MSDOS partition layout and can’t use the GPT stuff! Have you tried the good old MBR chainloader style yet?

     insmod part_msdos
     insmod chain
     rootnoverify (hd0,0)
     chainloader +1

Play with the numbers (at line rootnoverify) till you hit the right partition/disk.

@iamyogo I’d be keen to hear if any of these did not show the error.

@jmvela2x said in Multicast without registration starts OK, but hangs and disconnects clients due to timeout.:

I did see one error in the FOMulticastManager status output that may be a cause for concern. Expected?

Thanks, found and fixed in latest dev-branch.

@brakcounty As we usually don’t use GRUB in FOG for booting there are not that many resources on this topic in the forums. For that you need to search external sites. Here is a list of different GRUB configs used for chainloading to a Windows installation on disk: https://wiki.gentoo.org/wiki/GRUB2/Chainloading

I have not see the ntldr used much yet. Most Linux installations that setup dual booting with windows use the chainloader command I think. Try different ones and you should be able to boot from disk through this.

@whyzzi @george1421 From what I read between the lines I would also think that iPXE fails to hand off to rEFInd, though not sure why yet.

Can you please download different versions of rEFInd and give those a try? For each version download refind-bin-0.xx.y.zip, extract that and try out refind_x64.efi. See of you can make it chainload from disk using one of these. As George said, we moved from a single rEFInd binary to platform specific ones not too long ago. And I am wondering if you have a system here that pretends it’s 64 bit actually has a 32 bit CPU or something.

I have to check on a multicast failure I had with 1.5.8 but that is a different post for when I am ready to fix it and find that I need help.

We have fixed a few things in multicasting in the latest RC version.

@lebrun78 said in https, with home certificates and boot.php… No such file or directory (http://ipxe.org/2d0c613b):

./installfog.sh -C -K

I really hope you don’t use the fog-client software as re-generating the internal CA will break all communication to the fog-clients.

I modified /etc/httpd/conf.d/fog.conf with…

This will be overwritten as soon as you re-run the FOG installer. I know this part of FOG needs some more attention but I can’t find the time to get into all of this. So I lost track of the SSL stuff a few weeks ago. Will need to work on the wiki article about this again: https://wiki.fogproject.org/wiki/index.php?title=HTTPS (this is not ready-set-go yet)

I tried to generate a new ipxe configuration
cd /opt/fogproject-1.5.9-RC2/utils/FOGiPXE/
./buildipxe.sh

You will need to specify your CA cert on the command line when building and manually copy the binaries over after that, e.g.:

cd /opt/fogproject-1.5.9-RC2/utils/FOGiPXE/
./buildipxe.sh /etc/httpd/cert/DigiCertCA.crt
cd ../../packages/tftp/
find -type f -exec cp -Rfv {} /tftpboot/{} \;

@fly Just as you’d create other boot entries as well. If you’ve never done this before you wanna check out George’s topic on booting ISOs: https://forums.fogproject.org/topic/10944/using-fog-to-pxe-boot-into-your-favorite-installer-images

For basics: In the fog WebGUI go to FOG Configuration -> iPXE New Menu Entry and enter the values accordingly. Name and description as you like. The iPXE commands go into the important field Parameters. Try this:

initrd http://192.168.1.9/fog/service/ipxe/iso/PER620_BOOTABLE_20.04.00.126.iso
chain memdisk iso raw || goto MENU

All untested… You definitely need to change the IP and maybe path/URL depending on where you want your ISO to be located. HTTP or TFTP