etherboot-developers Mailing List for Etherboot (Page 2)
Brought to you by:
marty_connor,
stefanhajnoczi
You can subscribe to this list here.
2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
(10) |
Sep
(3) |
Oct
(10) |
Nov
(47) |
Dec
(20) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2001 |
Jan
(41) |
Feb
(107) |
Mar
(76) |
Apr
(103) |
May
(66) |
Jun
(72) |
Jul
(27) |
Aug
(31) |
Sep
(33) |
Oct
(18) |
Nov
(33) |
Dec
(67) |
2002 |
Jan
(25) |
Feb
(62) |
Mar
(79) |
Apr
(74) |
May
(67) |
Jun
(104) |
Jul
(155) |
Aug
(234) |
Sep
(87) |
Oct
(93) |
Nov
(54) |
Dec
(114) |
2003 |
Jan
(146) |
Feb
(104) |
Mar
(117) |
Apr
(189) |
May
(96) |
Jun
(40) |
Jul
(133) |
Aug
(136) |
Sep
(113) |
Oct
(142) |
Nov
(99) |
Dec
(185) |
2004 |
Jan
(233) |
Feb
(151) |
Mar
(109) |
Apr
(96) |
May
(200) |
Jun
(175) |
Jul
(162) |
Aug
(118) |
Sep
(107) |
Oct
(77) |
Nov
(121) |
Dec
(114) |
2005 |
Jan
(201) |
Feb
(271) |
Mar
(113) |
Apr
(119) |
May
(69) |
Jun
(46) |
Jul
(21) |
Aug
(37) |
Sep
(13) |
Oct
(4) |
Nov
(19) |
Dec
(46) |
2006 |
Jan
(10) |
Feb
(18) |
Mar
(85) |
Apr
(2) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(10) |
Jul
(20) |
Aug
(9) |
Sep
(11) |
Oct
(4) |
Nov
(1) |
Dec
(40) |
2008 |
Jan
(19) |
Feb
(8) |
Mar
(37) |
Apr
(28) |
May
(38) |
Jun
(63) |
Jul
(31) |
Aug
(22) |
Sep
(37) |
Oct
(38) |
Nov
(49) |
Dec
(24) |
2009 |
Jan
(48) |
Feb
(51) |
Mar
(80) |
Apr
(55) |
May
(34) |
Jun
(57) |
Jul
(20) |
Aug
(83) |
Sep
(17) |
Oct
(81) |
Nov
(53) |
Dec
(40) |
2010 |
Jan
(55) |
Feb
(28) |
Mar
(36) |
Apr
(7) |
May
|
Jun
|
Jul
(7) |
Aug
|
Sep
|
Oct
(1) |
Nov
(3) |
Dec
|
2011 |
Jan
(1) |
Feb
|
Mar
(3) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(6) |
Oct
|
Nov
(10) |
Dec
|
2012 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2013 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Marty C. <md...@et...> - 2010-07-22 23:33:29
|
Hi Jeff, You should join the gPXE or gPXE-devel lists to report issues with gPXE: http://etherboot.org/wiki/mailinglists and more specifically: http://etherboot.org/mailman/listinfo Is where you would sign up. You would probably get more help debugging on those lists. Regards, / Marty / On 7/22/10 4:15 PM, Jeff Sadowski wrote: > I forgot which version I was using > I am using gpxelinux 1.0.0 that comes with syslinux-4.0.1 > > On Thu, Jul 22, 2010 at 2:14 PM, Jeff Sadowski <jef...@gm...> wrote: >> I have been using pxelinux for a long while now. >> I came across a method of booting that uses gpxelinux to utilize http >> as a download method. >> I have my machines set to pxe boot first with pxelinux I can have the >> default set to localboot. >> When I tried local boot with gpxe it works in vmware test boxes but on >> my hp machines it says booting local disk and just stops. >> >> vmware exits gpxelinux as follows >> Booting local disk... >> PXE-M0F: Exiting Intel PXE ROM. >> >> my hp machines on pxelinux exit as follows >> Booting local disk... >> PXE-M0F: Exiting HP PXE ROM. >> >> with gpxelinux it only gets to >> Booting local disk... >> >> and it just stops. >> > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Sprint > What will you do first with EVO, the first 4G phone? > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first > _______________________________________________ > Etherboot-developers mailing list > Eth...@li... > https://lists.sourceforge.net/lists/listinfo/etherboot-developers |
From: Jeff S. <jef...@gm...> - 2010-07-22 20:16:06
|
I forgot which version I was using I am using gpxelinux 1.0.0 that comes with syslinux-4.0.1 On Thu, Jul 22, 2010 at 2:14 PM, Jeff Sadowski <jef...@gm...> wrote: > I have been using pxelinux for a long while now. > I came across a method of booting that uses gpxelinux to utilize http > as a download method. > I have my machines set to pxe boot first with pxelinux I can have the > default set to localboot. > When I tried local boot with gpxe it works in vmware test boxes but on > my hp machines it says booting local disk and just stops. > > vmware exits gpxelinux as follows > Booting local disk... > PXE-M0F: Exiting Intel PXE ROM. > > my hp machines on pxelinux exit as follows > Booting local disk... > PXE-M0F: Exiting HP PXE ROM. > > with gpxelinux it only gets to > Booting local disk... > > and it just stops. > |
From: Jeff S. <jef...@gm...> - 2010-07-22 20:14:16
|
I have been using pxelinux for a long while now. I came across a method of booting that uses gpxelinux to utilize http as a download method. I have my machines set to pxe boot first with pxelinux I can have the default set to localboot. When I tried local boot with gpxe it works in vmware test boxes but on my hp machines it says booting local disk and just stops. vmware exits gpxelinux as follows Booting local disk... PXE-M0F: Exiting Intel PXE ROM. my hp machines on pxelinux exit as follows Booting local disk... PXE-M0F: Exiting HP PXE ROM. with gpxelinux it only gets to Booting local disk... and it just stops. |
From: H. P. A. <hp...@zy...> - 2010-07-20 22:52:35
|
On 07/20/2010 03:25 PM, Jeff Sadowski wrote: > > this should be gpxe/pxelinux.0 > however it is still using > /pxelinux.cfg/default > and not > /gpxe/pxelinux.cfg/default > This doesn't apply to chainloaded files, unless you use pxechain.com. -hpa |
From: H. P. A. <hp...@zy...> - 2010-07-20 21:26:38
|
On 07/20/2010 12:44 PM, Jeff Sadowski wrote: > For now: > > Is there a way to get gpxelinux to look in a different directory for > its config file. > Like chainloading gpxelinux and from the chain load use a different > directory as the base directory so it uses a separate default file. > Other than just putting it in a different place, you can either set DHCP option 209, or recompile gpxelinux.0 with a different embedded script (gpxe/pxelinux.gpxe in the sources.) -hpa |
From: H. P. A. <hp...@zy...> - 2010-07-20 17:24:27
|
On 07/20/2010 10:12 AM, Jeff Sadowski wrote: > What version of syslinux can I download that have an older version > syslinux-3.86 still has gpxe v 1.0.0 same as syslinux-4.01 with > copying all of syslinux-3.86's versions of gpxelinux.0 and pxelinux.0 > it works the same.(different appearance) pxelinux.0 works with > localboot and gpxelinux.0 does not. Look at the NEWS file. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. |
From: H. P. A. <hp...@zy...> - 2010-07-19 22:31:02
|
On 07/19/2010 03:27 PM, Jeff Sadowski wrote: > > The VMWare machine worked flawless with a disk however the HP Laptops did not. > The HP Laptops one is a nw8440 the others are hp 6715b and I have a > few others I need to test > The laptops get to > Booting local disk... > They don't get to > PXE-M0F: Exiting Intel PXE ROM. > Like the vmware machines do > > Using pxelinux from 4.01 on the HPs I get > PXE-M0F: Exiting HP PXE ROM. > OK, so this is HP brokenness, quite possibly inside gPXE, and/or in the interaction between gPXE and Syslinux. a) This really belongs on the gPXE and Syslinux mailing lists. b) Does "keeppxe" work? c) Do older versions of gpxelinux.0 work? -hpa |
From: Bill S. <wst...@hg...> - 2010-04-19 01:12:10
|
I am using my WOL code from the contrib directory of etherboot. The WOL never gets sent, it appears to be a timing issue or something. I did some testing from the gpxe command line, I am able to aquire an IP via dhcp, but then there is error recovery in those sort of exchanges that will compensate from lost packets. I also added a command to the gpxe command line to send the wol packet manually, it does seem to get sent in that case. That is why I think it might be a timing issue or something. Perhaps related to sending the packet to soon after initialization or something. In the end my solution was to send the WOL packet 5 times, now it does seem to get sent always. All I am using gpxe for is waking a backend server. I run XBMC for my media system, all the media is on a backend server in the basement. I use gpxe to start the backend early in the boot process of the frontend before XBMC has started. ----- Original Message ----- > Good day Bill, > > You asked about adding support for an NVIDIA NIC to forcedeth.c in order > to send a WakeOnLAN packet. What makes you think it's not working > properly (error messages?) and how were you sending the WakeOnLAN > packet? > > - Shao Miller |
From: Stefan H. <ste...@gm...> - 2010-04-16 19:07:29
|
The gdb*.{c,h} are correct. Thank you for adding this Shao. Stefan |
From: Alex Z. <ale...@eu...> - 2010-04-08 08:18:52
|
H. Peter Anvin wrote: > On 03/25/2010 03:57 AM, Alex Zeffertt wrote: >> Michael Brown wrote: >>> On Wednesday 24 Mar 2010 12:02:44 Alex Zeffertt wrote: >>>> Perhaps the Bootix NBP shouldn't be doing this... but we've found that if >>>> we make PXENV_TFTP_READ_FILE only update the filename in >>>> cached_info[CACHED_INFO_DHCPACK] and leave the filename in >>>> cached_info[CACHED_INFO_BINL] then the boot succeeds. (See patch below.) >>>> >>>> If anybody is still reading, do you know whether this is an okay way to fix >>>> the problem, ... or will it break NTLDR? >>> Nice debugging! >>> >>> Unfortunately I have no idea whether or not it will break NTLDR, and NTLDR >>> compatibility probably has to take higher priority than Bootix compatibility. >>> If you can verify that your change still allows a successful RIS deployment >>> (for which you would need Windows Server 2003 R1; I believe RIS was obsoleted >>> in 2003 R2 and replaced with WDS), then we could fairly safely apply this >>> change. >>> >>> I have Windows Server 2003 R1 media and licence keys, so could test this for >>> you, but I won't be able to do so any time soon, sorry. >>> >>> Michael >>> >> You're right, we can't break NTLDR. Here's an alternative way to fix the >> problem. Now, I know this is a terrible hack... but it does guarrantee(*) that >> non-Bootix NBPs will not be affected. >> >> Alex >> > > It would seem to me that something is fundamentally bogus if it can only > be detected by recognizing the particular NBP. Rather, that seems to > indicate that something was mischaracterized in how other BCs act... > > -hpa > You're right that this is a hack. But it's a hack to workaround problems caused by an earlier hack :-) Thankfully my hack is not needed since Michael found the earlier hack wasn't necessary after all, and he reverted it in commit 80d1ac7320f597b4c981dfdeb19d8e88eb85ca69. Regards, Alex |
From: H. P. A. <hp...@zy...> - 2010-04-07 18:26:36
|
On 03/25/2010 03:57 AM, Alex Zeffertt wrote: > Michael Brown wrote: >> On Wednesday 24 Mar 2010 12:02:44 Alex Zeffertt wrote: >>> Perhaps the Bootix NBP shouldn't be doing this... but we've found that if >>> we make PXENV_TFTP_READ_FILE only update the filename in >>> cached_info[CACHED_INFO_DHCPACK] and leave the filename in >>> cached_info[CACHED_INFO_BINL] then the boot succeeds. (See patch below.) >>> >>> If anybody is still reading, do you know whether this is an okay way to fix >>> the problem, ... or will it break NTLDR? >> >> Nice debugging! >> >> Unfortunately I have no idea whether or not it will break NTLDR, and NTLDR >> compatibility probably has to take higher priority than Bootix compatibility. >> If you can verify that your change still allows a successful RIS deployment >> (for which you would need Windows Server 2003 R1; I believe RIS was obsoleted >> in 2003 R2 and replaced with WDS), then we could fairly safely apply this >> change. >> >> I have Windows Server 2003 R1 media and licence keys, so could test this for >> you, but I won't be able to do so any time soon, sorry. >> >> Michael >> > > You're right, we can't break NTLDR. Here's an alternative way to fix the > problem. Now, I know this is a terrible hack... but it does guarrantee(*) that > non-Bootix NBPs will not be affected. > > Alex > It would seem to me that something is fundamentally bogus if it can only be detected by recognizing the particular NBP. Rather, that seems to indicate that something was mischaracterized in how other BCs act... -hpa |
From: Michael B. <mb...@fe...> - 2010-04-01 20:43:45
|
On Thursday 01 April 2010 20:18:34 Shao Miller wrote: > Stefan Hajnoczi wrote: > > For the record, I never committed a patch that fixes this in gPXE. > > Some prefices use the memory region which RIS accesses, thereby > > filling it with non-NUL bytes. The solution I had in mind was to zero > > memory in libprefix.S or in prefices, but it's been a while... > > I find the results of Michael Brown's tests interesting... In his > tests, I don't believe he was using { -> PXELINUX -> pxechain.com } as > middle-man to Windows RIS' startrom.0. Correct; I was invoking startrom.com directly from gPXE. Michael |
From: Shao M. <Sha...@yr...> - 2010-04-01 19:18:47
|
Stefan Hajnoczi wrote: > > For the record, I never committed a patch that fixes this in gPXE. > Some prefices use the memory region which RIS accesses, thereby > filling it with non-NUL bytes. The solution I had in mind was to zero > memory in libprefix.S or in prefices, but it's been a while... > I find the results of Michael Brown's tests interesting... In his tests, I don't believe he was using { -> PXELINUX -> pxechain.com } as middle-man to Windows RIS' startrom.0. H. Peter addressed the RIS bug directly in PXELINUX, and my test results differed... Might really be that FAF0 RIS business; wish we knew what it was really for. - Shao |
From: Stefan H. <ste...@gm...> - 2010-04-01 07:30:30
|
On Thu, Mar 25, 2010 at 2:58 AM, Miller, Shao <Sha...@yr...> wrote: > I'm slightly wondering if the old symptom was due to the business > addressed in Syslinux' commit 18ca4d8cc87761c6a5ab763069fad562fec69b59. > I can't seem to track down where gPXE addresses this, but remember both > you (Michael Brown) and Stefan Hajnoczi thinking about it. A related > e-mail to refresh memories[1], in case it's a possibility. For the record, I never committed a patch that fixes this in gPXE. Some prefices use the memory region which RIS accesses, thereby filling it with non-NUL bytes. The solution I had in mind was to zero memory in libprefix.S or in prefices, but it's been a while... Stefan |
From: Alex Z. <ale...@eu...> - 2010-03-29 08:57:21
|
Michael Brown wrote: > On Friday 26 Mar 2010 17:51:53 Michael Brown wrote: >> I'm going to try removing pxe_set_cached_filename() completely, and check >> that RIS proceeds right through to an installed and working Win2k3 system. > > Confirmed. RIS is working perfectly for me with pxe_set_cached_filename() > removed. > > I've pushed this change. Alex: could you check that this solves your Bootix > problem? > Thanks for all your efforts Michael. I can confirm that removing pxe_set_cached_filename() works with Bootix, since I've already tested a change that stubs it out. Regards, Alex > I'd appreciate any reports of breakages caused by this change, though I don't > believe we ever had anything besides RIS that we thought depended on it. > > Michael > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Etherboot-developers mailing list > Eth...@li... > https://lists.sourceforge.net/lists/listinfo/etherboot-developers > |
From: Miller, S. <Sha...@yr...> - 2010-03-28 02:10:27
|
Good day Bill, You asked about adding support for an NVIDIA NIC to forcedeth.c in order to send a WakeOnLAN packet. What makes you think it's not working properly (error messages?) and how were you sending the WakeOnLAN packet? - Shao Miller |
From: Miller, S. <Sha...@yr...> - 2010-03-27 18:09:54
|
Good day Binh, You had a question in regards to gPXE. Are you aware that there is a gPXE mailing-list? http://www.etherboot.org/wiki/mailinglists http://etherboot.org/mailman/listinfo/gpxe Since you appear to be using the Etherboot mailing-list, you might have missed yesterday's e-mail[1] in the gPXE mailing-list in regards to the fact that the scripting discussion in the gPXE developers' mailing-list[2] is slow-going and certain points have not yet been agreed upon by all. Labels and 'goto' have not yet been committed to gPXE's official codebase. You could look in Stefan Hajnoczi's repository[3] or my own[4] to checkout some possibilities. - Shao Miller [1] http://etherboot.org/pipermail/gpxe/2010-March/000735.html [2] http://etherboot.org/pipermail/gpxe-devel/2010-March/000089.html [3] http://git.etherboot.org/?p=people/stefanha/gpxe.git;a=shortlog;h=refs/h eads/ifgoto [4] http://git.etherboot.org/?p=people/sha0/gpxe.git;a=shortlog;h=refs/heads /exit_if_goto_v4 |
From: Binh T. <bt...@nc...> - 2010-03-27 17:43:03
|
Hello everyone, Could someone let me know if the mainline gPXE already supports label and goto in scripting? I tried defining a label as ":abc" or "abc:" but both failed. Thanks a lot, Binh __________ Information from ESET NOD32 Antivirus, version of virus signature database 4965 (20100322) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com |
From: Michael B. <mb...@fe...> - 2010-03-26 18:42:57
|
On Friday 26 Mar 2010 17:51:53 Michael Brown wrote: > I'm going to try removing pxe_set_cached_filename() completely, and check > that RIS proceeds right through to an installed and working Win2k3 system. Confirmed. RIS is working perfectly for me with pxe_set_cached_filename() removed. I've pushed this change. Alex: could you check that this solves your Bootix problem? I'd appreciate any reports of breakages caused by this change, though I don't believe we ever had anything besides RIS that we thought depended on it. Michael |
From: Michael B. <mb...@fe...> - 2010-03-26 17:51:32
|
On Friday 26 Mar 2010 14:06:34 Miller, Shao wrote: > I would be curious to see if overwriting both DHCPACK and BINL cached > packets' filenames with "bar" at each set_cached_filename() call passes > your tests, if you'd care to. Tests so far: Unmodified gPXE : RIS seems to work (reaches graphical setup) Skipping pxe_set_cached_filename() completely : RIS still seems to work Setting both DHCPACK and BINL filenames to "bar" : RIS dies before reaching the "Windows Setup" text-mode screen Setting both DHCPACK and BINL filename to "" : RIS dies before reaching the "Windows Setup" text-mode screen Setting only DHCPACK to "" : RIS seems to work Setting only BINL filename to "" : RIS dies before reaching the "Windows Setup" text-mode screen Note that this testing involves a Windows DHCP server with no explicitly- configured filename, relying on ProxyDHCP to provide the correct boot filename. In earlier tests (many years ago, when the "overwrite filename" logic was first added and tested), I think I was using an explicitly-configured filename. I'm going to try removing pxe_set_cached_filename() completely, and check that RIS proceeds right through to an installed and working Win2k3 system. Michael |
From: Miller, S. <Sha...@yr...> - 2010-03-26 14:46:31
|
Thanks, Michael. At last, the Wiki has been updated with this correct location. :) http://www.etherboot.org/wiki/doc?rev=1263191914&do=diff - Shao Miller |
From: Michael B. <mb...@fe...> - 2010-03-26 14:38:24
|
On Friday 26 Mar 2010 14:33:23 Miller, Shao wrote: > In regards to viewing gpxe/src/doc/build_sys.dox: > > http://www.etherboot.org/wiki/doc#source_code_documentation > http://www.etherboot.org/share/sha0/gpxe/src/bin/doc/html/build_sys.html And also http://etherboot.org/api/build_sys.html (which is automatically updated to keep in sync with the latest git tree). Michael |
From: Miller, S. <Sha...@yr...> - 2010-03-26 14:34:15
|
Good day Binh, In regards to viewing gpxe/src/doc/build_sys.dox: http://www.etherboot.org/wiki/doc#source_code_documentation http://www.etherboot.org/share/sha0/gpxe/src/bin/doc/html/build_sys.html - Shao Miller |
From: Binh T. <bt...@nc...> - 2010-03-26 14:18:01
|
Hi, Does anyone know what viewer I can use to read the build_sys.dox in src/doc folder? Thanks Binh __________ Information from ESET NOD32 Antivirus, version of virus signature database 4965 (20100322) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com |
From: Miller, S. <Sha...@yr...> - 2010-03-26 14:07:33
|
Good day Michael, I would be curious to see if overwriting both DHCPACK and BINL cached packets' filenames with "bar" at each set_cached_filename() call passes your tests, if you'd care to. - Shao Miller |