the following problem was introduced with udev 009:
[root@claw packages]# rpm -Uvh ~mh/rpm/RPMS/ppc/udev-010-1.ppc.rpm
Preparing...########################################### [100%]
1:udev ########################################### [100%]
error: unpacking of archive failed on file /usr/share/doc/udev-010/COPYING;3fe8a8e3: cpio: open failed - Permission denied
it's because the mode of the directory /usr/share/doc/udev-010/ is
0644. This is with yellodog-3.0.
the following patch fixes it:
Now we only sleep if we can't find the device file, and we have
a hack to sleep for 1 second if we are on a partition. This will be
removed when the libsysfs change gets made...
Here is a small fix for udev-test.pl, to print the METHOD also
for the "whitespace config" tests.
TEST: Handle comment lines in config file (and replace kernel name)
method '' for 'class/tty/ttyUSB0' expecting node 'visor'
add: ok remove: ok
In udev-009 and previous releases, for klibc compatibility, the pgsize var
in sysfs_read_attribute() (file sysfs_dir.c under libsysfs) is handcoded
to 0x4000.
Should it not be 4096 bytes (0x1000 in hex) instead of 0x4000 (16k bytes)?
incremental to 20031222-2,
2003-12-22 multipath-010
* tweak the install target in Makefile
* stop passing fds as argument : this change enable a strict
segregation of ugly 2.4 code
* sysfs version of get_lun_strings()
* be careful about the return of get_unique_id() since errors
formerly caught up by if(open()) in the caller fn are now returned
by get_unique_id()
* send get_serial() in unused.c
incremental to 20031222,
2003-12-22 multipath-010
* introduce dm-simplecmd for RESUME & SUSPEND requests
* split add_map() in setup_map() & dm-addmap()
* setup_map() correctly submits "SUSPEND-RELOAD-RESUME or CREATE"
sequences instead of the bogus "RELOAD or CREATE"
incremental to 20031220,
2003-12-22 multipath-010
* don't print .sg_dev if equal to .dev (2.6) in print_path()
* since the kernel code handles defective paths, remove all
code to cope with them :
* move do_tur() to unused.c
* remove .state from path struct
* remove .state settings & conditionals
* add a cmdline switch to force maps to failover mode,
ie 1 path per priority group
* add default policies to the whitelist array (spread io ==
MULTIBUS / io forced to 1 path == FAILOVER)
* move get_disk_size() call out of add_map() to coalesce()
* comment tricky coalesce() fn
* bogus unsused.c file renamed to unused.c
An important one, against stock udev-009 :
2003-12-20 multipath-010
* big ChangeLog update
* start to give a little control over target params :
introduce cmdline arg -i to control polling interval
* cope with hotplug-style calling convention :
ie "multipath scsi $DEVPATH" ... to avoid messing with
online maps not concerned by an event
* example hotplug agent to drop in /etc/hotplug.d/scsi
* revert the run & resched patch : unless someone proves me
wrong, this was overdesigned
* move commented out functions in unused.c
* update multipath target params to "udm[23] style"
* mp target now supports nr_path == 1, so do we
* add gratuitous free()
* push version forward
Here is a experimental CALLOUT script for udev to create devfs nodes
for IDE-devices. Not that I need these, I just wanted to see if it works :)
The script is really stupid, no error handling, nothing more than
absolutely needed. The rule uses the 'k' format char of the previous
patch. The %D is not used, so the user can have disc or disk :)
this single line:
CALLOUT, BUS="ide", PROGRAM="/etc/udev/ide-devfs.sh %k %b %n", ID="hd*", NAME="%1c", SYMLINK="%2c"
creates the following on my machine with two hard disks, one DVD and a PCMCIA-compact-flash inserted:
/udev
|-- hda
|-- hda1
|-- hda2
|-- hda4
|-- hdb
|-- hdb1
|-- hdc
|-- hde
|-- hde1
`-- ide
|-- host0
| |-- bus0
| | |-- target0
| | | `-- lun0
| | | |-- disc -> ../../../../../hda
| | | |-- part1 -> ../../../../../hda1
| | | |-- part2 -> ../../../../../hda2
| | | `-- part4 -> ../../../../../hda4
| | `-- target1
| | `-- lun0
| | |-- disc -> ../../../../../hdb
| | `-- part1 -> ../../../../../hdb1
| `-- bus1
| `-- target0
| `-- lun0
| `-- cd -> ../../../../../hdc
`-- host2
`-- bus0
`-- target0
`-- lun0
|-- disc -> ../../../../../hde
`-- part1 -> ../../../../../hde1
Attached is a patch that introduces the format char 'k' to be replaced with
the kernel name. I like to have it in a callout script.
I've moved the build_kernel_name() back to namedev_name_device() since
we don't expect it growing cause of 'sdaj' :)
Ananth released sysfsutils 0.4.0 last night, I'm sure you saw the email.
Here's a patch with the latest changes from the pre-patch I already
gave you. It includes sysfs_get_device_parent(), which you said you
needed. I've run your test scripts and I've built scsi_id. Please
play around with this and check it out.
There are quite a few changes. Please do not access
structure pointers, like sysfs_device's parent, directly like
dev->parent. Please use the "get" function to retrieve. The functions
load things on demand and refresh views under the covers.
I've moved the malloc out of the udevdb into udev-remove to free the
struct after use and not to allocate a different struct in the case the
device is not in the data base. I seems a bit easier to read.
Uups, we have a bug in udev-remove.c.
udev segfaults with NULL-pointer, if the device is not in the database:
./test.block: line 29: 4844 Segmentation fault $BIN block
Dec 17 22:47:42 pim udev[4882]: udev_remove_device: '/block/sdy' not found in database, falling back on default name
Dec 17 22:47:42 pim udev[4882]: udev_remove_device: name is '(null)'
Scsi_id hasn't been changed to use the latest libsysfs changes. The
"directory" in the sysfs_class_device is now considered "private" and only
should be accessed using functions. Treating the structures as handles lets
us only load information when it's needed, reducing caching or stale
information and also helping performance.
Here's the problem.
static inline char *sysfs_get_attr(struct sysfs_class_device *dev,
const char *attr)
{
return sysfs_get_value_from_attributes(dev->directory->attributes,
attr);
}
Please try this quick fix:
Got a nasty surprise after upgrading my RPM. The config files weren't
marked as configs and were subsequently replaced! DOH! Fortunately, I
didn't have much in there yet but that certainly isn't something others
will like going forward. Attached is a simple patch to the spec file so
they aren't replaced in the future. The config files included in the
RPM should wind up as udev.conf.rpmnew, etc if they are different from
what is installed.
greg@kroah.com