Feedback: Anaconda Web UI partitioning

I install Fedora specifically Standard (no LVM), without /home, XFS root, and root resized to full-size. That requires a fun button press sequence in Custom (not Blivet-gui). I looked at Blivet-gui once I think on F39 and it didn’t appear I could do the same convenient GUI set-up like Custom, so I didn’t proceed with it.

I know I don’t want LVM, Btrfs, no separate /home, and expect root to take up as-much space on the disk as possible after auto-reasonably-sized essential partitions (/boot, ESP); I have no time for games and traditional Standard partitioning works fine. If I have to calculate any kind of disk space/byte value to make that set-up, I won’t bother installing the distro (I’d be on Arch with fdisk and pen-and-paper if I wanted to deal with that :stuck_out_tongue: ). I can do that with Ubuntu and openSUSE TW today through easy GUI, and Fedora with the GUI Custom partition install option, so any changes with Anaconda need to continue to offer that!

I believe there’s also a web UI for the libstorage-ng partitioning system that Agama uses. It does support the action plan/plan-then-apply strategy and they have implemented this in Agama.

Has there been any discussion with the Agama/YaST team about making that component reusable for Anaconda?

I wasn’t aware of that, however, our priority is to have consistency between CentOS Stream / Fedora and RHEL. I don’t think there will be someone willing to take over maintenance of libstorage-ng on RHEL side.

In any case, because we are taking Cockpit Storage as external tool I don’t see a reason to not have storage-ng web UI next to the Cockpit Storage solution as another external tool. However, we won’t take on ourselves maintenance burden so if it will be taken as critical component with blocker bugs it will be on libstorage-ng maintainer on Fedora to deal with it or it will be hidden/removed in Anaconda.
In other words, I’m leaving support and implementation of this on community.

This change proposal has now been submitted to FESCo with ticket #3272 for voting.

To find out more, please visit our Changes Policy documentation.

[I know this might not be the best place to post this, but I don’t see a better one.]

I wanted to take a fresh look at the WebUI installer. I did a fresh install and a re-install over a previous install using installation ISOs in a VM. Some unstructed notes below and then a summary/evaluation.

Ubuntu with subiquity (ubuntu-24.04.1-desktop-amd64.iso)

  • A linear flow with a very good toolkit. Visually this looks great.
  • The installer uses the full window provided by libvirt, does not need resizing.
  • The installer boots very quickly.
  • Plays a sound when the installer is up, a nice touch for accessibility.
  • There’s a “accessibility settings” panel early on.
  • “Ads” are displayed very well and showcase various games and tools.
  • Features a stop button that has no effect.

Advanced partitioning:

  • not able to create & mount a /home subvolume?
  • clicking ‘back’ loses the configured partition layout
  • a spectre vda2 1MB partition is inserted with no type, name, or explanation.
    (This is probably a biosboot partition, but it’s displayed very badly.)

Guided partitioning:

  • offers a limited set of choices
  • encryption seems to be only an option with LVM, so the modern encryption + btrfs does not seem to be an option
  • LUKS password is not tested for strength (user password is)
  • description of steps is only partial: “partition vda2 formatted as ext4 used for /boot”, “partition vda3 created”

Fedora WebUI installer (Fedora-Workstation-Live-x86_64-Rawhide-20240927.n.0.iso)

  • “Destination 0x1af4 (vda) 21.5 GB disk”.
    I tried to figure out what 0x1af4 is, to no avail. Doesn’t match the block device number.

  • The curse of mandatory password strength requirements returns.
    “Must be at least 6 characters”
    (But at least “weak” is allowed.)

  • Display of subvolumes is not great:
    “/ vda3 20.4 GB format as btrfs encrypt”
    “/home vda3 20.4 GB format as btrfs encrypt”
    If one doesn’t know that the default setup uses subvolumes, this looks like an error.

  • Going back loses state!
    Password is forgotten.

  • “Language: English (United States)” is automatically selected without any choice.
    If the language can be configured later, then this should probably say so.
    But it’s not clear what keymap is used for the LUKS password.
    (Later: it’s always “us”.)

  • Storage editor is very well hidden under a three-dot menu

  • The disk is displayed as “unformatted data”. Clicking format
    open a dialogue to format /dev/vda (whole disk) as ext4 (sic).

  • The requirement on password length is not present here.

  • Strength of password is not shown.

  • I see “Encryption options” free text field. Who knows what that is for?

  • On an existing partition, shrinking or growing is not supported.
    “btrfs cannot be resized”. ??

  • The installer actually displays subvolumes as such, nice.

  • It doesn’t seem possible to create a subvolume.
    “Subvolume needs to be mounted”.

  • After mounting, the subvolume can be created, but it’s not obvious.

  • "Critical error
    The installer cannot continue due to critical error.
    Error details:
    TypeError: n[A] is undefined
    "
    That is followed by journal dump for the boot.

  • Report bug opens (I think) a firefox window to log in to bugzilla.
    After typing (maybe?) a wrong password, I see “Please press Back to try again.” but the window has navigation hidden, so there are no buttons.

  • After logging in, there’s a prefilled bugzilla ticket, with the text “Please attach the log file /tmp/webui.log to the issue.” which I guess the user is supposed to do manually.

  • Bug 2315891 filed.

  • After submitting bug, the window stays open fullscreen.
    The user has to figure out how to switch back to the installer.
    (Not that it does much good, since the only option is to quit.)

  • After the installer exits, I see that /dev/vda1 with LUKS was created, but I cannot open it. The password was “asdfasdf”, so I don’t think it’s likely that I made a typo in the passphrase. Instead, maybe the password wasn’t actually set?

  • Of course reboot fails because the disk is not usable.

  • A second install succeeds. (I know what to avoid.)

  • After a reboot, the boot seems very slow.
    I see “Process 1345 (abtrd) of user 0 dumped core.”
    Oh, "Failed with result ‘timeout’.
    Also “Failed to start app-gnome-vmware\x2duser-2758.scope”,
    “no such process”. (I think it’s an known bug.)
    Those are problems not with the installer, but with rawhide itself.

