Description of problem:
When adding a bunch of options for a particular subnet, the format
used by system-config-netboot is confusing. Yes, we both know the
files used in the background are matched by removing digits from the
IP, but it shouldn't be necessary for people to know that.
It'd be nice if the tool let people write in subnet masks the same way
the other system-config tools do. Upon clicking OK, the tool would
check to make sure masks entered this way were possible to use with TFTP.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.Want to set up network booting for a particular subnet. Enter in the
subnet using VLSN just like all the other system-config tools.
This doesn't work. The subnet mask must be written in a rather unusual
way. The tooltips and System Admin guide don't make this particular
It'd be nice if using VLSN was possible. This would make things easier
and more consistent with other system-config- tools.
Internal RFE bug #132312 entered; will be considered for future releases.
I clearing out some old bugs here - sorry for the delay .
This can't really be fixed in s-c-nb, because PXE doesn't really
work that way: the PXE client boot code looks for a file named
with each whole BYTE of the hex IP address, which can't really
be specified with VLSP / CIDR notation, which allows individual
BITS to be specified .
The s-c-db "New Host" dialog does let you omit whole bytes from the
IP address and creates files accordingly.
Please try out the latest s-c-nb for RHEL-3:
This can't really be fixed in s-c-nb,
Er, yes it can.
User enters subnet mask.
If the subnet mask doesn't cover a whole byte range, ask the user to
REOPENED status has been deprecated. ASSIGNED with keyword of Reopened is preferred.
This bug is filed against RHEL 3, which is in maintenance phase.
During the maintenance phase, only security errata and select mission
critical bug fixes will be released for enterprise products. Since
this bug does not meet that criteria, it is now being closed.
For more information of the RHEL errata support policy, please visit:
If you feel this bug is indeed mission critical, please contact your
support representative. You may be asked to provide detailed
information on how this bug is affecting you.