I think writing something from scratch for anaconda on ourselves and without immediate involvement of the anaconda team itself is not realistic. Beyond the question who will write it, if we add it to what we ship to users, it needs to be reliably maintained, and I think that goes towards a big effort and much need of organization and providing prove before FESCo would accept it (for good reasons).
I would stick with what is already available and reliably maintained (incl. dependencies) in our repos, and that just needs just to be added (+ later maybe removed again) in simple ways to web-ui, in collab with anaconda, without it having relations / impacts beyond the “text that contains the link” (so to speak).
I’d trigger @bookwar and ask, if she has a moment time, if anything contained in the posts after the post of Neal can be useful / realistic and worth a discussion. Otherwise, we keep speculating
Let me put it straight: the current version of Anaconda is working.
I asked you personally to come up with specific issues. @lruzicka has kindly offered help for anyone who has a specific example for a issue not tested, so that he can go check it as Fedora QA.
You haven’t come up with any actual request. Instead you are bringing claims like this. Please stop doing it, it is not useful, unnecessary exaggerated, and harmful.
And no, there is no way to go back to GTK3 interface. There is a way forward, and it is to work together to prioritize specific use cases and discuss issues, while keeping GTK3 UI as an available fallback option for as long as needed (and as GTK3 is there).
This is what we are doing here, and you are not helping.
This is technically what Anaconda WebUI is doing right now. With the “advanced partitioning tool” being Cockpit Storage Editor.
If there are good other options for the storage editor we might use them. Depending on the dependency footprint and so on.
You can also use any other partitioning tool while running a Live image, before starting the installation. For non-live environment the question is trickier, but we are not using WebUI there yet.
You can contribute to the Anaconda itself expanding the storage screen. As I mentioned above we do not reject the idea of adding more guided paths and more options to them. It would require some work and discussion, but it is possible.
For the current team priorities - we are working on Networking configuration, partial kickstart support and the remote installation.
There is no reported case of a partitioning, which can not be created manually by the Cockpit Storage Editor so far. All the reported cases talk about how it should be done easier and less manual
Thus the improvement in Storage options can not be prioritized above those three features.
And that’s a five minute search, not a real gathering of issues.
This is not going to improve until you and RH devels finally understand that desktop users ARE NOT GOING TO FILE BUG REPORTS. You can have all the server users and the premium, Ultra pro suscibers of RHEL you want, but this is Fedora, a community of desktop users, so no, the new anaconda is not good enough
Being unable to invest more time today (sorry), I might follow up in the next days, but for now just would like to remind everybody that we all work to make Fedora better, even if our approaches and points of view might differ.
As preventive measure, I enable slow mode (1h): I know that most people involved here can bypass it, its more an incentive, but you might want to choose voluntarily to keep the slow mode pace It can be helpful to make posts more constructive, focused and valuable.
The first issue you are pointing to was a known bug which existed in the pre-release version of Fedora 43 (if I remember that correctly) and it did not appear on the Final ISO.
I am not sure about the second one, but it also looks like a possible bug and if reported it would have been fixed (it is probably fixed now because I am not seeing any such messages during installations).
You are saying that desktop users will not report bugs. That’s not optimal, but nobody is required to report anything. There will be somebody who reports it finally.
However, the earlier a bug gets reported, the earlier it gets fixed. And those who do not report will have to wait until somebody does it.
Fedora Quality has a Matrix channel where you can drop in and leave a note about issues you are having and somebody will gladly take a look and report it, if you can’t do so.
Aha! So if there is a partition use case that is not covered already, then work needs to go into the cockpit storage editor. That’s good to know.
But as you say if no one has a use case that is not already covered then it seems to me that it’s a case of documentation of use cases so people can be guided.
I pointed to a incomplete manual and made some adjustments. Linking to that would help about to know how the default looks like about the boot partition and the default layout in general. It is just missing to make a link.
As an alternative we could use a welcome screen on the Iso to guide users to Manuals and topics which give more explanations, how to deal with the new installer.
I think it can go in different directions. Or get stuck in between
Consider example - give user a possibility to do the full automatic partitioning without BTRFS. It is a one-click option to apply a certain autopartitioning schema which Anaconda backend already knows quite well. It could be added to the main storage configuration screen in the Installer for a user to choose.
But the example: give me the easy way to create a boot partition, but then let me edit the rest. This probably is better suited for the Cockpit Storage Editor, because adding a valid /boot partition is just a one action in the overall editing process.
There is also a problem with the create partitioning first and edit later, because the installer way and the Cockpit Editor way of dealing with partitions is different. Installer postpones the actual change till the start of the installation process. And Cockpit deals with edits in real-time.
Which means you can not easily create some schema through the installer and then hand it over to Cockpit Storage for editing.
I invest my break for this post, not because of any one side in this debate is right or wrong (my today’s break is not long enough ) but because I would like to add a perspective to one point and put it into a wider context (maybe that’s useful for the wider debate?):
I would not ask you to challenge your decision about prioritization, but maybe to challenge the underlying reasoning that led you to this decision, because it might be contrary to the current Fedora strategy and its goals (which I think you co-designed?) → increase the amount of contributors largely.
For a user (including most contributors), it does not make a difference if you did not implement the partitioner or if they cannot find it: it’s not available to them in both cases → effectively a denial of service. That’s all that counts for them → it does not matter if the origin of the DoS is social, organizational or technical, as they don’t have that information anyway.
Having no partitioner available can deter a user from installing Fedora, and thus from engaging increasingly with the community. For some it is annoying and they might need to resort to manually install and use other tools, and then find a way to get web-ui using them the way they want, which takes time and efforts. Other users might be not able to do this at all: not everyone who needs custom partitioning is well experienced in the environment and command lines in order to consider this a straightforward task. Some might not want to invest the time/efforts, others cannot.
The installer can have a huge impact on contributors joining the Fedora community (I assume having an installed Fedora is often/mostly the foundation of contributors joining the community), and it can deter them (or depending on the knowledge & needs they have, force them to not install it).
The strategy, afafik, is to strongly increase the amount of contributors: is this reasoning of prioritization (I simplify & exaggerate: “partitioning is technically available, so priority is what is not yet technically available”) aligned with the strategy to increase the contributor amount strongly?
Personally, I joined “Linux” (I simplify) when I was 12 or 13 or so, and my knowledge was far below it is today: I learned much in the communities, I think even most I know today in terms of technology etc. And I think I can say I also contributed much also to technical issues until today. But in order to develop the knowledge, I needed to first get a Linux installed and start playing with it, and then slowly get into the communities.
Therefore, the “first installation” user experience was critical to satisfy the demand of someone interested in exploiting what is technically possible, but who was still learning and not intuitively getting all relations due to a lack of understanding of what is going on in the back.
I don’t remember my first installation, but given what I roughly knew at the age when I migrated to Linux, I think there is a chance I was already playing with file systems and checking in advance what I find on the Internet about what to use, but I am not sure if I would have got the understanding to start doing all that on the command line myself and know if/how that can work with web-ui or what implications there are (if not being even deterred by doing command line stuff and then rely on what I have done on a OS I have to entrust my data), which leads back to: is the reasoning of the prioritization aligned with the strategy?
That’s not a right or wrong question, and my points here are absolutely subjective and largely assumptions rather than facts, but maybe worth to be read
@py0xc3 suggested to create LVM through a gparted instance, but it is not necessary as
Anaconda WebUI is capable of an LVM set-up.
On the Installation method screen, click on the hamburger menu in the upper right corner and launch the storage editor (cockpit storage).
In the storage editor, there are more hamburger menus to deal with partitions (no LVMs, just regular partitions). On the right hand side, you have some info about the minimally required stuff - on an EFI machine, you need at least the /boot/efi partition and a /boot partition is recommended. You can create those partitions by clicking the hamburger menu in the corresponding space.
To create something more advanced, such as LVM or mdRAID, click on the three-bar menu in the upper right corner which gives you the options to select LVM to proceed.
First, create a physical volume in the empty space of the disk (after you have created the boot partitions), then create a logical volume for your partitions. At least one is compulsory to place the / partition, you can also have a separate /home or anything you wish.
When formatting the partition, you can set up encryption.
When you have created the layout of your choice, click Return to installation and the storage editor checks if you layout is valid. If it is, click Continue and you arrive at the installation screen in the main Anaconda application.
Now, Anaconda switches the installation method to Use configured storage and when you click on Next, the installation will start. After a while, the system is installed.
I had a bunch of screenshots to illustrate this workflow but it seems I cannot upload them here. Pitty.
I don’t think this is the place the majority of users would end up when they have a related issue The focus in this topic is more strategic I think anyway, not suitable for tackling individual cases
No I did not. Please interpret my posts in context. We were discussing easy-to-implement-in-anaconda alternatives IF the anaconda partitioner is not suitable/accessible for users for whatever reason (and I also mentioned I am not sure if gparted can do that at all with lv and vg etc). I did not question the IF in the very post, but tried to help find a solution for preceding posts.
Maybe something like “partitioning tools”? I would somehow involve the term partitioning or so. Especially if you want to raise awareness again to the field that is there from the beginning of the installation (that itself is a confusing element I think). If there is “additional tools” from the first window of the installation (as the three dots atm), I am not sure if users (or me) would intuitively link this to the storage section
Indeed, documentation can solve much. But we have to be aware users using the installer must have immediately the possibility to find it: including users who just install Fedora for the first time, who might not even know this forums.
I created a topic in ask.fp.o to collect specific use cases as a howto. I made a wiki so it is possible to edit it. @lruzicka feel free to edit your Blockquoted text I moved there. I guess you can also try to upload the pictures there. You are probably not allowed to upload because you not have enough rights in workstation-wg .
The topic is hidden for the moment (TL4+ can release it), it can be accessed over the link below. So as soon we do have a nice list we can release it for the public. Just as a answer to @rhea and others questions.
As I mentioned on the top of the topic, it is not for complains, it is for existing solutions and workarounds till we do have a official documentation for it.
Simple user has Next-Next-Next installation flow → we need more features because what if a user wants something non-default → then the user needs to read docs → but it is a simple user, who doesn’t know that docs exist → then they should use simple Next-Next-Next approach → but we need more features…
And hinestly, I do get it, I have been in this loop before in different roles too
So here is fo another round:
The big point number one is: when we were all starting with Linux (my first was Fedora Core 6), partitioning was indeed the most complex barrier to start with it. But that’s because while the older partitioning GUI was very feature rich, it was overwhelming. It doesn’t help me when the system asks me which type of /boot partition I prefer, if I do not know what partition is.
We did change that.
In the new WebUI a new user does not need partitioning. So the experience you described while valid, should not apply to a new installer workflow anymore. We have a one click dual boot setup now. And one-click reinstall. This has never been possible before.
And you can check some recent Youtubers trying to install Fedora Linux for the first time. They do not ask “how do i resize my boot partition”. Or “how do I switch from BTRFS to EXT4”. This question does not need to happen anymore when you meet Linux for the first time. It is a big win.
The reason why people asking it because they are not new. It doesn’t mean that the question is wrong, but it is no longer the entry point. We should stop treating and offering it as an entry point.
And if someone asks you how to install Linux - you should not mention partitioning to them, at all
And the second point is - we literally can not make advanced partitioning too discoverable.
Because what happens is that when a new user sees three easy default options and one “Advanced..” button, they click on the button every single time.
They do the “hmm, advanced options, there must have hidden something interesting there”. Then they get the advanced screen which they asked for, look at it, say “oh, i knew Linux is complicated” and run away.
And it sounds like an anecdote, but it has been confirmed by the literal user testing.
So we need user to know that advanced tool is available, but we should not invite user to click it. The current setup is not perfect for several reasons, but it is not because we do not care. Rather because we got stuck between these conflicting requirements.
) but because I would like to add a perspective to one point and put it into a wider context (maybe that’s useful for the wider debate?):