Please find attached some screenshots from exploratory testing of Fedora-Workstation-Live-44_Beta-1.2.x86_64.iso.
[I have added more details as requested.]
File system layout as shown, root and home subvolumes are mounted (blue bars), “Return to installation”, storage checker report as shown. Contrary to the report there is a subvolume with mount point /.
I think to understand the user has a problem or questions about the output, and thus created an ask topic for this. If I misunderstood the intention of this, let me know. I can adjust the title if necessary but ping me with @py0xc3 if you need something of me.
You might evaluate here if a bug report is necessary.
But as @bookwar stated they eliminate issues the whole time. So using the latest ISO makes sense to not relate twice the same issue. If the newer ISO works then the error is removed already.
We haven’t changed much in the Storage Editor for a couple of releases. So it will most likely work the same. But I am interested in what was the intent in the testing. Is there an end state you were trying to achieve?
And a reproducible sequence of actions which led to errors would help. it is not clear fro me from the screenshots alone.
Absolutely, that’s why I opened a topic about it to allow identifying here if that is something new or not, user misunderstanding or bug, etc. You’re on the right track to test first the newest version before going ahead with anything else.
I tried to reproduce the above results and I cannot do it in my virtual machine using Fedora Workstation Beta 44 1.2.
The above report:
uses the same ISO
uses a virtual machine
and basically uses a default partitioning for Fedora with one extra EFI partition that is not being used at the moment.
I tried to use the same layout as used above. I have a /boot and a /boot/efi with mountpoints assigned, but not mounted, and I also have two BTRFS subvolumes for / and /home, both are assigned and mounted.
When I click on “Return to installation”, the confirmation looks fine. Unfortunately I could move the dialogue away for the layout to be seen in the whole, but the status quo of the BTRFS suggests that both partitions were previously unmounted.
I could proceed to the installation and install just fine.
I think that the above might have been a temporary blipse, or a race condition, or perhaps some VM setting that I do not have. So, this looks awful, but it does not seem to be a standard experience people would have with it.
Thank you for trying to reproduce. I have reproduced the issue, see below. I’m using a default Gnome Box in UEFI mode on F43, no changes.
The difference between our test sessions is that your btrfs subvolumes are not empty. You are reinstalling. I’m installing onto an empty, newly created disk.
Retested again with new installation on clean disks brings me the same result as before. I can use that layout normally and can install. However, you are saying that you are using a default Gnome Box on EFI. Are you talking about a VM in the Boxes application? Because I have tested in virt-manager so far.
UPDATE:
Now I have tested this in Boxes with the UEFI option, clean installation, and it worked again.
What is your host machine? Mine is Fedora 44 with updates-testing enabled, fully updated.
Just to add the incentive: I once had a bug in web-ui (already fixed:) that was triggered by going back and forth again. So, without doing a change, just click the “back” button and then “next” again.
What I want to highlight with this example is that a bug is not necessarily only triggered by the underlying hardware(-emulation/virt.) and/or the exact configuration you prepare, but also how you do the steps, but maybe also what differs in earlier steps, even if they feel not related.
Such a bug can be also very superficial, e.g., in a check that is done on a high abstraction layer, or no check has failed but the error window is just provoked by accident (just examples). Even the order of partitions can theoretically provoke such a superficial bug.
It looks like you mounted after creating, what is not needed. The system will mount on it’s own. I also played around in a VM and not got this error message. However I also used the newest ISO as posted above.
These bugs do happen, yes. However, if they only happen after a specific trigger then most of the users will never hit that trigger and the bugs either go unnoticed for a long time, or they get triaged out to the backlog. The second is better because they can at least be documented and publicized.
That depends on the trigger. The point is, comparing screenshots of the moment the error becomes apparent would not determine what is necessary to reproduce a bug IF it falls into such a category
I would rather ask for more data. As we only know the state of the user when it fails. I cannot try to reproduce steps I don’t know.
@tk2345 Can you maybe add more data? It seems not yet clear how your issue is provoked. Can you give us the exact condition in which you do this (Fedora variant + host you use gnome boxes in uefi mode?), and then the exact file you use (still the one of the first screenshot?), and all steps and all clicks and text-inputs you do?
I don’t think I find time until next week, but if all is available, I might try next week to reproduce it.
That said, IF a VM relation exists, it becomes a problem that I cannot use GNOME boxes on my system, but it might be useful for you in any case to try if a different VM causes the same issue: can you do it on qemu/kvm with virt-manager or cockpit? That I can reproduce, at the best in user mode (although I doubt that implication is relevant). Let us know if you use bios, uefi, etc. and what versions of host and VM stuff you use and how far you customized something.
As a good practice I always create a new GPT boot sector. This way I am sure to not carrying an mbr boot record with, which has restrictions with EFI.
I would find it more useful to test the new ISO. So we can go ahead if it is not reproducible anymore. There are more than one factor involved when installing, the partitioning tool is just one of it.
Indeed, it would be most useful if @tk2345 would try to reproduce the issue in his tested environment with the old and new ISOs to compare the results of both.
Why would you ask for a task wich is obsolete in two weeks. The 1.2 betta iso will be usless in two weeks. Better starting with a Manual with something wich works already, or at least creating screenshots we can use to document and help others.
You’re on the right track to test first the newest version before going ahead with anything else.
