Created attachment 4385 [details]
report.bug.xz

Adding report.bug.xz

Are you sure you didn't say "no" to "You now have the opportunity to download updated packages"?

Keywords: (none) => NEEDINFO

Yes I did say no, to test the ISO rather than current cauldron.

We only add the media prior to installing the updates

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

Ahh yes, you're right. They are only added if medias are added at the start of installation or updates at the end.

Thanks Thierry, I'd forgotten.

No problem.
BTW next installer will explicitely log that user rejected the updates.

cat drakx/updates.log 
Error getting authority: Error initializing authority: Could not connect: No such file or directory

Even if you do select install updates, the media are not
added.

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

Created attachment 4428 [details]
report.bug.xz

Note that I did configure/start the network during
the summary screen.

I've been investigating this, with the latest dual-cd.
At the point where the installer says to reboot, the command
"exec /usr/bin/pkexec /usr/libexec/drakrpm-addmedia $*" fails.
Running pkexec anycommand (in the chroot), fails. After reboot, into the
installed system, the command works, so it isn't anything missing.
The only difference I can see between being in the installer, and being
in the booted system (logged in as root, and then using startx), is that
in the booted system, "cat /proc/self/loginuid" is returning 0, while in
the installer, it's returning a 10 digit number.

CC: (none) => eeeemail, mageia, tmb

From http://unix.stackexchange.com/questions/61945/how-do-i-write-a-login-daemon
The auid is typically set using pam_loginid. To guarantee it is set even when PAM is not configured correctly, write the user's uid to /proc/self/loginuid.

In the installed system, /etc/pam.d/login has
session    required     pam_loginuid.so

As that file is owned by util-linux, maybe it's just a matter of adding that
package to stage2 (or maybe stage 1), so that pkexec will work.

Note that a quick fix would be to have the installer call
/usr/libexec/drakrpm-addmedia directly, instead of calling gurpmi.addmedia.

