Created attachment 8637 [details]
phone picture of error

(F2 did not save picture during install)

Created attachment 8638 [details]
installer bug report

Created attachment 8639 [details]
updates.log

Because I am not sure it is included in report.bug.xz

Did it work in Mageia 5 ISOs?

(In reply to Samuel Verschelde from comment #4)
> Did it work in Mageia 5 ISOs?

Yup it worked in 5 final and latest 6 RC too

Assigning to stage2 for now, so that Thierry will look at the logs, figure out what's wrong and then reassign :-)


Don't know if this matters:

[marja@localhost ~]$ xzcat report.bug19742.xz | grep udisks | grep -v "udisks2" | wc -l
18
[marja@localhost ~]$ xzcat report.bug19742.xz | grep udisks2 | wc -l
40
[marja@localhost ~]$ 

(In my most recent Mageia 5 network install, only udisks2 + matching library was installed, udisks wasn't)

Should it be no problem to have both?

CC: (none) => marja11, thierry.vignaud
Assignee: bugsquad => mageiatools
Source RPM: classical 64 bit iso dated 08 Nov 2016 => drakx-installer-stage2-16.105.2-1.mga5

(In reply to Dick Gevers from comment #5)
> (In reply to Samuel Verschelde from comment #4)
> > Did it work in Mageia 5 ISOs?
> 
> Yup it worked in 5 final and latest 6 RC too

That's quite possibly because before release there are no updates available. I've just tried repeating the experiment with the released Mageia-5-i586-DVD.iso, and get the same error.

Repeating the process with the Mageia-5.1-x86_64-DVD.iso, but going into the TTY after adding the on-line media and before performing updates and removing the CDROM entries from urpmi's list of media allowed the updates to be performed without error.

CC: (none) => mageia

To double check, I swapped the roles and repeated the exercise. This time the mga5 ISO (with CDROM media removed) updated successfully and the mga5.1 ISO (with CDROM media retained) failed.

I'll also note that a GNOME only install didn't suffer from this bug. My guess is one of the updates is pulling in a new dependency which is found on the original media.

For me there were 57 Mb, 80 packages to be updated as I already wrote above in my original description.

But this did not work in the current 5.1 iso.

It did, however, work in several dozen iterations of 5.0: every alpha, beta or r.c. that was in any way succesful....

(In reply to Dick Gevers from comment #9)
> It did, however, work in several dozen iterations of 5.0: every alpha, beta
> or r.c. that was in any way succesful....

Yes, but at that time there would have been nothing in the updates repositories, so nothing to update...

But as noted in comment 8, what seems to be the trigger for this bug is an update that pulls in a new dependency that can be found in the original release, at which point the installer attempts to read that package from the CDROM, and fails because the udisk daemon is not running.

(In reply to Martin Whitaker from comment #10)

> Yes, but at that time there would have been nothing in the updates
> repositories, so nothing to update...

Nope usually was!

(In reply to Dick Gevers from comment #11)
> (In reply to Martin Whitaker from comment #10)
> 
> > Yes, but at that time there would have been nothing in the updates
> > repositories, so nothing to update...
> 
> Nope usually was!

Solved that mystery - when checking for updates at the end of installation, it looks at all media, not just update media. Pre-release, there will be plenty of new versions appearing in the release repositories.

Back to the main problem. I don't think it's possible to get the udisks daemon to run at this stage, so cdrom media are not going to be accessible. I can think of two possible solutions to this:

1) Disable the cdrom media when adding the on-line media. This also removes the annoyance of being prompted to insert the CDROM when installing software after booting the system.

2) Use the --excludemedia option to temporarily disable the cdrom media.

Thierry, what do you think? (see the second paragraph of comment 10 if you've lost track of the problem we need to fix)

Created attachment 8660 [details]
use only update media

Or else we can try sg like this (untested)

No, that still fails the same way. I think --update still allows dependencies to be taken from any media. Testing in the installer shell,

urpmi --auto-select --excludemedia "Core Release,Nonfree Release"

works, but gurpmi doesn't support the --excludemedia option.

It would be simpler to just add an option for ignoring removable media

Installed public 32-bit Mageia 5 on EFI [64-bit] hardware from USB, taking the suitable precautions. I hit this Udisks error near the end when accepting immediate updates. It did successfully a list of 'essentials', then proposed the much bigger list of the rest. Whence the Udisks error.
After which the installation went to end OK.

Re-booting the result does not complete: it seizes after no obvious errors [not related to this bug]. Hoping to resolve this by completing the updates, in 'rescue' mode I tried:
 # urpmi --auto-update
which threw the Udisks error.
I might try --auto-select --excludemedia "Core Release,Nonfree Release" as per Comment 14. If that does not work re-do the installation with *no* immediate update, and try updating from the installed system - if it works.

CC: (none) => lewyssmith

I forgot to say that my last - and good - x64 Classic Mageia 5.1 installation (EFI real h/w from, I think USB) did not give this problem on doing its immediate updates; some 90 IIRC. I may have remembered to disable first the installation media, though.

I just ran an install test under vb using the 5.1 x86_64 dvd, and did not
encounter this problem. Updates were successful at the end stage of the
installation.

We need a better understanding of what triggers the issue.

CC: (none) => davidwhodgins

(In reply to Dave Hodgins from comment #18)
> We need a better understanding of what triggers the issue.

For the TL;DR version, see last paragraph of comment 10.

To spell it out in more detail, after you choose to add on-line repositories at the end of the installation, urpmi will have a list of active media like this:

Core Release cdrom://x86_64/media/core
Nonfree Release cdrom://x86_64/media/nonfree
Core Release2 http://.../5/x86_64/media/core/release
Core Updates http://.../5/x86_64/media/core/updates
Nonfree Release2 http://.../5/x86_64/media/nonfree/release
Nonfree Updates http://.../5/x86_64/media/nonfree/updates
Core 32bit Release http://.../5/i586/media/core/release
Core 32bit Updates http://.../5/i586/media/core/updates
Nonfree 32bit Release http://.../5/i586/media/nonfree/release
Nonfree 32bit Updates http://.../5/i586/media/nonfree/updates

Note there are two active media each for core release and nonfree release, with the ones on the installation media listed first, and hence taking precedence.

When you then choose to update the installed packages, the installer will search all the above media for newer versions of the packages installed. For installed packages themselves, it should only ever find newer versions in the updates media (that's only true for a stable release - before that, the on-line release media are quite likely to have changed after the ISO you're testing was built).

However, those new versions may introduce new dependencies that weren't present in the original release of the package, and if those dependencies haven't themselves been updated in the meantime, they will be found in the release media, not the update media. So the installer will try to read them from the installation media (because they take precedence), and because the udisks daemon isn't running, fails.

An example of a package that triggers this bug is lib64xcb-devel. This tries to install lib64xau-devel, which is only available in core/release, not core/updates. So if you select the Development category during installation, you should see this bug.

Another example that will trigger this bug is abiword, which introduces a dependency on lib64aiksaurus.

(all the above examples are taken from a 64-bit installation - adjust names as appropriate for 32-bit)

Same happened with 64 bits classical iso dated 2211

And happed with 6sta2 32 bits iso dated 11.01.2017

Keywords: (none) => 6sta2
Summary: [5.1] Near end of installer process updates fail due to udisks-daemon not running => Near end of installer process updates fail due to udisks-daemon not running

We could disable DVD Sources (aka urpmi.removemedia -a) prior to adding online media for updates.

Created attachment 8862 [details]
remove media priror to add online media

If someones want to try...

i have not tested but this is exactly what i wanted :) ( https://bugs.mageia.org/show_bug.cgi?id=16002#c20 )

CC: (none) => mageia

Better late than never...

Having just stumbled across this bug again, I've tested the attached patch and can confirm it fixed this bug for me. Tested on the Mageia-6-x86_64-DVD ISO.

As we need a drakx update to fix bug 23393 for the 6.1 ISOs, it would be good to include the fix for this bug as well.

@Thierry, WDYT?

Not seen with M7 B3 Round 2 - probably earlier - closing

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

I don't see this in 7 rc anymore: closing