| Summary: | Installing cauldron using the boot.iso network install fails using for ftp and nfs protocols. | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | William Murphy <warrendiogenese> |
| Component: | Installer | Assignee: | Mageia Bug Squad <bugsquad> |
| Status: | RESOLVED OLD | QA Contact: | |
| Severity: | normal | ||
| Priority: | Normal | CC: | alien, contact, derekjenn, eeeemail, ennael1, ftg, jacques.pronchery, mageia, mageia, n54, nelg, thierry.vignaud, thkala, unruh |
| Version: | 3 | ||
| Target Milestone: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Source RPM: | drakx-installer-binairies | CVE: | |
| Status comment: | |||
| Attachments: |
switch to regular mount for NFS (untested)
drop our old forked nfs code |
||
|
Description
William Murphy
2013-02-12 19:06:36 CET
David Walser
2013-02-12 19:09:40 CET
CC:
(none) =>
thierry.vignaud
David Walser
2013-02-12 19:09:46 CET
CC:
(none) =>
ennael1
claire robinson
2013-02-12 19:12:29 CET
CC:
(none) =>
eeeemail in bug 9047, the guy use a local ftp mirror it works fine
David Walser
2013-02-13 06:08:50 CET
CC:
(none) =>
n54 (In reply to comment #1) > in bug 9047, the guy use a local ftp mirror it works fine or not :/ 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 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...
Thierry Vignaud
2013-03-24 11:48:24 CET
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? CC:
(none) =>
mageia
Thierry Vignaud
2013-11-12 21:36:56 CET
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. 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 =>
RESOLVED |