Doing a 64-bit HTTP install in today's cauldron fails immediately trying to retrieve mdkinst.sqfs. This happens whether /mnt/cauldron or /mnt/cauldron/x86_64 is given as the directory. Looking att VC3, I see 2 anomalies: 1) "reverse name lookup failed for self" Doing a "host (ip address)" on another host for the address that shows on VC3 as having been assigned returns the correct hostname 2) "getaddrinfo: No address associated with hostname" The hostname printed in the other VC3 messages is correct, and the server is up and mdkinst.sqfs is reachable from other hosts. The hostname in the message has an explicit port (:80), but there's nothing to indicate if the port is being appended to the hostname that's passed to getaddrinfo(). The only other odd thing I see is that install first tries /mnt/cauldron/install/stage2/mdkinst.sqfs, fails (predictably), and in trying /mnt/cauldron/x86_64 it adds an extra slash after the appended "x86_64, i. e. /mnt/cauldron/x86_64//install/stage2/mdkinst.sqfs. This shows up in the "trying ..." message, but the extra slash *doesn't* show up in the "HTTP: trying to retrieve ..." message which follows it. I've been doing 64-bit HTTP installs on this machine from the same server since forever without seeing this. I've double-checked the hostname and directory spelling. Reproducible: Steps to Reproduce:
it work's fine here using local house http mirror are all file accessible ?
Yes. Specifically, I tried to access mdkinst.sqfs via HTTP from Firefox on a different system, and it worked fine. Could you try it deliberately misspelling the directory name to force an error popup, and then check VC3 to see if you get the getaddrinfo and reverse name lookup messages, and also if the path it tries to load contains a double slash after x86_64 ? If you do, but it works using the correct directory, then those things are red herrings.
This is definitely a stage 1 bug. I have a second machine with an older isolinux on it (pre-release of MGA 4). I tried starting an install with that, and it worked fine. Then, I updated the isolinux to the current cauldron level, tried again, and it got the identical failure described above.
If I write /pub/cauldron it works too if I write /pub/cauldr indeed it adds x86_64, but this is the correct way (since mageia 2 you don't do add the arch) and an double slash change nothing in linux world (the date release show Feb 28 2014 07:37)
Yep, I figured out the arch thing from the multiple tries adding x86_64. I believe I entered a bug about this a long time ago, so I'll try to find it and close it. I also knew that the double slash thing *shouldn't* make a difference, and *wouldn't* make a difference to the web server, but it *might* make a difference to some custom perl HTTP client. In any case, there is a definite version difference between the isolinux that works and the one that fails, since the one that works gives a mirror choice of "Mageia 4" while the one that fails displays "Mageia 5". February 28 is quite possible, since I don't think I've done a fresh install since before then.
Did you note whether you got the getaddrinfo message or the reverse name lookup message in either of those cases ? I don't think the reverse name lookup is significant, because it goes on to try and load mdkinst.sqfs. The getaddrinfo message occurs on each try with a different path variant, though. I'm using an FQDN hostname for the server (that also was a requirement years back, although now there are VC3 messages indicating that the installer is taking note of the domain name returned by DHCP, so this may have been fixed as well).
The getaddrinfo message is the smoking gun. If I use the unqualified host name of "ftgfiles1", it fails. If I use the FQDN of "ftgfiles1.griffin.treehouse.com", it fails. If I use the IP address of 192.168.3.104, it works fine. The problem is in the hostname supplied to getaddrinfo(), and the message is correct.
This also affects NFS installs.
...and 32 bit.
CC: (none) => mrmazda
Substituting IP for hostname works on i586 too.
Hardware: x86_64 => All
Mirror hostname still fails using 06 June installation kernel and initrd. Substituting mirror's IP is still required to start installing.
This works in current MGA4. Whatever broke, it was after that.
well I just cannot reproduce...
CC: (none) => thierry.vignaud
Frank, can you still reproduce?
Keywords: (none) => NEEDINFOSummary: HTTP 64-bit install fails loading mdkinst.sqfs => HTTP install fails loading mdkinst.sqfs
No. I didn't have occasion to do fresh installs for a while, and by the time I did it was working again (I had actually forgotten about this bug, and just used the hostname). No idea what fixed this or when.
Status: NEW => RESOLVEDResolution: (none) => FIXED