|Summary:||linuxconf generate wrong PLIP scripts , NFS install via PLIP does not work|
|Product:||[Retired] Red Hat Linux||Reporter:||benno|
|Component:||linuxconf||Assignee:||Michael K. Johnson <johnsonm>|
|Status:||CLOSED CURRENTRELEASE||QA Contact:|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||1999-03-18 22:50:55 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
Description benno 1998-12-04 18:51:19 UTC
In linuxconf, when adding a PLIP interface there are 2 errors: 1) PLIP devices starts at 1 (plip1) and not at 0 (plip0) when adding a plip device in linuxconf it tries to do ifconfig plip0 ... which fails 2) in /etc/sysconfig/network-scripts the *-plip files (ifcfg, ifup) try to ifconfig the plip device as it were an ethernet device (BROADCAST ecc.) route -net on the plip devce is wrond too, because it is a pointopoint device. the correct way of initializing is ifconfig LOCALIP pointopoint REMOTEIP and then route add -host REMOTEIP dev plip1 (for example) the redhat 5.2 installation disk fails to install via an NFS mounted partition on a PLIP device at startup the installer threats the PLIP device as it were an ethernet, this is wrong too. the installer should prompt up a dialog and let the user input the LOCALIP and REMOTEIP for the PLIP device. PLIP is important on installing Linux on laptops via parallelcable, since much of them do not have an ethernet and a CDROM drive. best regards, Benno Senoner.
Comment 1 David Lawrence 1998-12-08 18:58:59 UTC
I have verified this to be a bug with linuxconf. I used it to create a plip device and it created a plip0 device with the proper entries in a file called ifcfg-plip0. Plip devices due in fact goe from 1-x not 0-x. After editing the ifcfg-plip0 file properly and changing it to ifcfg-plip1, ifup plip1 was able to activate the device properly. The routing table was also not setup properly. The install problems relating to NFS install over plip have been verified and placed into a second bug report so as to be assigned to proper developer.
Comment 2 David Lawrence 1998-12-09 18:27:59 UTC
I was incorrect on the fact that plip devices are numbered by the kernel from 1-3. It is 0-2 instead. It although numbered the follwing way: 0x278 plip0 0x378 plip1 0x3bc plip2 The person who reported the problem just happens to have his port set at 0x378 so the kernel assigns it 0x378. Linuxconf does not check for this and therefore writes a config file for ifcfg-plip0.
Comment 3 David Lawrence 1998-12-09 18:28:59 UTC
Sorry again: 0x3bc plip0 0x378 plip1 0x278 plip2
Comment 4 David Lawrence 1999-01-06 23:25:59 UTC
*** Bug 301 has been marked as a duplicate of this bug. *** This bug affects both linuxconf and netcfg. If you try to configure RedHat Linux 5.1 or 5.2 (and probably 5.0 as well) to do PLIP, you will get the following error messages when you try to start it up with "ifup plip0": SIOCSIFADDR: Operation not supported by device plip0: unknown interface SIOCSIFDSTADDR: Operation not supported by device plip0: unknown interface netmask: No address associated with name All except the last message are trivial to fix. Many PC's do not really have a "/dev/lp0" device. The first parallel port is usually "/dev/lp1". That makes the first PLIP device interface "plip1" There is currently no way to tell RedHat to use the "plip1" DEVICE for the first (ie 0) PLIP configuration. The workaround is to create two PLIP configurations (plip0 and plip1), then delete plip0 and set plip1 up the way you want it. If you do this, it still won't work, but all except the last message above will go away. The last message is caused by a bug in Red Hat's plip configuration code. The /etc/sysconfig/network-scripts/ifcfg-plip1 file needs to contain a "NETWORK=" entry which is expected by the ifup-plip script. If you manually add a line with the appropriate network number (e.g. "NETWORK=192.168.1.0"), then "ifup plip1" should work fine. BUT NOTE THAT IF YOU EVER CHANGE THE PARAMETERS OF PLIP1 USING EITHER LINUXCONF OR REDHAT'S NETCFG, YOU WILL HAVE TO REMEMBER TO RESTORE THE "NETWORK" LINE THAT THE TOOL DELETED. ------- Additional Comments From email@example.com 01/05/99 19:50 ------- Oops, sorry about the duplicate bug ... I just noticed that it is reporting the same problems as #301 reports about linuxconf. The same problems exist in both places, but if netcfg is being phased out, I guess it doesn't matter unless an Errata update gets released.
Comment 5 Michael K. Johnson 1999-03-18 22:50:59 UTC
I think that this has all been dealt with. There were so many different issues brought up that I might have missed one or two by accident... One particular comment: no NETWORK line is needed; that is created from the IPADDR and NETMASK components automatically.