Marcy Cortes writes: > Does anyone know what these mean? This is SLES10 SP 2 - new install. > The volume groups are very large - vg02-vg06 each contain 22 mod 54 > volumes (almost a Terabyte). vg01 contains 12 mod 54. Volume group > "system" is pretty small at 6G. > > > There was some discussion on this list a year ago, but no resolution was > posted. > > Waiting for udev to settle... > Scanning for LVM volume groups... > Reading all physical volumes. This may take a while... > Found volume group "vg02" using metadata type lvm2 > Found volume group "vg01" using metadata type lvm2 > Found volume group "vg04" using metadata type lvm2 > Found volume group "vg05" using metadata type lvm2 > Found volume group "system" using metadata type lvm2 > Found volume group "vg06" using metadata type lvm2 > Found volume group "vg03" using metadata type lvm2 > Activating LVM volume groups... > 1 logical volume(s) in volume group "vg02" now active > udevd-event[4269]: run_program: ressize 256 too short [lots more "ressize 256 too short" lines snipped]
Some initial googling makes it look like udevd is invoking a program with util_run_program() or udev_exec() and the caller is expecting that program to produce a result (by writing to stdout) of no more than 256 characters. The called program is producing too much stdout which makes its caller sad. A search of the udev codebase shows #defines of length of 256 for some filename and directory name buffers and one or two other things. You could try running udevmonitor while the scan takes place and then work through which udev rules and external programs get invoked to try to catch the one constructing the undesirably long output. --Malcolm -- Malcolm Beattie System z SWG/STG, Europe IBM UK ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
