Local repo won't work anymore

[isadora]

I've had a working local repo for years now and suddenly for M3 64bit it
does not work anymore. I get to it via FTP. Here's the command and the result:

Code: Select all

[root@localhost wilcal]# urpmi.addmedia           core64              ftp://xxxxx:xxxxx@192.168.1.2//distrib/3/x86_64/media/core/release with media_info/hdlist.cz
adding medium "core64"
...retrieving failed: curl failed: exited with 9

no metadata found for medium "core64"

Everything seems to be there and I completely rebuilt the repo over night and updated
it a couple times today and it still does not work. I can use the repo source

mirrors.kernel.org

just fine.

[doktor5000]

Check curl error code meaning and fix the ftp access:

9 FTP access denied. The server denied login or denied access to the particular resource or directory you wanted to reach. Most often you
tried to change to a directory that doesn't exist on the server.

[wilcal]

Many thanks for your input. After extensive checking this morning I've come
to the conclusion that for some reason my local repo on my new M3 server is
not responding to ftp urpmi.addmedia requests from other Mageia boxes
on my LAN. And that holds true for both M2 and M3 boxes. I have checked
and rechecked that the /distrib/3/i586(x86_64), also M2, directories are
really truly there, in the right place, and in good shape. Those ( M2 & M3 )
repos rsync correctly with their source ( mirrors.kernel.org ).

One way I checked this is that the repo server is equipped with a removable
replaceable HD system. The original M2 1TB drive & system remains unchanged
and was removed from the system and put aside before the new M3 1TB drive &
system was installed in the system. I removed the M3 drive and put the old
M2 drive back ( with it's M2 & M3 repos ) and the ftp urpmi.addmedia requests
work just fine.

I've reverted back to not using my local repo and going directly to mirrors.kernel.org
and that works just fine. I'll stay with that until this question has been resolved.

One question. Using the MCC -> Software Management -> Configure media
does that use an FTP process or HTTP?

Thanks for your help. As soon as I get a little more confidence in this I will
raise a Bug.

[doktor5000]

If you add a custom repo, you can choose whether thats an HTTP, FTP or rsync repository.

[wilcal]

If you add a custom repo, you can choose whether thats an HTTP, FTP or rsync repository.

Sorry I've got to check that

[wilcal]

Boot the 32-bit M3 Live-CD. Once it's running open an su terminal and use the command:

urpmi.addmedia tainted_debug ftp://mirrors.kernel.org/mageia/distrib ... nted/debug with media_info/hdlist.cz

You'll get the same error message. Feel free to suggest any other command that will work.

[jkerr82508]

Try using wget instead of curl

Code: Select all

urpmi.addmedia --wget tainted_debug ....

Jim

Edit: That also fails with a wget error 8

[wilcal]

I'm over on the M2 Live-CD and getting the same curl error even with the --wget command
Many many thanks to jkerr82508 for helping here. These kinds of thing make me crazy.
Used to work, now don't, is it me or not?
Looks like it may be something in the repo

[wilcal]

Gotta find a working urpmi command line that works.

[doktor5000]

Well, there's no such directory on the mirror, so the error message is correct.
What you want is in ftp://mirrors.kernel.org/mageia/distrib ... d/release/

Anyways, why do you need tainted_debug repo?

[wilcal]

Anyways, why do you need tainted_debug repo?

Just for testing and not disturb anything else.

[jkerr82508]

FWIW, I have no problem accessing my local mirror, using the GUI, either via ftp or http. (I use anonymous login.) The mirror is on Mageia 3 and I can access it from either Mageia 3 or cauldron.

urpmi.addmedia also works fine for me from the CLI with my local mirror. I also tested with distrib-coffee and it worked. The problem would appear to originate with kernel.org. (I used core/release which was what you quoted in your first post.)

Jim

[wilcal]

Using the 32-bit M3 Live-CD:

urpmi.addmedia core_release ftp://mirrors.kernel.org/mageia/distrib ... re/release with media_info/hdlist.cz
(works)

urpmi.addmedia --wget core_release ftp://mirrors.kernel.org/mageia/distrib ... re/release with media_info/hdlist.cz
(works)

urpmi.addmedia core_release ftp://xxxxx:xxxxx@192.168.1.2//distrib/ ... re/release with media_info/hdlist.cz
...retrieving failed: curl failed: exited with 9
no metadata found for medium "core_release"

urpmi.addmedia --wget core_release ftp://xxxxx:xxxxx@192.168.1.2//distrib/ ... re/release with media_info/hdlist.cz
...retrieving failed: wget failed: exited with 8
no metadata found for medium "core_release"

urpmi.addmedia core_release ftp://xxxxx:xxxxx@192.168.1.2//mageia/d ... re/release with media_info/hdlist.cz
...retrieving failed: curl failed: exited with 9
no metadata found for medium "core_release"

urpmi.addmedia --wget core_release ftp://xxxxx:xxxxx@192.168.1.2//mageia/d ... re/release with media_info/hdlist.cz
...retrieving failed: wget failed: exited with 8
no metadata found for medium "core_release"

[jkerr82508]

I recall that some years ago there were problems when the server required a login:password but when anonymous login was allowed there was no problem. (That problem, however, was with the installer.)

Jim

[wilcal]

I recall that some years ago there were problems when the server required a login:password but when anonymous login was allowed there was no problem. (That problem, however, was with the installer.)

Jim

Yep, I was part of all of that. Probabaly filed the bug.

[wilcal]

Here's the M3 directory tree. Attached.

[wilcal]

I recall that some years ago there were problems when the server required a login:password but when anonymous login was allowed there was no problem. (That problem, however, was with the installer.)

Jim

I initially found this problem with my first 64-bit boot.iso M3 install using the
new repo on the new M3 server. After you give the IP, directory, ID & PW
it errors out. Same as the original problem you refer to.

[wilcal]

Here it is. Could be back:

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

[wilcal]

I have been successful in using my local repo by creating a directory in
my "mageia" user public_html directory called "repo" then putting a soft
link in that directory back to the local repo. Using an already installed
M3 I can then in an su terminal:

urpmi.removemedia -a

then

urpmi.addmedia core http://192.168.1.2:8080/~mageia/repo/di ... re/release with media_info/hdlist.cz

and so on and so forth and that sets the installed M3 to my local repo.
I have already done this, plus updates, to two M3 32-bit systems
and also to a 32-bit Live-CD. So the local repo is a good one.
So the local repo works. So my suspicians are, like jkerr82508, that
we are back again to

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

where adding repos via the command line, or the boot.iso, will only work with anonymous ftp servers.
I've a few more things to poke at before raising the new bug.

[doktor5000]

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

where adding repos via the command line, or the boot.iso, will only work with anonymous ftp servers.
I've a few more things to poke at before raising the new bug.

If it's the exact same problem you can either reopen that bug or clone it into a new one, saves some work.

[wilcal]

If it's the exact same problem you can either reopen that bug or clone it into a new one, saves some work.

Thank's, still poken at it to see if it's exactly the same.
Will probably raise the bug tomorrow ( 4 Jun ).
Local repo is work'n great as long as I get to it via HTTP.

[wilcal]

I have filed:

M3 repo not responding to urpmi requests requiring a login:password authentication
https://bugs.mageia.org/show_bug.cgi?id=10430

It feels a lot like 4156 but I think that was at the client end.
This time it appears to be on the server end.