Rename iso -> anaconda-iso
#165
Conversation
cgwalters
force-pushed
the
anaconda-iso
branch
from
7d619b9
to
220b16d
Compare
|
@cgwalters Just to clarify, Are you saying this would be a live ISO that you could use to install to disk using anconda from a live system rather than having an automated install with a kickstart file like it currently is now? |
|
This PR is just changing the name of the existing artifact. But yes the new ISO type I am proposing would support what you are talking about. (Though there's some nontrivial details here, like to have the GUI anaconda I think we should embed it really as a flatpak etc.) There is however some steps to bridge things here...if we support configuring the kickstart for our existing anaconda-iso (in particular, leaving off things like the partitioning) then I think it automatically kicks anaconda into interactive mode. (But yeah this is still not what one wants...IMO for honestly any case, but there's just a huge amount of Fedora-derivative inertia around Anaconda as it is going on here) |
I think the benefit I see to having an Anaconda interactive mode (allowing for user creation, etc.) is it allows bootc-image-builder to support building things like Silverblue Custom ISOs or Universal Blue ISO images which would be hugely helpful to the Desktop Linux community. Being able to use this tool to build desktop ISO images would be so cool! |
|
Hm tmt tests fell over with
which is surely unrelated? Will look... (Side note, I am just not a fan of dynamic languages anymore...and tangentially related to this was looking at refactoring the qemu Go wrapper we have in coreos-assembler (see coreos/coreos-assembler#3712 ) so that in theory it can be shared and reused with podman-machine) |
cgwalters
force-pushed
the
anaconda-iso
branch
3 times, most recently
from
453d883
to
c2003ab
Compare
Fwiw, I agree and would love to use rust/go more … |
|
Hmm some strange failures in the testing farm job there: |
I would like to potentially introduce a generic "live iso" that generates *exactly the input container* just as a Live ISO, very similar to how Fedora CoreOS (and one of its parents, the original Container Linux) do it. This has several use cases, such as always running from a PXE boot. I also think this is the long term architecture for an ISO, as opposed to the current Anaconda. This "direct" Live ISO is also the same as how e.g. Fedora Workstation does it, where the installer is just an app in the system. For compatibility we continue to honor the `iso` as an alias.
cgwalters
force-pushed
the
anaconda-iso
branch
from
c2003ab
to
461937c
Compare
This PR just renames the
isoartifact toanaconda-iso.The reason is that I would like to potentially introduce a different generic "live iso" that generates exactly the input container just as a Live ISO, very similar to how Fedora CoreOS (and one of its parents, the original Container Linux) do it.
This (proposed)
live-isowould have several use cases, such as always running from a PXE boot. I also think this is the long term architecture for an ISO, as opposed to the current Anaconda. It would also be the same as how e.g. Fedora Workstation does it, where the installer is just an app in the system.Anyways again, this is just a rename. For compatibility we continue to honor the
isoas an alias.