Description of problem: When adding a new bunch of options, it would be useful to have the words 'Options apply to...' followed by a choice of 'specific IP or subnet' or 'all other hosts'. The latter would edit the pxelinux.cfg/default file. Version-Release number of selected component (if applicable): 0.1.3-7 How reproducible: Always Steps to Reproduce: 1.Want to set up network booting, and don't need different options for different subnets 2.Use system-config-netboot Actual results: Wish you could edit the default option rather than having to specify a subnet Expected results: Just choose the 'all other hosts' option. In fact, that should probably be made default (people who want different options for different hosts or subnets will know they want to). Additional info: Thanks.
Internal RFE bug #132311 entered; will be considered for future releases.
Just clearing out some old bugs here - sorry for the delay . s-c-nb can't work this way, because : o The pxelinux.0 boot client looks for .cfg files named with each whole byte sequence of its IP address prefix . You can sort of specify a default cfg file by just specifying one byte of the IP address, but that one byte must be specified. o The snapshot directory must be unique to each client, else we could have multiple clients updating the same writable files which are meant to be client specific. That's why each client creates its own snapshot dir if one is not specified.
"The pxelinux.0 boot client looks for .cfg files named with each whole byte sequence of its IP address prefix ." and then looks for a file called default.cfg. Reopening.
Pardon me, the file is called 'default', as mentioned in the original bug report.
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: http://www.redhat.com/security/updates/errata/ 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.