Fork of ipxe; additional commands and features https://git.openslx.org/openslx-ng/ipxe.git/atom/src/config/cloud?h=openslx 2025-11-24T23:25:31+00:00 2025-11-24T23:25:31+00:00 Michael Brown 2025-11-24T20:27:53+00:00 urn:sha1:dfea3bbfad75aa742623beb4d88e2be086a4b8ee On some systems (observed on an AWS m8g.medium instance in eu-west-2), the UEFI firmware omits the PCI host bridge drivers for all but the first PCI bus. The observable result is that any devices on other PCI buses (such as the ENA network device) are not enumerated by the UEFI firmware and are therefore unusable by iPXE. Support these systems by switching to using PCIAPI_CLOUD for EFI cloud builds, trying the EFI PCI I/O API first and falling back to direct access (via ECAM) for devices that the UEFI firmware has failed to enumerate itself. Signed-off-by: Michael Brown <mcb30@ipxe.org> 2025-11-24T20:54:01+00:00 Michael Brown 2025-11-24T20:18:52+00:00 urn:sha1:ff1a17dc7e5d764b905559fdc623249741d173dd Use the linker table mechanism to enumerate the underlying PCI I/O APIs, to allow PCIAPI_CLOUD to become architecture-independent code. Signed-off-by: Michael Brown <mcb30@ipxe.org> 2025-10-29T13:26:50+00:00 Michael Brown 2025-10-29T13:18:28+00:00 urn:sha1:606e87ec7a3d74a4f995e60e93d0db09e0f0cbbb Experiments suggest that the instance type is exposed via the SMBIOS product name. Include this information within the default output, since it is often helpful in debugging. Signed-off-by: Michael Brown <mcb30@ipxe.org> 2025-10-20T11:58:03+00:00 Michael Brown 2025-10-20T11:35:36+00:00 urn:sha1:c8f088d4e11a1dedda4829c4be1bb1b14e9da016 On some newer (7th and 8th generation) instance types, the 32-bit build of iPXE cannot access PCI configuration space since the ECAM is placed outside of the 32-bit address space. The visible symptom is that iPXE fails to detect any network devices. The public AMIs are all now built as 64-bit binaries, but there is nothing that prevents the building and importing of a 32-bit AMI. There are still potentially valid use cases for 32-bit AMIs (e.g. if planning to use the AMI only for older instance types), and so we cannot sensibly prevent this error at build time. Display the build architecture as part of the AWS EC2 embedded script, to at least allow for easy identification of this particular failure mode at run time. Signed-off-by: Michael Brown <mcb30@ipxe.org> 2022-09-18T12:41:21+00:00 Michael Brown 2022-09-18T12:41:21+00:00 urn:sha1:649176cd608e74ce54d20488a0618b4c6d8be71d Pretty much all physical machines and off-the-shelf virtual machines will provide a functional PCI BIOS. We therefore default to using only the PCI BIOS, with no fallback to an alternative mechanism if the PCI BIOS fails. AWS EC2 provides the opportunity to experience some exceptions to this rule. For example, the t3a.nano instances in eu-west-1 have no functional PCI BIOS at all. As of commit 83516ba ("[cloud] Use PCIAPI_DIRECT for cloud images") we therefore use direct Type 1 configuration space accesses in the images built and published for use in the cloud. Recent experience has discovered yet more variation in AWS EC2 instances. For example, some of the metal instance types have multiple PCI host bridges and the direct Type 1 accesses therefore see only a subset of the PCI devices. Attempt to accommodate future such variations by making the PCI I/O API selectable at runtime and choosing ECAM (if available), falling back to the PCI BIOS (if available), then finally falling back to direct Type 1 accesses. This is implemented as a dedicated PCIAPI_CLOUD API, rather than by having the PCI core select a suitable API at runtime (as was done for timers in commit 302f1ee ("[time] Allow timer to be selected at runtime"). The common case will remain that only the PCI BIOS API is required, and we would prefer to retain the optimisations that come from inlining the configuration space accesses in this common case. Cloud images are (at present) disk images rather than ROM images, and so the increased code size required for this design approach in the PCIAPI_CLOUD case is acceptable. Signed-off-by: Michael Brown <mcb30@ipxe.org> 2021-07-20T12:19:15+00:00 Michael Brown 2021-07-20T12:19:15+00:00 urn:sha1:4d180be5175e176ec27680557c1d67536a847610 The DHCP service in EC2 has been observed to occasionally stop responding for bursts of several seconds. This can easily result in a failed boot, since the current cloud boot script will attempt DHCP only once. Work around this problem by retrying DHCP in a fairly tight cycle within the cloud boot script, and falling back to a reboot after several failed DHCP attempts. Signed-off-by: Michael Brown <mcb30@ipxe.org> 2021-06-23T09:22:38+00:00 Michael Brown 2021-06-23T09:22:38+00:00 urn:sha1:0688114ea63fee21c39d94cc8df9e2a5003ac283 Signed-off-by: Michael Brown <mcb30@ipxe.org> 2021-05-02T11:38:03+00:00 Michael Brown 2021-05-02T11:35:37+00:00 urn:sha1:1dfc05622d183213c55b49c3ea4f4fd5c7bd6253 Signed-off-by: Michael Brown <mcb30@ipxe.org> 2021-04-10T19:03:32+00:00 Michael Brown 2021-04-10T19:03:32+00:00 urn:sha1:3ae83222ce611afacd98419c0073aa98fb97f9e7 Signed-off-by: Michael Brown <mcb30@ipxe.org> 2021-02-17T22:38:38+00:00 Michael Brown 2021-02-17T22:37:56+00:00 urn:sha1:4039b54ba308757c4d3ef4845453637819be59d6 Most EFI firmware builds (including those found on ARM64 instances in AWS EC2) will already send console output to the serial port. Do not enable direct serial console output in EFI builds using CONFIG=cloud. Signed-off-by: Michael Brown <mcb30@ipxe.org>