Description of problem: Installing cauldron into a virtual machine or network computer using the boot.iso image works for HTTP, but not FTP or NFS. Using ftp from either a local repository or public mirror will start the graphic installer and complete all the steps up to 'Installing' successfully. At that point, the graphic installer spits out: An error has occured media.cfg not found. TTY3 has this in the logs: ... * starting step `choosePackages' * change_phys_medium ftp://xxx:xxx@emailurl.net@distro.ibiblio.org//pub/linux/distributions/mageia/distrib/cauldron/x86_64/media for file media_info * getFile media_info/media.cfg on ftp://xxx:xxx@emailurl.net@distro.ibiblio.org//pub/linux/distributions/mageia/distrib/cauldron/x86_64/media * retriving media.cfg * '/usr/bin/curl' '-q' '--location-trusted' '-R' '-f' '--disable-epsv' '--connect-timeout' '60' '--nyauth' '--stderr' '-' '-O' 'ftp://xxx:xxx@emailurl.net@distro.ibiblio.org//pub/linux/distributions/mageia/distrib/cauldron/x86_64/media/media_info/media.cfg' * retrieval of '/mnt/var/cache/urpmi/media.cfg' failed * step "choosePackages" took: 0:00:00 * error: media.cfg not found at /usr/lib/libDrakX/install/media.pm line 661. Installing cauldron using nfs was less succesful and fails as soon as the network comes up. 7 of the 9 OS's on the network machine mount nfs shares on boot, so the nfs server should be accessable. The logs from TTY3 after the installer tried to connect using nfs 3 protocol and failed: ... * mounting 192.168.10.3:/images/install/cauldron/2013-01-30 on /tmp/media as type nfs * have to insmod nfs * needs /lib/modules/3.8.0-desktop-0.rc5.1.mga3/sunrpc.ko.xz * needs /lib/modules/3.8.0-desktop-0.rc5.1.mga3/lockd.ko.xz * needs /lib/modules/3.8.0-desktop-0.rc5.1.mga3/fscache.ko.xz * needs /lib/modules/3.8.0-desktop-0.rc5.1.mga3/nfs.ko.xz * succeeded nfs * preparing nfsmount for 192.168.10.3:/images/install/cauldron/2013-01-30 * nfsmount: kernel_nfs_mount_version: 4 * nfsmount: doing client call in nfs version: 3 * mount failed: Protocol not supported * unsetting automatic * exiting bootspash * opening /proc/splash failed The server logs make note that the request was authenticated, but the client seems to fail. How reproducible: Every time. Steps to Reproduce: 1. Boot from the boot.iso image on a CD/DVD or memory card. 2. Choose either NFS server or FTP server from the menu. 3. Use DHCP network connection type (fastest). 4. Enter host name and domain. For NFS servers: 5. Enter the server name or IP and path to cauldron install and the installer fails to connect, then issues an error. For FTP servers: 5. Skip the proxy, choose 'Mageia 3' from the next menu and select a mirror, then enter 'anonymous' in the login field and any email address in the password field. The graphic installer should start. 6. Complete the steps up to and including partitioning, then the installer fails to import the media.cfg file and displays an error.
CC: (none) => thierry.vignaud
CC: (none) => ennael1
CC: (none) => eeeemail
in bug 9047, the guy use a local ftp mirror it works fine
CC: (none) => n54
(In reply to comment #1) > in bug 9047, the guy use a local ftp mirror it works fine or not :/
*** Bug 9063 has been marked as a duplicate of this bug. ***
CC: (none) => derekjenn
I had the same issue wit FTP over vsftpd in a local network. After some days updates it started to work again... there is a different behaviour for i586 and x86_64.
I have the same problem in ftp with boot.iso for i586 The beginning is OK but when it install packages it stop and on the console F3 I have the continius message : * starting step 'installPackages' * install.sh does not contain 'root (hd...)' line, no way to magically adapt device.map * writing /mnt/etc/fstab * step "installPackages" took: 0:00:00 * error : output in file /mnt/etc/fstab failed : No file or directory
CC: (none) => jacques.pronchery
Now the FTP install is working fine.
the nfs one looks like the server forces v4 and the client is v3... this might be resolved by setting v3 on your nfs server settings
CC: (none) => alien
*** Bug 9456 has been marked as a duplicate of this bug. ***
CC: (none) => contact
Ahh, "those who do not study history are condemned to repeat it". See bug#2577, bug#2578, bug#2854. This is old history going back to the MDV days.
CC: (none) => ftg
we used old code from old util-linux code, which defaults to nfs4 on recent kernels. util-linux now just calls {,u}mount.nfs from nfs-utils. we should: - build a static dietlibc build of mount.nfs - include it int stage1 - run it instead of our own old code
or someone should try to sync mdk-stage1/nfsmount.{h,c} with nfs-utils code...
CC: (none) => mageia
This bug, or at least #9456 has just affected me, when trying to install Mageia 3 on my main system. I am surprised this was not marked as release critical. Any workaround to still use nfs? Or are we stuck with no NFS installs for Mageia 3?
CC: (none) => nelg
(In reply to Glen Ogilvie from comment #12) > This bug, or at least #9456 has just affected me, when trying to install > Mageia 3 on my main system. > > I am surprised this was not marked as release critical. > > Any workaround to still use nfs? Or are we stuck with no NFS installs for > Mageia 3? work around for me to network install was to provide the files over http using apache, with syntax like: KERNEL images/Mageia3/vmlinuz APPEND initrd=images/Mageia3/all.rdz ramdisk_size=128000 vga=788 root=/dev/ram3 rw automatic=method:http,network:dhcp,ser:kit,dir:/mnt/x86_64/ Instead of: KERNEL images/Mageia2/vmlinuz-64 APPEND initrd=images/Mageia2/all-64.rdz ramdisk_size=128000 vga=788 root=/dev/ram3 rw automatic=method:nfs,network:dhcp,server:kit,directory:/data/iso/Mageia-2-x86_64-DVD/mnt/x86_64
Colin, now that we're dynamically linked with glibc, we could drop our special nfs code & rely on mount.nfs from nfs-utils. WDYT?
Source RPM: (none) => drakx-installer-binairies
Yeah we probably could do that quite happily. I guess we'll need rpc.statd too or perhaps we can mount without that easily enough... It'll probably pull quite a few other libs into the initrd too - e.g. the krb5 stuff. Can't say I've played too much with the NFS stuff tho', but this seems reasonable. If you want to hack on it, just see the file /usr/lib/dracut/modules.d/90mgainstaller/module-setup.sh. It's responsible for including various binaries and kernel modules. We could also use the "network" and "nfs" modules from dracut but this will likely include other stuff in the initrd that we maybe don't need and bloat it even more.
*** Bug 12901 has been marked as a duplicate of this bug. ***
CC: (none) => unruh
Just a success report from me... I have successfully installed Mageia 4 x86_64 using NFS: - The NFS server was a Mageia 3 system. I loop-mounted the Mageia 4 x86_64 DVD ISO image under /srv/nfs/mageia and setup an NFS export using MCC. - I had to manually configure Shorewall to let the client IP range through - just selecting NFS as a service to allow in MCC/Security/Firewall did not seem to work - probably because NFS uses dynamic port assignment + portmap by default. - I downloaded the Mageia 4 x86_64 boot-nonfree.iso image and dd'ed it to a USB flash drive. - Then all I had to do for each client was boot with the USB flash drive, get it to start the network and type in the NFS server IP address and /srv/nfs/mageia/x86_64 path. I installed a full GNOME install on three desktops using this method, although I do not believe that I had to use any of non-free packages at the end.
CC: (none) => thkala
Thanks Theodoros. Changing the version assignment as this bug was reported for Mageia 3.
Version: Cauldron => 3
If you're using an Intel CPU or AMD one you likely needed the microcode package
Created attachment 5050 [details] switch to regular mount for NFS (untested)
Created attachment 5051 [details] drop our old forked nfs code
Colin that needs altering d-i-images creation to include NFS stuff (mount.nfs & the like)
we also need to replace the call to mount() by system("mount %s %s -t %s ...")
we should also drop our dhcp client & use dhclient
Not sure who you were addressing with the suggestion about microcode (I was the reporter of 12901 which was declared a duplicate ) The original report here was cauldron for Mageia 3. The problem with the cauldron designation is that it does not say what it is cauldron for. My systems were Intel CPUs.
Mageia 3 changed to end-of-life (EOL) status 4 months ago. http://blog.mageia.org/en/2014/11/26/lets-say-goodbye-to-mageia-3/ Mageia 3 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Mageia please feel free to click on "Version" change it against that version of Mageia and reopen this bug. Thank you for reporting this bug and we are sorry it could not be fixed. -- The Mageia Bugsquad
Status: NEW => RESOLVEDResolution: (none) => OLD