PXE Menu Problem - timeout and boot from HDD (menu option 1) -- doesn't happen

mkstreet

The same hardware I used to use with Fog v.032 and then it worked no problem.
Here is the host info from the Fog v1.2.0 inventory:

System Manufacturer LENOVO
System Product 3554CTO
System Version ThinkCentre M72z
System Serial Number PBG8GDL
System Type Type: Desktop
BIOS Vendor LENOVO
BIOS Version F6KT32AUS
BIOS Date 09/03/2013
Motherboard Manufacturer LENOVO
Motherboard Product Name MAHOBAY
Motherboard Version NOK
Motherboard Serial Number
Motherboard Asset Tag
CPU Manufacturer Intel Corporation
CPU Version Intel Core i5-3470S CPU @ 2.90GHz
CPU Normal Speed Current Speed: 2900 MHz
CPU Max Speed Max Speed: 2900 MHz
Memory 3.68 GB
Hard Disk Model WDC WD10EZEX-08RKKA0
Hard Disk Firmware 80.00A80
Hard Disk Serial Number WD-WCC1S6814856
Chassis Manufacturer To Be Filled By O.E.M.
Chassis Version
Chassis Serial PBG8GDL
Chassis Asset

Wayne Workman

I’ve been having the blues with Lenovo ThinkCenters at work recently…

Thus far, undionly.kkpxe and r3277 fixed it as far as I can tell.
It’s worth a try, for sure. Turn your menu back on and see how it goes.

For more information on that, see this thread: [url]http://fogproject.org/forum/threads/lenovo-mt-m-9964-a1u-cant-register-fails-compatibility-test.12766/[/url]

Also, you’re particular model is listed in WorkingDevices using undionly.kpxe as of late last year: [url]http://fogproject.org/wiki/index.php/WorkingDevices[/url]

mkstreet

Hmmm… okay… These Lenovos worked perfectly fine under Fog 0.32…

but what do I need to do to try “…undionly.kkpxe and r3277…”?

Wayne Workman

You could just swap your boot file for now to undionly.kkpxe.

If that doesn’t work, I’d recommend trying the latest revision.

mkstreet

Umm… sorry for being dense… but is “undionly.kkpxe” something I download from the fogprohect.org website or ??

Next, when you say try the latest revision, you mean the most current release of Fog itself, right? I’m fine with doing that, if that is a better way.

Tom Elliott

undionly.kkpxe should already exist in your fogserver’s /tftpboot directory.

Either make a copy of this file as your current undionly.kpxe[code]mv /tftpboot/undionly.kpxe /tftpboot/undionly.kpxe_orig
cp /tftpboot/undionly.kkpxe /tftpboot/undionly.kpxe[/code] OR Edit your DHCP servers Option 67/Filename to look at undionly.kkpxe.

mkstreet

Ok. I will try that in the morning. I will do the mv/cp way.
Do I need to restart anything to have this take effect?

Wayne Workman

[quote=“mkstreet, post: 45916, member: 24215”]Ok. I will try that in the morning. I will do the mv/cp way.
Do I need to restart anything to have this take effect?[/quote]

Nope.

mkstreet

Ok.

I did the mv/cp for the kpxe/kkxe. Here are the results:

Fog PXE Boot Menu Configuration.No-Menu=unchecked
Fog PXE Boot Menu Configuration.Exit-to-hard-drive-type=Sanboot
Result: after PXE menu, black screen with just an underline-style cursor blinking in the upper left corner

Fog PXE Boot Menu Configuration.No-Menu=unchecked
Fog PXE Boot Menu Configuration.Exit-to-hard-drive-type=GRUB style
Result: after PXE menu, black screen with just an underline-style cursor blinking in the upper left corner

Fog PXE Boot Menu Configuration.No-Menu=unchecked
Fog PXE Boot Menu Configuration.Exit-to-hard-drive-type=Exit Style (i.e. unselected)
Result: after PXE menu, black screen that says: Exiting PXE-M0F ROM and then the underline-style cursor blinking

Fog PXE Boot Menu Configuration.No-Menu=**checked
Fog PXE Boot Menu Configuration.Exit-to-hard-drive-type=(any value)
Result: after PXE menu, Windows boots and it’s happy

