Feedback: Anaconda Web UI partitioning

[jkonecny (Jiří Konečný)]

Anaconda team is looking for feedback for the future change proposal about the new web UI partitioning solution. This is reaction on Issue #3169: Weigh in on installer storage setup issue - fesco - Pagure.io which is FESCO decision resulted in postponing the web UI from Fedora 40. Unfortunately, the ticket is missing requirements for having the FESCO and Fedora users satisfied. We would like to use this discussion to find out the requirements to satisfy FESCO and Fedora users and to be able to propose given change below.

Prepared change proposal: Changes/Anaconda Web UI Partitioning - Fedora Project Wiki

Anaconda Web UI partitioning

Summary

The Anaconda OS installer project needs to have a new approach for partitioning with the new web UI. This approach needs to be easy to control for users who don’t understand details of the Linux storage but still allows more complex requirements.

Detailed Description

This is separation of one topic from the Anaconda WebUI for Fedora Workstation by default change in Fedora. The storage part of the new installer UI was extracted here to start an open discussion of our solution, to collect feedback and get agreement with the proposed approach. Main reason for creating this change is to agree on a solution and to find feasibility for the next Fedora delivery.

With the current GTK UI of Anaconda we provide users three ways of creating partitioning.

• Automatic - select disks (optional encryption) and Anaconda will do everything else for you.
  • If disks are not empty a pop-up will show, which allows you to select what partitions you want to remove or preserve to free up space for the automatic installation.
• Custom - select disks and then you will get to an advanced screen where you design your output partitioning. This is the top-bottom partitioning approach where you design your mount points but do not have to care about how the final goal is reached.
• Blivet-gui - select disks and then design your storage from the bottom (bottom-top approach) by creating a partition on it BTRFS etc…
  • This solution was added later and its external tool integrated into Anaconda, not directly maintained by the Anaconda team.

However, with web UI we need to change this because technologies are different. When we are changing this, we would like to resolve old pains of the current approach. The current approach is great in being middle ground but in general, however, there are people who want to have something extra (top-bottom approach is not specific enough) but we also do not cover users, who don’t have much experience with Linux partitioning (use cases as reinstall my existing system). Another issue is that the Anaconda team size has reduced significantly from times when the GTK solution was created, so we are looking for solutions which are simple yet smart and easier to maintain and extend.

Our solution:

• Guided partitioning - this is a more powerful automatic partitioning where the user will select a goal and have additional customizations possible. The goal here is that most users should be covered by this guided experience.

  • Currently our implementation has three possibilities:
    • Reinstall all selected disks and remove everything that is on them.
    • Install into a free space on selected disks.
    • Use existing storage and assign mount points for the installed system.
      • Good option for reusing the existing partitioning.
      • Users can also create their partitioning ahead of time with any partitioning tool they prefer and use this option to just tell Anaconda how to use the partitioning.
  • We will extend the existing set of possibilities with the following list:
    • Reinstall existing system.
      • Users will have a list of existing systems installed on disks and select which one they want to reinstall (remove existing system and install to the same space).
      • Anaconda will replace root and should have a possibility to preserve /home with user data.
    • Easy way to reclaim space from the existing disks and start installation to the free space.
      • Similar approach to what we had on GTK UI.
      • It is simple and should cover a lot of cases in a simple way.
    • Based on the user feedback we would love to add more requested workflows.

• Cockpit storage - this is an external tool which is provided to the user, however, thanks to the fact that web UI and Cockpit storage are based on the same technologies, we are able to integrate Cockpit Storage into the Anaconda web UI. Please note, that it is still an external tool and shouldn’t be taken as part of the installation workflow. We are trying to make this obvious in the UI.

  • We have chosen the Cockpit Storage because it is using the same PatternFly and Cockpit frameworks as the web UI, so it has a consistent look and feel and allows us much seamless integration with Anaconda. Also Cockpit Storage can be used with remote HTTPS installations in the future. Users of Fedora might be familiar with this tool because it is already used in Cockpit, it is a stable and well maintained project.
  • Cockpit storage does not support action planning which creates controversy around this approach. All the actions done in the Cockpit Storage are immediately applied to the disk. This is a drawback compared to the current GTK UI, however, the approach as explained above should be used as the secondary option when you are not satisfied with the Guided partitioning and only for advanced users. This shouldn’t be taken as the main installation method nor part of the installation workflow.

Feedback

