predefine interfaces by MAC with udev?
Hello list,
observing a bit more deeply into the procedure
init has a call to the init-premount procedures,
maybe_break premount
[ "$quiet" != "y" ] && log_begin_msg "Running /scripts/init-premount"
run_scripts /scripts/init-premount
[ "$quiet" != "y" ] && log_end_msg
into the subdirectory there is the procedure named udev
with some code like this:
mkdir -p /dev/.udev/db/
udevd --daemon
mkdir -p /dev/.udev/queue/
udevtrigger
udevsettle || true
Regards,
Jordi
El Friday 08 February 2008 17:02:43 v?reu escriure:
> On Feb 8, 2008 4:40 PM, Jordi Pujol <jordipujolp at gmail.com> wrote:
> > Hello list,
> >
> > I believe that live-initramfs and all the initramfs systems of the actual
> > Debian use udev as the device naming system,
> > and what we should do is the right rules to put udev working,
> >
> > analize that decompressing an initrd file
> >
> > mkdir initrd
> > cd initrd/
> > gzip -dc ../chroot/boot/initrd.img-2.6.22-3-686 | cpio -id
> >
> > we can see how the main init procedure uses udev to detect and name the
> > devices
>
> The only references I see to udev in init are here
>
> # Note that this only becomes /dev on the real filesystem if udev's scripts
> # are used; which they will be, but it's worth pointing out
> tmpfs_size="10M"
> if [ -e /etc/udev/udev.conf ]; then
> . /etc/udev/udev.conf
> fi
> mount -t tmpfs -o size=$tmpfs_size,mode=0755 udev /dev
> [ -e /dev/console ] || mknod /dev/console c 5 1
> [ -e /dev/null ] || mknod /dev/null c 1 3
>
> > /dev/.initramfs-tools
>
> mkdir /dev/.initramfs
>
> That doesn't look like its populating /dev with devices
>
> # grep -r udev *
>
> Binary file bin/udevinfo matches
> Binary file sbin/udevtrigger matches
> Binary file sbin/udevsettle matches
> Binary file sbin/udevd matches
>
> # grep -r udevtrigger *
>
> Binary file sbin/udevtrigger matches
> scripts/live: udevtrigger
> scripts/init-premount/udev:udevtrigger
> scripts/live-bottom/23networking:udevtrigger
>
> Let's see if I can get somewhere after the weekend. ;)
>
> Chris.
>
> > Regards,
> >
> > Jordi Pujol
> >
> > El Friday 08 February 2008 16:14:04 Chris Fanning va escriure:
> > > On Feb 8, 2008 9:55 AM, Jordi Pujol <jordipujolp at gmail.com> wrote:
> > > > Hello Chris and list,
> > > >
> > > > Sorry, I have supposed that but I don't have tested the naming of the
> > > > interfaces in live-initramfs,
> > > > a comment,
> > > > I have seen that live-initramfs only activates the network interfaces
> > > > when it's starting through the network, otherwise the interfaces are
> > > > activated later, when the main OS starts,
> > > > so writing udev rules in the initrd file only could be useful in this
> > > > case,
> > >
> > > Hi,
> > >
> > > Well, I've got some more data (changed hardware too).
> > >
> > > Using a pc with just on nic (eth0):
> > > I include an incorrect mac in the chroot
> > > udev/rules.d/z25_persistent-net.rules for eth0
> > > SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="bad:mac:address",
> > > NAME="eth0"
> > >
> > > This boots fine. Strangely, the udev of the main os sees the bad:mac
> > > and puts correct mac to eth1. But if I do 'ip link sh' I can see that
> > > the correct mac is on eth0.
> > >
> > > So it seems that initramfs ignores the udev rules as you suggested
> > > Jordi.
> > >
> > > Then I continued with 2 nics and I'm _almost_ back to when I started.
> > > :( I can boot successfully 100% of the time from one nic, and
> > > I get 100% failures booting from the second nic (fails at Begin:
> > > Mounting root file system)
> > >
> > > So, that reminds me of the days before udev, when the eth* order was
> > > determined by the pci slot.
> > >
> > > Any ideas?
> > >
> > > Thanks.
> > > Chris.
> > >
> > > > Regards,
> > > >
> > > > Jordi
> > > >
> > > > El Friday 08 February 2008 09:13:35 Chris Fanning va escriure:
> > > > > Hi,
> > > > >
> > > > > > > that can solved with only one initrd
> > > > > > > we can include a list with all the network cards MACs in the
> > > > > > > servers, because all the network cards have different MAC, ? :)
> > > > > >
> > > > > > ok. I understand now. That sound's a lot easier than what I've
> > > > > > been trying to do today. I would only need to update the initrd
> > > > > > when I include a new server, right?
> > > > >
> > > > > No go :(
> > > > >
> > > > > My /etc/udev/rules.d/z25_persistent-net.rules looks like this
> > > > > SUBSYSTEM=="net", DRIVERS=="?*",
> > > > > ATTRS{address}=="44:4d:50:e1:f1:4e", NAME="eth0"
> > > > > And when I break=top, I can see that it is present. So it's there
> > > > > on boot.
> > > > >
> > > > > But the interfaces are still getting mixed up.
> > > > >
> > > > > Does that make any sense? Maybe my hardware is faulty?
> > > > >
> > > > > Thanks.
> > > > > Chris.
> > > >
> > > > _______________________________________________
> > > > debian-live-devel mailing list
> > > > debian-live-devel at lists.alioth.debian.org
> > > > http://lists.alioth.debian.org/mailman/listinfo/debian-live-devel
> >
> > _______________________________________________
> > debian-live-devel mailing list
> > debian-live-devel at lists.alioth.debian.org
> > http://lists.alioth.debian.org/mailman/listinfo/debian-live-devel
Reply to: