Re: [Evms-devel] possible evms 2.0.0 problems

[Kevin C. <co...@us...>]

Hi Daniel,

On Sunday 30 March 2003 08:20, Daniel Landstedt wrote:
> Hello,
>
> I get this when running evms_activate and evmsn:
> Engine: Error loading /lib/evms/xfs-1.0.1.so: undefined symbol:
> uuid_compare Engine: Error loading /lib/evms/csm-1.0.0.so: undefined
> symbol:
> uuid_generate_random
> Engine: Error loading /lib/evms/gpt-1.1.3.so: undefined symbol:
> uuid_generate_random
> Engine: Error loading /lib/evms/bbr_seg-1.1.1.so: undefined symbol:
> uuid_generate_random
> Engine: Error loading /lib/evms/sparse-0.2.0.so: undefined symbol:
> uuid_generate_random
> Engine: Error loading /lib/evms/jfs-1.1.3.so: undefined symbol:
> uuid_compare My solution for now was to delete them because I don't think i
> need those anyway.

Apparently these plug-ins could not find the uuid library when they were 
loaded by the engine...so there are a couple of possibilities. You may not 
have libuuid installed on your system. However, the configure script for EVMS 
should catch that condition, and not try to build the above plugins. Or, you 
could have libuuid installed, the evms build was able to find it, but the 
plug-ins are not able to find it at runtime.

Can you please run the configure script in evms-2.0.0 and send me the output? 
Also, can you determine if you have libuuid installed on your system (try 
running "locate libuuid")?

BTW, deleting the above plug-ins should not hurt anything. You are almost 
certainly not going to use csm, gpt, and sparse. If you don't have any JFS or 
XFS filesystems, you won't need jfs or xfs. If you want to use 
bad-block-relocation in the future, you might want bbr_seg...but that's up to 
you.

> And when I compile Device-Mapper as modules I get these errors when trying
> to load them:
> /lib/modules/2.4.20/kernel/drivers/md/dm-io.o: couldn't find the kernel
> version the module was compiled for
> /lib/modules/2.4.20/kernel/drivers/md/dm-io.o: insmod
> /lib/modules/2.4.20/kernel/drivers/md/dm-io.o failed
> /lib/modules/2.4.20/kernel/drivers/md/dm-io.o: insmod dm-bbr failed
>
> /lib/modules/2.4.20/kernel/drivers/md/dm-io.o: couldn't find the kernel
> version the module was compiled for
> /lib/modules/2.4.20/kernel/drivers/md/dm-io.o: insmod
> /lib/modules/2.4.20/kernel/drivers/md/dm-io.o failed
> /lib/modules/2.4.20/kernel/drivers/md/dm-io.o: insmod dm-sparse failed
>
> dm-mod loads fine. So for now I just compile them into the kernel, but I'd
> like them as modules.

Well...that's a new one. :)  I'll have to try building the DM driver as 
modules again and see if I can trigger that error. I'll let you know what I 
find out.


> What is the sparse segment manager btw? I've tried to find out but haven't
> succeded.

The sparse segment manager is a plug-in for creating "sparse" devices. Such a 
device can appear to be any size you like, with a limited amount of actual 
storage space. When the available storage space runs out, the device is full 
and returns errors on additional write requests. If you are familiar with 
snapshots, it could be thought of as a writeable snapshot without an origin. 
It is primarily for testing purposes, and really shouldn't be used in normal 
storage management situations.

> And I keep geeting these in my syslog:
> Mar 30 15:56:48 [modprobe] modprobe: Can't locate module block-major-117
> IIRC that is the permanent major device block number you were assigned?
> I guess they're not dangerous but quit annoying, is it supposed be that way
> or is there anything I/you can do about it?

EVMS 2.0 performs a check to see if the EVMS 1.2.x driver is running in the 
kernel. If it is, EVMS 2.0 will not run. It performs this check by trying to 
open the 1.2.x control device (major 117, minor 0). If the open succeeds, the 
1.2.x driver is running. Apparently your system is trying to load a kernel 
module when it gets an open() request for major 117. You might examine your 
/etc/modules.conf, or if you are running devfs, your /etc/devfs.conf and 
/etc/modules.devfs files. There ought to be a way to prevent it from trying 
to load a module for that particular major number, since you know you aren't 
running the old EVMS driver.

> Anyway, thanks for EVMS guys!
>
> /Daniel Landstedt

Thanks for the feedback!

-- 
Kevin Corry
co...@us...
http://evms.sourceforge.net/