After Workstation has received a new Anaconda version, it is Server's turn. Before wasting time and effort or using them incorrectly, I think it makes sense to determine in detail what requirements we have regarding configurability.
I think at least the following list of topics would be worth working on.
1. == Of the current items in the main menu, keyboard layout, installation destination, network configuration, and root/user account seem indispensable to me. In my opinion, all the others are superfluous.
Under the current item “Software Selection,” you can first choose between Server and Minimum. According to our technical specifications, we only want to offer Server and nothing else. ‘Minimum’ is a remnant from before 2014 and is currently part of the “Everything” image.
The options mostly relate to services. We want to install these using Ansible Script and configure them to suit the server. It is not possible to install the services properly using Anaconda Installation, as server-specific preparations must be made (e.g., setting up LV or BTRFS subvolumes), which is not possible at this stage. That leaves the “Hardware Support” option for special cases. I remember using this last time about 20 years ago. I suspect that this option is also superfluous. And I doubt that this point is still actively maintained.
=== Proposal ad 1: === We are removing the “Software Selection” menu item without replacement.
2. == I also consider menu item 2, “Software Source,” to be superfluous. For the DVD version, it is the installation medium, and for a network-based installation, it is the nearest mirror server. Perhaps it would be useful to display a pop-up if no mirror server can be found.
=== Proposal ad 2: === We are removing the “Software Source” menu item without replacement.
3. == The timeserver and time zone configuration is a typical post-installation task and is already included in our documentation.
=== Proposal ad 3: === We are removing the “Time / Timezone” menu item without replacement.
4. == For years, we have been installing the same set of packages over and over again. We do not take advantage of the flexible installation options offered by Anaconda. And the current technical concept does not (any longer) provide for such optionality. We should check whether it would be advantageous and possible to flush a complete root file system instead. This would significantly speed up the installation process.
=== Task ad 4. === We check whether it is feasible and advantageous to flush a complete root file system instead of installing each package individually.
5. == We should check whether it is also advantageous for Server Edition (as it is for Workstation) to boot for types of interactive installations a kind of headless live image and use this as a basis for the further installation process.
Maybe we can evolve this into an advanced rescue system where the server either boot into such a termional session or starts a remote access server, so the admin can access it.
=== Task ad 5. === Evaluation of the feasibility and usefulness of a minimal server live image.
Feel free to add further topics to this list.
-- Peter Boy https://fedoraproject.org/wiki/User:Pboy PBoy@fedoraproject.org
Timezone: CET (UTC+1) / CEST (UTC+2)
Fedora Server Edition Working Group member Fedora Docs team contributor and board member Java developer and enthusiast
As I alluded to in the Matrix chat, here are my thoughts:
In regards to proposal 1:
Have the installer default to installing the server-product group and just installing the base system would be the best way forward.
Looking at my kickstart file for my server installs, it consists of the following packages and environment groups:
- Server-Product-Environment - Admin-tools - Development tools - Headless Management - Container Environment - vim
Admittedly, before I started using kickstart, I would install components of Admin-tools, development tools, and container environment post install. I could start doing that again, but doing it via Ansible going forward.
Proposal 2:
if we just install Server-Product-Environment, with no other options as it's all handled via ansible post installation, I don't think we need the software selection option.
Proposal 3:
I support this, I don't think I've ever actually gone into that option on any install.
Proposal 4:
I'm going to be honest, I am not sure what this means.
Proposal 5:
A live server image might work. The CoreOS install image is a live image, and that seems to work, but a live environment seems like overkill in the server space. I can't think of the last time that I used a live environment (other than when I installed CoreOS to see if it would work for my needs on the server) for installation. I do keep a KDE Live environment on hand for rescue purposes.
Just my thoughts.
Jocelyn On Sun, Jun 1, 2025 at 3:43 PM Peter Boy via server < server@lists.fedoraproject.org> wrote:
After Workstation has received a new Anaconda version, it is Server's turn. Before wasting time and effort or using them incorrectly, I think it makes sense to determine in detail what requirements we have regarding configurability.
I think at least the following list of topics would be worth working on.
== Of the current items in the main menu, keyboard layout, installation destination, network configuration, and root/user account seem indispensable to me. In my opinion, all the others are superfluous.
Under the current item “Software Selection,” you can first choose between Server and Minimum. According to our technical specifications, we only want to offer Server and nothing else. ‘Minimum’ is a remnant from before 2014 and is currently part of the “Everything” image.
The options mostly relate to services. We want to install these using Ansible Script and configure them to suit the server. It is not possible to install the services properly using Anaconda Installation, as server-specific preparations must be made (e.g., setting up LV or BTRFS subvolumes), which is not possible at this stage. That leaves the “Hardware Support” option for special cases. I remember using this last time about 20 years ago. I suspect that this option is also superfluous. And I doubt that this point is still actively maintained.
=== Proposal ad 1: === We are removing the “Software Selection” menu item without replacement.
== I also consider menu item 2, “Software Source,” to be superfluous. For the DVD version, it is the installation medium, and for a network-based installation, it is the nearest mirror server. Perhaps it would be useful to display a pop-up if no mirror server can be found.
=== Proposal ad 2: === We are removing the “Software Source” menu item without replacement.
== The timeserver and time zone configuration is a typical post-installation task and is already included in our documentation.
=== Proposal ad 3: === We are removing the “Time / Timezone” menu item without replacement.
== For years, we have been installing the same set of packages over and over again. We do not take advantage of the flexible installation options offered by Anaconda. And the current technical concept does not (any longer) provide for such optionality. We should check whether it would be advantageous and possible to flush a complete root file system instead. This would significantly speed up the installation process.
=== Task ad 4. === We check whether it is feasible and advantageous to flush a complete root file system instead of installing each package individually.
== We should check whether it is also advantageous for Server Edition (as it is for Workstation) to boot for types of interactive installations a kind of headless live image and use this as a basis for the further installation process.
Maybe we can evolve this into an advanced rescue system where the server either boot into such a termional session or starts a remote access server, so the admin can access it.
=== Task ad 5. === Evaluation of the feasibility and usefulness of a minimal server live image.
Feel free to add further topics to this list.
-- Peter Boy https://fedoraproject.org/wiki/User:Pboy PBoy@fedoraproject.org
Timezone: CET (UTC+1) / CEST (UTC+2)
Fedora Server Edition Working Group member Fedora Docs team contributor and board member Java developer and enthusiast
-- _______________________________________________ server mailing list -- server@lists.fedoraproject.org To unsubscribe send an email to server-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/server@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On Sun, Jun 1, 2025 at 8:19 PM Jocelyn Gould via server server@lists.fedoraproject.org wrote:
As I alluded to in the Matrix chat, here are my thoughts:
In regards to proposal 1:
Have the installer default to installing the server-product group and just installing the base system would be the best way forward.
Looking at my kickstart file for my server installs, it consists of the following packages and environment groups:
Server-Product-Environment Admin-tools Development tools Headless Management Container Environment vim
Admittedly, before I started using kickstart, I would install components of Admin-tools, development tools, and container environment post install. I could start doing that again, but doing it via Ansible going forward.
Proposal 2:
if we just install Server-Product-Environment, with no other options as it's all handled via ansible post installation, I don't think we need the software selection option.
Proposal 3:
I support this, I don't think I've ever actually gone into that option on any install.
Proposal 4:
I'm going to be honest, I am not sure what this means.
Proposal 5:
A live server image might work. The CoreOS install image is a live image, and that seems to work, but a live environment seems like overkill in the server space. I can't think of the last time that I used a live environment (other than when I installed CoreOS to see if it would work for my needs on the server) for installation. I do keep a KDE Live environment on hand for rescue purposes.
I do actually use the interactive setup options in the installer for my bare metal server setups, and I also use kickstarts for my server VM setups. I imagine that others that use Fedora to explore server stuff do the same. I'm not really in support of most of these proposals because Fedora Server is intended to support those workflows.
I don't think Anaconda has support for a per-product comps group filter, which would be required for filtering software sources. Also, if someone uses the "interactive kickstart" mode or adds additional repositories interactively in Anaconda, those composition groups can change based on additional repositories. That can be meaningful for someone doing an interactive installation.
I know of people who do take advantage of those options you want to remove, and I don't think it's meaningfully reasonable to drop them.
On Sun, Jun 1, 2025, at 3:43 PM, Peter Boy via server wrote:
== For years, we have been installing the same set of packages over and over again. We do not take advantage of the flexible installation options offered by Anaconda. And the current technical concept does not (any longer) provide for such optionality. We should check whether it would be advantageous and possible to flush a complete root file system instead. This would significantly speed up the installation process.
Off hand I'm only thinking of LiveOS being capable of this. Otherwise the root file system on the installation media is super minimalist, envisions only running anaconda, and doing RPM based installation.
Workstation has only one image, it's LiveOS based, and uses rsync to copy the root file system, excluding some things, and then making post-installation changes. Those post-installation changes are actually a pretty big time hit. I haven't dug down to see exactly what those tasks are and why they take so long. I know one is building two initramfs.
While the rsync copy isn't slow, it's not as fast as it could be. Using btrfs seed+sprout feature [1] it goes very quickly. Faster than dd.
I don't know if there's an equivalent in LVM, akin to pvmove, that could replicate a PV. I'd have to think a little bit about how to achieve an encrypted system. I think anaconda tends to make the LV the container for the ciphertext, not a plain partition, i.e.
partition -> PV -> VG -> LV -> dm-crypt -> file system
rather than
partition -> dm-crypt -> PV -> VG -> LV -> file system
[1] The seed is a Btrfs file system image with a read-only "seed" flag set. It can only ever be mounted read-only, and can't be modified. But a 2nd device can be added, made read-write, and then remove the seed - thereby replicating the contents of the seed onto the sprout - at which point the seed is removed, the sprout is a stand alone single device file system.
This can be the basis for performing the installation. But it can also be the basis for a rescue partition. That is, once the sprout is created, umount it, set it with the seed flag. That's your emergency partition. You could have a rescue boot entry that always boots this partition, and even uses something like `fstab=no systemd.volatile=overlay` which sends all writes to an in-memory overlay, similar to how LiveOS works.
There's quite a few ways to leverage this, including even seeds in series. You can have seed 1 image as server minmal, and then building from that, seed 2 image contains all the extras that make it a full server installation. If the user wants to install minimum, replicate from seed 1. If they want full, replicate from seed 2 (which implies also seed 1).
Using these btrfs based seeds to not prevent replication using rsync to a non-Btrfs destination. So you don't actually have to commit to Btrfs across the board to take advantage of some of the features. Including always on data checksumming, and compression.
Note, when replicating a btrfs seed having been created with compression, the compressed extents are what get replicated to the destination btrfs. There's no need to decompress then recompress. So it is faster than a regular copy would be in any case.
Further, it's plausible the seed images could be made available on a local network, and make it a future feature to perform many concurrent installations of server, with just small variations among them (such as hostname).
Good morning, friends!
#1: If we aren't going to offer more software selection roles besides "Server", then removing the option makes sense. It's basically a prompt that seeds the package group selection, and that can be done via kickstart. An administrator wanting to deviate from "Server" would probably do so via kickstart instead of the interactive installer.
#2: I disagree with the software source being superfluous, but I can see where the vast majority of the Fedora Server users aren't going to need this option in the "UI" so long as we can still have this functionality via kickstart. Specifying a local or offline mirror is essential when you are working in a disconnected environment, so using "the closest mirror" is not really an option. There are tons of reasons why someone would have such an environment in place, and removing the feature from the installer entirely means you are potentially removing Fedora Server from the small number of distributions where working offline is possible / "easy-ish".
Side note: The difficulty of working in an offline environment is also why I don't use any of the atomic desktops like Kinoite or Silverblue. When you go to install those in an air-gapped network they come out half baked because the systems rely on Flatpaks to provision user applications. Mirroring all of that stuff is another complicated mess compared to how direct and simple it is to mirror a yum/dnf repo.
#3: This is strictly my "work me" kicking in, but I disagree with the timezone being a post-installation task. The system needs to wake up knowing when and where it is. The administrator should be able to have installed systems "born" with a compliant state, and timezone configuration is part of that. I suggest we default it to "ETC/UTC", but still let the admin have the option of changing the value.
#4: Flushing a static root file system takes away flexibility. Installing that way may be quicker and advantageous for one scenario, but now we are again taking away the ability for an administrator to define a system state at "birth". I understand that folks in the Server WG may not have been using Anaconda's functionality in this way, but I do when I generate new templates (both at home with Fedora and at work with RHEL). Am I the only one out there doing this? Building the system from packages doesn't take very long, and I'm not entirely convinced that saving a minute or two on install time outweighs the benefits of being able to tailor the system (even if it's removed from the user interface portion of the installer and presented more as an 'advanced' feature by way of kickstart).
#5: ...Interesting idea. When I need an emergency boot disk, Fedora isn't the first thing that comes to mind. I go right for a Rescuezilla USB or CD. I'm curious what it is we'd supposedly offer that an already established project isn't providing to the public, keeping in mind that if we 'create' it, we have to 'maintain' it.
Regards, Paul Maconi
On Mon, Jun 2, 2025 at 12:47 AM Chris Murphy via server < server@lists.fedoraproject.org> wrote:
On Sun, Jun 1, 2025, at 3:43 PM, Peter Boy via server wrote:
== For years, we have been installing the same set of packages over and over again. We do not take advantage of the flexible installation options offered by Anaconda. And the current technical concept does not (any longer) provide for such optionality. We should check whether it would be advantageous and possible to flush a complete root file system instead. This would significantly speed up the installation process.
Off hand I'm only thinking of LiveOS being capable of this. Otherwise the root file system on the installation media is super minimalist, envisions only running anaconda, and doing RPM based installation.
Workstation has only one image, it's LiveOS based, and uses rsync to copy the root file system, excluding some things, and then making post-installation changes. Those post-installation changes are actually a pretty big time hit. I haven't dug down to see exactly what those tasks are and why they take so long. I know one is building two initramfs.
While the rsync copy isn't slow, it's not as fast as it could be. Using btrfs seed+sprout feature [1] it goes very quickly. Faster than dd.
I don't know if there's an equivalent in LVM, akin to pvmove, that could replicate a PV. I'd have to think a little bit about how to achieve an encrypted system. I think anaconda tends to make the LV the container for the ciphertext, not a plain partition, i.e.
partition -> PV -> VG -> LV -> dm-crypt -> file system
rather than
partition -> dm-crypt -> PV -> VG -> LV -> file system
[1] The seed is a Btrfs file system image with a read-only "seed" flag set. It can only ever be mounted read-only, and can't be modified. But a 2nd device can be added, made read-write, and then remove the seed - thereby replicating the contents of the seed onto the sprout - at which point the seed is removed, the sprout is a stand alone single device file system.
This can be the basis for performing the installation. But it can also be the basis for a rescue partition. That is, once the sprout is created, umount it, set it with the seed flag. That's your emergency partition. You could have a rescue boot entry that always boots this partition, and even uses something like `fstab=no systemd.volatile=overlay` which sends all writes to an in-memory overlay, similar to how LiveOS works.
There's quite a few ways to leverage this, including even seeds in series. You can have seed 1 image as server minmal, and then building from that, seed 2 image contains all the extras that make it a full server installation. If the user wants to install minimum, replicate from seed 1. If they want full, replicate from seed 2 (which implies also seed 1).
Using these btrfs based seeds to not prevent replication using rsync to a non-Btrfs destination. So you don't actually have to commit to Btrfs across the board to take advantage of some of the features. Including always on data checksumming, and compression.
Note, when replicating a btrfs seed having been created with compression, the compressed extents are what get replicated to the destination btrfs. There's no need to decompress then recompress. So it is faster than a regular copy would be in any case.
Further, it's plausible the seed images could be made available on a local network, and make it a future feature to perform many concurrent installations of server, with just small variations among them (such as hostname).
-- Chris Murphy -- _______________________________________________ server mailing list -- server@lists.fedoraproject.org To unsubscribe send an email to server-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/server@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Am 02.06.2025 um 15:57 schrieb Paul Maconi, Jr. via server server@lists.fedoraproject.org:
Good morning, friends!
...
#2: I disagree with the software source being superfluous, but I can see where the vast majority of the Fedora Server users aren't going to need this option in the "UI" so long as we can still have this functionality via kickstart. Specifying a local or offline mirror is essential when you are working in a disconnected environment, so using "the closest mirror" is not really an option. There are tons of reasons why someone would have such an environment in place, and removing the feature from the installer entirely means you are potentially removing Fedora Server from the small number of distributions where working offline is possible / "easy-ish".
OK. That’s a valid argument. We should retain that flexibility.
...
#3: This is strictly my "work me" kicking in, but I disagree with the timezone being a post-installation task. The system needs to wake up knowing when and where it is. The administrator should be able to have installed systems "born" with a compliant state, and timezone configuration is part of that. I suggest we default it to "ETC/UTC", but still let the admin have the option of changing the value.
If I remember correctly, in case of a working internet connection Anaconda determines the time zone. And, well, I think we’ll have some post-installation tasks anyway.
#4: Flushing a static root file system takes away flexibility. Installing that way may be quicker and advantageous for one scenario, but now we are again taking away the ability for an administrator to define a system state at "birth". I understand that folks in the Server WG may not have been using Anaconda's functionality in this way, but I do when I generate new templates (both at home with Fedora and at work with RHEL). Am I the only one out there doing this? Building the system from packages doesn't take very long, and I'm not entirely convinced that saving a minute or two on install time outweighs the benefits of being able to tailor the system (even if it's removed from the user interface portion of the installer and presented more as an 'advanced' feature by way of kickstart).
We have to retain the kickstart ability, no doubt. And with kickstart, a package by package installation path is mandatory. But do you start kickstart installation using the interactive installation medium?
#5: ...Interesting idea. When I need an emergency boot disk, Fedora isn't the first thing that comes to mind. I go right for a Rescuezilla USB or CD. I'm curious what it is we'd supposedly offer that an already established project isn't providing to the public, keeping in mind that if we 'create' it, we have to 'maintain' it.
Your caveat is entirely justified. However, I guess we can't include something like Rescuezilla in the Fedora distribution.
-- Peter Boy https://fedoraproject.org/wiki/User:Pboy PBoy@fedoraproject.org
Timezone: CET (UTC+1) / CEST (UTC+2)
Fedora Server Edition Working Group member Fedora Docs team contributor and board member Java developer and enthusiast
* Peter Boy Uni via server [04/06/2025 09:15] :
Your caveat is entirely justified. However, I guess we can't include something like Rescuezilla in the Fedora distribution.
There is a 'Security Labs' group in comps that contains system rescue tools that looks like it is no longer used. Perhaps we could leverage that.
Emmanuel
Timezone and user account creation are handled by a first boot setup application. - Unless we either force the use of Kickstart (I'm not in favor of this) *or* write a post setup first boot configuration tool, it will have to be something that is available in the installer for those that are doing an offline install with no kickstart file.
As for package selection: Any one who is installing a bunch of packages during the inital bootstrapping stage is using kickstart or they are going to do it with Ansible, bash scripts, or manually. I think removing the option for package selection and installing the default server-product-envrionment.
Additionally: if I remember correctly, there is a TUI version of the current Anaconda installer. Is this still going to be an option (possibly over SSH) going forward?
Jocelyn
In the meeting that we had on Matrix on 11-06-2025, those present discussed the needs of the Anaconda installer for the Server product. This is a summary of that discussion.
In the matter of removing the timezone option in Anaconda, it was decided to leave the functionality in the installer, possibly with defaulting to setting the timezo`ne to UTC. (current defualts are Americas/New_York if there is an offline install and geolocation based timezone selection for an online install.)
Another topic discussed was removing the software selection option in Anaconda. Defaulting to the 'server-product' environmenrt group brings our installer in line with other Fedora products and spins.
It was brought up that a lot of folks may not touch these options or will use kickstart to configure at install time; or something like Ansible to configure after the base install is done. Those options will remain available for advanced users as any changes to Anaconda are aimed at the average user who is installing on one or two machines, not a large number of machines.
Tracking issue on Pagure: https://pagure.io/fedora-server/issue/163 Previous discussion on mailing list: https://lists.fedoraproject.org/archives/list/server@lists.fedoraproject.org...
server@lists.fedoraproject.org
-
Chris Murphy -
Emmanuel Seyman -
Jocelyn Gould -
Jocelyn Gould -
Neal Gompa -
Paul Maconi, Jr. -
Peter Boy -
Peter Boy Uni