We unfortunately don’t have much feedback from the community yet, however, for that reason the FESCO decided in Issue #3169: Weigh in on installer storage setup issue - fesco - Pagure.io that we should have testing for feedback collection after Fedora 40 is released.

However, we were able to collect a bit of a feedback from FESCO members

• Cockpit storage is missing planning and immediate execution of actions feels unsafe.
  • Reply: We worked hard on notifying users that this is the case and users could lose their data (which applies to any partitioning method). Also this tool should be used only by the advanced users and ideally only to a smaller number of them. The guided solution should be the preferred one.
• What other tools can we use than Cockpit Storage?
  • Reply: To our knowledge there are no other tools for partitioning based on the same technologies as we are using for Cockpit Storage. Which is making the Cockpit Storage an obvious choice for us and enables us to also support this tool with remote HTTPS installations in the future.
• Why Anaconda won’t implement their own solution.
  • Reply: Reasons were already described above. Anaconda team size has reduced a lot recently and we are looking at ways to maintain less to be able to keep the project alive reasonably and not only for bug fixing. Implementing our own solution would take significant resources to implement and would increase maintenance costs.

Benefit to Fedora

Anaconda GTK UI partitioning solution is quite complex but it also could be limiting to advanced users. Our new solutions should simplify the process of partitioning for Fedora users by selecting what they want to achieve instead of how to achieve and leave the rest on Anaconda. On the other hand we also allow users to use external partitioning tools if they prefer.

Thanks to the fact that the Cockpit Storage project is maintained by another team, the Anaconda team should have more capacity to focus on other goals and priorities. As the outcome of this, Anaconda team should have more capacity for feature work and bug fixing of issues for the Fedora users.

The biggest benefit is the new guided partitioning. This approach should simplify installation a lot and provide a powerful tool for users who don’t bother about details but want to achieve a specific goal.

A few screenshots from the current web UI (Work In Progress)

Main storage screen with workflow selection

Cockpit Storage main screen

Cockpit Storage device details

Mount point mapping screen (pre-created storage or previous installation)

Review screen

[sgallagh (Stephen Gallagher)]

As I noted in the FESCo meeting and elsewhere, I think my concerns would be addressed if we:

1. Provide a guided option for the cases described above, as well as for resizing and dual-booting with an existing Windows installation.

2. Make it clearer in the UI that use of Cockpit Storage is destructive. Users should be advised not to touch it unless the Guided options are insufficient to their needs.

3. In the Cockpit Storage UI, there should be visible helper text reminding people that the final state will require a separate /boot and /boot/EFI partition, since this is very easy to get wrong.

[jkonecny (Jiří Konečný)]

Thanks for the list. This is definitely something we can improve.

However, we can’t resize new Windows installation because of bitlocker which is not yet supported on Linux land to my knowledge. So we can’t cover that. However, for standard resizing in level of what was supported in the GTK UI, we are already taking a look on that.

[sgallagh (Stephen Gallagher)]

Can we at least detect whether Bitlocker is in use and allow them to proceed if not?

If Bitlocker is present, we can probably gray out that option with an explanation.

[jkonecny (Jiří Konečný)]

We were thinking about solution similar to Ubuntu has which is to tell users that it is not possible in the installer and QR code with a link to the guide. However, not sure how problematic would be to detect this for us. So right now it’s TBD plan.

[barryascott]

@jkonecny

However, we can’t resize new Windows installation because of bitlocker

I have been adding fedora along side windows 11 on some laptops and forgot that bit locker issues.

Specifically I did not have the bitlocker unlock code available (see nice hole in my foot).

You may want to detect bitlocker and tell the user that they must have the bitlocker unlock code saved to continue booting windows after the fedora installation.

I reinstall windows 11
Saved the bitlocker unlock code
Used windows disk partitioning to shrink Windows partition
Booted the fedora workstation f39 usb install stick.
Installed using defaults into the unused space.
Cannot recall, at the moment, if EFI boot needed to be updated to boot Fedora by default or if that was changed automatically.

When windows booted it wanted the bitlocker code.
After entering once windows was happy to boot without code.

[garrett (Garrett LeSage)]

Thanks for your feedback!

We have had mockups for a while that address several of the points, and there are some new ones that address the “reclaim space” idea. I’m including a bunch in this post.

---

Cockpit Storage is supposed to show up in a modal with a dropshadow, background scrim, and an alert, as in this mockup:

