Topics created by Jim Holcomb

@Jim-Holcomb So unfortunately i’m not readily available for a remote assist due to work requirements and duties so I apologize.

@Jim-Holcomb said in [BUG] iPXE Boot Loop & Menu Failure After FOG 1.5.10.1660 Upgrade:

After upgrading to the latest FOG version, my PXE boot environment is broken. What used to work flawlessly is now a disaster. PXE clients either hang, enter a loop, or display autoexec.ipxe not found. Sometimes pressing ESC brings up a green DOS-style login prompt, then fails to chainload. Sometimes they hang on “Booting…” indefinitely.

So this “autoexec.ipxe not found” always shows. This is not an issue. It’s simply saying there’s no file called autoexec.ipxe on your /tftpboot folder. It’s NOT whatever was causing ipxe boot issues. I’m guessing this PXE boot environment was broken due to whatever was changed?

As to the selective hard drive. I’m not sure I understand what is wrong here. YOu watched it write ONLY to the /dev/nvme drive but somehow it wrote to both the sda and the nvme? Something doesn’t sound right there. Single Disk resizable and Multiple Partition Single disk shoudl only write to a single drive and be done. Do you have video of this process writing to both? I only ask because seeing this in action will help me understand where the code is flawed. To my knowledge, however, it seems more likely that at some point before you wrote to the NVME it had accidentally written to the SDA drive, then you try to figure out how to have it write to the NVME. Then, finally, it was able to write to the NVME, but now it LOOKS like it wrote to both because the SDA drive was never cleared out?

And yes, d1.mbr is absolutely correct. That’s how it initializes the disk.

Hello All! (Especially Wilsol)

I used the top configuration ideas from Wilsol, and before I could get through the entire list, darned thing started working. (yeah probably secure boot, thanks Tom for pointing us in the right direction)

Thanks to everyone for the assist.

-Jim

Oops!
I deleted from CLI. But I just did that again and the image did not appear in the list and the storage number increased accordingly.

-Jim

@Jim-Holcomb Please share more details.

@sebastian-roth said in Image menu not showing recently created images:

@Jim-Holcomb How many images do you have? I am not aware of a limit of images that can be seen in the menu but I can’t tell you for sure.

So would you be able to delete an older one and see if one of the new one pops up in the menu?

Hello Sebastian - I tried that - deleting older images. No joy. You know that the image menu just keeps going to the next number in order. I am currently at 160, but of course I do not have anywhere near that many images. Then menu goes to 158 then ends. Yet if I go to “List all Images” of course the image resides there with all of it’s available information, size, date, etc…

I am stumped here.

@jim-holcomb Was an upgrade recently done?

@sebastian-roth
That’s true, but every time I upgraded either fog or the OS, something would break. I used to have the advantage of Tom Elliott being available to assist in these cases, but he never returns emails or phone calls from me in like nearly 2 years.

@Jim-Holcomb What do you mean by “manually” - through the FOG PXE boot menu?

@Jim-Holcomb I still don’t fully understand. The database is just a point to store and pull the data from. Nothing more.

If you manually rename the folder in Linux, would you expect the database to automatically update when now it has no reference point? It’s the same reason in reverse. Why allow the folder to be renamed in the terminal if it won’t update the database that may be referencing it?

The folder doesn’t get automatically created when you define a new image. This only happens after the image is defined and captured. The pieces handling it are all after the database information is pulled. The GUI is not creating the folder. FTP is.

If you manually change the folder name in the terminal, you will still need to change the folder in the GUI. It’s the same for updating the path in the GUI. While you could temporarily store the change, but what about you are changing the path when the image hasn’t been captured yet?

@Jim-Holcomb Great to hear! Keep us posted. I won’t be online much in the next two days though…

@Sebastian-Roth Perhaps not for the MBR issue; but certainly for the resize issue.

@Sebastian-Roth okay, thanks. I’ll do some research and see which route seems best. I still have a lot to learn about linux and wasn’t sure if there was a “new” way of adding storage to a FOG server since the wiki didn’t mention LVM and I was am not familiar with that yet.

@Athena What exactly do you need help with?

It’s there now and working. It was not there on Friday, on any of the pages. Not sure if you guys did a refresh or anything like that, but it’s working just fine now. Thanks a bunch!

@Jim-Holcomb said in http 500 error:

uncaught error: call to a member function lastInsertID()

This is usually due to a database connection issue. Please read through this: https://forums.fogproject.org/topic/10006/ubuntu-is-fog-s-enemy

@quazz You’re right. Must have been a bad spot or something. One thing we all know Windows does is to add a minimum of two partitions on a clean install. Mine had 3 (ms system reserved, empty) partition. Did lots of research, found I don’t need three, just setup GPT with single partition, did base install, and now FOG imaging upload works.

Thanks for pointing me in the right direction.

To me this sounds as if the OP never had IT in UEFI mode. I am pretty sure of that because when you try to PXE boot a legacy binary in UEFI it should not even get as far as “initializing devices” …

@x23piracy update to working branch for now.

@sebastian-roth

As recommended, I did upgrade to RC-9, and yes the issue has been resolved. Thanks all! Please mark this as solved!

Been there - done that!

Tom’s reply worked perfectly! After months of playing with this thing, I finally have a working FOG server! Yea!

Thanks Guys