Have you tried the new xnba-undi version 1.21.1-1 added by https://github.com/xcat2/xcat-dep/pull/47 ?
-----Original Message----- From: Russell Jones <russell-l...@jonesmail.me> Sent: Tuesday, October 25, 2022 1:25 PM To: xcat-user@lists.sourceforge.net Subject: Re: [xcat-user] [External] Re: xCAT 2.16.2 new xNBA issue Hi all, This is a pretty large thread so I may have missed it - is there an open bug ticket / issue that is tracking boot problems with the new xnba? I also ended up here today because of upgrading xcat, and then no longer being able to boot a few dozen nodes we have with ASUS mainboards. Downgrading xnba fixed the issue. On 10/11/2021 11:02 AM, THomas HUMMEL wrote: > > > On 10/11/21 16:10, Jarrod Johnson wrote: >> 1a) Correct. > > Thanks Jarrod. > > -- > Thomas > > At the time we first did it, iPXE codebase and/or uefi didn't do well > at 'exiting', so offering nothing was the choice, while pxe is slower, > it means we didn't have to contend with UEFI crashes that happened in > the wake of iPXE trying to exit. Things might have changed by now > between UEFI maturing and iPXE maturing, but even with kkpxe in legacy > we occasionally have BIOSes where exit to short out the netboot > attempt causes headaches. Considered a little less critical as UEFI > OSes tend to rewrite the bootorder on deploy to make themselves first, > and we have the ability to explicitly request network boot through a > BMC by and large, so the fastest mechanism for diskful boot is to just > boot straight to hard drive and only network boot when there's a > deployment to do. Incidentally, some security teams have started > requiring this, as they don't like the concept of a PXE attempt every > boot. >> >> -----Original Message----- >> From: THomas HUMMEL <thomas.hum...@pasteur.fr> >> Sent: Monday, October 11, 2021 9:37 AM >> To: xcat-user@lists.sourceforge.net >> Subject: [External] Re: [xcat-user] xCAT 2.16.2 new xNBA issue >> >> Hello Mark, >> >> So if I sum up again, what was left unclear to me was: >> >> a) is it expected that after the initial install, when a UEFI >> stateful node reboots in PXE first (if order gets manually changed >> again for instance), no tftp of xNBA occurs ? : like xCAT would check >> the install status of the node ? >> I've always thought the way stateful once installed booted on disk >> (if PXE first) was to download the dummy 'exit' only iPXE script via >> xNBA (which would imply to see tftp of xNBA beforehand), not by >> giving up on no boot filename answer >> >> b) why isn't the .uefi /tftpboot file >> (/tftpboot/xcat/xnba/nodes/<node>.uefi) changed in sync with the >> no-extension one after install ? >> >> c) for duplicates messages : I still don't know why those messages >> show in logs. >> >> Thanks for your help >> >> -- >> Thomas HUMMEL >> >> On 10/1/21 18:19, THomas HUMMEL wrote: >>> [Sorry Mark for the duplicate answer - I mistakenly reply to you only] >>> >>> On 10/1/21 17:26, Mark Gurevich wrote: >>>> Thomas, >>>> >>>> Sorry, I do not quite follow your point about "2)", is the observed >>>> behavior different from what you expected ? >>> >>> Well yes : I would expect (expect may not be the correct word - let's >>> say I thought it worked that way) that a node, even once installed (in >>> the stateful case), which reboots on the network would tftp xNBA >>> (which in turn would GET one of the /tftpboot/xcat/xnba/node/<node> or >>> <node>.uefi script). >>> >>> My understanding is that it works this way for legacy (BIOS) boot. >>> Otherwise what would be the point to change the iPXE script file to: >>> >>> #!gpxe >>> #boot >>> exit >>> >>> ? >>> >>> So I was assuming any host PXE-ing would always get xNBA wether it is >>> on initial install or a later reboot (if UEFI network is first in boot >>> order) >>> >>> >>>> >>>> As to "duplicate lease" point, is it possible you have an IP >>>> associated with a MAC, that is also inside dynamic range ? >>> >>> I thought about it but I don't thinks it's the case. >>> >>>> Can you show: >>>> >>>> lsdef -t network -l >>> >>> >>> "maestro_net","192.168.144.0","255.255.240.0","eth0","192.168.144.1",, >>> "<xcatmaster>",,,,"192.168.144.2-192.168.147.254",,,,,,"maestro.pasteu >>> r.fr","1500",, >>> >>> "maestro_ipmi","10.7.96.0","255.255.248.0",,"10.7.96.1",,,,,,,,,,,,,"1 >>> 500",, >>> >>> "maestro_ipoib","172.16.0.0","255.255.248.0",,,,,,,,,,,,,,,"1500",, >>> >>>> lsdef <node> -i ip,mac >>> >>> Object name: maestro-satvmtmpl >>> ip=192.168.148.204 >>> mac=00:50:56:b5:ac:de >>> >>>> makedhcp -q node >>> >>> # makedhcp -q maestro-satvmtmpl >>> maestro-satvmtmpl: ip-address = 192.168.148.204, hardware-address = >>> 00:50:56:b5:ac:de >>> >>> Thanks for your help >>> >> >> >> _______________________________________________ >> xCAT-user mailing list >> xCAT-user@lists.sourceforge.net >> https://apc01.safelinks.protection.outlook.com/?url=https://lists.sourceforge.net/lists/listinfo/xcat-user&data=04|01|jjohns...@lenovo.com|f12a7ae143734d28f70108d98cbc4565|5c7d0b28bdf8410caa934df372b16203|1|0|637695562527776411|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0=|1000&sdata=1uZ2Ak81i5pksIjigqV0Gg1VOkBskHdpT2a3EBRsoaA=&reserved=0 >> >> >> >> >> _______________________________________________ >> xCAT-user mailing list >> xCAT-user@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/xcat-user >> >> > > > _______________________________________________ > xCAT-user mailing list > xCAT-user@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/xcat-user _______________________________________________ xCAT-user mailing list xCAT-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xcat-user _______________________________________________ xCAT-user mailing list xCAT-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xcat-user
