Re: [ipxe-devel] gunzip downloaded image?

On 18/06/18 21:01, Jarrod Johnson wrote: So grub can boot a gzipped kernel, I was wondering if there's a syntax I'm missing to acheive the same end in ipxe? There's no support for gunzipping a downloaded image, sorry. We do have code for the underlying decompression algorithm (used in e.g.

Re: [ipxe-devel] [PATCH] [efi] Use memcpy to handle efi header name

On 18/06/18 13:09, Christian Nilsson wrote: I send an identical patch (except the message of course) on May 15th. And there were different solutions on the mailing list as well. Michael, can we commit a fix for this, please? This is probably the 3rd thread about this, so let's go back to the

Re: [ipxe-devel] Can't clone from git.ipxe.org over IPv6

On 25/05/18 21:11, Teran McKinney wrote: I can't clone from git.ipxe.org over IPv6. It does have an IPv6 address but seems to not be listening on the appropriate port. Can cause problems with cloning. Thank you for the clear and detailed report. Should now be fixed, after adding "flags =

Re: [ipxe-devel] TLS error "Operation not permitted 410de13c"

On 31/05/18 20:00, Roman Gorshunov wrote: Kernel and initrd files served via HTTPS by JFrog Artifactory running in docker/kubernetes. Service is proxied by ingress controller (nginx). SSL certificate is valid, but iPXE prints an error and does not load files: TLS 0xf7074 received fatal alert 40

Re: [ipxe-devel] [PATCH v2] Always update the IRQ state in the IP layer

On 10/01/18 15:32, Martin Habets wrote: With this patch we update the IRQ state in the IP layer even if the driver does not support interrupts, so that UNDI calls will return PXENV_UNDI_ISR_OUT_OURS for the boot device. For other devices it will still return PXENV_UNDI_ISR_OUT_NOT_OURS like

Re: [ipxe-devel] HTTPS error : http://ipxe.org/err/1c25e0

On 09/01/18 03:02, Youkay akay wrote: I am not using Hyper-V. I am running iPXE on Intel's Ivy Bridge processor. I don't see the definition of get_noise in src/arch/i386/interface/pcbios/rtc_entropy.c. Do we need to custom define it based on our environment ? You are using a UEFI build of

Re: [ipxe-devel] link down

On 26/01/18 10:11, Joakim Tjernlund wrote: This got me thinking, I went into BIOS and turned off Wake On LAN and now it works :) However it only works after power on, if reboot I get the same link down. I guess the driver needs to reset something before it can handle reboot's. Any ide what that

Re: [ipxe-devel] delay on connection to ISCSI (double connection establishment)

On 13/01/18 09:42, Armin Ranjbar wrote: having a very strange problem here, it appears that connection is established twice to iscsi and at some phases, it takes a long time. log: http://pastecode.org/index.php/view/23465877 script: http://pastecode.org/index.php/view/80532914 now, two

Re: [ipxe-devel] link down

On 25/01/18 15:13, Joakim Tjernlund wrote: Got link down when booing ipxe from grub(linux16 boot/ipxe.lkrn), http://ipxe.org/err/380861 suggest to send a mail to here: Did you try following the other instructions on that page? In particular: "if you see a message such as Waiting for

Re: [ipxe-devel] iPXE MemoryAllocationLib.c assert failures on Dell PowerEdge

On 25/01/18 19:06, lynn.heinem...@dell.com wrote: We compiled with the debug flags you provided and induced a failure. This doesn't occur on every boot but currently on approximately 1 out of every 10 attempts. > > > EFIDRV PciRoot(0x1)/Pci(0x2,0x0)/Pci(0x0,0x0)/MAC(246E96925728,0x1) has

Re: [ipxe-devel] hyperv net device driver design question

On 22/01/18 17:12, Roman Kagan wrote: Our workaround was to disable the message page once the VMBus setup was over and the message page was no longer needed, and not to enable the event page as we were using polling anyway so we could busy-wait directly on the ringbuffer descriptors. That

Re: [ipxe-devel] iPXE MemoryAllocationLib.c assert failures on Dell PowerEdge

On 02/02/18 22:45, daniel.johns...@dell.com wrote: I’m a colleague of Lynn’s and wanted to put my old C experience to use here, but have hit a snag. I’m attempting to insert my hook early in iPXE’s execution through __init_fn but it never executes. The debug text strings don’t even appear in

Re: [ipxe-devel] gcc defaults to pie ?

