Hello everyone,
we (Anaconda team) would like to propose Fedora system wide change for Fedora 39 Workstation about using our Web UI in your product. We would like to discuss details and get requirements from you.
Our meetings are Tuesdays at 10:00 AM EDT (14:00 UTC).
Does Tuesday, March 21 work OK for you?
Metadata Update from @catanzaro: - Issue tagged with: meeting-request
I hoped we would discuss it this Tuesday but if it is already packed than we can move it to 21.
We already have another guest that day for the adwaita-qt discussion, and that will probably take most of the meeting time, so there might be quite a wait before we get to you and I don't know how much time would be remaining when we do. If we use the 21st then I can put you at the start of the hour so you won't have to wait for any other topics and can take as much time as you need.
Thanks for explanation. In that case we will join 21.st
I've scheduled this discussion for Tuesday, March 21 at 10:00 AM EDT (14:00 UTC) using this Jitsi Meet room.
Metadata Update from @catanzaro: - Issue untagged with: meeting-request - Issue tagged with: meeting
OK, thanks for info. We will connect to JItsi then :)
Status update: anaconda developers want Workstation WG to list some requirements for switching to the new installer. I'll leave this on the agenda for next week for further discussion.
Requirements that I think we have for the installation experience (not all of these points need to be addressed by the installer itself):
/home
I'd also like to raise the general topic of appropriateness for new Linux users, which is an important group for us. Dual boot is important for this group. So is having an approachable installer that doesn't require technical knowledge.
I know that dual boot support isn't fantastic at the moment, and I don't expect it to get better at this stage in a redesign. But I don't think we should sweep it under the carpet either.
Hi, I will try to sort things out. :)
Ability to connect Bluetooth input devices (likely through an assistant that is launched when no input is detected) Ability to turn on and use accessibility features in installer and live session System status display while using the installer - at least to show the audio volume (for accessibility) and battery level
These are handled by Live environment. The same as it works even now.
Ability to select a language for installer and live session
Installer has a select language as first screen. Live session language needs to be solved by you. I know you had an idea about asking user after boot to select the language. Installer is not responsible for live session language.
Ability to select a keyboard for installer (required for configuring the time, setting a disk encryption password, and potentially for other disk configuration) and live session
Currently the keyboard is selected based on the language selection. The first screen will select installation + installed system language.
Ability to switch keyboard layouts during installation?
That is something we can think about. However, we are not able to get to better shape of what we have now - which is separated Live keyboard configuration from Anaconda. That happens because of reasons explained on meeting and here: https://bugzilla.redhat.com/show_bug.cgi?id=2016613 . Because of that, I'm honestly not that thrilled on adding keyboard layouts now. It would again resulted in Anaconda has some layout but user types passwords in other layout in Live. The situation would be better if we get into a separate installer environment but that is not possible to do now (too much work to be done).
About this specific issue I would like to know what is the priority for you. If (at least for the first version) it would be fine to go just with the default language layout or if you want us to focus on this and discuss possible solutions as priority.
Ability to select the live session or installer (ideally in a way that is accessible and possible using Bluetooth input devices)
We expect this to work the same way as it works now.
Ability to reuse a /home partition or subvolume (for which there would ideally be a guided experience) as part of a new install
I would like to know how much is this a priority for you. Again we can focus on this issue in case you really need the support.
Some kind of allowance for custom disk configurations. This is not going to be a majority case, but there will need to be some way to achieve it, either for niche use cases, or for testing and development purposes. This could require someone to use a separate tool to create the disk layout, and then have the ability in Anaconda to specify how each volume should be used for the new install. However, in that case, we have to determine what the recommended disk configuration tool would be, and establish that it meets our use cases.
Honestly, I'm not sure about this. Based on our data (definitely could wrong) users don't want to use most of the reasonable solutions. If possible I would like to get the feedback from users about how to solve this. I'm afraid of creating something which will not be accepted by users.
If you agree I would skip this one until we get more feedback from users. Than we can revisit it. As a workaround for the time being I would suggest people to use Everything ISO or other net installation ISO which still contain the old Anaconda.
Do you agree?
Support for automated workstation installation - that's #85
Not going to happen, sorry. This is a new feature request which is not related to UI at all. And if we want to go with a separate installer environment than create the solution now would be harmful more than useful because it would have to completely change.
I'd also like to raise the general topic of appropriateness for new Linux users, which is an important group for us. Dual boot is important for this group. So is having an approachable installer that doesn't require technical knowledge. I know that dual boot support isn't fantastic at the moment, and I don't expect it to get better at this stage in a redesign. But I don't think we should sweep it under the carpet either.
I have a feeling that we supports the dual boot if users will create a space for the installation to happen. However, I need to verify that.
Anyway, I hope you like the new Web UI installer and I'm looking forward to see users feedback when it's available officially. So far from the preview image we had mostly positive reviews which was a great experience!
If we don't have keyboard layout selection somewhere, then I won't be able to install Fedora, so it really has to exist. Not sure why you'd think keyboard selection is optional. IMO the best place for it would be either gnome-initial-setup (which would need to run sooner, replacing fedora-welcome) or fedora-welcome (which already runs first) so it wouldn't be anaconda team's problem either way, but we need to discuss this further.
It's a reasonable worry. That said, I think we'll get a lot of complaints if the custom partitioning functionality is not roughly equivalent to what we have now and/or what other distro installers support. In particular, reusing /home seems to be very popular. This would have to be a collaborative decision between Workstation WG and anaconda team, but I personally would be uncomfortable with shipping without a better custom partitioning UI.
This certainly seemed to be the impression I got from other WG members at yesterday's meeting. Seems fair to say we're generally pleased with the new design.
To clarify - the list of requirements above is my own personal list, not that of the wider working group. It's intended as a starting point for our discussion next week.
Thanks for the clarification. If you have questions on the Anaconda team, please feel free to ask :).
This is pretty important as it's been pretty highly asked. The Mageia, openSUSE, and Ubuntu installers can all do this automatically. We should be able to do it too. The openSUSE and Ubuntu installers go a step further and are able to read the existing install's user list and import them as part of the install process so that they're working right out of the gate.
Further, YaST can also detect and import the SSH host key and redeploy it if requested. This is not an ask from the WG at this time, but I think you should put it on the roadmap for not just workstations, but servers too.
Ability to select a language for installer and live session Ability to select a keyboard for installer
For this, we discussed how to get out of this as a hard requirement for the MVP by reorganizing the live session in the following way:
This would also make our live session more accessible to users who can't use the default US settings for keyboard, language and timezone.
So we have basically two issues here.
The Working Group would like to see custom partitioning functionality that's roughly on par with the previous anaconda custom partitioning user experience (not the super advanced blivet workflow, but the less-advanced built-in workflow). The design doesn't have to be similar, but you should be able to accomplish basic tasks like create partitions, mount filesystems, and reuse existing home directory. We expect the large majority of users will never use custom partitioning, but it still needs to be there because all competing distros offer this functionality and users who want to use it will likely switch to another distro if we don't offer it.
Need way to select language and keyboard layout, ideally before starting the live session. Action item: Michael and Matthias to discuss whether Red Hat can commit to implementing a new gnome-initial-setup session that runs before anaconda.
Now if we additionally move anaconda to a separate live session, then we'd have even more to consider, like how to choose which session to launch, and whether or how to get language/keyboard/timezone settings into anaconda. Plus Allan's longer list of requirements (above) to make sure we have basic shell functionality. But I understand this is not part of the minimal viable product that you want to ship in Fedora 39.
Metadata Update from @catanzaro: - Issue untagged with: meeting
So right now we have /usr/libexec/livesys/livesys-main that creates a liveuser user at boot. If it just didn't do that (and the subsequent automatic login configuration), then when GDM was started gnome-initial-setup would run.
The installer could then just run from that user account instead of a "liveuser" account, and maybe it could transfer the user over to the installed system wholesale ?
The idea is still to present a 'try or install' alternative at the end of initial-setup, though. For the try case, we still need to create a user and transition into a proper user session.
Well we still want to run the installer in a full user session if they choose "install" right ? I mean to me, a pretty straight forward way to do this is:
Having the user pick a username, and configure online accounts and whatnot seems suboptimal if the goal is just a 'try live' session. I think we really want to limit the initial-setup to just keyboard/language/timezone, and hardcode the user ID.
shrug it doesn't seem that onerous to me to do one extra click past online-accounts (edit: well i guess there would be Network too, etc)
But, the same basic flow could still work I suppose. We just do as mcatanzaro proposed and integrate fedora-welcome into gnome-online-accounts... so revised workflow could be:
[list of steps redacted]
EDIT: my updated proposal didn't actually avoid the extra questions for the just "try it" mode of operation.
I guess the main point is, we're talking about system language, default keyboard layout, system timezone...this initial setup is for system configuration not user configuration. So we should be running gnome-initial-setup in system mode not existing user mode (which I think got removed anyway).
GDM already has code to run gnome-initial-setup in system mode automatically if there is no user already. So we should make sure the liveuser isn't created before GDM is started.
gnome-initial-setup already has code to go from system mode to a user session it creates. So we should leverage that code by creating the user account from gnome-initial-setup.
If we don't want to ask the user what username to use, I guess we could add a new --live-user mode to have it create the user with canned values without showing the page. (for simplicity it should probably just assume --live-user if rd.live.image is on the kernel command line.
--live-user
rd.live.image
If there are other pages we don't want to show for --live-user mode we can hide them too.
I started to sketch out what the --live-user mode could look like here:
https://gitlab.gnome.org/GNOME/gnome-initial-setup/-/merge_requests/200
I haven't tested it or anything, but it should at least show what I mean.
The working group will need to review the state of the new web UI to decide whether we think that it's ready for F39, and it would be good to decide on the timeline for that evaluation ahead of time.
Beta freeze starts on 22 August. Should we aim to conduct our review 3 weeks ahead of that date?
Metadata Update from @aday: - Issue assigned to aday - Issue set to the milestone: Fedora 39
Let's make this the main tracking issue for the new web installer. Previous discussions on this topic can be found in the following issues:
The other main issue we have on this topic is the live user mode in initial setup. That's being tracked in #366.
Hi, we will try to target Change Checkpoint: Completion deadline (testable) which is Tue 2023-08-08 to have most of the functionality implemented. I think that sounds like the best deadline for evaluation.
Change Checkpoint: Completion deadline (testable)
Plan agreed at yesterday's working group meeting:
apologies for missing the above mentioned deadlines. I'm taking a look today (and yesterday) and think we should be able to land this pretty soon.
I updated the gnome-initial-setup merge request to fill in some of the missing bits discussed on that merge request. The biggest missing piece was adding a new "Install or Try?" page as Allan requested. I've added a first cut at that now. it can still use a little style tweaking to get it more pixel perfect with the mock up, and I haven't actually seen the installer start yet with "Install" button because i've been running in a simulated live environment not a real live environment.
My next task today is to try to (re-)figure out how to build a live image to do a more real test.
We needed some changes to the livesys scripts to accommodate gnome-initial-setup taking on more of the load. I've posted those here:
https://pagure.io/livesys-scripts/pull-request/17
Though we can't land them until the gnome-initial-setup bits land first.
I also need a minor change to the liveinst script in anaconda. It uses consolehelper to get root privileges, which doesn't work well for gnome-initial-setup. consolehelper is deprecated anyway, so I ported it to use polkit instead:
https://github.com/rhinstaller/anaconda/pull/5044
Another important bit that's not landed, is making sure ibus configuration gets added for users when they have no keyboard configuration in GSettings.
Will post another update when I've figured out how to test it in my own live image.
So I was able to cobble together a liveimage using:
sudo '/sbin/livemedia-creator' '--ks' 'liveimg.ks' '--logfile' 'livemedia-out.log' '--no-virt' '--resultdir' 'output' '--project' 'Fedora-Workstation-Live' '--make-iso' '--volid' 'Fedora-WS-Live-39-20230814.n.0' '--iso-only' '--iso-name' 'Fedora-Workstation-Live-x86_64-39-20230814.n.0.iso' --releasever '39' --macboot
where liveimg.ks is mostly stolen from the last live image build in koji but with a few changes:
repo --name="anaconda-override" --baseurl=file:///srv/sources/github/anaconda/result/build/01-rpm-build repo --name="gnome-initial-setup-override" --baseurl=file:///srv/sources/pkgs/gnome-initial-setup/x86_64 repo --name="livesys-scripts-override" --baseurl=file:///srv/sources/pkgs/livesys-scripts/noarch
this adds the packages with my changes.
%packages ... anaconda-webui
this adds the anaconda-webui to the package set so it gets used instead of the hub and spoke installer.
Things mostly worked but I had a few issues:
the webui failed to start at first because it's running firefox as root, and firefox disallows normal users to run firefox with elevated privileges. I worked around this by adding "unset XAUTHORITY" to the liveinst script to defeat firefox's heuristics, but I assume it doesn't actually need to run as root? probably webui-desktop should drop privileges itself (maybe webui-desktop could just throw pkexec --user $(id -n -u ${PKEXEC_UID}) in the front of the BROWSER environment variable if ${PKEXEC_UID} is set and its running as root.
the webui showed a titlebar mentioning firefox. Maybe widget.allow-client-side-decoration needs to be prefs.js somewhere or something? firefox is just an implementation detail, so it shouldn't be a branded part of the experience.
widget.allow-client-side-decoration
the installed system was "weird". rpm -qa reported no installed packages, despite there clearly being installed packages. The default target in systemd was multi-user.target not graphical.target so it just dropped to a getty after boot.
the installer didn't have me create a user, so after booting into single user mode, and changing the target to graphical.target it started gnome-initial-setup again, and asked questions I had just answered before the install. This might be because of
[PasswordSpoke] visited=1 [UserSpoke] visited=1
in /etc/sysconfig/anaconda. I'll try taking that out tomorrow. EDIT: Though actually thinking about this more, we probably do want to create the user on the next boot, because otherwise we'll miss out on some other gnome-initial-setup pages that we didn't ask before install. so maybe gnome-initial-setup should run and skip the pages that already have system configuration in place. The re-asked pages aren't an immediate blocker at any rate.
It could be some of my issues are because I cobbled together the live image by looking at what koji does. I could try putting the packages in a copr or something if jkonecny or someone wants to use a more typical work flow for generating images (whatever that workflow may be). I did try using some make targets provided in anaconda upstream for generating the isos but they seem out of date (they use a anaconda-live-iso-creator container image in quay.io that no longer exists, among other issues)
As a side note, I also tried the hub and spoke installer. It worked basically the same. One issue is I had added
[DatetimeSpoke] visited=1
to /etc/sysconfig/anaconda and it still showed the timezone configuration that gnome-initial-setup already asked the user about. I guess I got the group name wrong?
Anyway I'll poke more tomorrow, but I don't think we're far at all.
I'm afraid /etc/sysconfig/anaconda is not really wired together with the Web UI yet - I'll check how it is actually setup to behave right now. In any case, the expectation for F39 is that the flow should go like this:
GIS: language & keyboard Anaconda Web UI: Storage reboot GIS for everything else, including Time & date (wee agreed GIS will take this over on F39, there was still Tem & date configuration in the GTK UI before).
BTW, please put the GIS RPMs (and possibly any other RPMs that need to be changed) somewhere, so we can try this out as well & test Anaconda side fixes.
BTW, we have this live image build workflow: https://github.com/rhinstaller/anaconda/blob/master/CONTRIBUTING.rst#testing-anaconda-changes (at the end of the section) Not sure if it would be useful for you as well. :)
okay great, so we'll rely on gnome-initial-setup to create the user on first boot. that makes sense. but it does mean we have the problem of duplicate questions, since it's getting run a second time. we'll have to figure out a story for that, maybe not before beta though. Maybe we can write to /var/lib/gnome-initial-setup/visited-pages which pages have been visited and anaconda can copy that file from the live image to the installed system.
We can also try to do heuristics on a page by page basis, but i feel like that might be more fragile (especially if the user is using defaults). I'll post a link with my last rpm builds soon.
builds are here: https://people.redhat.com/rstrode/gnome-initial-setup-builds/
Make sure whatever anaconda build you throw in the mix includes https://github.com/rhinstaller/anaconda/pull/5044 or the installer won't work
builds are here: https://people.redhat.com/rstrode/gnome-initial-setup-builds/ Make sure whatever anaconda build you throw in the mix includes https://github.com/rhinstaller/anaconda/pull/5044 or the installer won't work
Thanks! Sure, I'm testing your PR right now anyway. :)
So i'm going to do a fresh build of gnome-initial-setup in a few minutes to update vendor.conf to skip all pages in live user mode but language and keyboard, you'll see extra pages before that build finishes
I think I've figured out whats going on with the /etc/sysconfig/anaconda file - on workstation we hide these screens via our product configuration file (https://github.com/rhinstaller/anaconda/blob/master/data/profile.d/fedora-workstation.conf#L19C1-L24C14):
[User Interface] custom_stylesheet = /usr/share/anaconda/pixmaps/workstation/fedora-workstation.css hidden_spokes = NetworkSpoke PasswordSpoke UserSpoke
But they still somehow get marked as visited. Still looking into what actually does that, as our code I was able to find out just writes out the "post_install_tools_disabled" key. :P
https://github.com/rhinstaller/anaconda/blob/948c3eff353ba3e187545f2c8a75b7eb79be1707/pyanaconda/modules/services/installation.py#L122
What screens do get duplicated ? Language & keyboard ? That indeed should not repeat.
BTW, back in the day, when we first discussed the idea of a pre-installation tool running early and setting language for the Live environment and the installation, the /etc/sysconfig/anaconda file specification was designed to handle the pre-installation/installation/post-installation tools to communicate:
https://anaconda-test.readthedocs.io/en/latest/user-interaction-config-file-spec.html
Not sure if that idea is salvageable right now, especially given the timeframe. :P
oh /etc/sysconfig/anaconda is written by the live scripts intentionally and thats why they're marked as visited. I assumed that's how spokes were hidden though. now that i know it's done from product configuration, it all makes sense why me updating it didn't make timezone disappear for hub-and-spoke. anyway that was just a curiosity since the idea is to not use hub and spoke going forward, and now i realize timezone is for first boot anyway.
yes Lang and keyboard a the two that will get duplicated. Should be fixable. I don't think we should user /etc/sysconfig/anaconda as a middle man when its to convey to a second run of gnome-intiial-setup what the user did from a previous run though of gnome-initial-setup. makes sense for questions anaconda asked of course.
Yeah, I've checked the flow in the Live image I have generated (https://fedorapeople.org/groups/anaconda/webui/temp/Fedora-Workstation_test_ray_liveinst_changes.iso) and it indeed does not show any specific time & date configuration screen (although it does ask if geolocation should be enabled). So I think this should be fixed to show the GIS Time & date screen.
Yeah, that's a good call - definitely feel free to use what works best for GIS right now. :)
hey so
sudo make -f ./Makefile.am anaconda-live-iso-creator-build # to build the container if it doesn't exists already sudo make -f ./Makefile.am container-live-iso-build
works for you? I tried before and it failed for a few reasons, but the main one was that I don't have access to https://quay.io/rhinstaller/anaconda-iso-creator ? for me it says 403 forbidden. is it visible to you?
just tried your iso and something went wrong with generation:
[liveuser@localhost-live ~]$ rpm -q livesys-scripts --changelog | head -n 3 * Thu Jul 20 2023 Fedora Release Engineering releng@fedoraproject.org - 0.4.3-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild
[liveuser@localhost-live ~]$ rpm -q gnome-initial-setup --changelog | head -n 3 * Mon Aug 07 2023 Kalev Lember klember@redhat.com - 45~beta-2 - Sort files list
[liveuser@localhost-live ~]$ rpm -q anaconda --changelog | head -n 3 * Thu Aug 03 2023 github-actions github-actions@github.com - 39.29-1 - webui: spread the state update function into seperate hooks and useMemo (kkoukiou)
it doesn't have the new builds. i'm going to try to do a fresh build now using the dnf repo i gave you to see if it's a problem with the repo.
@jkonecny Might know more - its strange, you should not need any special access anywhere, especially as the first command should build the container.
@rstrode Hmm, given that is a live iso, can't you actually just install your GIS packages on it ? Even a normal Live ISO might work - anaconda-webui is in Rawhide repos (just not installed anywhere by default), so that also should not be a problem. :)
ah i don't have an issue cobbling together a testing environment. I just thought you wanted to see things too. no worries.
i think i know what was going wrong with those commands (i don't think they work when getting run in the provided toolbox). I'm guessing you run them directly on your host and don't use toolbox ?
Yeah, I just run that directly. I know we have some sort of toolboox config, but it might be possible it has not been tested with this exact workflow.
@jkonecny I think we should remember to note that in the docs. :P
Sure, I do - haven't got so far today, but I think I should be able to tomorrow. :)
one other issue I just noticed. The installer has an "About" button that brings up github in a browser window and from there i can get to youtube. I think it's probably better to lock that down and let the users only do that sort of stuff if they're in the logged in live session.
Sorry, for that. The containers are not yet on quay.io you have to build them manually. Follow:
https://anaconda-installer.readthedocs.io/en/latest/contributing.html#backend-and-tui-development
or in other words, you need to call:
make -f ./Makefile.am container-rpms-scratch
first to get Anaconda RPMs built.
And then:
sudo make -f ./Makefile.am anaconda-live-iso-creator-build sudo make -f ./Makefile.am container-live-iso-build
to build the container. And yes, it can't be done in toolbx because you need to run this under root to be able to create loop devices for the ISO build.
If you want to add your GIS repository to the build, the easiest option is to have your custom kickstart file and mount it over the one in the container as this:
-v ./workstation.ks:/lorax/workstation.ks:z
Well, we need users to at least reach Bugzilla, as thats how our bug reporting is setup for F39. We generate a URL for the new-Fedora-Bug form on Bugzilla & pre-fill what we can with data from the crash (if available). I am not sure we can lock this down without breaking this.
Also it could be useful for users to reach out to documentation and tutorials for the new UI. Or for storage, as we basically delegate storage configuration to the user in F39, with the Web UI only handling the final mountpoint assignment.
well do don't do network setup, so we should be treating this as an offline install imo.
Well, that could be a problem - how do you report bug then ? I guess the user can enable networking & then interact with Bugzilla ? We could tell then what to do in the UI but it would still not be the best UX. :P
CCing @adamwill for the bug reporting flow
EDIT: oh sorry, I already forgot you mentioned there's a dedicated bug flow in place above. ignore the below
honestly even if networking is enabled, the ux for bug reporting isn't really great. I mean there's nowhere in the UI that says "report a bug" or anything like that, there's just a link saying it will go to the project page, but clicking it shows source code on github.
From a user point of view, they have to scroll past things like .codecov.yml and discussions of a bird that is linguistically talented ("a translation canary ?!), At the bottom of the code dump after scrolling, they can see the readme, that mentions bug reporting instructions, but it points to bugzilla.redhat.com which requires creating an account which requires using a different device anyway. Also, once the account is made, it's not clear for a user, I think, what questions to answer next to get a report to the right place.
.codecov.yml
It might be better to just put "To report bugs, visit bugzilla.redhat.com, create an account, and file a New report against the anaconda component of the Fedora product" in flat text and drop the link to the project page if in live mode.
So if we want the dedicated bug flow to work, I guess we need to bring network configuration page into gnome-initial-setup. i'll add it I guess.
We have a PR open that adds a "report bug" option to the global menu: https://github.com/rhinstaller/anaconda/pull/5047
We also show similar dialog automatically if DBus call to backend fails or if an installation task fails - this can be seen on the screenshots in this PR: https://github.com/rhinstaller/anaconda/pull/4942
I'm also working on a way for triggering mock errors at runtime, so the whole machinery can be easily tested when needed (kinda like you can test error reporting in the old GTK UI by sending it a signal).
That's what I mean Bugzilla reporting workflow - sorry for the confusion. :P
The thing is, the Live installer is pretty much network independent by default & on purpose. It seems a bit weird to force people to enable network just so they might report a bug, not to mention complicate the initial GIS flow. On the other hand, without network it unlikely we will get any bug reports at all. :P
Not sure what's the best solution and possibly a call for @aday and Workstation SIG in general to make.
indeed. more food for thought: networking will work for most wired connections without any questions at all.
so just to give a status update:
I've added code to prevent duplicate pages between the live instance and the post install screen on the gnome-initial-setup side. I haven't tested it yet, but will soon. anaconda will need to make sure the file /var/lib/gnome-initial-setup/state gets copied from the live system to the installed system for things will work.
I'm working on the keyboard migration code i alluded to now (to make sure input methods get properly brought in post-install. i think it's best to add it to gnome-shell directly, so i'm looking into that now.
After that I think I'm ready to do builds. (provided the anaconda polkit change is in a build, i haven't confirmed that yet)
So, let me check I understand: the design is that, on the install path, the user gets walked through a controlled g-i-s flow then dumped straight into the installer, and has no access to the regular desktop - presumably including the top-right menu? - so cannot configure the network if it needs configuring?
Hmm. Seems like a tricky one. In an ideal world I guess there'd be a nice 'get online' step in the g-i-s wizard which mentioned why you might want to (automatic locale/timezone detection, and bug reporting?) and let you skip it if you didn't care. (And obviously if you're already connected via ethernet, doesn't get displayed). But if we don't have anything like that right now, we probably don't have time to write a good version of it before this needs to land.
For Beta at least, and probably the F39 release, we can probably live without it, I guess. I believe the bug reporting workflow can tell whether it's online and will let you save the report data to disk if it can't report it to Bugzilla, but I'm not 100% sure, we should check.
yup, your take is pretty close to right.
We do actually offer access to the regular desktop as an alternative to starting the installer. it's a choice the user makes. "Install or Try?". Once in the normal session they can start the installer too. so there is a way to get network configured and start the installer. it's just not the "normal" path.
gnome-intiial-setup does have a network page we could add. The issue is two fold: 1. what @m4rtink said: it really is only needed for reporting bugs, so in the common case its just an extra step 2. there's no code to transfer the network config over to the installed system afaik, so we'd be asking the user it again after install.
I think your gut is right here, we should just avoid having the screen, at least for beta. bugs are still reportable for users on ethernet and via the logged in session, so hopefully that's good enough for now.
Since the bug reporting workflow is just "open github.com," my vote is to not make changes to gnome-initial-setup to facilitate this, and leave network configuration for post-install. You can just as easily report bugs using a different device that does have network.
That's not the bug reporting workflow. The bug reporting workflow is that when anaconda crashes, a libreport-based workflow runs, gathers a bunch of useful data, asks you for a bugzilla API key (this part is unfortunate but unavoidable, it used to ask you for a password...), and files a bugzilla report with the useful data attached.
okay another status update. I got the keyboard migration code sketch out now and posted here:
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2896
It's not tested yet. i'm making a live image now to try it out, but probably happen until tomorrow.
I also did some testing with duplicate page code and ironed out a few issues there.
Assuming everything goes as planned, I'll probably be pushing stuff tomorrow.
About the network settings. Isn't it possible to configure the network from the top bar? If yes, then Anaconda can just add a note that for bug reporting you need to configure the network in the top bar configuration menu. So we would not force people to go there until they need it because the network is not available automatically or other reason.
WDYT @rstrode @adamwill?
About the network settings. Isn't it possible to configure the network from the top bar? If yes, then Anaconda can just add a note that for bug reporting you need to configure the network in the top bar configuration menu. So we would not force people to go there until they need it because the network is not available automatically or other reason. WDYT @rstrode @adamwill?
I like that & I've just checked and the regular network configuration options are there. (BTW, definitely something we should have on netins/boot.iso in the future as well)
<img alt="live_gis_network.png" src="/fedora-workstation/issue/raw/files/09108409460b0c03dc55a66db07d3d8c68101d3d7e9588cdf4e5f6e3a779589c-live_gis_network.png" />
heh right. The top bar totally slipped my mind. Case closed.
I played with the GIS solution ISO today and I found some issues:
Live environment is set to English language and ignoring what is selected in GIS
We are missing localization files on Live (or it seems that is the issue). That was probably fine in the past because it was in English only anyhow, but now we are missing translations for the applications which makes the localization broken. Probably originally implemented to reduce size of the ISO.
I even mentioned it in my comment! Nobody picked up on it :D "presumably including the top-right menu?"
wouldn't be the first comment on this ticket i glossed over when reading! sorry!
I played with the GIS solution ISO today and I found some issues: Live environment is set to English language and ignoring what is selected in GIS We are missing localization files on Live (or it seems that is the issue). That was probably fine in the past because it was in English only anyhow, but now we are missing translations for the applications which makes the localization broken. Probably originally implemented to reduce size of the ISO.
Eh? The current (non-webUI, that is) live installer does localization just fine. Here's a screenshot of a recent F39 Workstation live doing a Japanese install.
<img alt="Screenshot_from_2023-08-17_08-18-57.png" src="/fedora-workstation/issue/raw/files/b4d1fb990adfed2ec02faafe78090916934fb737a411bc93ad41cd7816eb61e6-Screenshot_from_2023-08-17_08-18-57.png" />
I played with the GIS solution ISO today and I found some issues: Live environment is set to English language and ignoring what is selected in GIS We are missing localization files on Live (or it seems that is the issue). That was probably fine in the past because it was in English only anyhow, but now we are missing translations for the applications which makes the localization broken. Probably originally implemented to reduce size of the ISO. Eh? The current (non-webUI, that is) live installer does localization just fine. Here's a screenshot of a recent F39 Workstation live doing a Japanese install.
Anaconda itself picks up the language from GIS just fine - though it currently has other issues: - Anaconda geolocation interfering https://bugzilla.redhat.com/show_bug.cgi?id=2232579 - overall low amount of all the new Web UI strings being translated yet
But it looks like apps we launch are partially translated, even if the package includes all the translations normally. Is there perhaps some translation file culling going on to make the Live image smaller ?
Here it can be seen on Blivet GUI (which we launch via a button from the storage config page):
<img alt="live_gis_blivet_gui_partital_translation.png" src="/fedora-workstation/issue/raw/files/8c56bb3ab1d77938eff3973e24de7331d87bb0d105af07a8f88c00d76ef8b73a-live_gis_blivet_gui_partital_translation.png" />
As you can see, there are some German strings on the about page, but the rest of the app is not translated. According to @vtrefny (Blivet GUI maintainer) it should be almost fully translated to German.
Even Anaconda is actually running in German - note the bubble in the header. In this case its likely just too many fresh strings:
<img alt="live_gis_anaconda_partital_translation.png" src="/fedora-workstation/issue/raw/files/3fd76b0365be5632f2476ad38dc529800aaab0e993ba4e77108010dad18638e5-live_gis_anaconda_partital_translation.png" />
okay just to give another status update...
https://github.com/rhinstaller/anaconda/pull/5056
It's not tested yet, but I'm working on that now
I fixed a few issues that cropped up with the gnome-shell patch
I've been iterating with my own test live images trying to make things work completely. Still in progress. Getting really close.
okay I did a couple more anaconda patches to address the first two issues I mentioned here: https://pagure.io/fedora-workstation/issue/362#comment-868970
https://github.com/rhinstaller/anaconda/pull/5057 - fixes the titlebar issue
https://github.com/rhinstaller/anaconda/pull/5058 - fixes the "browser runs as root" issue
I've also started to sketch out how anaconda can run blivet via firefox instead via cockpit to fix focus issues here: https://github.com/rhinstaller/anaconda/pull/5059 but that's still work in progress.
Hey folks!
/me still is reading through this thread :D I am proposing 2023.08.25 through 2023.08.31 for the test week. if we wanna do two weeks because this is a fairly large change, we can do that as well. Lemme know and I will set up the bits :D
just a note, there's some discussion about deferring this until F40 now among fesco:
https://pagure.io/fesco/issue/3053
Final decision is going to be made on Thursday I believe.
I wouldn't expect a final decision on Thursday. I would expect FESCo (or Workstation WG) could ask us to revert the changes at any time if there are problems. We'll just need to be prepared for that possibility.
https://bugzilla.redhat.com/show_bug.cgi?id=2173474
I think it would b great to address this minor issue in the new installer. Currently, the root partition name set by Anaconda is "fedora_localhost-live", but this doesn't make sense when the system is installed.
Hi, thanks for the heads-up. I've added that to our tracker bug so we won't miss it.
https://bugzilla.redhat.com/show_bug.cgi?id=2231339
I don't think it's specific to webUI, is it? It was already the case before, I think?
Yeah, we looked at it with @vtrefny today and it looks like it has been like this for quite a while. So while it indeed the name sounds weird & likely should be fixed eventually, I would not say its a pressing concern right now.
We've agreed to proceed with the new installer including warts, assuming blocker bugs can be addressed. Closing.
Right, that bug is really annoying and unprofessional, but it's a longstanding issue rather than a new problem with the web installer. Do we have an anaconda bug report for it?
Metadata Update from @catanzaro: - Issue close_status updated to: Fixed - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.