| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
In NetworkManager-world, we want the GATEWAY to be store per device
rather than for the entire system, so what ifcfg-fedora is reading
is the correct thing to do.
|
|
|
|
|
| |
We are linking with glibc now, so use strverscmp() in place of the
rpmvercmp() function in loadermisc.c.
|
|
|
|
| |
Nothing is using this function anymore.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Restores functionality we had before the NM changeover. This was
originally requested by gurulabs.com. Instead of sending just
'anaconda' as the vendor class identifier, send something like:
anaconda-Linux 2.6.27.5-117.fc10.i686 i686
Of course, if we fail to collect that information, fall back on
'anaconda'. Guru Labs wanted this functionality for PXE booting
as it allowed them to more easily control per-client/per-release
settings from the DHCP server. My fault for not adding this back
when the NM changeover happened.
|
| |
|
|
|
|
|
|
| |
Load the SCSI modules earlier for CD/DVD installs on s390. Also,
always set up the network interface because you still need that
to ssh in and run loader.
|
|
|
|
|
| |
Fix two missing things. I dropped the { in the git patch and needed
to remove the now-unused iface_t in main.
|
|
|
|
|
|
|
| |
If the user passes ks=hd: or another non-remote kickstart location,
do not bring up networking during installation. However, if they
pass the 'vnc' parameter, make sure we do bring up networking early
because we can't let them configure it by the time we get to stage2.
|
|
|
|
|
|
| |
As a side effect, this makes it go through waitForCdromTrayClose().
Signed-off-by: Chris Lumens <clumens@redhat.com>
|
|
|
|
|
|
| |
If a user boots from boot.iso and specifies syslog=HOST, we need
to send them through the network configuration steps in loader so
that networking is available by the time anaconda starts.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This one has been around for a while. If a user selects the wrong
network interface in loader and waits for the failure message to
appear, they are taken back to the 'select an interface' screen.
They select the right interface, but loader used the TCP/IP settings
entered the first time around.
On network configuration failure and if we are doing an interactive
install, blank out ipv4method and ipv6method so that we take the
user to the TCP/IP configuration screen. I use ipv4method and
ipv6method to figure out if a kickstart installation is beginning,
so by blanking them out for the interactive install case, we get to
take the user back to the TCP/IP settings screen.
|
| |
|
|
|
|
|
| |
Mount options are handled elsewhere, we do not need to store them
in the instRepo variable.
|
| |
|
|
|
|
|
|
|
| |
We've backed this out on RHEL 5.3 for now because it was far more
complex than IBM had told us, so it's back to the drawing board
for this one. Keeping rawhide in sync with what's happening on
the RHEL side with this feature.
|
|
|
|
|
|
|
|
| |
This needs to be called before newtWinMessage, which can happen in various
conditions in the networking code paths. So we can either create our own
newtWinMessage to call startNewt for us (preferred fix for the future), add
more calls to startNewt throughout the networking code, or just move the first
call earlier. For F10, the last seems like the most straightforward fix.
|
|
|
|
|
|
| |
Make the loader code match the behavior of the anaconda Python
code. Only write NM_CONTROLLED=no. If a device is controlled
by NM, don't write an NM_CONTROLLED line.
|
|
|
|
|
|
| |
Was using DEBUGLVL for all of the D-Bus messages. Make sure error
messages are at the ERROR log level and info-type messages are at
the INFO log level.
|
|
|
|
|
|
| |
If the user passes dhcpclass= at the boot prompt, write the value
to /etc/dhclient-DEVICE.conf as 'send vendor-class-identifier %s'
so that NM will use those settings when sending the DHCP request.
|
|
|
|
| |
I didn't mean to commit this log message.
|
|
|
|
|
| |
It spins backwards, overruns the buffer constantly, and worst of all,
there are two of it. No more, I say!
|
|
|
|
| |
My previous edit had tabs all over the place.
|
|
|
|
|
|
| |
Don't check for ENOMEDIUM on opening the device right after we got a
real drive status from it. Instead, just consider the actual drive
status from waitForCdromTrayClose().
|
|
|
|
|
| |
These are acting up too much recently, so make it so we can see them
before stage2 is ready.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
IBM had requested that on s390x we add the cio_ignore=all parameter
to the default boot file. Well, cio_ignore all except for the 3270
terminal. The motivation for this change was to decrease device
discovery time on systems with thousands of subchannels.
The fix was only part of the solution. When you use cio_ignore to
disable everything, you need to explicitly free the device from
cio_ignore and then enable it using the magic of /sbin/chccwdev.
This patch adds the un-ignore capability to linuxrc.s390.
|
|
|
|
|
|
| |
Kickstart installs should work again like they did at one point.
If you do not specify IP configuration parameters on the boot:
line, loader assumes DHCP (which is what we've done forever).
|
|
|
|
|
| |
If you select Back in loadUpdates(), the installer would segfault
under certain cases.
|
|
|
|
|
|
| |
Writing to /.tmp proved to work, now to move the temporary files to a
better location. Using /etc/sysconfig/network-scripts, but writing
the files as ".ifcfg-DEVICE" and then renaming to ifcfg-DEVICE.
|
| |
|
| |
|
|
|
|
|
|
| |
In STEP_IFACE, ipinfo_set was always getting reset to 0, which
caused the net.c code to ignore any network configuration values
specified on the boot line.
|
|
|
|
|
| |
All of this code is handled in setupIfaceStruct(), so there's no
need for it here.
|
|
|
|
|
|
| |
Clean up the loop termination and return value handling. Currently
the configureTCPIP() function returns LOADER_NOOP if the user
chose dhcp and LOADER_OK if the user chose manual configuration.
|
|
|
|
|
|
|
|
|
| |
I was told by upstream that NM_CONTROLLED= should be sufficient
for nm-system-settings to pick up an interface for control. But
the parsing in the ifcfg-fedora plugin for nm-system-settings is a
little strange (shvar.c) and what happens when NM_CONTROLLED is
empty isn't entirely clear. Set it to yes to avoid any possible
problems.
|
|
|
|
|
| |
The ipv4method and ipv6method variables are in use now, remove
flags that are not used anymore.
|
|
|
|
|
|
|
| |
Rather than writing new config files directly in /etc/sysconfig
in writeEnabledNetInfo(), write them to /.tmp first and then move
them in place using rename(2). Why /.tmp? rename() fails across
different filesystems and this was the path of least resistance.
|
| |
|
|
|
|
|
|
|
|
| |
Back with libdhcp, we needed to call pumpDhcpClassRun() in several
locations. Moving to NM, I converted those calls to be calls to
get_connection() instead. In this patch, the call to get_connection
in configureTCPIP() has been eliminated because we should only be
calling it from readNetConfig().
|
| |
|
| |
|
|
|
|
|
|
| |
Got static networking when you are configuring the settings in
loader, but using the ip= command line parameters? Totally
different story.
|
|
|
|
|
|
|
|
| |
If you pick the wrong interface in anaconda and NM times out, you
are placed at the configure TCP/IP screen again. If you select
Back, you can go back and pick another interface (if you have more
than one). Users going back to select a new interface were seeing
segfaults, which is not what we want.
|
|
|
|
|
|
| |
We don't really need to do this anymore because if the user has
provided an invalid host, the mount will fail and we pop up the
dialog box anyway.
|
|
|
|
|
| |
This correctly brings over static IP settings. Went ahead and
added code for more IPv6 values, but those are disabled for now.
|
|
|
|
|
|
|
| |
This fixes a problem where we'd kill NM, then try to unmount our NFS
installation source. The result was a hang on the unmount and anaconda
never rebooting. Instead, unmount before killing processes and do the
unmounts lazily since /mnt/stage2 is likely to still be busy.
|
|
|
|
|
| |
When the user specifies ip=, netmask=, gateway=, and dns=...use
them.
|
|
|
|
|
|
|
|
|
| |
Since we're using NetworkManager, just try things and see if they
work. For example, try to do a hostname lookup when mounting the
NFS source. If it works, we have working DNS and can move on.
If it fails, we can tell the user they are missing DNS information
and maybe they'll get the hint to either configure DNS servers or
to specify the NFS source using an IP address.
|