[asterisk-bugs] [Zaptel 0013108]: [patch] Uninstalling modules will fail when installing to the subtree

noreply at bugs.digium.com noreply at bugs.digium.com
Tue Jul 22 01:27:00 CDT 2008


A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=13108 
====================================================================== 
Reported By:                Romik
Assigned To:                
====================================================================== 
Project:                    Zaptel
Issue ID:                   13108
Category:                   zaptel (the module)
Reproducibility:            always
Severity:                   trivial
Priority:                   normal
Status:                     new
Zaptel Version:             1.4.11 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             07-18-2008 10:42 CDT
Last Modified:              07-22-2008 01:27 CDT
====================================================================== 
Summary:                    [patch] Uninstalling modules will fail when
installing to the subtree
Description: 
Modules uninstall script ./build_tools/uninstall-modules will partially
fail when installing to the subtree DESTDIR=/somepath/ .
------------------------------------------
for mod in $MODULES; do
        BASE=`basename $mod`
        for file in `cat $KERNEL_MODULES_DIR/modules.dep | cut -d : -f 1 |
grep "$BASE$"`; do
                if [ -e "$file" ]; then
                        #echo "Deleting $file."
                        rm -f $file
                fi
        done
done
------------------------------------------
`cat $KERNEL_MODULES_DIR/modules.dep` fill fail with 
cat: /subtree-path/lib/modules/kernel-version/modules.dep: No such file or
directory
====================================================================== 

---------------------------------------------------------------------- 
 Romik - 07-22-08 01:27  
---------------------------------------------------------------------- 
> What if you install to a DESTDIR and it actually had older versions?
$DESTDIR is primarily used for building RPM's (of course under non-root
account), so $DESTDIR then becomes equal to %{buildroot} (also
$RPM_BUILD_ROOT) variable. And %{buildroot} is cleaned every time before
you attempt to build another package, so you may be quite sure that there
will be no old module versions in $DESTDIR, isn't it?

> A casual look at the uninstall script also shows that it uses files in
/tmp 
> in an insecure way. temporary files should be created with mktemp(1).
I've looked through build_tools/uninstall-modules script and found nothing
there that creates any files. Only echo’s, conditions and `rm -f` for
modules. What did you mean tzafrir?

> Why does the script search in modules.dep instead of using find? There
are 
> other reasons that may cause the information in modules.dep to be
incorrect.
Then to whom do you trust? Read `man 5 modules.dep`.
------------------------------
...
The  modules.dep  as generated  by module-init-tools depmod, lists the
dependencies for every module in the directories under
/lib/modules/version, where modules.dep is.
...
This file is used by modprobe to know the order to load modules (they are
loaded right to left, and removed left to right).
...
------------------------------
If someone does not want his server to work in correct way and doesn't run
`depmod` after compiling new kernel and/or its' modules then that's on his
own responsibility. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
07-22-08 01:27  Romik          Note Added: 0090550                          
======================================================================




More information about the asterisk-bugs mailing list