Closed bgilbert closed 5 years ago
I hate to keep commenting without contributing, but we have a concrete case where something like this is needed, so I thought it might be helpful. We have widely distributed systems we have to stage replacement hardware in different parts of the country in order to meet support commitments. The way that usually works is that we have a third-party company hand-carry a new system out to the site and configure it on the spot. In such cases they will not have access to a network configured with the DHCP, file server, etc, for a PXE install, so we need some standalone alternative. What I'd been thinking up to now was to have something like a customized Fedora LiveOS that they could plug into a USB port, boot that, configure network access based on whatever the local environment is (sometimes it's a point-to-point link, etc, rather than DHCP on a LAN) then run a script (I guess like coreos-install) that downloads and installs kernel+OS+ignition from remote servers and copies those to the local disk.
Since I have not been able to experiment yet with installing CoreOS, Atomic, or Fedora CoreOS in this manner, I'm not sure what the best approach is.
Disabling Zincati in live ISO images: https://github.com/coreos/zincati/issues/63
I would be interested in live ISO (flash) image feature for running temporary nodes (w/o installing anything onto the disks).
Assuming that the goal here is to provide some form of lowest common denominator install CD for bare-metal servers of all varieties here is an information point from: https://mattgadient.com/linux-dvd-images-and-how-to-for-32-bit-efi-macs-late-2006-models/
The “problem” with the 32-bit EFI macs (as I understand it) is that they fall apart when they try to load a “multi-catalog” disk image. Most linux distros use multi-catalog images so that they support both BIOS and EFI. When the Mac tries to load the disk image, you get the cryptic “select CD-ROM boot type” text. Since the mac hasn’t loaded any keyboard stuff yet, you can’t actually choose any of the options.
The cleanest solution is to change the disk image to be BIOS-only (non-EFI). Basically, remove other items from the El Torito catalog. That’s what the old Ubuntu amd64+mac ISO’s did. The 64-bit BIOS linux bootloader kicks in, and all is well. A more detailed explanation can be found here: https://askubuntu.com/questions/37999/what-is-different-about-the-mac-iso-image#answers
(show me anyone who would want to boot own macbook from livecd and burn it by running k8s workloads)
I wasnt actually referring to the liveCD per se. Core2Duo iMacs are available for <$30, and old Mac Pro's run k8s just fine.
macOS hasn't supported 32-bit EFI machines since 10.8 in mid-2012. I don't think we should put significant effort into supporting those older Macs.
The FCOS installation CD/DVD is less than 100Mb, how is publishing it as a single layer ISO image "significant effort". I was just promoting awareness of the issue. Secondly this has nothing to do with macOS, or 32bitEFI.
Those of us in the mac world are used to repurposing older machines for more than 10 years (unfortunately Apple forgot this), back in the day some offices only discovered that they had a MacSE/30 server in the cupboard when it eventually caught fire. For myself a MacPro1,1 with a couple of decent mirrored HDD makes a cost effective alternative to online storage with failover.
The FCOS installation CD/DVD is less than 100Mb, how is publishing it as a single layer ISO image "significant effort".
As I understand it, supporting these old Macs would require publishing an image that doesn't boot under UEFI, which means we'd need to publish a second image that does. That increases the chance of user confusion, and of course also increases the number of artifacts we'd need to release.
FWIW, the installer ISO is going away, and will be replaced by a live ISO which will be significantly more than 100 MB. See https://github.com/coreos/fedora-coreos-tracker/issues/203 for details.
Secondly this has nothing to do with macOS, or 32bitEFI.
Sorry, I had understood that you were proposing a workaround specifically for 32-bit EFI machines. Is there a more general problem you're hoping to address here?
@bgilbert - I know there has been a lot of work here. Where do we stand?
The latest testing release shipped live ISO images. We still need docs, and https://github.com/coreos/fedora-coreos-tracker/issues/281 should be fixed, but other than that it's done.
@bgilbert Thank you very much, Benjamin.
Should we close this and let remaining pieces be covered by #281 and maybe #159 (or create a separate docs ticket)
Yeah, let's close this out.
Container Linux supports booting a stateless live system from an ISO image. This provides a reasonably convenient way to boot Container Linux on bare metal for experimentation or to run
coreos-install
. Fedora CoreOS has some cases where an ISO image would be useful:coreos-install
(or equivalent) to write an OS image to a USB key. That allows configuring the live system with Ignition, but also produces a stateful live image, which may be surprising to users.The CL ISO image is implemented by dropping the PXE kernel and initrd into an ISO along with ISOLINUX. It thus inherits the basic model of PXE-booted systems (#105). A similar approach could be used for Fedora CoreOS.
Getting an Ignition config into an ISO-booted system is not straightforward. In CL it's possible to manually add a
coreos.config.url
kernel command-line parameter, which is awkward at best. We could provide a tool that builds a modified ISO image including an embedded Ignition config, though that also seems awkward.