Posts made by Scott Lynch

@george1421 :

Thanks for mentioning the gzip/compression settings of the image in the FOG console. I would never have thought they were a cause of one of my issues. So zstd is the preferred compression method for the images?

@george1421 :

Ok, I adjusted my image settings and restarted the capture process. This time it is behaving as it “should”. At least everything seems to be optimal on the capture process.

@george1421 :

Sorry for the late reply. Other work kept me busy. I will verify the image settings and make the adjustments you mentioned and will try again. It will be Monday before I will likely get the results for you.

@scott-lynch :

Here is the error.

At this point I need to get to my doctor appointment. Thanks for your help.

@george1421 :

Capture task started and client booted to FOS, selected option 1, and it is currently resizing the filesystem. So far, everything looks optimal. It didn’t even hiccup on the call to DHCP for an IP Address. I think the issue with it “failing” had to do with the client sending 4 requests for an IP address.

However, the client just threw a garbled error message. I’ll try and upload a picture. One sec.

@george1421 :

No problem. I will start a task and do as you say on booting the client.

@scott-lynch :

I am about to leave for the day. Doc appointment. I will continue in the morning. Is there a dictionary of commands for the fos boot system somewhere I can look at to familiarize myself with the next bit of testing?

@george1421 :

ip link show gives:

eth0: <BROADCAST, MULTICAST, UP, LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 3c:18:a0:0c:d6:05 brd ff:ff:ff:ff:ff:ff

The network connection looks sound. (Besides, with the trouble I went through to find a usb-to-ethernet adapter that the computer would recognize during boot, it better work… LOL)

@george1421 :

I don’t think there is a need, I ran the ifconfig command and it shows that eth0 has an IP address and the link is up. No idea why it would say it failed to get an IP address. Regardless, it seems to be okay.

So, to begin the debug process, since I am NOT having an issue with eth0, I use the command ‘fog’ to start an image capture?

@george1421 :

I updated the grub.cfg with my server’s IP address and booted the client. It loaded to the DHCP testing, still threw a could not get IP address from DHCP on the 4th query of eth0, but loaded to the FOG splash screen when I hit the key to continue.

@george1421 :

LOL actually, I saw that in the tutorial and forgot about it… No biggie. Easily fixed.

@george1421 :

Ok, I booted to the FOS and it worked to the point of loading the kernel and executing the client compatibility tests. After starting the eth0 interface and waiting on the link to come up, it did some udhcpc discover with the client IP, deleted routers, and added dns entries 3 times then failed to get a response from DHCP on the 4th run through.

@george1421 :

Will do. I was just having an issue with grub not wanting to have both grub-efi-ia32 and grub-efi-amd64 installed simultaneously. Every attempt to install one, uninstalls the other.

I’m not exactly proficient with linux, but am getting a crash course it seems…

@george1421 :

Well, to get everything set up for all of this, I deleted the bzImage and bzImage32 files located in /var/www/fog/service/ipxe, but I didn’t touch either the init.xz nor the init_32.xz. I also deleted anything with ‘ipxe’ in its filename from /tftpboot/

I then ran the FOG installfog.sh in fog_1.4.4/bin to have it put everything back that I’d removed.

@george1421 :

I am still working through the FOS build, but have run into a few snags I am attempting to get through. Namely, should I be looking at the multiboot instructions? They seem to be the only set that mentions EFI…

@sebastian-roth :

My bad. The Intel TPM chip was still enabled. I just disabled it and, just for kicks, ran the PXE boot sequence. I made it to the FOG boot menu. It correctly showed the host as being already registered. (I had manually entered the information into the FOG console since I am having to use a usb-to-ethernet adapter to get things rolling client side.) I then attempted to have it run the Client System Information (Compatibility) at which point it successfully loaded the stock bzImage. It threw a few ACPI errors before going into kernel panic. Exact message for the kernel panic is:

Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(1,0)

In truth, this is a bit of headway given that, before, it wouldn’t even load the kernel, much less read it and attempt to execute it.

@sebastian-roth :

No problem. I do have secure boot disabled on the WinBook and the 2nd test computer. Neither computer would boot to the USB stick with the secure boot option turned on. I will go through the FOS tutorial and get back with the results.

@george1421 :

Ok, I’ll go through the tutorial now. I have the FOG server reset to the stock kernel, so everything should be good to go. Will post back with results.

@george1421 :

My work day is about to end; however, I would be happy to go through the process with you sometime soon.

I did test loading FOG via UEFI on a completely different model of machine. The new machine doesn’t complain about the exec format error. The new machine loads to the FOG boot menu like it should; but, when a task is selected it immediately reloads ipxe and unloads it, and then reloads ipxe in an almost continues loop, when it finally stops, it loads the reFind.efi which gives restart and reboot as its two main options.

@sebastian-roth :

I just noticed your question about me trying to get an old FOG server UEFI capable. The answer is no, I only have 1 FOG server currently running on Ubuntu Server 16.04.03.

I am going through the custom kernel builds because everything I have been reading said the most likely cause for the exec format error was the kernel was lacking these two settings enabled:
EFI runtime service support = y
EFI stub support = y