(The styling of the alert bar at the top was different in the implementation.)

The sidebar already lists /boot as a requirement when you’re creating partitions. If /boot/EFI is also needed, then that should be listed there as well. When in BIOS mode, the required partitions in the sidebar include /biosboot.

---

Anaconda had a warning for blivet-gui in the Fedora 39 timeframe, which was necessary, as it launched a separate app. It could be repurposed for Cockpit Storage like so:

It could be brought back, if the visual styling of the Cockpit-Storage modal is not enough.

---

As for the first point, the requirements for inclusion for Fedora did not include that (as it was planned for and seemingly agreed upon for a future release), but I’ve implemented a “reclaim storage”. It’s been inspired from the GTK version of Fedora, but retooled a little, mainly to fit in better with PatternFly and to not have two different modes in the same UI. It’s been well received so far:

The way that it would be brought up could be from the list like this:

By default, using free space, when there’s enough free space, you’d see this:

You can then opt-in to reclaim space, if you want:

If there is not enough free space, choosing the free space option would always bring up the reclaim space modal dialog:

---

As far as being guided, we have that already, right from the beginning. There are options for using the full disk, using free space, and using (and reusing) existing partitions. I’ve revised the text for the last one of these to make it more clear.

The mount point mapping (“Use existing partitions”) is supposed to automatically detect all required partitions as well as /home, and set a reformat where necessary (for /, but not /home, for example). This would be a “best-effort”, as we cannot support all various random distributions, but it should work for Fedora (traditional and atomic), and ideally it should work for coming from Ubuntu too. This would handle the reinstall, upgrade, and cross-distro installs. The mount point mapping screen would still show up as a confirmation as well as providing a way to add additional mount points (if desired).

It looks like this when you select the existing partitions and have a previous Linux installation (I haven’t touched it since well before Fedora 39, but it is still relevant):

[tomh (Tom Hughes)]

As somebody that has pretty much always used the middle “custom” option I’d obviously be sad to see it go but assuming that cockpit storage can do everything I’m sure it will be a usable option for me if a little slower by having to build every individual item manually.

One thing in particular that’s useful with the custom flow is the ability to have it create a default layout so that you can see what current recommendations are for things like partition sizes even if you then scrap that and a build a different layout that encapsulates your preferences for other things - does the new proposal allow you to see what automatic mode would do and then go into cockpit storage to do your own thing?

If you’re wondering why I generally use custom rather than automatic then that would be things like wanting to be able to install to mirrored disks, want to be able to choose not to have a separate /home partition, wanting to be able to choose filesystem types etc.

[jlinton (Jeremy Linton)]

@sgallagh

Make it clearer in the UI that use of Cockpit Storage is destructive. Users should be advised not to touch it unless the Guided options are insufficient to their needs.

I’m not sure how to put this gently, but this is basically a violation of every single UI study/guideline ever published. Reversibility is a core tenant of UI design, and while I might tend to toss this under the, people should know what they are doing category, its also a DISK PARTITION utility, meaning a miss click can destroy data.

So if I were the PM on something like this, a batched summary like anaconda currently does would be basic criteria before it was allowed to see the light of day. Especially given the command line fdisk/parted/etc utilities can batch updates. For that matter, I would have also made the minimum requirement for a rewrite 100% feature parity but that’s just me.

PS: systemd-boot systems don’t actually need a /boot partition, they work fine with /boot being part of the rootfs as long as /boot/EFI is a FAT/ESP partition.

[garrett (Garrett LeSage)]

I’m not sure how to put this gently, but this is basically a violation of every single UI study/guideline ever published.

Having read many design books and studies over the past few decades (including running quite a few myself), I can tell you that’s not an accurate statement.

But it is a problem of mixing both active and queued UI paradigms, and I think that’s what you’re talking about. And that’s why Cockpit Storage is specifically not in the wizard flow and why there are some steps taken (and some more than can be implement) to communicate this better.

Reversibility is a core tenant of UI design

This is also not accurate, else nobody would ever be able to delete files, empty trash, format partitions, delete files, remove posts from social media, and so on.

You do always want to prevent data loss — and ideally, there would be an undo option whenever possible. But for some things, there really is no undo.

The “core tenants” of UI design are just a few famous general guidelines, and the most two famous lists are from Dieter Rams and Jakob Nielsen. (There’s also the Bauhaus list, but it’s more general, about art and visual design. Some of it applies to product design usability too. But it’s from the early 1900s, way before ‘undo’ was invented.)

