Re: initrd race conditions
Mike Crowe wrote:
1. Failure to boot at all and being dumped at a shell prompt inside
the ramdisk if the onboard SATA driver is loaded prior to the megaraid
driver. This is despite the fact that nothing is connected to
SATA. I've worked around this one by disabling the onboard SATA.
I actually had this exact problem myself for the first time this morning
with my X2 system, with an initrd built by initramfs-tools.
Using yaird may help because AIUI it will only load the modules required
to mount the root filesystem during the initramfs stage, or at least
will load those first.
2. Almost random ordering of ethernet devices between boots. The
machine has a single e100 and two tg3 ports. Although I can believe
that the two tg3s always appear in the same order I've had the e100
detected either first, last or inbetween the two tg3s! Statically
configuring IP addresses is very hard if you don't know which will be
eth0 next time. I've not fathomed a workaround for this one. This
makes bug #342498 entered against the installer even worse.
You can fix the names of network interfaces using udev-- istr that's
available in sarge, even though a kernel that supports it isn't (fun).
e.g. I have:
bash$ cat /etc/udev/rules.d/010_local.rules
# Local rules
# eth0: dl2k (gigabit adaptor)
SUBSYSTEM=net, SYSFS{address} = 00:05:5d:9a:a3:a8, NAME=eth0
# ethX: e100 (onboard)
SUBSYSTEM=net, SYSFS{address} = 00:02:a5:cf:bb:d4, NAME=ethX
This renames my onboard ethernet adaptor to ethX to keep it out of the
way because the BIOS doesn't permit disabling it (grumble).
HTH
SRH
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: initrd race conditions
Mike Crowe wrote: 1. Failure to boot at all and being dumped at a shell prompt inside the ramdisk if the onboard SATA driver is loaded prior to the megaraid driver. This is despite the fact that nothing is connected to SATA. I've worked around this one by disabling the onboard SATA. On Tue, Feb 07, 2006 at 02:26:54PM +, Steven Haslam wrote: I actually had this exact problem myself for the first time this morning with my X2 system, with an initrd built by initramfs-tools. Using yaird may help because AIUI it will only load the modules required to mount the root filesystem during the initramfs stage, or at least will load those first. Assuming I can persuade the stock 2.6.15 kernel to use yaird rather than initramfs then I'll give that a go. If I have to compile the kernel myself I might as well just compile in the drivers I need which will also solve the problem for me. 2. Almost random ordering of ethernet devices between boots. The machine has a single e100 and two tg3 ports. Although I can believe that the two tg3s always appear in the same order I've had the e100 detected either first, last or inbetween the two tg3s! Statically configuring IP addresses is very hard if you don't know which will be eth0 next time. I've not fathomed a workaround for this one. This makes bug #342498 entered against the installer even worse. You can fix the names of network interfaces using udev-- istr that's available in sarge, even though a kernel that supports it isn't (fun). e.g. I have: bash$ cat /etc/udev/rules.d/010_local.rules [snip] But surely that's too late? The ramdisk will load the drivers before my root filesystem and therefore that rules file can be seen. -- Mike Crowe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: initrd race conditions
Mike Crowe wrote: Mike Crowe wrote: On Tue, Feb 07, 2006 at 02:26:54PM +, Steven Haslam wrote: I actually had this exact problem myself for the first time this morning with my X2 system, with an initrd built by initramfs-tools. Using yaird may help because AIUI it will only load the modules required to mount the root filesystem during the initramfs stage, or at least will load those first. Assuming I can persuade the stock 2.6.15 kernel to use yaird rather than initramfs then I'll give that a go. If I have to compile the kernel myself I might as well just compile in the drivers I need which will also solve the problem for me. There shouldn't be any kernel changes required. Just use mkinitrd.yaird to build a new initrd.img. You can fix the names of network interfaces using udev-- istr that's available in sarge, even though a kernel that supports it isn't (fun). e.g. I have: bash$ cat /etc/udev/rules.d/010_local.rules [snip] But surely that's too late? The ramdisk will load the drivers before my root filesystem and therefore that rules file can be seen. I presume that unless you're mounting the root filesystem over nfs, then the ramdisk doesn't try to load net drivers. There's a certain amount of "it works for me" in play here. Hmm. You could well be right-- the machine I'm using that udev tinkering on is using a yaird-built ramdisk, so it definitely *doesn't* load the net drivers. tinkers OTOH, building an initramfs using initramfs-tools takes a copy of your /etc/udev and /etc/modprobe.d at the time it was built, so you just have to update /etc/udev/rules.d and rebuild the initrd. SRH
Re: initrd race conditions
Mike Crowe wrote: I'm running the backports.org 2.6.15 kernel on an otherwise sarge amd64 box with a couple of Opteron 275s. It seems that modules are being loaded by the initrd at startup in parallel. This seems to lead to serious race conditions with the following symptoms: BTW you can also add modules explicitly to /etc/mkinitramfs/modules and they will be individually (and presumably sequentially, assuming modprobe only exist when the module has finished probing) loaded before udev is started. That may be the easiest option of all for sorting out your drive hardware ordering. I'm fairly sure it's udev that is setting off module loads in the background. SRH -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: initrd race conditions
On Tue, Feb 07, 2006 at 05:36:51PM +, Steven Haslam wrote: There shouldn't be any kernel changes required. Just use mkinitrd.yaird to build a new initrd.img. I installed the sarge-backports yaird and modified /etc/kernel-pkg.conf to say ramdisk=mkinitrd.yaird and then ran dpkg-reconfigure linux-image-2.6.15-1-amd64-k8-smp which seemed to cause the ramdisk to be rebuilt using yaird. As you explained this meant that the network drivers were not loaded by the initrd. I still couldn't get my local udev rules to rename the interfaces on startup though. In the end I just disabled the e100 in the BIOS - I hope that the two tg3s will always be discovered in the same order... :-) Thanks for all your help. I think I'd like to log a bug report about this though. Is udev the best package to do that against? -- Mike Crowe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: initrd race conditions
Mike Crowe wrote: I still couldn't get my local udev rules to rename the interfaces on startup though. In the end I just disabled the e100 in the BIOS - I hope that the two tg3s will always be discovered in the same order... :-) Well, presumably the ordering of the tg3s is based on their PCI bus positions, so it should be better defined. I think I'd like to log a bug report about this though. Is udev the best package to do that against? Not sure. It could be argued that udev is simply doing its thing, which is loading modules in response to hotplug events: and processing them serially is possibly going to cause other problems. Mmmm. dunno. Raise it anyway and see what happens, I guess :) The issue with not being able to rename your net interfaces is certainly a udev issue, although whether it's a bug or misconfiguration is hard to determine. Maybe double-check the sysfs attributes using, for example, udevinfo -a -p /sys/class/net/eth0. The first block of values (for the /class/net/eth0 node) are what can be used to rename the device. Also if udev isn't running when the module gets loaded, the renaming won't happen. I remember it took me a few attempts to get it right, but it was a while ago and I can't remember too many details. And just for kicks, the machine I'm using it on is i386 not amd64, so you never know but I'd be surprised if the arch made a difference. SRH -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: initrd race conditions
On Tue, Feb 07, 2006 at 02:26:54PM +, Steven Haslam wrote:
Mike Crowe wrote:
2. Almost random ordering of ethernet devices between boots. The
You can fix the names of network interfaces using udev-- istr that's
available in sarge, even though a kernel that supports it isn't (fun).
e.g. I have:
bash$ cat /etc/udev/rules.d/010_local.rules
# Local rules
# eth0: dl2k (gigabit adaptor)
SUBSYSTEM=net, SYSFS{address} = 00:05:5d:9a:a3:a8, NAME=eth0
Another option is to use ifrename. Then you just create an /etc/iftab
which lists the MAC addresses and desired names. I'm using it on my laptop,
where the wired and wifi interfaces come up in random order.
This problem isn't particular to dual-processor machines at all; the
modules do load in parallel or random order.
# ethX: e100 (onboard)
SUBSYSTEM=net, SYSFS{address} = 00:02:a5:cf:bb:d4, NAME=ethX
This renames my onboard ethernet adaptor to ethX to keep it out of the
way because the BIOS doesn't permit disabling it (grumble).
You could blacklist the module, if it's the only e100 you have.
I blacklisted the eth1394 module here since I don't want ethernet over
firewire.
Hamish
--
Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
