predefine interfaces by MAC with udev?
On Feb 8, 2008 5:23 PM, Jordi Pujol <jordipujolp at gmail.com> wrote:
> 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
ok. I'll try
/sbin/udevd --daemon --debug-trace --verbose log_priority=debug
or something like that when I get back to the workshop.
>
> mkdir -p /dev/.udev/queue/
> udevtrigger
> udevsettle || true
>
Thanks again.
Chris.
> 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
>
>
>
> _______________________________________________
> 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: