I have a specific observation/bug(?) about the dracut stage of the installation process.
To meet my requirements I needed to modify the Fedora 25 install image.
My requirements are:
- I need to automatically deploy in remote locations where I don't have
control over the local network environment, that specifically means I cannot
use a DHCP/TFTP boot server.
- I have only limited upload bandwidth.
=> therefore I need a small installation image that is easy to upload
with an embedded kickstart ks.cfg file and the rest of the installation media
should get downloaded from the internet on-site.
To achieve this I thinned the install image (among other things by removing the second
anaconda stage - install.img) so that it results in a 65 MB image instead of 500 MB.
Then I patched the boot parameters to get control over the network configuration,
the location of the second anaconda stage on a fedora mirror server and the proxy settings
(ip+nameserver, inst.stage2, inst.proxy parameters).
And in this specific combination I encountered a quirk with those parameters.
In all cases below, inst.stage2 is set and points to a fedora mirror with a FQDN.
- ip not set, nameserver not set, inst.proxy set:
First stage fetches network configuration from DHCP and uses the proxy to download
- ip set, nameserver set, inst.proxy set:
First stage configures network according to ip-parameter setting and then ignores the
proxy and downloads the second stage directly from the internet.
- ip set, nameserver not set, inst.proxy set:
First stage configures network according to ip-parameter setting, apparently tries to
directly download the second stage but as it's missing a nameserver it cannot resolve
the address of the mirror server and times out. After one or two timeouts it changes its
mind, uses the proxy (proxy is specified with raw IP address) and successfully
downloads the second stage.
- ip set, nameserver set, inst.proxy set and proxy also set (without "inst."-prefix):
First stage configures network according to ip-parameter setting and then uses the
proxy and downloads successfully downloads the second stage.
To me it looks like the dracut stage has internally two stages of its own.
The first one can cope with the direct network configuration via "ip"-parameter
and also understands the "proxy"-parameter but it cannot make use of the "inst.proxy" option.
If this stage fails, it switches to a second one that now also honors the "inst.proxy"-parameter.
As this concerns a modified install image I don't file it as a bug, but I want to share it here
in case somebody else does something similar and also stumbles over this issue.
And maybe some of the developers see it and think about homogenizing the behavior
of the (inst.)proxy parameters. But for me the current situation is ok, you just need to know
how to use it.
Btw. the dracut+anaconda installer is pretty sweet to work with. Well done!