On 31/01/18 16:35, Joakim Tjernlund wrote: On Gentoo gcc 6 defaults to PIE and that generates and ton of error: code model kernel does not support PIC mode Throwing in a general -fno-pie does not seem to be the right fix either. Maybe iPXE should start specifying -fno-pie where needed?

Re: [ipxe-devel] gcc defaults to pie ?

On 31/01/18 17:05, Joakim Tjernlund wrote: On Thu, 1970-01-01 at 00:00 +, Michael Brown wrote: There's logic within arch/i386/Makefile which is supposed to autodetect compilers that do this and specify the appropriate combination of "do not use PIE" options. We may need

Re: [ipxe-devel] gcc defaults to pie ?

On 31/01/18 17:31, Joakim Tjernlund wrote: Yes, building on x86_64 for x86_64, various targets, for example make -j1 Q='' CC=x86_64-pc-linux-gnu-gcc LD=x86_64-pc-linux-gnu-ld AS=x86_64-pc-linux-gnu-as AR=x86_64-pc- linux-gnu-ar NM=x86_64-pc-linux-gnu-nm OBJCOPY=x86_64-pc-linux-gnu-objcopy

Re: [ipxe-devel] gcc defaults to pie ?

On 31/01/18 18:52, Joakim Tjernlund wrote: I can build bin/8086100e.rom but not bin-x86_64-pcbios/8086100e.rom: cc1: error: code model kernel does not support PIC mode nor bin-x86_64-pcbios/undionly.kpxe bin-x86_64-pcbios/ipxe.lkrn bin-x86_64-pcbios/ipxe.usb adding this makes it

Re: [ipxe-devel] link down

On 05/02/18 17:47, Joakim Tjernlund wrote: On Thu, 1970-01-01 at 00:00 +, Michael Brown wrote: This sounds like a similar problem to http://forum.ipxe.org/showthread.php?tid=10280 If so, then I have just received some suitable test hardware (courtesy of a customer), and will be looking

Re: [ipxe-devel] #define KEYBOARD_MAP fi does not work

On 07/02/18 09:11, Joakim Tjernlund wrote: Fond my error: should be config/local/console.h Somewhat inconvenient to use different files though The config is split across multiple files to avoid having to rebuild the entire codebase whenever you make a configuration change. The keyboard

Re: [ipxe-devel] [PATCH 3/3] ndp: make IPv6 prefix user-settable

On 07/02/18 07:16, Hannes Reinecke wrote: On 02/07/2018 03:06 AM, Michael Brown wrote: On 05/02/18 08:36, Hannes Reinecke wrote: NDP will discover the IPv6 on-link prefix, so we should make it user-settable. I'm trying to figure out the use case for this, but without any luck so far. Could

Re: [ipxe-devel] Booting from iSCSI with U-Boot and iPXE (snp.efi)

On 30/01/18 21:29, Heinrich Schuchardt wrote: In version U-Boot 2018.03-rc1 all patches have been merged that are needed to launch iPXE's snp.efi target and boot from an iSCSI drive on ARM systems. Awesome! Thanks for doing this work, and for letting us know! Michael

Re: [ipxe-devel] Intel I219-V configuration failing

On 03/02/18 23:11, Benjamin Schneider wrote: I'm still getting errors. I captured early debug messages this time. Immediately after "Intialising devices..." I get the following messages: INTEL 0xdcfe8 forced MAC reset (00180260/40080603 was 00180240/40080603) INTEL 0xdcfe8 has autoloaded MAC

Re: [ipxe-devel] Intel I219-V configuration failing

On 27/01/18 19:50, Benjamin Schneider wrote: I've got a relatively new system and am getting error 040ee119 (no configuration methods succeeded). net0 is using i219v-2 ifstat shows TX:4 and TXE:1 with an error code 3c654003 (operation not supported) I compiled with DEBUG=intel and see the

Re: [ipxe-devel] [PATCH 3/3] ndp: make IPv6 prefix user-settable

On 05/02/18 08:36, Hannes Reinecke wrote: NDP will discover the IPv6 on-link prefix, so we should make it user-settable. I'm trying to figure out the use case for this, but without any luck so far. Could you give an example of how this might be used? Thanks, Michael

Re: [ipxe-devel] #define KEYBOARD_MAP fi does not work

On 06/02/18 08:28, Joakim Tjernlund wrote: I want Swedish keyboard and added #define KEYBOARD_MAP fi to my build(fi is the same layout as Swedish) but my keyboard is still US(on my Lenovo Thinkpad 470s laptop) To which header file did you add this #define? The keyboard mapping is

