Matthew Burgess wrote:
Alexander E. Patrakov wrote:
WARNING: the patch is incomplete. It assumes that SCSI module
autoloading rules are already added, but they are in fact not.
Erm, they are in the udev-config-6.rules file, unless you've spotted a
problem with those?
They don't load the co
Alexander E. Patrakov wrote:
WARNING: the patch is incomplete. It assumes that SCSI module
autoloading rules are already added, but they are in fact not.
Erm, they are in the udev-config-6.rules file, unless you've spotted a
problem with those?
+Create some rules that work around broke
On Mon, Feb 27, 2006 at 07:03:04AM -0700, Archaic wrote:
> It is done before udev is started. It just happens to be done in the
> same script that starts udev and currently that is the most logical. We
> can't do it in the mountfs script because udev must run before that. We
> could do it in the mo
On Mon, Feb 27, 2006 at 11:30:18AM +0500, Dimitry Naldayev wrote:
>
> why we want mount /dev in udev startup script? Why not do this task in
> another script running before udev startup?
It is done before udev is started. It just happens to be done in the
same script that starts udev and currentl
"Alexander E. Patrakov" <[EMAIL PROTECTED]> writes:
> Bryan Kadzban wrote:
>
>> It should be easy enough to have only "start" and "restart" targets, and
>> have the "restart" target do a "killall udevd" (or whatever), then
>> simply run "$0" start (perhaps after waiting for a second).
>
> No, that
Alexander E. Patrakov wrote:
> No, that won't work. We want to mount tmpfs on /dev for start, but
> not for restart.
True, unless we unmount it first (thus removing all devices). Well,
actually we probably can't unmount it, because at least /dev/console
will be open.
OK, so how about restart doe
Bryan Kadzban wrote:
It should be easy enough to have only "start" and "restart" targets, and
have the "restart" target do a "killall udevd" (or whatever), then
simply run "$0" start (perhaps after waiting for a second).
No, that won't work. We want to mount tmpfs on /dev for start, but not
f
On Fri, Feb 24, 2006 at 05:29:07PM +0500, Alexander E. Patrakov wrote:
> As written, this is incorrect. Increasing the logging verbosity achieves
> nothing, because udev runs before syslogd. Proposed solution:
>
> 1) Implement some "restart" target in the udev initscript that kills old
> udevd,
I wrote:
+
+ Udev creates a device incorrectly, or makes a wrong
symlink
+
+ This usually happens if an incorrect rule unexpectedly matches
+ the device, or some rule unexpectedly matches the wrong device. E.g.,
+ a poorly-writen rule can match by vendor both a SCSI disk
I wrote:
+
+cat > /etc/udev/rules.d/26-network.rules << "EOF"
+ACTION=="add", SUBSYSTEM=="net", SYSFS{address}=="52:54:00:12:34:56",
NAME="realtek"
+ACTION=="add", SUBSYSTEM=="net", SYSFS{address}=="00:a0:c9:78:9a:bc",
NAME="intel"
+EOF
+This rule will always rename the network cards
The
Matthew Burgess wrote:
Alexander E. Patrakov wrote:
Matthew Burgess wrote:
Alexander E. Patrakov wrote:
3) Linux-2.6.15 is used, which means that some deices (e.g., IDE
CD-ROMs and input devices) won't get modaliases or won't generate
uevents properly.
There is already a note in the book
Matthew Burgess wrote:
Alexander E. Patrakov wrote:
For those of you who are still patient enough to test the udev_update
branch out, please find an updated Udev rules file at
http://www.linuxfromscratch.org/~matthew/pub/. I think it corrects all
the problems Alexander pointed out.
Tha
Alexander E. Patrakov wrote:
For those of you who are still patient enough to test the udev_update
branch out, please find an updated Udev rules file at
http://www.linuxfromscratch.org/~matthew/pub/. I think it corrects all
the problems Alexander pointed out.
Regards,
Matt.
--
http://lin
Matthew Burgess wrote:
11) The deprecated udev_run_hotplugd helper is needed for
compatibility with BLFS (look at HAL).
>>> Why? I thought Kay was actively helping the HAL guys out? Why has
>>> he caused it to break by deprecating the udev_run_hotplugd helper?
>> That's just obsolete
On Thu, 23 Feb 2006, Alexander E. Patrakov wrote:
The "iseries" rules in our file are also useless on anything other
than s390 boxes.
Wearing my pedant's hat for the moment, iSeries != s390 (I believe
iSeries is POWER, or it might be ppc64). I know somebody did LFS on
s390 a while ago,
On Thu, 23 Feb 2006, Alexander E. Patrakov wrote:
The "iseries" rules in our file are also useless on anything other than s390
boxes.
Wearing my pedant's hat for the moment, iSeries != s390 (I believe
iSeries is POWER, or it might be ppc64). I know somebody did LFS on
s390 a while ago, but
Alexander E. Patrakov wrote:
Matthew Burgess wrote:
Alexander E. Patrakov wrote:
The udev_retry initscript should run after mountfs
and re-trigger the failed uevents in hope that they won't fail again.
I really don't think this is necessary.
Think about ALSA: alsactl is in /usr/sbin. B
Matthew Burgess wrote:
Alexander E. Patrakov wrote:
2) There is no "udev_retry" initscript. The idea is that, if a program
specified in the "RUN" rule exits with nonzero status (presumably
because it needs /usr), udev places a symlink into /dev/.udev/failed.
The udev_retry initscript should
On 2/22/06, Alexander E. Patrakov <[EMAIL PROTECTED]> wrote:
> 3) Linux-2.6.15 is used, which means that some deices (e.g., IDE CD-ROMs
> and input devices) won't get modaliases or won't generate uevents
> properly. The solution is to upgrade to linux-2.6.16-rc4 or to say that
> the bug exists and
Alexander E. Patrakov wrote:
Below is the incomplete list of things done wrong or incompletely in the
udev_update branch. Here "wrong" doesn't include upstream faults.
Thanks very much for the report Alexander.
1) Udev bootscript doesn't wait for uevents to be fully processed.
OK, I'll add
I wrote:
1) Udev bootscript doesn't wait for uevents to be fully processed.
Upstream recommends the following shell snippet for this purpose:
loop=300
while test -d /dev/.udev/queue; do
sleep 0.1
test "$loop" -gt 0 || break
loop=$(($loop - 1))
21 matches
Mail list logo
