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:
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
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
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 => RESOLVEDResolution: (none) => INVALID
(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.