Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 1780 - Network script dependencies may break netmount, portmap and nfs
Summary: Network script dependencies may break netmount, portmap and nfs
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: x86 Linux
: High normal (vote)
Assignee: Martin Schlemmer (RETIRED)
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2002-04-14 17:56 UTC by Avi Schwartz
Modified: 2003-02-04 19:42 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Avi Schwartz 2002-04-14 17:56:04 UTC
I have a problem with bringing up certain networking elements due to the
way the init.d scripts are currently dependent on each other.

The problem I am having is that my laptop has a 3C59X built-in network
adapter which is the way I use the laptop at work.  It is set using dhcp.
It addressed as eth0.

I also have a wireless network card (Orinoco) which I use at home and is
addresses as eth1 and has a fixed IP.

The problem is that netmount, portmap and nfs are dependent on net.eth0
scripts and keep failing when eth0 doesn't come up (i.e. using the
laptop at home).  The problem does not manifest itself when the
situation is reversed, when eth0 is up but eth1 is not.
Comment 1 Seemant Kulleen (RETIRED) gentoo-dev 2002-04-15 02:21:51 UTC
Az,

Thoughts on this?
Comment 2 Martin Schlemmer (RETIRED) gentoo-dev 2002-04-15 14:38:58 UTC
To provide the "net" service that most network services depends on, the
specific net.eth? must be added to the "boot" or "default" runlevel. I
am guessing that net.eth0 is added to "default", but not net.eth1 ?

Anyhow, how you could fix this, was to create two runlevels:

# mkdir -p /etc/runlevels/work
# mkdir -p /etc/runlevels/home

And then add the same services to each of them that you have in "default"
currently.  The only exception  is that "work" only have net.eth0 added,
and net.eth1 only have "home" added.

then you could edit /etc/inittab:
------------------snip----------------------
si:S:sysinit:/sbin/rc boot
l0:0:wait:/sbin/rc shutdown 
l1:1:wait:/sbin/rc single
l2:2:wait:/sbin/rc nonetwork
l3:3:wait:/sbin/rc default
l4:4:wait:/sbin/rc default
l5:5:wait:/sbin/rc default
l6:6:wait:/sbin/rc reboot
z6:6:respawn:/sbin/sulogin
--------------------------------------------

to become:
------------------snip----------------------
si:S:sysinit:/sbin/rc boot
l0:0:wait:/sbin/rc shutdown 
l1:1:wait:/sbin/rc single
l2:2:wait:/sbin/rc nonetwork
l3:3:wait:/sbin/rc default
l4:4:wait:/sbin/rc work
l5:5:wait:/sbin/rc home
l6:6:wait:/sbin/rc reboot
z6:6:respawn:/sbin/sulogin
--------------------------------------------

Note that we changed level 4 to "work" and level 5 to "home".

Next you could add two menu entries to grup with kernel lines:

1) for work:

kernel /boot/bzImage root=/dev/hda2 4

2) for home:

kernel /boot/bzImage root=/dev/hda2 5


NOTE that you will have to change the kernel line to suite your
setup, and the only thing of interest is the "4" and "5".

If you are at work, then select the work entry, which should start
net.eth0 correctly, and the same for "home" that should start net.eth1.

another solution is to have a fairly empty "default" runlevel, also
with "work" and "home", and after booting, just do:

# rc work

or:

# rc home


Hope this is of some help.
Comment 3 Avi Schwartz 2002-04-16 23:03:26 UTC
I fixed it in a different way, although I am not sure why it worked.  What I did
was to move net.eth0 to "boot" instead of "default" and net.eth1 was left only
in /etc/init.d (i.e. not in any runlevel).  Now all services are coming up
properly in both environments.

I prefer to do it this way over creating new run levels since I don't have to
remember to select the proper Grub entry.  All is done automatically.

Now it would be nice to know why this method works :-)
Comment 4 Martin Schlemmer (RETIRED) gentoo-dev 2002-04-21 13:32:12 UTC
Because its in the boot runlevel, even when it fails to start, it gets marked
as started to ensure that we get the box booted.