Bug 13111

Summary:	HTTP install fails loading mdkinst.sqfs
Product:	Mageia	Reporter:	Frank Griffin <ftg>
Component:	Installer	Assignee:	Mageia Bug Squad <bugsquad>
Status:	RESOLVED FIXED	QA Contact:
Severity:	normal
Priority:	Normal	CC:	mrmazda, thierry.vignaud
Version:	Cauldron	Keywords:	NEEDINFO
Target Milestone:	---
Hardware:	All
OS:	Linux
Whiteboard:
Source RPM:		CVE:
Status comment:

Description Frank Griffin 2014-03-28 16:36:20 CET

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:

Comment 1 Manuel Hiebel 2014-03-28 18:39:36 CET

it work's fine here using local house http mirror

are all file accessible ?

Comment 2 Frank Griffin 2014-03-28 19:32:54 CET

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.

Comment 3 Frank Griffin 2014-03-29 19:16:56 CET

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.

Comment 4 Manuel Hiebel 2014-03-30 10:51:00 CEST

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)

Comment 5 Frank Griffin 2014-03-30 14:13:31 CEST

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.

Comment 6 Frank Griffin 2014-03-30 14:19:25 CEST

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).

Comment 7 Frank Griffin 2014-03-30 16:30:15 CEST

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.

Comment 8 Frank Griffin 2014-03-31 19:19:15 CEST

This also affects NFS installs.

Comment 9 Felix Miata 2014-05-02 08:44:34 CEST

...and 32 bit.

CC: (none) => mrmazda

Comment 10 Felix Miata 2014-05-02 09:09:45 CEST

Substituting IP for hostname works on i586 too.

Hardware: x86_64 => All

Comment 11 Felix Miata 2014-06-05 11:18:41 CEST

Mirror hostname still fails using 06 June installation kernel and initrd. Substituting mirror's IP is still required to start installing.

Comment 12 Frank Griffin 2014-06-24 22:01:55 CEST

This works in current MGA4.  Whatever broke, it was after that.

Comment 13 Thierry Vignaud 2015-02-27 20:12:51 CET

well I just cannot reproduce...

CC: (none) => thierry.vignaud

Comment 14 Samuel Verschelde 2015-06-01 19:07:50 CEST

Frank, can you still reproduce?

Keywords: (none) => NEEDINFO
Summary: HTTP 64-bit install fails loading mdkinst.sqfs => HTTP install fails loading mdkinst.sqfs

Comment 15 Frank Griffin 2015-06-01 19:38:32 CEST

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 => RESOLVED
Resolution: (none) => FIXED