Lenovo m72 image issues



  • Server
    • FOG Version: 1.3.4
    • OS: centos 7
    Client
    • Service Version:
    • OS:
    Description

    Our imaging works like a champ to all of our systems except the our Lenovo m72 systems. The system stalls at initializing ipxe devices. Bios is up to date and current.


  • Developer

    @wlsnfmly said in Lenovo m72 image issues:

    The only change I made was to go back to the default undionly.kpxe option

    This really is the recommended file.

    Please let us know if you experience further issues with your systems pxe booting. I am not exactly certain why you experienced the issues you did, but I am glad you were able to resolve them.



  • @sudburr I checked, and the info I was pulling from was the wrong system. F1KT71A, sorry. Somehow though now the system is PXE booting just fine. The only change I made was to go back to the default undionly.kpxe option



  • ok, so I changed the boot option back to the kpxe version, the version I had originally and now it is pxe booting.



  • Lenovo ThinkCentre M72e latest BIOS is f1kt71a.

    Lenovo ThinkCentre M72z latest BIOS is f6kt44a.

    What is the exact long name of your model?

    eg: our M72z models are 3548C1U and 3548C8U .


  • Developer

    @wlsnfmly I wouldn’t be able to tell you. I have compiled the kpxe in the past to include the drivers for some of the Realtek nics on MSI boards, but that was back in 0.33b days. The all inclusive ones, or the other pxe files in the tftpboot have always been able to serve my purposes since.

    It’s a trial and error thing, unless someone else knows which check boxes need to be checked, I built about every relevant looking thing into my kpxe files in order to get them booting, this made them rather large, but I didn’t mind as long as the machine did it’s imaging task.

    I’m sorry this isn’t much help, but if you figure out which ones are intrinsically needed, I am sure Tom can start including them, and if you post your resolution(s) here, it’s guaranteed to benefit someone else in the future.

    I apologize for not having the information in front of me, but if you can provide the model number of your Realtek nics, I can try to look up the information for you.


  • Moderator

    @wlsnfmly OK we have a case of someone reusing a term.

    The firmware installed on your computer is 9ckt10a. What I’m asking is most modern devices support either legacy (bios) mode or uefi mode. That is a switch in the firmware setup pages to change. Which mode are these units running in. That info is used to decided what iPXE kernel should be sent.



  • @george1421 I believe they are on bios verison 9ckt10a, which is the highest bios revision Lenovo offers.



  • @george1421 M72e is a desktop, M72z is an All-in-One.


  • Moderator

    @wlsnfmly If you’ve answered this already I apologies in advance.

    What mode bios (legacy) or uefi are these computers in?



  • @Jaymes-Driver Is there a special code that I would need to be able to allow the m72 to pxe? They have realtec nic’s and keep stalling. I found a few things on that wiki, but not sure what exactly to change to allow all systems to pxe. We basically run Lenovo and hp for everything we image, and with them failing, there isn’t a way for me to register, then select a different pxe option in fog


  • Developer

    @wlsnfmly said in Lenovo m72 image issues:

    @george1421 I see the kkpxe in the tftp directory, but when trying to mod it, VI, the coding is all garbled, Is that normal?

    Yes, pxe files are compiled, you can’t just pop them open and edit them.

    https://wiki.fogproject.org/wiki/index.php?title=Building_undionly.kpxe

    This explains how to build your own kpxe files if you are interested.



  • @george1421 I see the kkpxe in the tftp directory, but when trying to mod it, VI, the coding is all garbled, Is that normal?



  • @george1421 I have both of those options set, and modified the 67 option to see the kkpxe file. I will check the tftp directory for the files and see what I might be missing


  • Moderator

    @wlsnfmly Where you able to follow Sudburr’s instructions?

    I don’t know leonvo’s any more but what is the difference between m72 and m72z that sudburr uses?

    Your dhcp options 66 should be the IP address of the fog server and 67 is the boot file. Option 66 tells the pxe booting client where to get the file from and 67 tells the client what file to load. These files are on the fog server in the /tftpboot directory.



  • Stil having issues with this if anyone has some insight?



  • @sudburr are those the kkpxe file commands or operational commands for me to test with



  • @Tom-Elliott how can I confirm the correct files are used? We currently have our dhcp options pointing to the undionly.kpxe file but I can not locate that file anywhere to be able to determine if the code is correct



  • What we use for our M72z with BIOS - f6kt43a :

    For Legacy Network Boot (undionly.kpxe):

    - POWER UP / hold [F1]
    - Menu EXIT  \ OS Optimized Defaults = [disabled]
    
    - Depress:  [F9] … to load setup default configuration
    
    - Menu Startup \ Primary \ Automatic \ Error Boot Sequences
    1st device = [Network 1]
    2nd device = [SATA 1]
    

    For UEFI Network Boot (ipxe.efi):

    POWER UP / hold [F1]
    - Menu EXIT \ OS Optimized Defaults = [ENABLED]
    
    - Depress:  [F9] … to load setup default configuration
    
    - Menu Security \ Secure Boot \ Secure Boot = [disabled]
    
    - Menu Startup \ Primary \ Automatic \ Error Boot Sequences
    1st device = [Network]
    2nd device = [SATA]
    3rd device = [USB HDD]
    
    - Menu Startup \ CSM = [disabled]
    - Menu Startup \ Boot Mode = [UEFI]
    

    I just tested this out with 1.3.5 RC5


  • Senior Developer

    Please use the ipxe7156.efi labelled files. If I remember correctly the m72 are booting UEFI.

    If this is not the case, then try the ipxe.pxe or undionly.kkpxe files (notice in the undionly there’s 2 k’s)


Log in to reply
 

Looks like your connection to FOG Project was lost, please wait while we try to reconnect.