Rams’ list of 10 is about product design in general (including UI/UX design): https://www.vitsoe.com/us/about/good-design — it doesn’t list reversibility or undo.

Jakub Nielsen does has one that can somewhat apply here: https://www.nngroup.com/articles/ten-usability-heuristics/

5. Error prevention: “prevent problems from occurring in the first place”; “Mistakes are conscious errors based on a mismatch between the user’s mental model and the design.”

But we do have some safeguards in place already, and, as pointed out above, have some additional ones that are being implemented. This includes visual treatment, an alert with text right at the top of the modal, and — quite possibly — bringing back the confirmation modal dialog prior to getting into the UI that is powered by Cockpit Storage.

Additionally, we could also make it less prominent (like have it only in the global menu) and also want to extend the functionality of the tasks (which we already wanted to do and we’re planning on doing it too).

batched summary like anaconda currently does would be basic criteria before it was allowed to see the light of day

Having it batched is literally what Anaconda does, even in the Web UI. Cockpit Storage is not really intended for general use; it is meant as an advanced tool that is included for the non-standard cases. You’re not really supposed to use Anaconda’s integration of Cockpit Storage unless you really know what you’re doing and aren’t covered by the typical installation methods. It’s supposed to be a rare occurrence.

This is why it’s not inside of Anaconda’s wizard UI, and why it’s supposed to be in a visual overlay (see above) and at the beginning, before stepping through the wizard. It’s meant to prepare the disk for the actual installation.

For what it’s worth: This is also very, very similar to how macOS installer works. They provide their own Disk Utility to prepare the disk for the installer, and it acts upon the disk in real time. (I don’t have a Mac, but I’ve seen it before in the past and you can try it out on Linux with quickemu if you’d like to easily see it yourself. Alternatively, you could look at Apple’s official guide about this. Except, they don’t have guided install methods; they’ll just use the whole disk if you don’t prepare it yourself in their Disk Utility.) They’ve shipped it like this since the start of Mac OS X and haven’t changed it much even in the latest version of macOS (as far as I’m aware).

I originally designed for it to be in the menu and only active before you select select a method of installation and click next. It probably shouldn’t be so prominent.

---

Why does Cockpit Storage actively work on your disk? This all stems from a limitation of how udisks works. Every other tool that Fedora ships that uses udisks also acts this way, including GNOME Disks.

With the standard cases covered by “reclaim storage” dialog and partition mapping supporting reinstallation back on the roadmap, I’m going to (once again) strongly suggest moving it back in the global menu only and have it only active prior to committing to an installation method.

For reference: The global menu mockup has been like this since pre-F39, with features we want to eventually support (most of these will not be there for a few more Fedora releases)… the important one to point out is “modify storage”:

PS: systemd-boot systems don’t actually need a /boot partition, they work fine with /boot being part of the rootfs as long as /boot/EFI is a FAT/ESP partition.

AFAIK; Fedora doesn’t use systemd-boot anywhere yet; it still uses grub. But if the sidebar doesn’t show things correctly when systemd-boot will be supported, that’ll be a bug in Anaconda, not an issue with the design.

[glb (Gregory Lee Bartholomew)]

@garrett

AFAIK; Fedora doesn’t use systemd-boot anywhere yet; it still uses grub. But if the sidebar doesn’t show things correctly when systemd-boot will be supported, that’ll be a bug in Anaconda, not an issue with the design.

There is a beta implementation of systemd-boot that can be activated by adding inst.sdboot to the Anaconda command line (but I think it only works if you use the network installer). Unfortunately, the current implementation does relocate the content that has traditionally been under /boot (the kernel and initramfs) to a new /boot/efi mountpoint. The spec for systemd-boot actually recommends leaving the mount point at /boot. I’d be game for reworking the Anaconda installer to use the traditional (and recommended) /boot mount point when installing systemd-boot if people are OK with that.

[jlinton (Jeremy Linton)]

@garrett

This is also not accurate, else nobody would ever be able to delete files, empty trash, format partitions, delete files, remove posts from social media, and so on.

I find your examples humorous since the trashcan metaphor was invented to reverse file deletion, and this very social media site can undelete comments. But, I was speaking largely of human computer interaction studies and UI guidelines developed from those studies not blog articles written by people who are expressing opinions or UI beauty standards. Which I’m sure you are then aware of the fact that reversibility is a real thing, and the reasons for it, and why it shouldn’t be ignored unless there isn’t an alternative.