Reinstall

  • After a reboot and selecting to erase existing data, I see “vda1 delete”, but new partitions are numbered from vda2.

  • No warning about using a prerelease installer.

  • I also tried if preserving /home works.
    This doesn’t seem possible? (“Reclaim space” works at the level of partitions. In “Manual disk configuration” I can assign mount points, but it seems like I need to select “Reformat”. It doesn’t seem to have a concept of only deleting the subvolume.)

    It's difficult to reformat a btrfs partition/subvolume in the installer

  • The display of subvolumes and partions is … bad.
    I have to guess that “vda2” is a partition, and “root” is a subvolume under vda3.

F41 beta (Fedora-Workstation-Live-x86_64-41_Beta-1.2.iso)

  • Language can be selected

  • The interface seems rather confusing and cluttered.
    Esp. after coming back from the very clean Ubuntu.

  • vda is described as “0x1af4 ()” :frowning:

  • A detailed preview of operations is shown

  • “Disks will not be modified until ‘start installation’ is clicked”
    (approx. text, reverse translation from Polish)
    Very clear and welcome.

  • After clicking “stop installation”, Anaconda exits, but stuff
    is still happening in the background. Subsequent start of Anaconda
    hangs.

  • When doing “automatic partitioning” with “remove existing data”, I can
    select what should remain. Existing partitions are not wiped until
    I click “Begin installation”.

  • When redoing interruped installation, the next install fails with
    “luks device not configured” and Anaconda hangs.
    ‘“Install to Hard Drive” Is Not Responding’ pops up.

  • Starting Anaconda again fails. Next attempt works.

  • This time I selected “Remove everything” and installation succeeds.

  • I also tried a repeated install to test if preseving /home works.
    The same as for the WebUI installer, this just doesn’t seem possible?
    When I try to assing existing “root” subvolume as new root,
    it says “You must create a new file system on the root device.”
    and refuses.
    The best option I could find was to create a new root subvolume.
    After reinstallation, I’m asked to create a user, and end up
    with /home/$olduser and /home/$newuser owned by $newuser.
    Meh.

  • When I unlock Luks partition, a dialogue is shown that Anaconda is not
    responding for a few seconds. Then it goes away.

  • “vfat cannot be used for /boot”, bollocks.

Conclusions

The new Fedora WebUI and Ubuntu’s subiquity seem to share the same general UI concepts. The linear workflow with panels and next, next, next… is very clear. Even if there’s a bunch of those, the user can go through them very quickly. This seems a win over the previous Anaconda design. Nevertheless, it’s very important to never lose state. Every time I clicked “back” to check some setting from an earlier panel and lost state, I was very annoyed. If this was an actual install with real data and long passwords, that’d be even worse. Thus, linear series of panels is good, but state must be carefully maintained.

Accessibility in Subiquity seems to be core design feature. (I didn’t actually try any of the accessibility features, so no idea if they actually work.) Previous Fedora installer had internationalization of the installer, this seems gone with WebUI.

All of the installers display crucial information about disk state badly. They just differ in what parts are particularly bad. It is clear that subvolumes were added later, so instead of saying something useful like partition vda3, type btrfs, subvolume "root", Anaconda says "root" and leaves the user to figure out what it means and which of the 5 meanings of word root is meant here. In other places, subvolumes are displayed alongside partitions with no visual distinction.

A killer feature for people who upgrade Fedora Workstation is to keep /home subvolume and reinstall the OS in “root”. With a bit of manual twiddling this can be done, but the installer doesn’t help in any way. It seems that no consideration for this very important workflow has been made.

