report.bug.gz will be along shortly.

Created attachment 847 [details]
report.bug

Iirc I have see the same (with the http one)

as workaround you can only add the file used by urpmi/drakx-install, it's something like 300Mo

rsync -avPHS --partial --delete-after --exclude=media/debug --exclude='*.rpm' rsync://.../mirror/mageia/distrib/cauldron/i586 /media/.../pub/cauldron/

maybe there is a easiest way but I don't know :)

Thanks, but since I rsync the HD directory tree with the real mirror, this would have to be done on an ongoing basis every time I updated (which is several times a day).

You're right, HTTP has a similar problem (and its own open bug report).  This has been like this for years, and really ought to be fixed across the board.

3-monthly ping

CC: (none) => marja11

Hi,

This bug was filed against cauldron, but we do not have cauldron at the moment.

Please report whether this bug is still valid for Mageia 2.

Thanks :)

Cheers,
marja

Keywords: (none) => NEEDINFO

Franck are you sure this bug is still valid ?

Please look at the bottom of this mail to see whether you're the assignee of this  bug, if you don't already know whether you are.


If you're the assignee:

We'd like to know for sure whether this bug was assigned correctly. Please change status to ASSIGNED if it is, or put OK on the whiteboard instead.

If you don't have a clue and don't see a way to find out, then please put NEEDHELP on the whiteboard.

Please assign back to Bug Squad or to the correct person to solve this bug if we were wrong to assign it to you, and explain why.

Thanks :)

**************************** 

@ the reporter and persons in the cc of this bug:

If you have any new information that wasn't given before (like this bug being valid for another version of Mageia, too, or it being solved) please tell us.

@ the reporter of this bug

If you didn't reply yet to a request for more information, please do so within two weeks from now.

Thanks all :-D

Somehow missed the later posts on this.  I'll retest.

@ftg@roadrunner.com:

May I remind you of your #c9 reading ?

> Somehow missed the later posts on this.  I'll retest.

Keywords: (none) => NEEDINFO

@ftg:
Probably a dupe of your #2577 ?

Not a dupe, as this concerns an HD install rather than an NFS install.  I was given to understand that these cases were all handled separately.

I'll retest.

Aha! Clear. Thanks!

Problem still exists in cauldron.

Keywords: NEEDINFO => (none)
Whiteboard: MGA2TOO => 5Beta 1

Much obliged.

Whiteboard: 5Beta 1 => 5beta1

I had a look at the logs.
/tmp/media is where the partition is mounted, but then it creates /tmp/image and installs from there and /tmp/image seems to point to /tmp/media/x86_64.

There is some code to replace the path in adjust_paths_in_urpmi_cfg:

        } elsif (member($phys_m->{method}, qw(disk nfs))) {
            # use the real mount point:
            if ($medium->{url} =~ m!/tmp/image(/media)?!) {
                $medium->{url} =~ s!/tmp/image(/media).!$phys_m->{mntpoint}$phys_m->{rel_path}!;
            } else {
                # just remove $::prefix and we already have the real mount point:
                $medium->{url} =~ s!^$::prefix!!;
            }
        }

But this is too late as the addmedia was done with the wrong path and failed so we don't reach that place.

The solution may be in _get_media_url:

        $uri = $o->{stage2_phys_medium}{url} =~ m!^(http|ftp)://! && $o->{stage2_phys_medium}{url} ||
          $phys_medium->{method} =~ m!^(ftp|http)://! && $phys_medium->{method} || '/tmp/image';


Instead of using /tmp/image when it is not http or ftp install, we could use "$phys_medium->{mntpoint}$phys_medium->{rel_path}".

Something like:

$uri = '/tmp/image';
if ($o->{stage2_phys_medium}{url} =~ m!^(ftp|http)://) {
  $uri = $o->{stage2_phys_medium}{url};
} elsif ($phys_medium->{method} =~ m!^(ftp|http)://!) {
  # This one is strange, why would method be an URL? 
  $uri = $phys_medium->{method};
} elsif (member($phys_medium->{method}, qw(disk nfs))) {
  # use the real mount point:
  $uri = "$phys_medium->{mntpoint}$phys_medium->{rel_path}";
} else {
  $uri = '/tmp/image';
}

Another simpler change would be to expand the symlink into an absolute path at the end of _get_media_url (if it is a symlink).

CC: (none) => pterjan

Ping ?

@ Frank

Is the _impossible_ in the summary of this bug still correct "HD 64-bit installs impossible - can't find Core32" ?

For my 64bit boot.iso installs from a mirror on a local disk - I only started doing that around 2013, so after this report was filed -, the 32bit media weren't found, either. However, afaik install always continued and finished fine (unless there was a different reason for it to fail).

Thierry, 

what about adding the "ok_if_missing" media flag handling to urpmi.addmedia we discussed earlier
(end we would need to add the same to mga5 too for upgrades to work...)

CC: (none) => tmb

(In reply to Marja van Waes from comment #18)
> @ Frank
> 
> Is the _impossible_ in the summary of this bug still correct "HD 64-bit
> installs impossible - can't find Core32" ?
> 
> For my 64bit boot.iso installs from a mirror on a local disk - I only
> started doing that around 2013, so after this report was filed -, the 32bit
> media weren't found, either. However, afaik install always continued and
> finished fine (unless there was a different reason for it to fail).

I can't retest at the moment as stage 1 seems to be broken, but my recollection is that clicking OK to the error popup drops you back to repository selection.

I don't think it's currently impossible: for now you should get a popup but it should still go on

Keywords: (none) => NEEDINFO

I'll test this in the next few days.  The problem is that my cauldron mirror is now on my fileserver and gets accessed for most installs via HTTP.  The only way to test an HD install is to take the fileserver down and run the install to a spare partition on that.

Just catching up with this....

The situation in current cauldron is that a 64-bit HD install will still get the errors about not finding the 32-bit repositories, but will continue anyway without them.  IIRC they are greyed out in the media selection panel, or if they aren't then selecting them gets the error.  In any case, they aren't enabled in the final system.