Created attachment 12974 [details]
Bug in netinstall Iso installation

The bug appears during packages search, after partition process.

Thank you for the report, and sorry for the angst.
Did you try the suggestion "Try again with '-vv --debug' options" ?

CC'ing the Mageia Tools group so they can give advice about how to pursue this.

CC: sysadmin-bugs => lewyssmith, mageiatools

Bug confirmed.

Workaround is to press the ok button, select the partitions again, after which
it works.

I stopped my test at the point of selecting which desktop environment to install
(I'd unselected the format partitions, and didn't want to spend too much time
on the test).

I think the bug is in the drakx-installer-stage2 package.

CC: (none) => davidwhodgins

I used Mageia-8-netinstall-nonfree-x86_64.iso from the princeton mirror for my
test.

-rw-rw-r-- 1 dave dave 125829120 Nov  4 16:39 Mageia-8-netinstall-nonfree-x86_64.iso

Thanks for the input, Dave.
Can you say where/how to use the diag options suggested?

I have tried the solution in comment 3, but don't work.

I don't know where to put the parameters that Lewis indicates in comment 2, and what I am clear about is that this is a serious problem for a user who comes to Mageia and tries to install from the netinstall iso.

I hope that the devs can fix this bug early.

Greetings!!

I can't reproduce. Two installations from USB stick on real hardware, one using FTP from my local mirror (sync'd to distrib-coffee), the other using HTTP from the princeton mirror. Both completed a default Plasma install without error.

I have never been able to complete a Mageia 8 net install in Vbox - somewhere along the line a FTP transaction takes too long and times out. It's a different package each time. But that's always been the case running on my machines.

CC: (none) => mageia

The error message in attachement is about resolving dependencies.

So it is interesting to know what selections you have made regarding packages to install (or does this comes up before that?), and what mirror you use.

That goes for Dave in Comment 3 as well.

And yes how to get debug output?

CC: (none) => fri

The "Try again with '-vv --debug' options" is a generic error message from urpmi. You can't do that in the installer.

To get debug output, it's the standard method for the installer. When the error occurs, Ctrl-Alt-F2 to switch to the debug shell, insert a formatted USB stick in another USB socket, and enter the command "bug". That should write a report.bug file to the USB stick, which you should compress and attach to this ticket.

These are the option that i mark always:

- I select ftp or http server: free.fr
- I select erase all disk
- I select all instalation media, x86_64 and i586 that the system suggest me.

And later, the system start search packages for instalation, here it crash and appears the warning of the attachment.

Really, I think that this options are the most normal for a installation in a clean disk or new pc.

I guess Dave used princeton, which if so rules out single mirror fault. 

José, have you tried with updates repos enabled?
(I dont remember if they are usually suggested or not.  IMO they should be)

Precisely the corresponding updates repos for the other corresponding repos.
(should work without, but personally that is what I usually use)

Hi,

I put here a link to report bug. I don't attach it beacuse it is very big.

https://mega.nz/file/n0cm3bqZ#nklRB8SN18_DhoabXsbN1zH_XeCq_AcDDsHONKhYNHI

As I said, compress the file before attaching it, e.g.

  xz report.bug

will produce report.bug.xz.

To me, the normal thing is to keep the default selection of media. 32-bit media should only be enabled if you really need them. And it is enabling both 32-bit and 64-bit Core updates that allows this bug to be reproduced.

In fact the root cause can be seen even without the 32-bit media enabled, although then it just means some packages don't get installed rather than going into a dependency loop. From your report.bug:

* selecting java-11-openjdk-headless-11.0.11.0.9-0.1.mga8.x86_64
* requiring /usr/sbin/alternatives[*],copy-jdk-configs[>= 4.0],javapackages-filesystem,lksctp-tools(x86-64),rootcerts-java,timezone-java[>= 2021a] for java-11-openjdk-headless-11.0.11.0.9-0.1.mga8.x86_64

then

* no packages match /usr/sbin/alternatives[*] (it is either in skip.list or already rejected)
* unselecting java-11-openjdk-headless-11.0.11.0.9-0.1.mga8.x86_64
* unselecting java-11-openjdk-11.0.11.0.9-0.1.mga8.x86_64
* unselecting libreoffice-ure-7.2.2.2-1.mga8.x86_64
* unselecting libreoffice-core-7.2.2.2-1.mga8.x86_64
* unselecting libreoffice-gtk3-7.2.2.2-1.mga8.x86_64
* unselecting libreoffice-kf5-7.2.2.2-1.mga8.x86_64
* unselecting libreoffice-langpack-es-7.2.2.2-1.mga8.x86_64
* adding a reason to already rejected package java-11-openjdk-headless-11.0.11.0.9-0.1.mga8.x86_64: unsatisfied /usr/sbin/alternatives[*]

