Bug 14152

Summary: boot.iso seems to not be able to use local repos
Product: Mageia Reporter: William Kenney <wilcal.int>
Component: InstallerAssignee: Mageia Bug Squad <bugsquad>
Status: RESOLVED INVALID QA Contact:
Severity: normal    
Priority: Normal CC: thierry.vignaud
Version: CauldronKeywords: NEEDINFO
Target Milestone: ---   
Hardware: i586   
OS: Linux   
Whiteboard:
Source RPM: drakx-installer-binaries CVE:
Status comment:
Attachments: local ftp syntax
local ftp error message
local http syntax
local http error message
mirrors.kernel.org ftp syntax
mirrors.kernel.org http syntax

Description William Kenney 2014-09-23 18:15:31 CEST
Description of problem:

I'm having troubles using, or understanding, how to utilize my local
repo when installing using the boot.iso package(s). First the following
commands work properly after an install is completed:

urpmi.removemedia -a
urpmi.addmedia           core              http://192.168.1.2:8080/~mageia/repo/distrib/5/i586/media/core/release with media_info/hdlist.cz
urpmi.addmedia           nonfree           http://192.168.1.2:8080/~mageia/repo/distrib/5/i586/media/nonfree/release with media_info/hdlist.cz
urpmi.addmedia           tainted           http://192.168.1.2:8080/~mageia/repo/distrib/5/i586/media/tainted/release with media_info/hdlist.cz

This changes the repo from either the Classic Installer or live media to my local repo.

The local repo is mirrored daily as follows:
rsync -aH --delete  rsync://mirrors.kernel.org/mirrors/mageia/distrib/cauldron/i586/   /home/mageia/distrib/5/i586

I have attached four KSnapshots. Two are of successful usages of ftp/http from mirrors.kernel.org
and the other two are attempting to use my local repo with the same syntax. This function worked
in Mageia 2 then went defect in Mageia 3&4. I'm attempting here to resurrect the situation to see
if something has changed and I just don't understand how to use it. Seems I remember this working,
then not working and got fixed, then went not working again. My local repo is on an M4 system.
Maybe the ftp part of this is that the boot.iso does not handle ftp access when there is a username
and password attached to it. That was a problem, and got fixed, in the past. Now gone bad again?
The local repo is updated daily from mirrors.kernel.org. Any suggestiongs are greatly appreciated.
This is all easy to reporduce if you have a local repo. For FTP  Username: mageia  Password: linux

The following commands do not work after install:

urpmi.addmedia           core              ftp://mageia:linux@192.168.1.2//distrib/4/i586/media/core/release with media_info/hdlist.cz
urpmi.addmedia           nonfree           ftp://mageia:linux@192.168.1.2//distrib/4/i586/media/nonfree/release with media_info/hdlist.cz
urpmi.addmedia           tainted           ftp://mageia:linux@192.168.1.2//distrib/4/i586/media/tainted/release with media_info/hdlist.cz

But that may be a different problem.

Feel free to change the title of this bug to better describe the situation.

Thanks.

Testing is executed in Vbox but exhibits the same situation on real hardware.

Test platform:
Intel Core i7-2600K Sandy Bridge 3.4GHz
GIGABYTE GA-Z68X-UD3-B3 LGA 1155 MoBo
GIGABYTE GV-N440D3-1GI Nvidia GeForce GT 440 (Fermi) 1GB
RTL8111/8168B PCI Express 1Gbit Ethernet
DRAM 16GB (4 x 4GB)
Mageia 4 64-bit, Nvidia driver
virtualbox-4.3.10-1.1.mga4.x86_64
virtualbox-guest-additions-4.3.10-1.1.mga4.x86_64

Reproducible: 

Steps to Reproduce:
Comment 1 William Kenney 2014-09-23 18:17:18 CEST
Created attachment 5434 [details]
local ftp syntax
Comment 2 William Kenney 2014-09-23 18:18:37 CEST
Created attachment 5435 [details]
local ftp error message
Comment 3 William Kenney 2014-09-23 18:19:44 CEST
Created attachment 5436 [details]
local http syntax
Comment 4 William Kenney 2014-09-23 18:20:16 CEST
Created attachment 5437 [details]
local http error message
Comment 5 William Kenney 2014-09-23 18:21:39 CEST
Created attachment 5438 [details]
mirrors.kernel.org ftp syntax
Comment 6 William Kenney 2014-09-23 18:22:15 CEST
Created attachment 5439 [details]
mirrors.kernel.org http syntax
Comment 7 claire robinson 2014-09-23 18:36:29 CEST
Do the ftp links open in a browser Bill, or ftp client. Just checking your ftp server is configured correctly.