Thanks Dave - looks like another one of mine :(

Yeah I think either the quick fix or a chroot friendly UID check in the wrapper script that actually calls pkexec. I think the latter might be quite nice for other reasons (i.e. when mounting via chroot).

I doubt just adding the loginuid pam module would help as pkexec would still need to talk to a polkitd deamon and read policy - none of which is infrastructure stage2 currently carries AFAIK.

If someone feels like poking at this, all that is needed is to edit the Makefile here: http://gitweb.mageia.org/software/rpmdrake/tree/polkit/Makefile

Currently it generates something like:

#!/bin/sh
exec /usr/bin/pkexec /usr/libexec/drakrpm-addmedia $*


After modification it should generate something like:

#!/bin/sh
PK=
[[ "$UID" != "0" ]] && PK=/usr/bin/pkexec
exec $PK /usr/libexec/drakrpm-addmedia $*

This should just be a noop script if you are already root which is the case in the installer. It has the added benefit of working as a command when used in a chroot (which wouldn't have polkitd running and thus would fail).

This makefile i copied around a few repos but if someone wants to fix this one that can then be copied to the others.

If no one else does, I'll do it sometime next week!

A third option would be to change pkexec to call geteuid, instead of
reading /proc/self/loginuid, as the command "id -u" does, which does
return 0, in the installer environment.

AFAIK pkexec still needs to do the whole dbus round trip anyway so this won't really help AFAICT

Also, this has further repercussions on security and audit stuff too, and was actually discussing this stuff with Colin Walters earlier today on an unrelated issue!

Anyway I think the wrapper fix would be the easiest, self-contained option for us.

Created attachment 4498 [details]
Patch to skip using pkexec if already root.

Untested, but I think this patch will work.

Comment on attachment 4498 [details]
Patch to skip using pkexec if already root.

Thing the $(id -u) bit might be interpreted by make - certainly it looks like a make variable which are interpreted else where.

I would just use $UID which save forking off a process to call id -u...

While the patch is clearly not working, I'm curious why you've
chosen to use the Makefile to generate a script, instead of
keeping the script in place, but adding something like

ThisScript="$0"
if  [[ ! ${ThisScript:0:1} = '/' ]] ; then
    ThisScript="$(pwd)/$0"
fi
if  [[ "$(id -u)" != "0" ]] ; then
    exec pkexec "$ThisScript" "$@"
fi

to the beginning of the script?  It's a royal pain to figure
out how to escape things in a Makefile, to generate an appropriate
bash script.

The online media are now being added, during install, but updates still fail with
Error getting authority: Error initializing authority: Could not connect: No such file or directory
So whatever command the installer is calling to actually install the updates,
is likely also using pkexec, and failing.

Should I open a new bug report about that?

It's OK Dave, I will push the same fixes to all the other polkit places in drakx which I suspect will sort things out.

If it's still a problem in beta2 then definitely shout (or generally just beat me with a stick!)

(In reply to Dave Hodgins from comment #19)

In order to install updates, installer runs commands in the chrooted system (unlike the regular install where stage2 is basically "urpmi --urpm-root=/mnt basesystem <whatever_you_selected>").

In the chroot, we first try to run gurpmi.addmedia or urpmi.addmedia (the first found).
Then we run gurpmi or urpmi (the first found) (in the chroot too).

Cool, so just copying the polkit/Makefile (or at least the wrapper script creation rule) from drakrpm to urpmi should sort this.

Will get around to that tomorrow or Sunday if no-one beats me to it.

Hmmm, actually no, all those commands should already be done (the g* ones are in drakrpm) and urpmi.addmedia isn't wrapped. Is urpmi.update run at all?

No. And there's no reason to do so.
See http://gitweb.mageia.org/software/drakx/tree/perl-install/any.pm#n946

Thierry, We've changed topics in this bug report. It's no longer
about the online media getting added, it's now about the updates
actually getting installed after the media are added, which is
failing with "Error getting authority", just like the adding of
the media was doing previously, which is why I suspect it's
another pkexec problem. I have have a hard time following the
installer code (I really dislike perl), so I'm not clear on
what it's running, to actually install the updates.

I've changed the bug title accordingly.

Summary: Online medias are not added during install => Updates are not installed, at end of installation, using classical installers

I did understand that and my comment stand for.
See the link I provided.
1) First we do some basic checkings (have we network, ...=
2) then we add media with {g,}urpmi.addmedia

BTW I was mistaken: we do run urpmi.update.
Blino added this (http://gitweb.mageia.org/software/drakx/commit/?id=810c20b3)
We should drop that IMHO since I fixed urpmi (version 7.27)

Then, in another sub, we apply updates with {g,}urpmi --auto-select

Ahh cool. Then this should fail if the user has installed mgaonline then. The latest build of mgaonline should solve this problem so even if the code stays it should be OK once that is pushed (requested on Sunday, but not pushed yet AFAICT)

Hmm, actually I don't see my freeze push mail... perhaps I never sent it :s

With first beta2 x86_64 iso, from /root/drakx/updates.log
Error getting authority: Error initializing authority: Could not connect: No such file or directory

Whiteboard: 4beta1 => 4beta1 4beta2

(In reply to Dave Hodgins from comment #29)
> With first beta2 x86_64 iso, from /root/drakx/updates.log
> Error getting authority: Error initializing authority: Could not connect: No
> such file or directory

I think this would be fixed by:

http://gitweb.mageia.org/software/mgaonline/commit/?id=fe658b9e9ad0cae32f922c0bc887636f42cf5b4c

It should only apply if your installation packages include mgaonline and thus have a urpmi.update in the /usr/bin/ path which is found before the one in /usr/sbin/ provided by urpmi itself.

With the above link, this problem should be avoided for an already root user.

It's also something that Thierry thought could be removed from the installer (the shelling out to call urpmi.update) as it's unnecessary.

Could be wrong on the above point but either way, I think this would be fixed. One way to test would be to do the install up to the point just before the problem occurs. In the tty, install the updated mgaonline package manually, then continue the install. If the rest of the updates are installed OK, then all is well!

(In reply to Colin Guthrie from comment #30)
> Could be wrong on the above point but either way, I think this would be
> fixed. One way to test would be to do the install up to the point just
> before the problem occurs. In the tty, install the updated mgaonline package
> manually, then continue the install. If the rest of the updates are
> installed OK, then all is well!

Difficult to do with the classical installers. Stage2 would have to be rebuilt
with the update.

Gah, true, my brain is not screwed on right today!

I guess one way to test currently is if it work OK, when mgaonline is NOT installed... e.g. switch to the tty and do a quick rpm -e, or just mv the /usr/bin/urpmi.update out the way temporarily (or edit it to be like the latest one shipped).

Or just wait for the next beta  :)

The change in comment 30 is included already.

The error message appears to be coming from
/usr/libexec/polkit-gnome-authentication-agent-1

Trying to run it in the tty returns the error
error XDG_RUNTIME_DIR not set in the environment

Also, after running "chroot /mnt" in the tty, uprmi anypackage fails
with "Error: /usr appears to be mounted read-only"

/proc/mounts shows "/dev/loop0 /usr sqaushfs ro,relatime 0 0"

(In reply to Dave Hodgins from comment #33)
> The change in comment 30 is included already.

Interesting, I thought the ISOs were spun before these changes were pushed (on the 19th).

> The error message appears to be coming from
> /usr/libexec/polkit-gnome-authentication-agent-1

Hmmm, I'm confused. Why is the polkit-gnome-authentication-agent-1 being launched in the installer? It doesn't come with any kind of bus activation AFAICT (and the package itself should die anyway) so I don't see why it's being started nor what starts it...

There should basically be no agent not any polkitd running in the installer IMO.

> Trying to run it in the tty returns the error
> error XDG_RUNTIME_DIR not set in the environment

This makes sense as an error, but I don't understand why it's being run in the first place.


(In reply to Dave Hodgins from comment #34)
> Also, after running "chroot /mnt" in the tty, uprmi anypackage fails
> with "Error: /usr appears to be mounted read-only"
> 
> /proc/mounts shows "/dev/loop0 /usr sqaushfs ro,relatime 0 0"

I saw a similar error doing something similar. Dunno why, perhaps /proc/mounts format changed in the kernel (it shouldn't change as such, but I remember an optional column that might show up and confuse any parsing of this info we currently do - could be the issue - the same issue affected dracut a while back).

cat /s3/m4/Mageia-4-beta2-x86_64-DVD/DATE.txt 
Tue Nov 26 20:59:30 CET 2013

Here's the output of sort /proc/mounts, just before the checking for
updates, from the installer tty (not in the chroot) ...
/dev/loop0 /tmp/stage2 squashfs ro,relatime 0 0
/dev/loop0 /usr squashfs ro,relatime 0 0
devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
/dev/sda1 /mnt ext4 rw,relatime,data=ordered 0 0
/dev/sr0 /tmp/media iso9660 ro,relatime 0 0
devtmpfs /dev devtmpfs rw,nosuid,size=2011812k,nr_inodes=502953,mode=755 0 0
devtmpfs /mnt/dev devtmpfs rw,nosuid,size=2011812k,nr_inodes=502953,mode=755 0 0
none /mnt/proc proc rw,relatime 0 0
none /mnt/sys sysfs rw,relatime 0 0
none /mnt/tmp/.X11-unix tmpfs rw,relatime 0 0
none /sysroot tmpfs rw,nosuid,nodev,relatime,mode=755 0 0
none /tmp/.X11-unix tmpfs rw,relatime 0 0
proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
rootfs / rootfs rw,size=2011800k,nr_inodes=502950 0 0
sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0
tmpfs /dev/.initramfs tmpfs rw,nosuid,nodev,mode=755 0 0
tmpfs /dev/shm tmpfs rw,nosuid,nodev 0 0
tmpfs /mnt/run tmpfs rw,nosuid,nodev,mode=755 0 0
tmpfs /mnt/run tmpfs rw,nosuid,nodev,mode=755 0 0
tmpfs /run tmpfs rw,nosuid,nodev,mode=755 0 0

Note that I do not have a separate /usr, in this test.

So something is going wrong that is causing /dev/loop0 to be mounted on /usr,
as well as on /tmp/stage2. Also /mnt/run is being mounted twice.

From http://gitweb.mageia.org/software/drakx/commit/?id=c4321813f9f3cd4136203d52c0f20343d7722228

+	if (mount(STAGE2_LOCATION "/usr", "/usr", "none", MS_BIND|MS_RDONLY, NULL))
+		fatal_error("Unable to bind mount /usr filesystem from rescue or installer stage2");

As the installer and rescue squashfs files never have a separate /usr,
why is this here?

It should be noted, that /mnt/usr is being bind mounted, before /mnt is mounted,
so the install works, anyway, but anything that checks /proc/mounts to see if
/usr is read only, will fail.

(In reply to Dave Hodgins from comment #38)
> From
> http://gitweb.mageia.org/software/drakx/commit/
> ?id=c4321813f9f3cd4136203d52c0f20343d7722228
> 
> +	if (mount(STAGE2_LOCATION "/usr", "/usr", "none", MS_BIND|MS_RDONLY, NULL))
> +		fatal_error("Unable to bind mount /usr filesystem from rescue or
> installer stage2");
> 
> As the installer and rescue squashfs files never have a separate /usr,
> why is this here?

This is how both rescue and the installer work when considering the initrd structure. In the past, the whole of the initrd's /usr was rm -rf'ed and replaced with a symlink into the /tmp/stage2/usr. In the recent revamp I've just replaced that with a bind mount to allow us to go back should we need (and at the time it was not done in a binary and couldn't be done atomically).

Due to this the code that detects readonly /usr seems to break. It doesn't actually check /usr within the root it's working in and check if it's a mount point. I'd argue the code that checks this (either in urpmi or rpm itself) is broken in that it doesn't validate the mounts properly.

That said, I could now go back to the rm -rf and symlink approach if this proves too hard to fix else where. It's now done in a binary again (the script based approach has now gone). All that said, I *want* to move to a different structure for both the installer and the rescue where they both do a proper pivot root. For rescue this is semi-easy but for the installer it's more work. Longer term it's a cleaner strategy.

(In reply to Dave Hodgins from comment #39)
> It should be noted, that /mnt/usr is being bind mounted, before /mnt is
> mounted,
> so the install works, anyway, but anything that checks /proc/mounts to see if
> /usr is read only, will fail.

Sorry, I don't grok the /mnt/usr being bind mounted bit. What do you mean here. /mnt/usr should not be bind mounted at any point. If it's s separate partition, it should be mounted directly as /mnt/usr and only after /mnt is mounted. Can you elaborate?

FWIW, anything that checks /proc/mounts to checks for read-only /usr should not really on parsing /proc/mounts. It should use proper checks - e.g. do whatever "mountpoint" does to check that a given location is or is not a mountpoint and look up the details via that mechanism.

So looking at libmount (and util-linux generally) it seems that the urpmi code for checking writeable /usr is using /proc/mounts whereas it *should* probably be using /proc/self/mountinfo which properly handles chroot environment stuff.

The following (untested) patch to urpmi might implement this:

diff --git a/urpm/sys.pm b/urpm/sys.pm
index bfe0e71..c9318c9 100644
--- a/urpm/sys.pm
+++ b/urpm/sys.pm
@@ -162,6 +162,11 @@ sub proc_mounts() {
     @l;
 }
 
+sub proc_self_mountinfo() {
+    my @l = cat_('/proc/self/mountinfo') or warn "Can't read /proc/self/mountinfo: $!\n";
+    @l;
+}
+
 sub trim_until_d {
     my ($dir) = @_;
     foreach (proc_mounts()) {
@@ -179,8 +184,8 @@ Checks if the main filesystems are writable for urpmi to install files in
 =cut
 
 sub check_fs_writable () {
-    foreach (proc_mounts()) {
-       (undef, our $mountpoint, undef, my $opts) = split ' ';
+    foreach (proc_self_mounts()) {
+       (undef, undef, undef, undef, our $mountpoint, my $opts) = split ' ';
        if ($opts =~ /(?:^|,)ro(?:,|$)/ && $mountpoint =~ m!^(/|/usr|/s?bin)\z!) {
            return 0;
        }

Untested is correct because I spelled the function name wrong when I called it, but I think it's still valid as a principle.

OK, I tested this principle and it seems to work OK. Thierry, is this OK to commit?

Separately, I don't think this is related to the problem of installing the updates OR the polkit agent issue, both of which seem tangential. The updates are not installed via urpmi on the command line as far as I know and the installer code doesn't seem to be affected by this same checks.

(In reply to Colin Guthrie from comment #40)

> Sorry, I don't grok the /mnt/usr being bind mounted bit. What do you mean
> here. /mnt/usr should not be bind mounted at any point. If it's s separate
> partition, it should be mounted directly as /mnt/usr and only after /mnt is
> mounted. Can you elaborate?

As soon as /usr/sbin/stage2-fake-switch_root is called,
/dev/loop0 is being bind mounted to /mnt/usr.

Simply boot the classic iso. Before selecting the language, switch to the
tty, and check /proc/mounts. It isn't mounted at the pre-pivot break point.

Once the partitions to install on, are selected, the root partition gets
mounted on /mnt, hiding the bind mounted /mnt/usr, so /usr is writable,
but the ro mount of /mnt/usr still shows up in /proc/mounts.
 
> FWIW, anything that checks /proc/mounts to checks for read-only /usr should
> not really on parsing /proc/mounts. It should use proper checks - e.g. do
> whatever "mountpoint" does to check that a given location is or is not a
> mountpoint and look up the details via that mechanism.

As it is a mount point (although hidden by the later mounting
of the root filesystem on /mnt), the check seems correct to me.

(In reply to Dave Hodgins from comment #44)
> (In reply to Colin Guthrie from comment #40)
> 
> > Sorry, I don't grok the /mnt/usr being bind mounted bit. What do you mean
> > here. /mnt/usr should not be bind mounted at any point. If it's s separate
> > partition, it should be mounted directly as /mnt/usr and only after /mnt is
> > mounted. Can you elaborate?
> 
> As soon as /usr/sbin/stage2-fake-switch_root is called,
> /dev/loop0 is being bind mounted to /mnt/usr.

Where? This certainly shouldn't be happening. I do bind mount /tmp/stage2/usr to /usr (no mention of /mnt/usr) as you quoted above in comment 40. As /tmp/stage2 is a loopback mount this makes things look like /dev/loop2 is mounted on /usr, but nothing should be doing anything with /mnt/usr.

> Simply boot the classic iso. Before selecting the language, switch to the
> tty, and check /proc/mounts. It isn't mounted at the pre-pivot break point.
> 
> Once the partitions to install on, are selected, the root partition gets
> mounted on /mnt, hiding the bind mounted /mnt/usr, so /usr is writable,
> but the ro mount of /mnt/usr still shows up in /proc/mounts.

OK, this is certainly more interesting. I don't see this in your /proc/mounts output in comment 37 tho' (only the expected /usr mount, no /mnt/usr). I'll have to look into this more to see what's happening.

I do see multiple /mnt/run mounts here tho'. This is likely a bug (albeit probably a small one)

> > FWIW, anything that checks /proc/mounts to checks for read-only /usr should
> > not really on parsing /proc/mounts. It should use proper checks - e.g. do
> > whatever "mountpoint" does to check that a given location is or is not a
> > mountpoint and look up the details via that mechanism.
> 
> As it is a mount point (although hidden by the later mounting
> of the root filesystem on /mnt), the check seems correct to me.

No the check is definitely wrong. Using /proc/self/mountinfo is contextual (i.e. it follows chroots) whereas /proc/mounts is absolute. Booting a system with a ro /usr and chrooting into a valid install would still trigger this failure which is incorrect. Now that the installer/rescue is using such a fs layout, this bug/limitation comes much more to the fore!!

Sorry I meant /dev/loop0 in my first comment above.

Sorry, my mistake. It isn't /mnt/usr being bind mounted, but /usr, which
still shows up in /proc/mounts, after going into the chroot, so changing
it to check /proc/self/mountinfo should fix the problem, of being able
to install updates, from the tty, before rebooting.

I agree, that likely has nothing to do with the polkit error. That's likely
being triggered by
/etc/xdg/autostart/polkit-gnome-authentication-agent-1.desktop  combined with
/proc/self/loginuid not being zero.

(In reply to Dave Hodgins from comment #47)
> Sorry, my mistake. It isn't /mnt/usr being bind mounted, but /usr, which
> still shows up in /proc/mounts, after going into the chroot, so changing
> it to check /proc/self/mountinfo should fix the problem, of being able
> to install updates, from the tty, before rebooting.

Phew! Thought I'd managed to do something really stupid for a while there!

> I agree, that likely has nothing to do with the polkit error. That's likely
> being triggered by
> /etc/xdg/autostart/polkit-gnome-authentication-agent-1.desktop  combined with
> /proc/self/loginuid not being zero.

Well the autostart .desktop file shouldn't be getting in the way as nothing should be triggering it. The processing of XDG autostart files is only done when a session is started, typically by GNOME, KDE or the DE in question (or some old xsession.d stuff for DEs that don't do it themselves). So unless somehow testing the X driver triggers the fallback xsession.d stuff which does the XDG stuff for systems it knows can't do that itself, I don't see why the XDG files come into play at all. This seems unlikely tho', and something that would have been problematic for a while (i.e. several releases).

Anyway, just for clarity we don't want to "solve" the loginuid "problem". We really don't want to run any polkit stuff (either an agent or any pkexec wrapped commands), so the fix is to ensure these are not run in the installer in the first place, not fix the symptoms of the problems they report. The next step is to work out what is triggering them...

(In reply to Colin Guthrie from comment #43)
> OK, I tested this principle and it seems to work OK. Thierry, is this OK to
> commit?

I'm OK with that change but:
1) we don't need proc_mounts() anymore then
2) so just rename the current function and replaces its contents with your new function

(In reply to Thierry Vignaud from comment #49)
> (In reply to Colin Guthrie from comment #43)
> > OK, I tested this principle and it seems to work OK. Thierry, is this OK to
> > commit?
> 
> I'm OK with that change but:
> 1) we don't need proc_mounts() anymore then
> 2) so just rename the current function and replaces its contents with your
> new function

I've just pushed the change, but didn't clean up proc_mounts as it's still used in trim_until_d() which checks the start of the string for the /dev/loop0. I'm not sure under what semantics it makes sense to fail if the ISO is mounted. e.g. inside a chroot should it still fail? If so, then /proc/mounts is still the valid choice... 

So I'd rather leave it to someone more versed in this code to make these decisions. Hope that's OK!

still valid with last -stage2 (using pre-beta2)

Confirmed. /root/drakx/updates.log still has
Error getting authority: Error initializing authority: Could not connect: No such file or directory
This was with the Mageia-4-beta2-x86_64-DVD.iso with DATE.txt
Sun Dec  1 11:23:48 CET 2013

Just pushed new urpmi, I'll rebuild stage2 with it after

What's the status with current fixed urpmi in drakx?

Assignee: thierry.vignaud => mageia

(In reply to Thierry Vignaud from comment #54)
> What's the status with current fixed urpmi in drakx?

is there a way to test without waiting new pre-beta2 build ?

Just test current Cauldron: pick install/images/boot-nonfree.iso from your favorite mirror.
eg: http://distrib-coffee.ipsl.jussieu.fr/pub/linux/Mageia/distrib/cauldron/x86_64/install/images/

It'll download current cauldron stage2 from the mirror of your choice.

yes but it will not propose to install updates if it's a netinstall

Humm, you got a point...
Ask Thomas, he's currently building ISOs

Prerelease round 3 of 4beta2 (64 bits): IMHO the bug as per summary is fixed.

Closing then

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

Not the case for me, but it looks like something other.

https://bugs.mageia.org/show_bug.cgi?id=11954