The dependency loop is a reaction to this failure.

In my case, I did not format the partition with an existing m8 install on it.

As that install has some 32 bit and tainted packages installed, the installer
chose to enable all release and updates repos including the 32 bit repos,
which I accepted.

Immediately after that, the error occured while the installer is first preparing
the list of package groups (desktop environment, etc.) for the user to select
from, before the user has the option to make any selections.

Once it got past that error, and presented the list of package groups to select
from, I aborted the install to prevent any actual writes to the existing install.

I was using http://mirror.math.princeton.edu/pub/mageia/distrib/8

Given comment 13, I gather the cause has been found.

(In reply to Dave Hodgins from comment #14)
> Given comment 13, I gather the cause has been found.

Yes, it's a packaging bug in the updated java-11-openjdk-headless package.

Thank you all for reporting and analysis

So no new ISO needed :)

Setting that package, and CC:ing its maintainer

CC: (none) => mageia
Source RPM: Iso Netinstall => java-11-openjdk-headless

Many thanks to contributors.

CC: lewyssmith => (none)
Assignee: bugsquad => java

sorry for the late answer. 

a Fixed package is in the BS currently.

Assignee: java => qa-bugs

Nicolas, optimally you shoukld tell what packages QA should test.

Basically i think we should install the new java-11 packages and see nothing breaks, then try network install without testing repo and see it fail, then retry with updates_testing enabled and it should work.  Preferably both x86 and i586.

I see also java-1.8.0 built a few hours ago but no bug opened yet. Is that completely separate from this bug?

Summary: Java update packaging bug makes system installs and upgrades to fail => Java-11 update packaging bug makes system installs and upgrades to fail

Yes for java 8 this is a security release ( java 8/11 ) : https://bugs.mageia.org/show_bug.cgi?id=29590

maybe both bugs should be merged in one as the other one is about java 11 too.

Ah, thanks.  Good idea.  Closing this as duplicate, adding priority and tests to be done on the other bug, and calling QA list for testers.

*** This bug has been marked as a duplicate of bug 29590 ***

Resolution: (none) => DUPLICATE
Status: NEW => RESOLVED

Reopening in order to better/easier test install after bug 29590 is pushed to normal updates.

See that bug c 13, 16

Resolution: DUPLICATE => (none)
Depends on: (none) => 29590
Status: RESOLVED => REOPENED

moving of QA list as it references another bug with the actual rpms

Assignee: qa-bugs => java

Waited to be sure the rpms had time to reach the Princeton mirror, then attempted a new 64-bit net install of Plasma in VirtualBox. 

At the step where the user selects the repos to be active, I selected all of them, including 32-bit ones. In a previous test in bug 29590, this generated the error. This time, there were no errors, and the install was successful.

I believe this bug can now be closed (fixed or works for me?), but it wouldn't be a bad idea if someone else tried it, just in case.

CC: (none) => andrewsfarm

This belongs to QA to verify if the now released packages from bug 29590 fixed the problem here in 29624.

Test OK for 64 bit in comment 25, thanks.
So this is *probably* solved by the java-11 packages of bug 29590.

Yes another test would be perfect, preferably on 32 bit.

Assignee: java => qa-bugs

Tested in VirtualBox, creating a 32-bit Plasma guest, using the desktop586 kernel, from the net install iso.

Did a test very similar to the one done in Comment 24, except for 32-bits. No issues encountered, and I was able to boot into a working desktop. Just for good measure, I started Libreoffice and ran a couple of the tools without issue.

I'm putting up OKs and validating. If that's not correct for this bug, please adjust accordingly, and close the bug in whatever is the appropriate manner.

Whiteboard: (none) => MGA8-64-OK MGA8-32-OK
Keywords: (none) => validated_update
CC: (none) => sysadmin-bugs

Thank you for the tests :)

Packages are already pushed in bug 29590.

Resolution: (none) => FIXED
Status: REOPENED => RESOLVED