Anyway, if all this remains a batched operation that takes effect at some later point (ex: during final install) then I guess I’m misunderstanding all those warnings about changes taking effect immediately. But, that sorta begs the question of why they aren’t later warnings to the effect “hey it looks like your deleting an active windows/whatever install are you sure”.

[sgallagh (Stephen Gallagher)]

Anyway, if all this remains a batched operation that takes effect at some later point (ex: during final install) then I guess I’m misunderstanding all those warnings about changes taking effect immediately. But, that sorta begs the question of why they aren’t later warnings to the effect “hey it looks like your deleting an active windows/whatever install are you sure”.

No, I think you missed what Garrett was saying. The Cockpit-Storage based approach is essentially a separate process that you launch and it DOES make real-time changes. However it is not the normal operation of Anaconda. In most cases, you are expected to just let Anaconda make the best choices. This is the “Guided” operation. You select one of the common approaches that Jiří described and Anaconda handles it in a batch.

However, some people prefer a hands-on approach to partitioning where they pick everything. This is the alternative “expert” mode that Garrett is describing. While I agree that it would be preferable that we had batched updates for the “expert” mode (and the current GtkUI has this), there are limitations to the udisks technology that Cockpit-Storage is built upon. It makes changes “live”. Maybe this can be enhanced in the future, but for now we’re limited in what it can do.

If we assume that we have to work within these strictures, the best option is to ensure that users are made very clearly aware that: 1) they probably shouldn’t be using this tool unless they absolutely have to; they should use one of the recommended and fully-tested guided paths. 2) If they do use Cockpit-Storage, it needs to be very clear about the dangers before they start hitting buttons.

[zbyszek (Zbigniew Jędrzejewski-Szmek)]

@garrett

PS: systemd-boot systems don’t actually need a /boot partition, they work fine with /boot being part of the rootfs as long as /boot/EFI is a FAT/ESP partition.

AFAIK; Fedora doesn’t use systemd-boot anywhere yet; it still uses grub. But if the sidebar doesn’t show things correctly when systemd-boot will be supported, that’ll be a bug in Anaconda, not an issue with the design.

There’s a lot of confusion here.

First, /boot/EFI is most likely (*) confusing /boot/efi with /boot/efi/EFI. The ESP is often mounted on /boot/efi, and it usually has a /EFI directory in the root of the partition.

systemd-boot has a concept of two “boot partitions”: the ESP, which is required by firmware and therefore will exist on all EFI systems, and XBOOTLDR which is an optional second partition to be used as a storage area for kernels. XBOOTLDR is only needed in one case: we are installing to a system which already has the ESP and the ESP is too small and we cannot enlarge it.

Ideally, we’d mount the ESP to /efi and XBOOTLDR to /boot if both exist, or ESP to /boot otherwise. Think “/boot is the place to put kernels”. The other option is to use nesting like /boot and /boot/efi, but this means that we cannot use automounts for point partitions, which we really want to do.

So it’s not really good to say that “systemd-boot systems don’t actually need a /boot partition” — generally, we always want something to be mounted on /boot. In most cases we don’t need the second partition and the ESP shall be mounted on /boot. But in no scenario does it make sense for /boot to be part of the rootfs.

Also, the ESP is generally expected to be VFAT and XBOOTLDR too, if it exists.

EDIT: (*) When /boot is VFAT, then it’s case-insensitive, so in principle we can use paths like /boot/EFI/EFI or /boot/EFI/efi, but that just adds more confusion

[zbyszek (Zbigniew Jędrzejewski-Szmek)]

@jlinton

Reversibility is a core tenant of UI design, and while I might tend to toss this under the, people should know what they are doing category, its also a DISK PARTITION utility, meaning a miss click can destroy data.

I’m with Jeremy on this one. All the warnings and click-through dialogues are crutches. Anaconda has an overall queue-and-accept design, and we’re talking about inserting a part in the middle that follows a completely different paradigm. What is baffling is that we already had an installer that was doing queue-and-accept partitioning and was quite well liked. So the current approach takes us 10 years back in the development of probably the most important part of the installer.