ftp://mageia:linux@192.168.1.2//distrib/4/i586/media/core/release
Comment 8 claire robinson 2014-09-23 18:37:22 CEST
IIRC there is a bug somewhere about only http working, now I think about it.
Comment 9 William Kenney 2014-09-23 18:48:57 CEST
(In reply to claire robinson from comment #7)

> Do the ftp links open in a browser Bill, or ftp client. Just checking your
> ftp server is configured correctly.
> 
> ftp://mageia:linux@192.168.1.2//distrib/4/i586/media/core/release

No they do not.
Comment 10 Manuel Hiebel 2014-09-23 18:50:30 CEST
and logs ?

(it works here with vbox between host and guest)
Comment 11 William Kenney 2014-09-23 18:56:45 CEST
(In reply to Manuel Hiebel from comment #10)
> and logs ?
> 
> (it works here with vbox between host and guest)

Interesting. So use localhost? How about FTP & HTTP?
Comment 12 William Kenney 2014-09-23 18:57:26 CEST
(In reply to claire robinson from comment #8)

> IIRC there is a bug somewhere about only http working, now I think about it.

Ya, I seem to remember opening a similar bug about this a year or two ago.
I don't think we can go back and fix the boot.iso's for M4/3.
So I wanted to bring this up again and see if we can fix, explain, it for M5.
I kinda did this in prep for M5B1.

Right now after the install I can use my local repo using HTTP.
I just can't find a working way to install with HTTP or FTP.
Or use FTP after the install. It kinda saves bandwidth and runs
a little faster if you can use the boot.iso's and a local repo.
Good for corporate installs.
Comment 13 Manuel Hiebel 2014-09-23 19:02:37 CEST
(In reply to William Kenney from comment #11)
> (In reply to Manuel Hiebel from comment #10)
> > and logs ?
I mean the drakx one alt+f*

> > 
> > (it works here with vbox between host and guest)
> 
> Interesting. So use localhost? How about FTP & HTTP?

it's like a lan 10.0.2.2 for the host 10.0.2.15 for the guest

I have no ftp server, I speak of http
Comment 14 William Kenney 2014-09-23 19:09:59 CEST
(In reply to Manuel Hiebel from comment #13)

> it's like a lan 10.0.2.2 for the host 10.0.2.15 for the guest

So exactly what would you plug into:

https://bugs.mageia.org/attachment.cgi?id=5436
Manuel Hiebel 2014-09-23 19:12:18 CEST

Keywords: (none) => NEEDINFO

Comment 15 Dick Gevers 2014-12-03 19:22:22 CET
@wilcal and @leuhmanu

Not clear who is waiting for what, but label NEEDINFO remains. Can you work it out among the 2 of you?   :))
Comment 16 William Kenney 2014-12-03 19:41:24 CET
Ya this situation still exists. I continue to use http to set up my local repos for an install. The same situation exists after the install. For some reason you can't use a user name and password to access a repo. Most people use repos that do not need ID & PW to get in. It also exists if your trying to install using a live media. As long as the repo your trying to use does not require ID & PW your fine.
Comment 17 James Kerr 2014-12-03 21:38:03 CET
This bug looks similar to an old Mandriva bug:
https://qa.mandriva.com/show_bug.cgi?id=49898

That bug (in the installer) was eventually fixed by Olivier Blin

Could his fix somehow have been reverted?
Comment 18 Thierry Vignaud 2015-02-24 14:13:11 CET
for FTP, if it doesn't work with urpmi too, that's not an installer bug but rather a server configuration or a network issue (since it doesn't work with curl/wget as used by urpmi).
Especially since it works nicely with an official mirror.
Though when seeing "file not found", it looks like you provided a bogus URL...
You should check your server logs and debug using curl/wget....

For http, "couldn't connect to host" point to a network issue.
You should check tty3 & tty4 for more infos
For the record I regularly use a local http repo without any issue...

CC: (none) => thierry.vignaud

Thierry Vignaud 2015-03-05 11:29:58 CET

Source RPM: (none) => drakx-installer-binaries

Comment 19 William Kenney 2015-03-07 19:18:15 CET
OK I spent a little more time on this. If I am going to use
the boot.iso install and the source/mirror is local, lets say
at IP 192.168.1.4. This is going to be a Vbox client install
on another box lets say at 192.168.1.3. The Mageia install
there is lets say cauldron ( M5 ) and on the repo server I'm
going to use HTTP. During the boot install process you get
to the panel "select a medium". If I input the following:

HTTP server: 192.168.1.4
Mageia directory: /~mageia/distrib/5/i586

that will work. But if I change httpd to be responding on
Port 9090 and use the following:

HTTP server: 192.168.1.4:9090
Mageia directory: /~mageia/distrib/5/i586

that will not work. I also still believe that if you
try to use an FTP source and you have to use a USERNAME
and PASSWORD that will not work either.
Comment 20 Thierry Vignaud 2015-03-07 21:54:39 CET
1) That's unrelated to the original issue (which uses std port)

2) stage1 doesn't parse the ":9090" as a port number.
It'll interpret it as part of hostname.
Port 80 is used (unless you choose to use a proxy).
Comment 21 William Kenney 2015-03-07 22:06:53 CET
(In reply to Thierry Vignaud from comment #20)
> 1) That's unrelated to the original issue (which uses std port)
> 
> 2) stage1 doesn't parse the ":9090" as a port number.
> It'll interpret it as part of hostname.
> Port 80 is used (unless you choose to use a proxy).

Thanks. Well that explains that. I'll take a look at the
ftp thing and USERNAME & PASSWORD again. Is it the same
thing there?
Comment 22 Thierry Vignaud 2015-03-07 22:40:04 CET
Note that we ask for separate server name & directory and not for a full URL.
As for username & password, we ask for them for ftp.
Comment 23 Samuel Verschelde 2015-06-02 14:44:53 CEST
If I understand correctly, this is not a bug. Could be a feature request to be able to use a different port than 80, but then it would be clearer to have it in a different bug report.

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

Comment 24 William Kenney 2015-06-02 16:01:55 CEST
(In reply to Samuel VERSCHELDE from comment #23)

> If I understand correctly, this is not a bug. Could be a feature request to
> be able to use a different port than 80, but then it would be clearer to
> have it in a different bug report.

I agree.