Bug 19742 - Near end of installer process updates fail due to udisks-daemon not running
Summary: Near end of installer process updates fail due to udisks-daemon not running
Status: NEW
Alias: None
Product: Mageia
Classification: Unclassified
Component: Installer (show other bugs)
Version: Cauldron
Hardware: All Linux
: High major
Target Milestone: ---
Assignee: Mageia tools maintainers
QA Contact:
URL:
Whiteboard:
Keywords: 5.1, 6sta2, PATCH
Depends on:
Blocks:
 
Reported: 2016-11-08 20:27 CET by Dick Gevers
Modified: 2017-01-16 15:30 CET (History)
6 users (show)

See Also:
Source RPM: gurpmi
CVE:
Status comment: Patch to be tested: removes installation media (including DVD) before adding media at the end of installation


Attachments
phone picture of error (62.51 KB, image/jpeg)
2016-11-08 20:34 CET, Dick Gevers
Details
installer bug report (213.00 KB, application/x-xz)
2016-11-08 20:42 CET, Dick Gevers
Details
updates.log (31.61 KB, text/plain)
2016-11-08 20:44 CET, Dick Gevers
Details
use only update media (697 bytes, patch)
2016-11-14 22:25 CET, Thierry Vignaud
Details | Diff
remove media priror to add online media (482 bytes, patch)
2017-01-16 11:00 CET, Thierry Vignaud
Details | Diff

Description Dick Gevers 2016-11-08 20:27:26 CET
Description of problem:

Use classical iso dated Tue Nov  8 11:28:45 CET 2016 (hardware per
https://wiki.mageia.org/en/QA_iso_hardware_list --> Notebooks --> dvgevers)

Select not GNOME/KDE but custom (all clients and desktops, no servers)

Install 5.1 (new install) and finish with trying to install updates.

After media are updated, 57 MB being 80 packages may be updated. When continuing with button "Ok" an error occurs reading:
quote
Udisks daemon (udisks-daemon) is not running or not ready
unquote

I will attach a picture if found in root (did not say so) and report from /root/drakx

IMHO this is major or higher
Comment 1 Dick Gevers 2016-11-08 20:34:01 CET
Created attachment 8637 [details]
phone picture of error

(F2 did not save picture during install)
Comment 2 Dick Gevers 2016-11-08 20:42:41 CET
Created attachment 8638 [details]
installer bug report
Comment 3 Dick Gevers 2016-11-08 20:44:09 CET
Created attachment 8639 [details]
updates.log

Because I am not sure it is included in report.bug.xz
Comment 4 Samuel Verschelde 2016-11-09 09:34:06 CET
Did it work in Mageia 5 ISOs?
Comment 5 Dick Gevers 2016-11-09 10:13:54 CET
(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
Comment 6 Marja van Waes 2016-11-09 21:54:36 CET
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?
Comment 7 Martin Whitaker 2016-11-13 23:12:11 CET
(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.
Comment 8 Martin Whitaker 2016-11-13 23:38:25 CET
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.
Comment 9 Dick Gevers 2016-11-14 00:33:38 CET
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....
Comment 10 Martin Whitaker 2016-11-14 09:25:28 CET
(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.
Comment 11 Dick Gevers 2016-11-14 10:14:45 CET
(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!
Comment 12 Martin Whitaker 2016-11-14 21:43:55 CET
(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)
Comment 13 Thierry Vignaud 2016-11-14 22:25:08 CET
Created attachment 8660 [details]
use only update media

Or else we can try sg like this (untested)
Comment 14 Martin Whitaker 2016-11-15 00:38:32 CET
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.
Comment 15 Thierry Vignaud 2016-11-16 15:43:10 CET
It would be simpler to just add an option for ignoring removable media
Comment 16 Lewis Smith 2016-11-16 17:27:57 CET
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.
Comment 17 Lewis Smith 2016-11-16 17:33:51 CET
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.
Comment 18 Dave Hodgins 2016-11-16 19:31:03 CET
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.
Comment 19 Martin Whitaker 2016-11-17 01:36:48 CET
(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)
Comment 20 Dick Gevers 2016-11-23 11:21:56 CET
Same happened with 64 bits classical iso dated 2211
Comment 21 Dick Gevers 2017-01-12 16:43:27 CET
And happed with 6sta2 32 bits iso dated 11.01.2017
Comment 22 Thierry Vignaud 2017-01-16 10:58:40 CET
We could disable DVD Sources (aka urpmi.removemedia -a) prior to adding online media for updates.
Comment 23 Thierry Vignaud 2017-01-16 11:00:32 CET
Created attachment 8862 [details]
remove media priror to add online media

If someones want to try...
Comment 24 Nicolas Lécureuil 2017-01-16 15:30:02 CET
i have not tested but this is exactly what i wanted :) ( https://bugs.mageia.org/show_bug.cgi?id=16002#c20 )

Note You need to log in before you can comment on or make changes to this bug.