Bug 4384

Thanks for the bug report.  We have reviewed the information you have provided above, and there is some additional information we require that will be helpful in our diagnosis of this issue.

Please attach your X server config file (/etc/X11/xorg.conf) and X server log file (/var/log/Xorg.*.log) to the bug report as individual uncompressed file attachments using the bugzilla file attachment link below.

Could you please also try to run without any /etc/X11/xorg.conf whatsoever and let X11 autodetect your display and video card? Attach to this bug /var/log/Xorg.0.log from this attempt as well, please.

We will review this issue again once you've had a chance to attach this information.

Thanks in advance.

Keywords: (none) => NEEDINFO
CC: sysadmin-bugs => (none)
Component: Release (media or process) => Installer
Source RPM: (none) => drakx-installer-stage2

Ummm, the network installation failed immediately after formatting the disc. There is nothing on my hard drive except an empty installation partition.

Oups sorry, I use the wrong stock reponse O:)

Could you provide the file /root/drakx/report.bug.gz as an attachment ?
If you don't have the file, you can switch to console 2 (by pressing 'Ctrl-Alt-F2') during installation, put a floppy in floppy drive or plug a USB key/stick and type: 'bug' then press Enter. It will put report.bug on the floppy/key.

Created attachment 1486 [details]
Bug Report

I've never done this before so I don't know if I did it right. I tried to go to console 2 early in the installation and it wouldn't execute the 'bug' command. After the gui came up (stage 2?) it accepted the command but when I tried to go back to console 1, the install crashed. Here's what I got so far. Should I wait until later in the installation before going to console 2?

I tried to install again today doing everything the same and the problem is gone. Very strange. Does the installer try to contact one of your servers at that point in the installation? Could it be that it was unable to reach your server due to your server outage and hung while waiting? Or perhaps the file with the list of available software was corrupted during a recent update.

(In reply to comment #5)
> I've never done this before so I don't know if I did it right. I tried to go to
> console 2 early in the installation and it wouldn't execute the 'bug' command.
> After the gui came up (stage 2?) it accepted the command but when I tried to go
> back to console 1, the install crashed. Here's what I got so far. Should I wait
> until later in the installation before going to console 2?

IIRC the gui is on the tty 7, the file seems good but I see nothing :/


(In reply to comment #6)
> I tried to install again today doing everything the same and the problem is
> gone. Very strange. Does the installer try to contact one of your servers at
> that point in the installation?
Yes it search on http://mirrors.mageia.org/api/mageia.1.x86_64.list

> Could it be that it was unable to reach your
> server due to your server outage and hung while waiting? 

"Starting a few days ago I can no longer get mga1 to
install." So I guess it's not that

> Or perhaps the file
> with the list of available software was corrupted during a recent update.

Yes that can be.

thierry, sysadmin, any ideas ? 

(we have severeal bugs open about the netinstall but still in the needinfo state)

Keywords: NEEDINFO => (none)
CC: (none) => sysadmin-bugs, thierry.vignaud

I've confirmed that the problem is resolved on another box. If a corrupted file list was the cause then it's been fixed. You might want to review the installation script to verify that it times out correctly when unable to contact your mirrors list file. Using a manually selected mirror (as I usually do) shouldn't require this connection and it should time out (or not even be attempted) in those cases. As far as I'm concerned you can close this bug.

We cannot guess anything without logs from a bug command run after the dialog
hangs.
On the other hand, the timing seems suspiciously similar to the downtime of mga
servers

I can only guess that it was a temporary glitch in the repo file list. I don't think it was the mirror list file access since I was able to see the list of mirrors in the previous screen. As I suggested on the mailing list, it might be a good idea to have a policy that anyone updating a mirror (including the original upload) use rsync --delete-after --delay-updates to prevent mirrors from being corrupted by partial/failed updates.

Seemed to be a temporary glitch related to incomplete mirrors updates. Never re-appeared. Resolved.

Status: NEW => RESOLVED
Resolution: (none) => WORKSFORME