I’m confused about the priorities that are being followed. The new installer is (IMO) quite pretty, but that is really secondary to the functionality. Many people use the installer very rarely, e.g. once for new hardware, and a bit of visual clunkiness is not much of a deal.

@tomh

One thing in particular that’s useful with the custom flow is the ability to have it create a default layout so that you can see what current recommendations are for things like partition sizes even if you then scrap that and a build a different layout that encapsulates your preferences for other things - does the new proposal allow you to see what automatic mode would do and then go into cockpit storage to do your own thing?

That is how I always used the installer: use the default layout as the initial proposal, extend it with one or two local modifications that I need.

I’m not sure if/how that works in the new installer. Looking at the mockups, I’m not sure what modifications can be made without going into the cockpit partitioning. I should try the latest version…

[garrett (Garrett LeSage)]

@zbyszek

we’re talking about inserting a part in the middle that follows a completely different paradigm

No, we’re not. We’re talking about something that is not part of the normal Anaconda flow and it’s at the beginning.

The normal Anaconda flow is all queued up. Look at the mockups and what I shared above.

The Cockpit Storage part is only intended as a tool at the beginning to let someone directly modify their storage situation in case they need or want to do something that is not typical. In almost every case, people really shouldn’t have to use it.

That is how I always used the installer: use the default layout as the initial proposal, extend it with one or two local modifications that I need.

What are the specific “one or two local modifications” that you do?

[supakeen (Simon de Vlieger)]

There seems to be a lot of discussion around the secondary issue of ‘how should it look’. The core thing to address here is that Anaconda and other distribution installers generally work through a plan-then-apply and that partitioning tooling on an already installed system is generally immediate (Gnome Disks, those sorts of things).

A lot of crutches get brought up leading to huge UX discussions: warnings, undo, where to place things so fewer people see them.

Anaconda used to be able to do this, why can’t we do it now. What is the technical reason for not being able to do plan-then-apply. Why is udisks usage mandatory? Did Blivet stop existing?

The WebUI is a huge improvement in the overall installation experience but the disk management is a regression in this shape and form.

[jkonecny (Jiří Konečný)]

More and more I’m reading I agree with Garret that people are getting confused. I wrote it by bold letters in the proposal and we are repeating it again and again. We don’t have custom partitioning, however, we support people to use external tooling (any external tooling they want) and because Cockpit Storage is the only one we can provide easily we are using that as one of the possibilities.

Anaconda is still plan and execute with the begging of the installation. That is the guided partitioning. As mentioned multiple times here, Cockpit storage is not part of the workflow and it is not intended to be.

[jkonecny (Jiří Konečný)]

@supakeen

Anaconda used to be able to do this, why can’t we do it now. What is the technical reason for not being able to do plan-then-apply. Why is udisks usage mandatory? Did Blivet stop existing?

First, we still use blivet as library for partitioning, that doesn’t change. We just don’t use blivet-gui, for three main reasons:

• It can’t be integrated for remote HTTPS installations because of GTK technology
• It can’t be reasonably integrated into web UI because of the GTK technology
• Blivet-gui is developed by one person who maintain this as pet project, he don’t want to maintain it in RHEL

@supakeen

The WebUI is a huge improvement in the overall installation experience but the disk management is a regression in this shape and form.

I don’t agree with you. I guess this is again an example of how people completely ignore everything else except Cockpit Storage.
Please feel free to say I’m not correct here.

[supakeen (Simon de Vlieger)]

@jkonecny

First, we still use blivet as library for partitioning, that doesn’t change. We just don’t use blivet-gui, for three main reasons:

• It can’t be integrated for remote HTTPS installations because of GTK technology
• It can’t be reasonably integrated into web UI because of the GTK technology

My internal confusion is rising. Anaconda both uses blivet and doesn’t use blivet. I understand that blivet-gui can’t be used since it draws GTK things, but blivet-the-library can and is being used. Could a frontend be created on that in the framework of the WebUI? It seems to already have initial DBus bindings that are incomplete.

• Blivet-gui is developed by one person who maintain this as pet project, he don’t want to maintain it in RHEL

blivet, blivet-gui, and udisks all seem to live under the same GitHub organisation. If this is a concern then it likely is also a concern for cockpit-storage.

I don’t agree with you. I guess this is again an example of how people completely ignore everything else except Cockpit Storage.
Please feel free to say I’m not correct here.

Not entirely sure what you’re trying to say. I really enjoy the new installer, it’s very pretty and smooth.