Each of the installers has various bugs. Just trying to set up a simple setup with a standard layout is enough to cause a crash. If anything goes wrong, any any changes have already been made, the user is left with a half-installed system. (The problem is worse with an installer that applies changes immediately.) Each installer has some random limitations, some of which can be worked around because the checks are not applied uniformly. Subiquity guided partitioning only supports a few legacy layouts that they care about (LVM, ZFS), a Workstation-like layout with btrfs and encryption would require manual configuration. Anaconda supports btrfs, but halfheartedly, it also doesn’t allow VFAT for /boot for bogus reasons.

In the Fedora context, the big question is whether “old anaconda” or the new WebUI is better. Based on my tests, I would say that visually, WebUI is better. (Though Subuiquity looks even better.) Nevertheless, the functionality in the old installer is better. There is nothing in the new installer that makes me say “oh, this works much better then before”.

1 Like

Yikes, this is really bad. If the keymap during setup doesn’t match the one after installation, users will potentially be locked out of their freshly installed systems.

It’s not that bad. The same keymap seems to be used when the password is set and later when it is checked. There just is no indication initially what the keymap is. During the query, a little icon indicates the keymap. A much bigger problem would be if a different keymap would be used, but in my testing that didn’t happen.

For what it’s worth, the behavior you described you didn’t face, does sound a lot like 1890085#c42 discussing F40, the original issue of which appears as prioritized in F41 blockerbugs page.

From the issue, it does sound like the new linear flow would have resolved this, and the fact you didn’t face it sounds encouraging.

I do not know the specifics of it, I was just browsing the blockers the other day and thought it could probably be relevant (?) to what you are discussing.

Language selection is problematic ATM because the intent on Workstation live is that you will do language selection outside of anaconda itself, as part of a tailored gnome-initial-setup flow. This requires extensive changes to various bits of GNOME upstream, and those patches have been caught up in upstream review for months. We were carrying them as downstream backports for a long time, but the maintainers got tired of doing that and dropped them in the 47 rebase, so this is now all broken.

Basically, it’s not anaconda’s fault, but it does need solving before we can land newUI.

MRs I’m aware of (there may be others):

2 Likes

It’s slightly more complicated than that. There’s also a request for all supported Wayland compositors in Fedora to add a mechanism to listen for locale1 updates triggered by Anaconda.

For the release-blocking desktops, Fedora KDE supports it as of Plasma 6.1, and it’s enabled it in the KDE live session. A ticket has been filed with GNOME for it, but no progress has been made on it yet.

For the non-blocking environments, there’s an implementation for Sway and in COSMIC. Mir is working on it and Weston has it planned for v15. It’s also planned for Budgie’s upcoming Wayland environment too.

There’s also a component for doing this on X11 live environments too.

That’s about the port to Wayland, not about the new workflow for Workstation live that’s been designed around webUI. The Wayland port is happening separately from webUI. (In fact, the new workflow for Workstation live would make that issue irrelevant in that particular configuration as you would set keyboard layout in the g-i-s flow before reaching anaconda).

That is true. However, if possible I would like to make the solution consistent everywhere. So hopefully everything in the future will use localed instead of custom solutions. That won’t happen anytime soon.

As said above, this won’t happen for F41, so yes, if G-I-S is again enabled the language selection will be set by G-I-S (as said Workstation SIG requirement) and Anaconda will only inherit the configuration of the system.

Thanks a lot for sharing your feedback. It’s really valuable for us.

A few notes from me:
I don’t blame Ubuntu installer to support only a subset of the storage options (LVM). It’s quite complex to get everything together where each of the technologies behaves differently.

The 0x1af4 name is long standing issue. I don’t remember the details and can’t find it out but it happens only in VMs and I have a feeling that some of our dependencies (under blivet) returns this as the disk identifier. Unfortunately, Anaconda is not able to resolve that.

For the /home reinstallation. Radek our team member is working on a workflow for enabling this easily in Web UI.

They have been progressively adding the storage options back. Originally it didn’t even support ZFS or LVM. I believe they intend to have full support of Ubiquity storage options by the time the next LTS rolls around in 2026 (26.04).

It only makes it irrelevant for Workstation if that new flow is used. Fedora ships more than Workstation and so we still need all that stuff to work.

1 Like

And if you’re not planning to use Gnome, what happens then? The installation is supposed to be DE agnostic.

Then something different will happen. But the plan has always been to enable newUI only for the Workstation live at first.

There will a be a language chooser as the first screen of the installation. It is already implemented but Workstation SIG don’t want to have it there because of GIS.

if it’s already implemented, we might want to turn it on in Rawhide for now, at least until the g-i-s flow is fixed.

This is a fantastic post! Lot’s to consider there that I’m1000% sure that I’d never be able to to test myself.

All I can say about this one aspect is: Wow. That one is an absolute mind-boggler.

Thanks!