As discussed on the qa list, netinstall of m8 is failing due detecting looping. I recreated the problem with core, nonfree, and tainted release and updates repos selected. Installing with just the release repos and then updating after install does not recreate the problem, nor does adding the media in a running live iso and selecting updates to install. My best guess at this point is that it's due to rpm trying to restart after installing rpm-4.16.1.3-1.1.mga8, but since the netinstall isn't running from the installed system fails. If I'm correct, rebuilding the m8 netinstall iso images with the rpm, glibc, etc. updates installed should fix it.
Assignee: bugsquad => isobuild
This may due to backports as in bug 29830, though I would expect that to also impact the other update methods above. If it is caused by bug 29830, then after that's fixed the netinstall iso images will need to be recreated with that update.
Seeing this on real uefi hardware, HP Pavilion 15-n211dx, AMD A8-4555M, AMD HD 7600 graphics, 16GB RAM, rtl8188ee wifi, 512GB SSD partitioned by the installer. Problem shows on two Tier 1 mirrors, whether connected via Ethernet or wifi.
In my test, I used a non-uefi vb guest. Using the live or classic iso images with online media added are both working ok. Just the netinstall iso is showing the problem. Mageia-8-netinstall-nonfree-x86_64.iso from Feb 18 2021. The repos enabled are Core release/updates, Nonfree release/updates, and Tainted release/updates. No 32bit repos selected.
Created attachment 13356 [details] bug command output from Mageia-8-netinstall-nonfree-x86_64.iso This looks like a duplicate of bug 29624, but I'm not sure.
The relevant lines from the report ... * requiring java-11-openjdk-headless(x86-64)[== 1:11.0.15.0.10-1.mga8],libgif.so.7()(64bit),libjava.so()(64bit),x11-font-bitstream-type1 for java-11-openjdk-11.0.15.0.10-1.mga8.x86_64 * chosen lib64gif7-5.2.1-5.1.mga8.x86_64 for libgif.so.7()(64bit) * selecting lib64gif7-5.2.1-5.1.mga8.x86_64 * selecting x11-font-bitstream-type1-1.0.3-9.mga8.noarch * requiring mkfontdir[*],mkfontscale[*] for x11-font-bitstream-type1-1.0.3-9.mga8.noarch * chosen mkfontscale-1.2.1-2.mga8.x86_64 for mkfontdir[*] * selecting mkfontscale-1.2.1-2.mga8.x86_64 * requiring libfontenc.so.1()(64bit) for mkfontscale-1.2.1-2.mga8.x86_64 * chosen lib64fontenc1-1.1.4-2.mga8.x86_64 for libfontenc.so.1()(64bit) * selecting lib64fontenc1-1.1.4-2.mga8.x86_64 * chosen mkfontscale-1.2.1-2.mga8.x86_64 for mkfontscale[*] * chosen java-11-openjdk-headless-11.0.15.0.10-1.mga8.x86_64 for java-11-openjdk-headless(x86-64)[== 1:11.0.15.0.10-1.mga8] * selecting java-11-openjdk-headless-11.0.15.0.10-1.mga8.x86_64 * requiring /usr/sbin/alternatives[*],copy-jdk-configs[>= 4.0],javapackages-filesystem,libasound.so.2()(64bit),libasound.so.2(ALSA_0.9)(64bit),libasound.so.2(ALSA_0.9.0rc4)(64bit),lksctp-tools(x86-64),tzdata-java[>= 2021e] for java-11-openjdk-headless-11.0.15.0.10-1.mga8.x86_64 * chosen lib64alsa2-1.2.4-1.mga8.x86_64 for libasound.so.2()(64bit) * selecting lib64alsa2-1.2.4-1.mga8.x86_64 * requiring libalsa-data for lib64alsa2-1.2.4-1.mga8.x86_64 * selecting libalsa-data-1.2.4-1.mga8.noarch * chosen lib64alsa2-1.2.4-1.mga8.x86_64 for libasound.so.2(ALSA_0.9.0rc4)(64bit) * selecting javapackages-filesystem-5.3.0-14.mga8.noarch * chosen copy-jdk-configs-4.0-1.mga8.noarch for copy-jdk-configs[>= 4.0] * selecting copy-jdk-configs-4.0-1.mga8.noarch * requiring lua,lua-posix for copy-jdk-configs-4.0-1.mga8.noarch * selecting lua-posix-35.0-1.mga8.x86_64 * requiring lua[>= 5.2] for lua-posix-35.0-1.mga8.x86_64 * chosen lua-5.2.4-7.mga8.x86_64 for lua[>= 5.2] * selecting lua-5.2.4-7.mga8.x86_64 * requiring lib64lua5.2[== 5.2.4-7.mga8] for lua-5.2.4-7.mga8.x86_64 * chosen lib64lua5.2-5.2.4-7.mga8.x86_64 for lib64lua5.2[== 5.2.4-7.mga8] * selecting lib64lua5.2-5.2.4-7.mga8.x86_64 * chosen lksctp-tools-1.0.18-4.mga8.x86_64 for lksctp-tools(x86-64) * selecting lksctp-tools-1.0.18-4.mga8.x86_64 * requiring libsctp.so.1()(64bit),libsctp.so.1(VERS_1)(64bit),libsctp.so.1(VERS_3)(64bit) for lksctp-tools-1.0.18-4.mga8.x86_64 * chosen lib64sctp1-1.0.18-4.mga8.x86_64 for libsctp.so.1(VERS_1)(64bit) * selecting lib64sctp1-1.0.18-4.mga8.x86_64 * chosen lib64sctp1-1.0.18-4.mga8.x86_64 for libsctp.so.1()(64bit) * chosen lib64sctp1-1.0.18-4.mga8.x86_64 for libsctp.so.1(VERS_3)(64bit) * chosen lib64alsa2-1.2.4-1.mga8.x86_64 for libasound.so.2(ALSA_0.9)(64bit) * no packages match /usr/sbin/alternatives[*] (it is either in skip.list or already rejected) * unselecting java-11-openjdk-headless-11.0.15.0.10-1.mga8.x86_64 * unselecting java-11-openjdk-11.0.15.0.10-1.mga8.x86_64 * unselecting libreoffice-ure-7.3.2.2-1.mga8.x86_64 * unselecting libreoffice-core-7.3.2.2-1.mga8.x86_64 * unselecting libreoffice-calc-7.3.2.2-1.mga8.x86_64 * unselecting libreoffice-kf5-7.3.2.2-1.mga8.x86_64 * unselecting libreoffice-gtk3-7.3.2.2-1.mga8.x86_64 * unselecting libreoffice-langpack-en-7.3.2.2-1.mga8.x86_64 * adding a reason to already rejected package java-11-openjdk-headless-11.0.15.0.10-1.mga8.x86_64: unsatisfied /usr/sbin/alternatives[*]
$ rpm -q -f /usr/sbin/alternatives chkconfig-1.14-1.mga8 $ rpm -q --provides chkconfig /sbin/chkconfig /sbin/update-alternatives /usr/sbin/chkconfig /usr/sbin/update-alternatives alternatives = 1.14-1.mga8 chkconfig = 1.14-1.mga8 chkconfig(x86-64) = 1.14-1.mga8 update-alternatives = 1.18.1-1 It looks like it should be requiring %{_sbindir}/update-alternatives rather then %{_sbindir}/alternatives I don't understand why it impacts a netinstall, but not other install methods.
Yes, bug 29624 was reintroduced here: https://svnweb.mageia.org/packages/updates/8/java-11-openjdk/current/SPECS/java-11-openjdk.spec?r1=1760807&r2=1863576 (see line 433 to 439) (In reply to Dave Hodgins from comment #6) > I don't understand why it impacts a netinstall, but not other install > methods. urpm resolves dependencies in an arbitrary and undefined order. If the package containing /usr/sbin/alternatives has already been selected, that file requirement will be met without having to select anything else. So it's a matter of luck whether you hit this bug or not.
CC: sysadmin-bugs => mageiaAssignee: isobuild => javaSummary: m8 netinstall failing. Dependencies loop? => Java-11 update packaging bug makes new system installs fail
my bad. Looking at it.
CC: (none) => mageia
CC: (none) => andrewsfarm
(In reply to Martin Whitaker from comment #7) > > (In reply to Dave Hodgins from comment #6) > > I don't understand why it impacts a netinstall, but not other install > > methods. > > urpm resolves dependencies in an arbitrary and undefined order. If the > package containing /usr/sbin/alternatives has already been selected, that > file requirement will be met without having to select anything else. So it's > a matter of luck whether you hit this bug or not. Before asking for help on the QA ML, I tried two mirrors with three tries on one and two on the other, using wired and wireless connections, all of which failed in the same way. With a run of luck like that, I'd better avoid playing the lottery for a while...
With the same starting conditions (mirrors in sync, same package selection, etc.) it probably is deterministic. But it could easily change when new updates arrive and the media synthesis files are regenerated.
(In reply to Martin Whitaker from comment #10) > With the same starting conditions (mirrors in sync, same package selection, > etc.) it probably is deterministic. But it could easily change when new > updates arrive and the media synthesis files are regenerated. So the mere act of pushing the update meant to fix the problem could make it seem to disappear even if it isn't actually fixed? I tested the previous incarnation of this bug, and don't remember doing it now, but it appears that all I did was try a vbox install before the bug was pushed, then again after, so how do we know that test was valid?
(In reply to Thomas Andrews from comment #11) > So the mere act of pushing the update meant to fix the problem could make it > seem to disappear even if it isn't actually fixed? > > I tested the previous incarnation of this bug, and don't remember doing it > now, but it appears that all I did was try a vbox install before the bug was > pushed, then again after, so how do we know that test was valid? Unfortunately we don't. Looking back at bug 29624 comment 7, I couldn't reproduce it even before it was fixed. The best we can do is check 'urpmq --requires' no longer lists /usr/sbin/alternatives. In general Mageia uses package-level, not file-level, provides & requires (there are a few exceptions, like /bin/sh), So seeing an individual file listed by 'urpmq --requires' is often the sign of a packaging bug (most commonly caused by importing a spec file from Fedora).
If not very soon fixed, IMO this is an item for errata. (New users should look there when install (or upgrade) fail) even when the problem is not on the released media. (very hard to know for users)
Keywords: (none) => FOR_ERRATA8CC: (none) => fri
(In reply to Morgan Leijström from comment #13) > If not very soon fixed, IMO this is an item for errata. > (New users should look there when install (or upgrade) fail) even when the > problem is not on the released media. (very hard to know for users) Now that we know the cause, it should be fixed shortly, so it's not needed in the errata.
Keywords: FOR_ERRATA8 => (none)
Wouldn't it be easier to add a provides for /sbin/alternatives to chkconfig? Might make it easier to keep java synced with Fedora.
new java 11 is on the BS.
Ready to assign to qa?
I noticed bug too trying to make new Vbox install of Mageia. How this fixed Java can be tested with netinstall that it fixes that problem. ?
CC: (none) => ottoleipala1
You could try to enable core_updates_testing repo during update (with the effect of installing also other testing packages)
Trying to use packages from updates testing during a netinstall does not work. There is no way to enable the testing repos. Once this is assigned to qa, it'll just be tested for regressions with some java applications, then validated and pushed to updates. Only when that's done can the netinstall be tested. I've already tested this update, if there are no additional changes planned and it gets assigned to qa.
(In reply to Morgan Leijström from comment #19) > You could try to enable core_updates_testing repo during update > (with the effect of installing also other testing packages) Netinstall????
(In reply to Dave Hodgins from comment #20) > Trying to use packages from updates testing during a netinstall does not > work. > There is no way to enable the testing repos. > > Once this is assigned to qa, it'll just be tested for regressions with some > java applications, then validated and pushed to updates. Only when that's > done can the netinstall be tested. > > I've already tested this update, if there are no additional changes planned > and > it gets assigned to qa. Good to know thanks.
(In reply to Dave Hodgins from comment #17) > Ready to assign to qa? Ping
*** Bug 30745 has been marked as a duplicate of this bug. ***
CC: (none) => ole.reier.ulland
Assignee: java => qa-bugs
Validating the update. As above, tested several java packages to ensure no regressions. Will retest a netinstall after this update has been pushed since there is no way to enable to testing repositories during a netinstall. Advisory committed to svn as ... type: bugfix subject: Updated java-11-openjdk packages fix netinstall src: 8: core: - java-11-openjdk-11.0.15.0.10-1.2.mga8 description: | Changes requires for /usr/sbin/alternatives to match what chkconfig provides, requiring /usr/sbin/update-alternatives instead. Should allow netinstall to work properly. references: - https://bugs.mageia.org/show_bug.cgi?id=30731
CC: (none) => sysadmin-bugsKeywords: (none) => advisory, validated_updateWhiteboard: (none) => MGA8-64-OK
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGAA-2022-0111.html
Resolution: (none) => FIXEDStatus: NEW => RESOLVED
Tested a vb nonfree netinstall using the princeton mirror. Completed a plasma x86_64 install with tainted repos (no 32bit repos) without error except a double free error when rebooting after the install. Booted to the installed system ok after removing the iso from the optical drive.
Tested too this in Vbox with princeton mirror custom minimal icewm install working...