| Summary: | boot.iso seems to not be able to use local repos | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | William Kenney <wilcal.int> |
| Component: | Installer | Assignee: | Mageia Bug Squad <bugsquad> |
| Status: | RESOLVED INVALID | QA Contact: | |
| Severity: | normal | ||
| Priority: | Normal | CC: | thierry.vignaud |
| Version: | Cauldron | Keywords: | 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
Created attachment 5434 [details]
local ftp syntax
Created attachment 5435 [details]
local ftp error message
Created attachment 5436 [details]
local http syntax
Created attachment 5437 [details]
local http error message
Created attachment 5438 [details]
mirrors.kernel.org ftp syntax
Created attachment 5439 [details]
mirrors.kernel.org http syntax
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 IIRC there is a bug somewhere about only http working, now I think about it. (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. and logs ? (it works here with vbox between host and guest) (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? (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. (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 (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 @wilcal and @leuhmanu Not clear who is waiting for what, but label NEEDINFO remains. Can you work it out among the 2 of you? :)) 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. 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? 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 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. 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). (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? 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. 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 (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. |