On Fri, Jan 8, 2021 at 8:52 PM Tejas Guruswamy
On 07/01/2021 08:43, Neal Gompa wrote:
On Thu, Jan 7, 2021 at 9:23 AM Axel Braun
wrote: ...
- setup of WIFI during installation 'is really old school' as one has to jump between different tabs to set it up. And, finally, the WIFI setting is not taken over to the installed system, so one has to enter it again (and he hit a known Plasma-bug by this https://bugs.kde.org/show_bug.cgi?id=389052 ) -> can the WIFI setup be done on a single page? -> can the wifi settings be transferred to the installed system?
yast2-network needs to learn how to configure NetworkManager for this to be fixed.
There are two strategies for doing this:
1. NetworkManager gets configured with the ifcfg-rh plugin enabled and we patch the plugin to look at ifcfg files in /etc/sysconfig/network. This is an incomplete solution because RH and SUSE ifcfg file formats differ slightly and there has been no attempt to rationalize them into a uniform file format. This might be easier now that Red Hat is actively working to retire legacy ifcfg-style configuration for NetworkManager keyfiles, as the plugin could be forked upstream and an "ifcfg-suse" plugin could be fully adapted for SUSE-style files. This doesn't make YaST "better", but makes it kind of "work".
2. yast2-network learns how to configure NetworkManager via its API or by writing native NetworkManager keyfiles. This is actually the preferred way to do it, since the keyfiles format is the native format and supports all the features of NetworkManager, including telling NM to use encrypted stores for credentials. This is also the _required_ format for VPN configuration.
The podcaster(s) also noted that setting up YaST Network in the installer but choosing NetworkManager for after install, means (surprisingly to them) a duplicate network setup required after first boot.
Wicked has been broken for years for the desktop, which is why NetworkManager is the default for all cases except for servers. I would actually prefer to change it to NetworkManager for servers too, but that's blocked on fixing YaST.
- there was some confusion around the activation of online repositories during installation from DVD. It is unclear where it is used or necessary for. -> a clarification that enabling the online repositories gives a wider variety of desktops and additional software should be included -> this hits for some parts the recent discussion if we can include repos like packman right at installation time -> If I remember correctly, a TW DVD with online repos enabled installs only if no new snapshot was released. Enabling the online repos on a DVD install pulls most packages from the repository instead of the DVD. This is clearly not a smart move, and I would consider this as bug. The reviewer had actually the same complaint. I agree with this complaint. It confused me as well when I first started using openSUSE, and it surprised me that there is no straightforward way to have both networking set up and use DVD repos for install.
Currently installer will always use latest available packages, from any enabled and available repo. Current options are no network, no online repos, install latest packages entirely from DVD; or yes network, enable online repos, and install latest packages (which are probably online).
Is it really useful to install Tumbleweed with network available and intentionally keep the system out-of-date for the first boot? Eventually you will update, right -- and then the net bandwidth use is the same?
In principle to achieve this the online repos could be added but kept disabled during installation, and enabled only after.
When using the DVD, yes. Especially if you're on constrained bandwidth. Given the frequency of Tumbleweed updates, it's reasonable for this case to work, because forcing online repos to be used even when using the DVD media is essentially saying you don't want to let someone do a known-good install. There are legitimate reasons for needing to be able to do that (bypassing bugs in YaST, broken kernel in repos, etc.).
Installation of software ========================
- After installation the reviewer obviously ran into severe performance problems (where it was not clear to me if this was coming from Intel Graphics or from free Nvidia driver). So he tried to install proprietary NVidia driver and had the issue that his graphics card was mentioned nowhere and he was unsure which driver to install ('this is managed on Fedora/Ubuntu with a checkbox, Arch installs one additional package'). In the istallation process, 'YaST hangs at 64% for ages' and he was uncertain whether to kill the process.
I suspect the issue was that NVIDIA driver installs appear to stall near the end due to regenerating mkinitrd in the post-install. YaST does not have a good way to guess progress of post-install scriptlets, obviously. Any ideas?
I assume this is because YaST runs the package management actions in-process rather than out-of-process like GNOME Software, Plasma Discover, and dnfdragora. There's probably nothing we can really do here, then.
-> can we improve the detection of hardware to recommend the right proprietary driver? I cant comment on how other distros do it, but it looks like this was easier. In Fedora, we have this set up with modalias() Provides and AppStream data with modaliases for the NVIDIA driver. This allows GNOME Software and Plasma Discover to suggest the correct driver for the hardware. Fedora Workstation has this workflow through GNOME Software for enabling and installing the driver.
The modalias() Supplements are present for openSUSE NVIDIA KMPs as well. In fact the counter-intuitive command `zypper install-new-recommends --no-recommends` will install this kind of suggested hardware packages, including NVIDIA if the repo has been added. AFAIK there is no equivalent of this in GUI, in either YaST or PackageKit/Discover/GNOME Software.
Therefore I view this as a documentation / discoverability issue. In the sense that our NVIDIA install procedure *should* be the same as Fedora, but we have poor communication of this. (It doesn't help that web searching "openSUSE NVIDIA" comes up with a lot of outdated info and scary-looking forum posts.)
I agree this is a discoverability issue, but that's also a UX problem. There are clearly better workflows that are intuitive and understandable to users that we should aim to try to implement. But at the minimum, even just having our documentation be up to date and having better SEO would help with this. -- 真実はいつも一つ!/ Always, there's only one truth!