Md wrote:
This reminds me that there should be a list of modules which MUST NOT be
added to the initramfs because loading them too early is both useless
and as in this case actively harmful.
I'm testing this solution:
I added a blacklist file in /etc/mkinitramfs/, put blacklist
net-module
On Jan 19, Davide Natalini [EMAIL PROTECTED] wrote:
udev now can rename the interfaces, because they haven't a name yet.
udev still loads the modules, you just have been lucky.
This is not a solution in any way.
furthermore this (or something similar) could be useful if we need some
modules
[EMAIL PROTECTED] (Marco d'Itri) writes:
On Jan 19, Davide Natalini [EMAIL PROTECTED] wrote:
udev now can rename the interfaces, because they haven't a name yet.
udev still loads the modules, you just have been lucky.
This is not a solution in any way.
Maybe network interface renaming
On Jan 19, Emilio Jesús Gallego Arias [EMAIL PROTECTED] wrote:
I've looked into the Suse sysconfig package, and it includes all the
network configuration utils, such as ifup and dhcp handling, and
they're coupled with the udev rules. As previously said those
Look harder, because there is no
[EMAIL PROTECTED] (Marco d'Itri) writes:
On Jan 19, Emilio Jesús Gallego Arias [EMAIL PROTECTED] wrote:
Merging that into Debian would mean that udev would replace some
ifupdown planned functionality.
Wrong.
I think that ifupdown maintainers are the ones who can say that for
sure, looking
On Thu, Jan 19, 2006 at 12:54:32PM +0100, Marco d'Itri wrote:
Interfaces renaming must be handled by udev because if it's not then
network hotplug handlers will be called with the wrong interface name.
When are those network hotplug handlers called?
I've got udev loading the network drivers,
On Jan 19, Hamish Moffatt [EMAIL PROTECTED] wrote:
Interfaces renaming must be handled by udev because if it's not then
network hotplug handlers will be called with the wrong interface name.
When are those network hotplug handlers called?
When udev receives the events from the kernel, like
Md wrote:
udev now can rename the interfaces, because they haven't a name yet.
udev still loads the modules, you just have been lucky.
This is not a solution in any way.
maybe I miss something, but for what I see we don't need udev not to
load the modules: we just need they are not loaded
On Jan 19, Davide Natalini [EMAIL PROTECTED] wrote:
maybe I miss something, but for what I see we don't need udev not to
Indeed. udev can rename the modules without any need to mess with the
initramfs or change anything else. Even if the driverss have already
been loaded, network hotplug events
Davide Natalini [EMAIL PROTECTED] writes:
Hi all
I'm trying to get static naming for my network interfaces with udev,
without success.
As far as I can tell, network interface names are given by the kernel
and they've nothing to do with udev.
To get a stable naming you should use some package
also sprach Emilio Jesús Gallego Arias [EMAIL PROTECTED] [2006.01.18.1254
+0100]:
As far as I can tell, network interface names are given by the
kernel and they've nothing to do with udev.
To get a stable naming you should use some package like ifrename.
ifrename is a hack and needed for
On Jan 18, Davide Natalini [EMAIL PROTECTED] wrote:
the system is debian sarge based, with udev version 0.076-6 and kernel
Just to be sure, I suggest you upgrade your version of udev.
usually the two interfaces are named the wrong way, but sometimes they
are named fine.
IOW, renaming is not
On Jan 18, Emilio Jesús Gallego Arias [EMAIL PROTECTED] wrote:
As far as I can tell, network interface names are given by the kernel
and they've nothing to do with udev.
Obviously you have no clue about udev (nor about proper quoting).
--
ciao,
Marco
signature.asc
Description: Digital
beside the fact that I find useful to name eth0 the realtek and eth1 the
other, there is a casuality in the naming process that I cannot remove
If you want to avoid racing with the kernel then you should choose
stable names from another namespace than the one that the kernel uses.
Suggestion:
On Jan 18, Thomas Hood [EMAIL PROTECTED] wrote:
If you want to avoid racing with the kernel then you should choose
stable names from another namespace than the one that the kernel uses.
Suggestion: Use 'eth_0' and 'eth_1' instead of 'eth0' and 'eth1'.
Md: Or is there something in udevd now
Md wrote:
SuSE uses some scripts to handle persistent interface names
[...] I had no time yet to investigate the details.
I just looked at the rename_netiface script in that package. The
following comments in the script give an idea of how it handles the
race problem.
# look for a network
Hello!
martin f krafft [EMAIL PROTECTED] writes:
also sprach Emilio Jesús Gallego Arias [EMAIL PROTECTED] [2006.01.18.1254
+0100]:
As far as I can tell, network interface names are given by the
kernel and they've nothing to do with udev.
To get a stable naming you should use some package
Philipp Matthias Hahn wrote:
udevd uses ioctl(SIOCSIFNAME) to rename the devices. If you drivers are
compiled in, the get assigned eth[01] during init, but udev is called
much later. Renaming eth0 to eth1 will fail, because there already is an
eth1 and vis versa. Consider using another name
On Jan 19, Davide Natalini [EMAIL PROTECTED] wrote:
maybe modifying mkinitramfs script to include udev in the initramfs
could help?
udev is already part of the initramfs, but its presence is not relevant.
The options are:
- use names which cannot be used by the kernel, or
- help me cleaning up
Op do, 19-01-2006 te 00:11 +0100, schreef Davide Natalini:
Marco, this is useful indeed, but the problem remains: in the debian
standard kernel the 8138too and 3c59x drivers are both modules, and both
are present in the initramfs.
If they are loaded and get the kernel name before udev starts
20 matches
Mail list logo