Again, did I mention that this host worked just fine with Fog V0.32 ?

Tom Elliott

This looks to me like GPT structures are on the disk still, but the disk type is expecting to be MBR Only. Essentially, it looks like the system is trying to boot UEFI, but you can’t exit back to UEFI from a legacy system, nor can you jump to legacy from a UEFI setup.

Wayne Workman

So, you basically need to play around in the firmware settings on the system, I think.

Look at your HDD mode, BIOS vs UEFI, Legacy ROM support, things like that. Play around with it.

From my experience, sanboot works for the handful of machine types in my building.

mkstreet

I looked and these are the only BIOS things that seem like they might have something to do with it.

Under ATA DRIVE SETUP:

SATA controller = Enabled
Configure SATA as= AHCI

Under STARTUP:

Boot Mode
The description says: Sets the boot policy as to whether to try Legacy Boot devices first or UEFI Boot options.
The value is “AUTO”, which is says will prioritize as: UEFI, Legacy
Boot Priority
The value is “Legacy First”, which it says means “the system will try to boot legacy OS first and then UEFI”

mkstreet

If I change the BOOT MODE from AUTO to Legacy or UEFI, then the BOOT PRIORITY disappears from the BIOS menu.
If I change the BOOT PRIORITY to UEFI, it goes into a rebooting loop.

I’ve changed it back, and I also moved the origin kpxe file back… but now the situation is worse.
After the Fog PXE menu, it goes to a black screen with cursor and the error beep starts beeping in a constant stream and nothing happens after that.

Even now when I do the NO MENU option, I can no longer get it to boot after PXE.
If I hit ESC to abandon PXE, then it will boot to Windows and is happy.

As far as PXE Fog Menu, I’ve gone from something that was not ideal but functional by specifying NO MENU…to now something that is non-functional.

Wayne Workman

You may have made a mistake copying the old undionly.kpxe back into it’s place.
The command should have been:
[CODE]cp /tftpboot/undionly.kpxe_orig /tftpboot/undionly.kpxe[/CODE]

And, you played around in the firmware, so maybe resetting it to defaults might help too.

additionally, if you’re brave, you might try the undionly.kpxe file from FOG 0.32 and see if the menu works then.
You’ll have to download it (or pull it from your old FOG server), extract that single file, and place it into your current FOG’s tftpboot directory… Maybe you’ll have luck? I’d recommend re-naming the old file to something like undionly-old.kpxe

mkstreet

I didn’t make a mistake in the copying. I looked at the directory and the file that is undionly.kpxe matches (in number of bytes) to undionly.kpxe_orig, and those two are different in number of bytes from undionly.kkxe.

In the firmware, I only changed the BOOT PRIORITY and BOOT MODE values. Nothing else. I’ve restored those to their original values.

So, … I guess the only remaining thing is for me to be brave?

Wayne Workman

Something else must have been done…

It doesn’t just break. If you set everything back the way it was, it should work as it did before.

Did it work with undionly.kkpxe ?

Remember this post ??

Fog PXE Boot Menu Configuration.No-Menu=**checked
Fog PXE Boot Menu Configuration.Exit-to-hard-drive-type=(any value)
Result: after PXE menu, Windows boots and it’s happy

Tom Elliott

If it is prioritizing the mode as uefi then legacy but booting to legacy first, change the mode back to legacy. Sure you lose the priority because you’ve implicitly set it so there is no priority to use. I don’t know if it will make the system work but this, for now, seems the best starting point.

mkstreet

Honestly, I took a siesta for about 2 hours. Then went into Fog to the IPXE Boot Menu config and just did an update without changing any values (i.e. still said NO MENU). Went to the Com Lab and it worked just like it did before. I think I will be happy with NO MENU and not try to improve on this.

Wayne Workman

Isn’t the menu required to register at the host? Or did you change it to do quick-register for anything that isn’t registered?

mkstreet

I’ve left the PXE menu activated to register everything to begin with during my deploy period.
But for my use/production period, I will have it as NO MENU.

PXE Menu Problem - timeout and boot from HDD (menu option 1) -- doesn't happen

223

12.0k

17.3k

155.2k