Re: [ipxe-devel] link down

On 06/02/18 08:14, Joakim Tjernlund wrote: Noticed your fix and tried it on my Lenovo laptop(I219v-4) but same result. Only works from power on, not when rebooting. Using x86_64, GRUB and ipxe.lkrn Does it work if you bypass GRUB (e.g. by rebooting straight into ipxe.usb on a USB key)? Just

Re: [ipxe-devel] Problem with ipxe on Xen 4.4

On 26/12/17 12:47, Michael Brown wrote: On 25/12/17 11:20, Eytan Heidingsfeld wrote: I retried with DEBUG=xenbus and saw that xenbus_probe_type failed for the device: device/suspend/event-channel (I think because it doesn't have a backend key - it is empty). As this device isn't critical

Re: [ipxe-devel] Cannot build wimboot

On 26/12/17 07:59, brent s. wrote: I am unable to successfully build wimboot as found at https://git.ipxe.org/wimboot.git Build output is attached. Environment: Arch Linux GCC 7.2.0 GNU Make 4.2.1 glibc 2.26 Reproduction: 1.) git clone https://git.ipxe.org/wimboot.git 2.) cd wimboot/src 3.)

Re: [ipxe-devel] Cannot build wimboot

On 26/12/17 17:12, brent s. wrote: hrm.. no, i didn't, at least not intentionally, and on the same version of binutils... let me try it on a brand new install. will reply shortly. i've confirmed that it fails on a fresh install of Arch, bare install (only openssh, grub, dosfstools,

Re: [ipxe-devel] Problem with ipxe on Xen 4.4

On 25/12/17 11:20, Eytan Heidingsfeld wrote: I retried with DEBUG=xenbus and saw that xenbus_probe_type failed for the device: device/suspend/event-channel (I think because it doesn't have a backend key - it is empty). As this device isn't critical for the usage of netfront I just commented

Re: [ipxe-devel] Cannot build wimboot

On 26/12/17 17:35, brent s. wrote: I cannot reproduce your failure on a fresh Arch installation, sorry. You could try a fresh install in Amazon EC2 using one of the AMIs from https://www.uplinklabs.net/projects/arch-linux-on-ec2/ For reference, I get a successful build using ami-566eeb2f

Re: [ipxe-devel] make giving segfault

On 04/10/17 08:41, Christian Hesse wrote: "brent s." on Mon, 2017/10/02 13:23: Thanks, Michael. It seems to be the linking throwing the segfault (reformatted for readability): ld \ -m elf_i386 \ -N --no-check-sections \ --section-start=.prefix=0 \

Re: [ipxe-devel] ECDHE_RSA cipher suites

On 28/07/18 05:04, LAU, ALOYSIUS wrote: In our environment, the servers are using the **ECDHE_RSA** cipher suites. TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384

Re: [ipxe-devel] help: are we support iPXE boot via Ipv6 ?

On 31/07/18 15:17, Elavazhagan Kumaraguru (ekumarag) wrote:  I am new to this group and started using  iPXE. Want to know are we support iPXE boot via Ipv6 ? Yes, iPXE supports booting via IPv6. Michael ___ ipxe-devel mailing list

Re: [ipxe-devel] [PATCH 1/1] build: Fix building with gcc 8.2

On 26/08/18 22:57, Heinrich Schuchardt wrote: Thanks for reviewing. Is there also an architecture specific bin/error target? The "errors" target exists within any architecture: try e.g. bin-arm64-efi/errors. Maybe we need some architecture specific #define for the prefix. It looks as

Re: [ipxe-devel] [PATCH 1/1] [efi] avoid stringop-truncation error in util/elf2efi.c

On 23/08/18 21:12, Heinrich Schuchardt wrote: Avoid the following error with gcc 7.3: In function ‘process_section’, inlined from ‘elf2pe.isra.4’ at util/elf2efi.c:914:25: util/elf2efi.c:497:2: error: ‘strncpy’ specified bound 8 equals destination size [-Werror=stringop-truncation]

Re: [ipxe-devel] [PATCH] sfc: Add support for X25xx adapters

On 18/06/18 11:41, Martin Habets wrote: The first adapters in this family are X2522-10, X2522-25, X2541 and X2542. These no longer use PCI BAR 0 for I/O, but use that for memory. In other words, BAR 2 on SFN8xxx adapters now becomes BAR 0. Pushed as

Re: [ipxe-devel] [PATCH 1/1] build: Fix building with gcc 8.2

On 26/08/18 11:45, Heinrich Schuchardt wrote: diff --git a/src/include/errno.h b/src/include/errno.h index e80bf9ca..0294a990 100644 --- a/src/include/errno.h +++ b/src/include/errno.h @@ -262,10 +262,10 @@ static inline void eplatform_discard ( int dummy __unused, ... ) {}

Re: [ipxe-devel] [ipxe/ipxe] Add support for Intel X552 NIC. (#74)

Merged; thanks. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/ipxe/ipxe/pull/74#issuecomment-403236913___ ipxe-devel mailing list ipxe-devel@lists.ipxe.org

Re: [ipxe-devel] [ipxe/ipxe] Add support for Intel X552 NIC. (#74)

Closed #74. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/ipxe/ipxe/pull/74#event-1721587759___ ipxe-devel mailing list ipxe-devel@lists.ipxe.org

Re: [ipxe-devel] [ipxe/ipxe] [efi_snp] Subtract link-layer header length from MaxPacketSize (#73)

Closed #73. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/ipxe/ipxe/pull/73#event-1721589323___ ipxe-devel mailing list ipxe-devel@lists.ipxe.org

Re: [ipxe-devel] [ipxe/ipxe] [efi_snp] Subtract link-layer header length from MaxPacketSize (#73)

Merged (with a minor change to use netdev->mtu directly instead of replicating the calculation); thanks! -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub:

Re: [ipxe-devel] [PATCH] [efi] Use memcpy to handle efi header name

On 18/06/18 13:20, Michael Brown wrote: Yes, I will pick an appropriate patch and push it (with credits to everyone who has also supplied a fix). Thank you to everyone who's reported/fixed this. I have pushed: http://git.ipxe.org/ipxe.git/commitdiff/8ed4e3049 I spent some time trying

Re: [ipxe-devel] [PATCH] rndis: register netdev with MAC filled

On 01/06/18 07:59, Roman Kagan wrote: register_netdev expects ->hw_addr and ->ll_addr to be already filled, so move it towards the end of register_rndis, after the respective fields have been successfully queried from the underlying device. Applied, with the error handling path fixed up:

Re: [ipxe-devel] [PATCH] vmbus: do not expect version in version_response

On 09/06/18 15:53, Roman Kagan wrote: The definition of version_response channel message in Linux doesn't include version field, so the upcoming VMBus implementation in QEMU doesn't set it either. Neither Windows nor Linux had any problem with this. The check against this field is redundant

Re: [ipxe-devel] [PATCH] rndis: register netdev with MAC filled

On 09/07/18 07:31, Roman Kagan wrote: > so the cleanup needed after a failed register_netdev is the same as after a failed open, and I left err_register label where it was on purpose. While at this, I'm also curious what the reason is to add this unreachable unregister_netdev? I think I

Re: [ipxe-devel] [PATCH 1/2] iscsi: Parse IPv6 address for rootpath

On 05/02/18 08:38, Hannes Reinecke wrote: The 'rootpath' variable might contain an IPv6 address in brackets [XX:XX::XX]. So update the parser to handle this address correctly. Applied with some simplifications (since ipv6_sock_aton() will accept an address that still contains the '[]'

Re: [ipxe-devel] [PATCH 2/3] ethernet: do not construct EUI-64 identifier for empty MAC

On 01/03/18 12:53, Hannes Reinecke wrote: An empty MAC address will cause other problems. If the driver expects the possibility of an empty MAC address, it should be using eth_random_addr() to construct a locally-assigned address. Which driver ended up providing an empty MAC address? igbvf.

Re: [ipxe-devel] [PATCH 2/3] ethernet: do not construct EUI-64 identifier for empty MAC

On 05/02/18 08:36, Hannes Reinecke wrote: If the MAC address is empty we should not construct an EUI-64 identifier, but rather return an error. An empty MAC address will cause other problems. If the driver expects the possibility of an empty MAC address, it should be using eth_random_addr()

Re: [ipxe-devel] [PATCH 1/3] dhcpv6: Fallback to using DUID-LL for empty UUID

On 05/02/18 08:36, Hannes Reinecke wrote: +/** DHCP unique identifier based on Ethernet Link-layer address (DUID-LL) */ +struct dhcpv6_duid_eth_ll { + /** Type */ + uint16_t type; + /** Hardware type: Ethernet */ + uint16_t hw_type; + /** Ethernet link-layer address

Re: [ipxe-devel] Several build errors

On 10/03/18 17:59, brent s. wrote: It appears that something along these lines: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=462003 may be related; I've looked at bugs in other projects[0] and they all seem to concur that it's sometimes necessary to add --32 to the compiler's invocation

Re: [ipxe-devel] [ipxe/ipxe] [efi_pci] Elevate TPL around pci_probe (#70)

Good catch. Should be fixed by the slightly more general solution at http://git.ipxe.org/ipxe.git/commitdiff/10d083ffa - please let me know if this doesn't fix your problem. Thanks! -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it

Re: [ipxe-devel] [ipxe/ipxe] [efi_pci] Elevate TPL around pci_probe (#70)

Closed #70. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/ipxe/ipxe/pull/70#event-1522214116___ ipxe-devel mailing list ipxe-devel@lists.ipxe.org

Re: [ipxe-devel] [ipxe/ipxe] [intel] Add PCI_ROM entry for Intel i354 NIC (#69)

Closed #69. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/ipxe/ipxe/pull/69#event-151259___ ipxe-devel mailing list ipxe-devel@lists.ipxe.org

Re: [ipxe-devel] the Last iPXE can't boot win10

On 15/03/18 07:11, W Drinsun wrote: Not show any error, just lose iscsi connection in win10 booting. The attached file is my iPXE script. Can you reproduce the failure with a much simpler script? Try reducing it to just a single fixed sanboot command. Thanks, Michael

Re: [ipxe-devel] [ipxe/ipxe] [intelx] Add PCI_ROM entry for Intel x553 NIC (#71)

Closed #71. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/ipxe/ipxe/pull/71#event-154138___ ipxe-devel mailing list ipxe-devel@lists.ipxe.org

Re: [ipxe-devel] [ipxe/ipxe] [intelx] Add PCI_ROM entry for Intel x553 NIC (#71)

Done (with added trailing comma): http://git.ipxe.org/ipxe.git/commitdiff/2eef77ecc -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub:

Re: [ipxe-devel] [PATCH 1/1] [arm] add -mno-unaligned-access compiler flag

On 19/04/18 16:26, Mark Rutland wrote: For better or worse, I don't think that it is sufficient to pass the compiler -mno-unaligned-accesses, even if it happens to mask the problem in this specific case. The compiler can validly assume structures have their usual alignment, and hence the LDRD

Re: [ipxe-devel] [ipxe/ipxe] Submit (#72)

Closed #72. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/ipxe/ipxe/pull/72#event-1586301521___ ipxe-devel mailing list ipxe-devel@lists.ipxe.org

Re: [ipxe-devel] [PATCH] [efi] use correct bound in strncpy to ensure NUL-termination

On 23/04/18 16:42, Bruce Rogers wrote: Using gcc8 with the [-Werror=stringop-truncation] option, the following error is emitted: util/elf2efi.c:494:2: error: 'strncpy' specified bound 8 equals destination size [-Werror=stringop-truncation] strncpy ( ( char * ) new->hdr.Name, name, sizeof (

Re: [ipxe-devel] [PATCH] [efi] use correct bound in strncpy to ensure NUL-termination

On 23/04/18 21:01, Bruce Rogers wrote: This is a fixed-length string field that is not supposed to be NUL-terminated. The use of strncpy() here is deliberate in order to be able to completely fill the field. Is there a (clean) way to indicate to gcc to ignore this false positive warning? I

Re: [ipxe-devel] [PATCH 1/1] [arm] add -mno-unaligned-access compiler flag

On 18/04/18 20:21, Heinrich Schuchardt wrote: the unaligned access problem with iPXE is still haunting me. Even with SCTLR.A = 0 not all forms of unaligned access are allowable. When trying to run iPXE on another board I experienced the following data abort: static int tcp_rx ( struct io_buffer

Re: [ipxe-devel] [PATCH 1/1] [efi] avoid unaligned read in efi_devpath_end()

On 28/03/18 19:49, Heinrich Schuchardt wrote: The old coding resulted in a "data abort" when compiled with gcc 6.3 for armhf and run on an Allwinner A20 SOC. The unaligned access occured when path->Length was on an uneven address. There's no way that the code: -( (

Re: [ipxe-devel] [PATCH 1/1] [efi] avoid unaligned read in efi_devpath_end()

On 28/03/18 20:23, Heinrich Schuchardt wrote: : 0: 7803ldrbr3, [r0, #0] <<< Reading on byte 2: 2b7fcmp r3, #127; 0x7f 4: d100bne.n 8 6: 4770bx lr 8: 8843

Re: [ipxe-devel] [PATCH 1/1] elf2efi: add support for R_ARM_REL32

On 27/03/18 18:07, Heinrich Schuchardt wrote: The relocation type R_ARM_REL32 is generated when building bin-arm32-efi/snp.efi using gcc 6.3 and ld 2.28. R_ARM_REL32 is a program counter (PC) relative 32 bit relocation so we can ignore it like all other PC relative relocations. Applied; thank

Re: [ipxe-devel] [PATCH 1/1] [efi] avoid unaligned read in efi_devpath_end()

On 28/03/18 20:10, Heinrich Schuchardt wrote: There's no way that the code: - ( ( path->Length[1] << 8 ) | path->Length[0] ) ); should ever be able to produce an unaligned access abort, since it just dereferences individual bytes.  What do you see if you disassemble the object

Re: [ipxe-devel] [PATCH 1/1] [efi] avoid unaligned read in efi_devpath_end()

On 28/03/18 20:11, Heinrich Schuchardt wrote: with the patch above I reach the iPXE prompt on a BananaPi. But when executing the dhcp command I see another "data abort", see below. I am trying to track down, in which routine this happens. The error occurs in monojob_wait(). Where do I find the

Re: [ipxe-devel] [PATCH 1/1] [efi] Run at TPL_CALLBACK to protect against UEFI timers

On 25/03/18 13:24, Michael Brown wrote: Unfortunately, good coding practice dictates completely ignoring the UEFI specification as far as is possible, since it is full of poorly-designed garbage such as EFI_HII_CONFIG_ROUTING_PROTOCOL, EFI_USB_IO_PROTOCOL, the EFI UNDI API, etc.  iPXE

Re: [ipxe-devel] IPXE failing to boot with multiple cards

On 24/03/18 18:39, randy silks wrote: I have 2 of the same type cards installed in a workstation, one has it’s flash programmed with IPXE  the other does not. When the machine is booted it seems to pick up the unprogrammed cards MAC address for use in booting. Booting into IPXE I find

Re: [ipxe-devel] [PATCH 1/1] [efi] Run at TPL_CALLBACK to protect against UEFI timers

On 24/03/18 16:43, Heinrich Schuchardt wrote: The patch clearly contradicts the UEFI spec: "Good coding practice dictates that all code should execute at its lowest possible TPL level, and the use of TPL levels above TPL_APPLICATION must be minimized. Executing at TPL levels above

Re: [ipxe-devel] [PATCH 1/1] [arm] add -mno-unaligned-access compiler flag

On 29/03/18 10:20, Mark Rutland wrote: I think this may be a bug in the UEFI implementation (which I guess is U-Boot?). In the 2.7 UEFI spec, section 2.3.5 states that for AArch32: Unaligned access should be enabled if supported; Alignment faults are enabled otherwise. All ARMv6 and

Re: [ipxe-devel] the Last iPXE can't boot win10

On 29/03/18 07:39, W Drinsun wrote: The last version can work now. I guess you’ve slaved the problem. Great; thanks for letting us know! Michael ___ ipxe-devel mailing list ipxe-devel@lists.ipxe.org

Re: [ipxe-devel] [RFC] Why does ARM set -mcpu=cortex-a15

On 29/03/18 01:45, Heinrich Schuchardt wrote: I have some questions concerning the compilation flags used by iPXE on ARM. There are a lot of different ARM CPUs available. Why do we set -mcpu=cortex-a15? In all honesty, I don't remember. My best guess is that the build options were copied

Re: [ipxe-devel] Ipxe on Wifi

On 21/03/18 18:21, Jatin Mistry wrote: I am Jatin, i am in internship at my job and i need to boot ipxe on wlan. But the actual ipxe driver can't work with my laptop i cant see the wifi list ? can u help me ? The driver linux wifi for my laptop intel iwlwifi 4.10 firmware 22.39 We don't have

Re: [ipxe-devel] branding patch

On 23/03/18 02:04, David Yeske wrote: I recently wanted to build a custom version of the ipxe firmware by creating the following file. % cat src/config/local/uefi/branding.h #undef PRODUCT_TAG_LINE #define PRODUCT_TAG_LINE "uefi Network Firmware" When I compiled and ran ipxe, it did not

Re: [ipxe-devel] Git not working?

On 14/11/2018 13:27, John Haxby wrote: On Wed, Nov 14, 2018 at 01:13:24PM +, John Haxby wrote: The git repo seems to have been down for about a week: $ git clone git://git.ipxe.org/ipxe.git Cloning into 'ipxe'... fatal: read error: Connection reset by peer I've tried it from a

Re: [ipxe-devel] IPXE master: NIC looses connectivity

On 24/09/18 23:33, Arun SAG wrote: We tried to run the latest master 133f4c47. Our build includes a SSL certificate in the undionly.kpxe. IPXE loads and does a dhcp request and receives a response, Loads the kernel and ramdisk, boots the ramdisk over https; the kernel boots and dracut in the

Re: [ipxe-devel] [PATCH 1/2] [util] Better processing of ROM images in Option::ROM

On 15/01/2019 19:32, Petr Borsodi wrote: The Option::ROM module now compare Code Type in PCIR header to 0x00 (PC-AT) in order to presence check of other header types (PnP, UNDI, iPXE, ...). Validity of these headers are checked not only by offset, but range and signature checks also. Image

Re: [ipxe-devel] Default path in IPXE chain command

On 16/01/2019 14:10, Lee Turchin wrote: Thank you for your quick response. We are attempting to integrate Razor bare metal. My most serious issue with this script is that Razor policies/tasks never "kick in" so to speak. Any hints on that aspect are most welcome. I haven't played with

Re: [ipxe-devel] [PATCH] wimboot: Add R_X86_64_PLT32 as known reloc target

On 17/12/2018 03:18, Alif M. Ahmad wrote: According to a discussion on ipxe mailing list[1], binutils 2.31.0 generates R_X86_64_PLT32 instead of R_X86_64_PC32. This change fixes building wimboot on systems with binutils >= 2.31.0 [1]

Re: [ipxe-devel] [PATCH 1/4] Fix strcmp()/strncmp() to return proper values

On 09/01/2019 19:35, Aaron Young wrote: Fix strcmp() and strncmp() to return proper standard positive/negative values for unequal strings. Current implementation is backwards (i.e. the functions are returning negative when should be position and vice-versa). Currently all consumers of these

Re: [ipxe-devel] [PATCH] [rom] Correct invalid base-class/sub-class/prog-if order in PCIR

On 14/01/2019 14:56, Petr Borsodi wrote: PCI Configuration Space contains fields prog-if at the offset 0x09, sub-class at the offset 0x0a and base-class at the offset 0x0b (it respects little endian). PCIR structure uses these fields in the same order. Good catch! Your mail client

Re: [ipxe-devel] [PATCH 0/4] Local UEFI disk boot support

On 09/01/2019 19:35, Aaron Young wrote: Example output of the efimap command is as follows: iPXE> efimap Drive# Path -- 0 PciRoot(0x0)/Pci(0x3,0x0)/HD(2,MBR,0x2E0E0369,0xBBC,0x3708) 1 PciRoot(0x0)/Pci(0x4,0x0)/HD(1,GPT,F82F29A0-...,0x800,0x64000) 2

Re: [ipxe-devel] [ipxe/ipxe] [efi_snp] Fix error handling path in efi_snp_probe (#86)

Rebased and merged; thanks. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/ipxe/ipxe/pull/86#issuecomment-454402169___ ipxe-devel mailing list

Re: [ipxe-devel] [ipxe/ipxe] [efi_snp] Fix error handling path in efi_snp_probe (#86)

Closed #86. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/ipxe/ipxe/pull/86#event-2074656411___ ipxe-devel mailing list ipxe-devel@lists.ipxe.org

Re: [ipxe-devel] Default path in IPXE chain command

On 15/01/2019 16:34, Lee Turchin wrote: I need to figure out the default search path for configuring IPXE I receive an error that files cannot be located during TFTP boot. Chain command in bootstrap.ipxe is the below.  Please note the first line- chain http://172.17.11.119:8150/svc/boot? 

Re: [ipxe-devel] [PATCH 1/2] [util] Better processing of ROM images in Option::ROM

On 16/01/2019 16:37, Petr Borsodi wrote: The Option::ROM module now compare Code Type in PCIR header to 0x00 (PC-AT) in order to presence check of other header types (PnP, UNDI, iPXE, ...). Validity of these headers are checked not only by offset, but range and signature checks also. Image

Re: [ipxe-devel] [PATCH 2/2] [util] Add support for EFI ROM images

On 16/01/2019 16:37, Petr Borsodi wrote: The Option::ROM module recognizes and checks EFI header of image. The disrom.pl utility dumps this header if is present. Applied, thanks: http://git.ipxe.org/ipxe.git/commitdiff/de4565cbe Michael ___

Re: [ipxe-devel] 64 bit?

On 22/01/2019 18:01, Johannes Thoma wrote: Thanks for your quick reply. When running make bin-i386-linux/tests.linux I run in an endless loop when building the dependencies. That's an annoying quirk of the build process when there are missing headers, sorry. It arises from some nasty

Re: [ipxe-devel] 64 bit?

On 10/01/2019 19:21, Johannes Thoma wrote: I will try that, in theory it should work then. Does it make sense to support loading images > 2GB in 32-bit version also? One has to change some size_t declarations to uint64_t then (it almost works for me), if I keep on trying I think that I can do

Re: [ipxe-devel] Need help in booting a FC volume using IPXE

On 29/11/2018 11:34, Parimala M V, Nitesh wrote: I have a FC volume(which has OS written onto it) created on the SAN and I've attached to a Server(Bare metal). Now I want to boot that volume using IPXE. I know that using “sanhook” we can boot ISCSI volume. From this

Re: [ipxe-devel] Howto boot from a non-pxe nic?

On 26/11/2018 12:40, Oliver Rath wrote: And O.P. is not aware that iPXE uses drivers from Linux. [1] Ok, this I didnt know. It's not actually true. It's possible to take a Linux driver as the starting point for creating an iPXE driver, but it's not just a case of copying and pasting.

Re: [ipxe-devel] ipxe

On 23/11/2018 20:36, Henny Zutt wrote: I am new at ipxe and have a question: When i try to boot from the network I get IPXE initialising devices…WARNING: Using legacy NIC wrapper on 79:79:79:79:79:79 Ok When i use the dhcp command on the ipxe prompt i get Down If i use ifconf -c dhcp

Re: [ipxe-devel] ipxe.org OSCP server issues?

On 15/11/2018 21:21, Stephen Soltesz wrote: Are there any known issues with the ipxe.org OSCP servers? Yesterday I was able to boot a test server but today I'm getting an error message for http://ipxe.org/err/432fe3 On 16/11/2018 18:32, Damien Radtke wrote: I was

Re: [ipxe-devel] Fallback to IPv4 or disable IPv6

On 01/11/2018 17:40, Anatoli Babenia wrote: My upstream provider doesn't support IPv6. No addresses are reachable. But my router still gives me an IPv6 address and is even able to resolve records. Being able to resolve IPv6 address iPXE thinks that it got IPv6 and fails, but it should try

Re: [ipxe-devel] Fallback to IPv4 or disable IPv6

On 19/11/2018 11:26, Geert Stappers wrote: Bullshit. Reread Geert: please be more polite. Michael ___ ipxe-devel mailing list ipxe-devel@lists.ipxe.org https://lists.ipxe.org/mailman/listinfo.cgi/ipxe-devel

Re: [ipxe-devel] Fallback to IPv4 or disable IPv6

On 19/11/2018 11:13, Andreas Fink wrote: On 19 Nov 2018, at 11:52, Michael Brown wrote: iPXE will query for records only if the DNS server address is itself an IPv6 address. This is the heuristic we use to decide between IPv6 and IPv4 when a DNS name is used. This is not really what

Re: [ipxe-devel] ipxe writing in a UEFI variable

On 19/11/2018 13:51, Tamas Baumgartner-Kis wrote: we trying to secure our network boot environment with UEFI secure boot. Because of that we put kernel, initrd and cmdlin in one big file with objcopy. Therefore we can't use ipxe for dynamically fill up some cmdline parameter, for example

Re: [ipxe-devel] Intel X722 VFs

On 09/01/2019 11:55, Matt Lupfer wrote: I'm interested in support for Intel X722 VFs in ipxe. I see that the ipxe intelxl driver supports the physical functions, but I want to be able to pxe boot VMs from the VFs. Is this support planned? Yes, this is already planned. Michael

Re: [ipxe-devel] 64 bit?

On 10/01/2019 18:57, Johannes Thoma wrote: I would like to sanboot images larger than 2GB via http. I already changed some of the size_t declarations to uint64_t but am currently stuck. I can boot 7.8 GB images but no 32 GB images (the capacity of the block device is truncated). Before

Re: [ipxe-devel] 64 bit?

On 22/01/2019 16:07, Johannes Thoma wrote:  From memory: the issue in 32-bit builds is that format_decimal() in core/vsprintf.c will handle only 32-bit (signed) integers and so the HTTP range request headers cannot be constructed correctly for >2GB. This limitation in format_decimal() is

<    5   6   7   8   9   10   11   12   >