Bugzilla – Bug 1226204
various package selection activity during NET installation requires Wicked or NetworkManger
Last modified: 2024-06-23 20:18:59 UTC
cf. bug 1183886 I wish to NET install a system to be used with systemd-networkd. In TW20240607 detailed package selection I managed to taboo wicked-service, wicked and networkmanager before selecting network on summary screen to disable network "services" (use neither wicked nor NM). In network, settings from cmdline were maintained, so I was able to proceed with installation, or so it lead me to believe. Apparently, network had been broken by the particular sequence of events, including clicking back button multiple times to redo network or detailed package selection, so fetch attempts all produced 404s, retries always produced 404, leaving only one other option - abort. I clicked abort before recovering exact language on software screen's network setup, upon which the installer exited and halted the system without rebooting. Thus, capturing logs was impossible. I started afresh, this time, with TW20240610, selecting to disable network before doing anything else at first visit to summary screen, and not bothering in detailed package selection to taboo already deselected NM and Wicked. This succeeded to a full installation. y2logs saved from first boot are available on request. The NET installer ought to be able to proceed using valid network settings from cmdline even after multiple trips between detailed package selection and network.
The main problem we have in the installation is that there is no a full differentiation of the running network config and the target system network config, that is, if you modify the network configuration during the installation it will change your current one copying it to the target system or translating it to Network manager at the end of the installation unless you select "None" backend as you asked for in the past. If there is no changes in the network configuration it should work fine, but if you mess the network configuration during the installation it will be hard to fix, so, the recommendation is to configure it by cmdline or with the interface and then just select a "Non"e backend. That should be enough. Will try to taboo that packages and reproduce the problem but It should be enough selecting none as the backend to be used.
I am not sure if this is even a supported scenario. If I understand the bug description correctly, this is a network-based installation (i.e. using the NET ISO that does not have any repos on the installation medium, so it relies completely on repos available via network), so it needs to initialize the network for the installation. Yet you want neither Network Manager (the default for openSUSE distros, Leap as well as TW) nor Wicked (the default for SLE products). Of course that means that you'll have to do the network setup manually at some point after the installation. This sounds to me like a total fringe case. If you want a non-networked machine to start with, the logical thing to start with would be a full DVD ISO, i.e. one that already contains all the repos on the installation medium. That way you can ensure that there will not be any artifacts of the network configuration that was used during installation on the target system. In pretty much all cases users expect the installation network configuration to be carried over to the target system, so they can continue to work with a working network seamlessly. That's what we have been striving to do for countless years to avoid disruptions caused by the network suddenly disappearing after the installation, which is very much a showstopper for the great majority of users.
So, please try this with a full DVD ISO and no network during the installation. If that works (which I expect), that should handle your very specific scenario. I don't think it is reasonable to expect a temporary network setup done by linuxrc during the installation to be magically made persistent without the help of one of the two tools that we are using to make that possible, NM or Wicked.
5 days later the exact details are no longer clearly remembered, while the nature of the installation abort prevented log collection. (In reply to Stefan Hundhammer from comment #2) > If you want a non-networked machine to start with I don't, and apparently you don't understand what the actual problem is. To preface, not directly related to the bug, I normally don't use any iso. I fetch linux and initrd from oss/boot/x86_64/loader/ and load them with Grub. My network needs neither NM nor Wicked nor management, as systemd-network provides the tools required for my entirely static IP installations. And, installation does proceed as expected that way, due to fix for bug 1183886, unless.... The problem: some kind of failure ignores the overview deselection of both NM and Wicked when it is made /after/ detailed package selection has occurred, if during detailed package selection something gets selected, even accidentally but subsequently deselected, that is, or apparently is related to, NM or Wicked or some other network function or feature. Evidently the trigger is attempting to exit summary screen, seeing something disturbing in the consequent package resolver popup, or remembering haven forgotten to address something in detailed package selection, and returning to detailed package selection, one /or more/ times, for changes. Ultimately, NM and Wicked remain deselected, unwanted and unneeded, but to prevent them from being installed via taboo, prevents the installation process to continue from the summary screen once its use has been completed. Package selection on the summary screen notes in red that NM or Wicked must be selected to proceed. I suspect the underlying obstacle in such circumstance is the detailed package selection exit summary resolver being triggered multiple times.
The problem may be in the interdependencies of the individual proposal categories: After one changes, in some cases another one needs to change as well. For example, changing language settings affects the package selection; if you change from English to, say, Italian, a number of *-lang-it or -i18n-it packages are added. And that's just one very simple example. So, in the case of networking, it is possible that the need to get some network going at all, one of the supported networking technologies (NM or wicked) are required; i.e. the network proposal has some influence on the software proposal. When one of the sub-proposal is changed by the user, the other ones are called in turn so they can check if their own requirements have now changed. I am not 100% sure how that affects packages that were explicitly set to "taboo", though, but my gut feeling is that a "taboo" status should be honored.
Created attachment 875524 [details] Screenshot: Dependency conflict when tabooing both NM and wicked I just did a quick test with the Leap 15.6 GA ISO: I used defaults all the way to the installation summary ("proposal"). Then I went into the network section and deleted the network card, then into the detailed software selection and set all packages starting with "networkmanager" (case insensitive) and then "wicked" to "taboo", and I got this dependency conflict. So it's not just the network proposal that enforces those packages, it's the "enhanced base" pattern already: It requires either the NM or the wicked packages. When I go to the patterns tab and deselect "Enhanced Base", it complains about the "YaST2 Base" pattern requiring one of NM or wicked. When I deselect that as well, it remains silent - no more dependency conflict. But then it complains in the proposal dialog about wicked in the software section, and this is an unrecoverable error; it insists on installing either NM or wicked.
Knut, according to bug #1183886 comment #14 this should actually work. Is this a regression, or did it never actually work during installation? Or did we (both Felix and I) do something wrong?
(In reply to Stefan Hundhammer from comment #7) > Knut, according to bug #1183886 comment #14 this should actually work. It should work.. and here are different problems being discussed... Disabling the wicked and NetworkManager services do not necessary mean uninstalling them. If there is some pattern that enforces the presence of once of both there will be a conflict that need to be solved. IIRC, we mark them to be removed in case of possible but... have to check. That is one thing, the other thing is the running configuration and the target one. If you configure the network "correctly" using linuxrc you should be able to reach the repositories and install the system, if you want a none backend you should be able to select it in the overview, but if you modify your current network configuration during the installation you are already modifying the current one and you could end without network in order to fetch the repositories and so on... > > Is this a regression, or did it never actually work during installation? Or > did we (both Felix and I) do something wrong? To consider it a regression it should work as expected at some point, so, Felix did actually worked previously in the same way you are configuring it now?
Sorry I neglected to confirm fix of bug 1183886, which I originally reported. It's possible I never tested in TW until last week. If the fix landed in 15.5 or 15.6, it would have been utilized there. I have as many as 3 y2log sets for 15.6 and 4 for 15.5 that might confirm. As explained in paragraph 2 of OP here, the bug 1183886 fix does result in working as expected, absent activity in detailed package selection to cause dependency conflict. I do have a y2log set from last week that would prove this worked, but I scarcely believe last week's was the only WFM since the fix reached TW, even though my saved y2logs include none for TW between fix and last week.
Created attachment 875542 [details] Screenshot: Initial proposal (installation summary) I tried again (with Leap 15.6 again, but that code is the same in TW), and I got it to work: I clicked through the installation workflow with defaults everywhere until the proposal ("Installation Summary"). Here it is crucial to click "disable services" in the "Network Configuration" section at the very bottom to stop the network proposal from insisting on either wicked or NM. Then I went to the SW selection, searched for "wicked", tabooed those packages, and did the same for the "NetworkManager" packages. This will result in a dependency conflict dialog where you have to select (x) 1: do not install pattern:enhanced_base and (x) 1: do not install pattern:yast2_basis and then click [OK -- Try Again]. All depencency problems are gond, but so are of course those patterns; you might have to select individual packages from them again. Please note that some YaST packages still require those network packages (NM or wicked). That's the price to pay.
Created attachment 875543 [details] Screenshot: Installation summary with network services disabled Notice that this is before entering the SW selection to taboo the wicked and NM packages.
Created attachment 875544 [details] Screenshot: Dependency conflicts after tabooing wicked and NM packages Make sure to select the solutions that remove those two patterns from the installation set.
I also checked the network that I had active during installation (starting an xterm with Ctrl-Shift-Alt-X and then "ping www.google.com"), and it still worked. The installation can be started without a complaint. Felix, please try and reopen if it still doesn't work for you.
Created attachment 875662 [details] 15.6 y2logs from host g5eas I just finished up a try with 15.6. I succeeded to get installation done sans wicked and sans NM, but somehow yast2 & yast2-logs didn't get selected, and zypper, libzypp & deps got deselected, before package installation proceeded. The latter was not much fun to fix. After fix was complete, this happened: # zypper -v in yast2 Verbosity: 2 Non-option program arguments: 'yast2' Initializing Target Checking whether to refresh metadata for NonOSS Checking whether to refresh metadata for OSS Checking whether to refresh metadata for Update Checking whether to refresh metadata for UpdateBP Checking whether to refresh metadata for UpdateNonOSS Checking whether to refresh metadata for UpdateSLE Loading repository data... Reading installed packages... Selecting 'yast2-4.6.8-150600.1.1.x86_64' from repository 'OSS' for installation. Resolving package dependencies... Force resolution: No Problem: 1: the to be installed yast2-4.6.8-150600.1.1.x86_64 requires 'sysconfig >= 0.80.0', but this requirement cannot be provided not installable providers: sysconfig-0.85.9-150200.12.1.x86_64[OSS] Solution 1: Following actions will be done: remove lock to allow installation of wicked-service-0.6.74-150600.9.2.x86_64[OSS] remove lock to allow installation of wicked-0.6.74-150600.9.2.x86_64[OSS] Solution 2: Following actions will be done: remove lock to allow installation of wicked-service-0.6.75-150600.11.3.4.x86_64[UpdateSLE] remove lock to allow installation of wicked-0.6.75-150600.11.3.4.x86_64[UpdateSLE] Solution 3: do not install yast2-4.6.8-150600.1.1.x86_64 Solution 4: remove lock to allow installation of NetworkManager-1.44.2-150600.1.7.x86_64[OSS] Solution 5: break yast2-4.6.8-150600.1.1.x86_64 by ignoring some of its dependencies Choose from above solutions by number or cancel [1/2/3/4/5/c/d/?] (c): 5 Applying solution 5 Resolving dependencies... Resolving package dependencies... Force resolution: No The following 2 recommended packages were automatically selected: ruby2.5-rubygem-gem2rpm 0.10.1-3.45 xdg-utils 1.1.3+20210805-150500.1.1 The following 40 NEW packages are going to be installed: augeas 1.14.1-150600.1.3 augeas-bash-completion 1.14.1-150600.1.3 augeas-lenses 1.14.1-150600.1.3 expat 2.4.4-150400.3.17.1 fdupes 2.3.0-150400.3.3.1 hostname 3.16-2.22 libruby2_5-2_5 2.5.9-150000.4.29.1 libxslt1 1.1.34-150400.3.3.1 libyaml-0-2 0.1.7-1.17 libyui-ncurses16 4.5.3-150500.3.7.8 libyui16 4.5.3-150500.3.7.8 perl-CPAN-Changes 0.400002-1.24 perl-Devel-Symdump 2.18-1.24 perl-Net-DBus 1.1.0-1.30 perl-Pod-Coverage 0.23-1.23 perl-Test-Pod 1.51-1.24 perl-Test-Pod-Coverage 1.10-1.23 perl-X11-Protocol 0.56-1.24 perl-XML-Twig 3.52-3.3.1 ruby 2.5-1.21 ruby-common 2.1-3.15 ruby2.5 2.5.9-150000.4.29.1 ruby2.5-rubygem-abstract_method 1.2.1-1.28 ruby2.5-rubygem-cfa 1.0.2-1.33 ruby2.5-rubygem-cheetah 0.5.2-1.33 ruby2.5-rubygem-fast_gettext 1.6.0-1.18 ruby2.5-rubygem-gem2rpm 0.10.1-3.45 ruby2.5-rubygem-mini_portile2 2.3.0-1.27 ruby2.5-rubygem-nokogiri 1.8.5-150400.14.3.1 ruby2.5-rubygem-ruby-augeas 0.5.0-1.31 ruby2.5-rubygem-simpleidn 0.0.9-1.17 ruby2.5-stdlib 2.5.9-150000.4.29.1 xdg-utils 1.1.3+20210805-150500.1.1 yast2 4.6.8-150600.1.1 yast2-core 4.6.0-150600.1.7 yast2-hardware-detection 4.6.0-150600.1.5 yast2-perl-bindings 4.6.0-150600.1.5 yast2-pkg-bindings 4.6.5-150600.3.2.8 yast2-ruby-bindings 4.6.2-150600.1.5 yast2-ycp-ui-bindings 4.6.0-150600.1.5 40 new packages to install. Overall download size: 16.9 MiB. Already cached: 1.2 MiB. After the operation, additional 41.6 MiB will be used. Backend: classic_rpmtrans Continue? [y/n/v/...? shows all options] (y): y