update_modules() should delete the old directory before copying the new #106

Closed
notro opened this Issue Aug 20, 2013 · 11 comments

Projects

None yet

4 participants

@notro
Contributor
notro commented Aug 20, 2013

I'm going to use rpi-update to distribute my own kernel.
In this kernel I have backlight.o as a builtin and not as a loadable module.

rpi-update just copies the new modules on top of the old directory.
This results in the kernel complaining about duplicate symbols, because the old backlight.ko from the prevoius kernel is still present in the directory.

I'm not sure how this deleting should be done.
Delete all /lib/modules/dirs that is present in the update?

I'm not skilled in shell scripting, so I'm not sure how to do this.

@notro
Contributor
notro commented Aug 21, 2013

There was a solution right before my eyes in that function.

This change solves my problem

 function update_modules {
    if [[ ${SKIP_KERNEL} -eq 0 ]]; then
        echo " *** Updating modules"
+       find "${FW_REPOLOCAL}/modules" -mindepth 1 -maxdepth 1 -type d | while read DIR; do
+           rm -rf ${FW_MODPATH}/$(basename "${DIR}")
+       done
        cp -vR "${FW_REPOLOCAL}/modules/"* "${FW_MODPATH}/"
        find "${FW_REPOLOCAL}/modules" -mindepth 1 -maxdepth 1 -type d | while read DIR; do
            echo " *** depmod $(basename "${DIR}")"
            depmod -b "${ROOT_PATH}" -a $(basename "${DIR}")
        done
    else
        echo " *** As requested, not updating modules"
    fi
 }
@popcornmix
Collaborator

I'd like to leave this open for a bit to see if we have any objections.
I'm a little cautious about deleting files.

Perhaps a user has compiled an out-of-tree kernel module, and will be upset it's been deleted.
Granted after a kernel update, the module typically gives a version error, but it's something to think about.

@notro
Contributor
notro commented Aug 21, 2013

Perhaps a user has compiled an out-of-tree kernel module, and will be upset it's been deleted.
Granted after a kernel update, the module typically gives a version error, but it's something to think about.

I agree with that. Such a module will probably still work.

This would preserve those modules (extra/)

rm -rf ${FW_MODPATH}/$(basename "${DIR}")/kernel
@notro
Contributor
notro commented Aug 21, 2013

Another solution is to rename the directory

mv ${FW_MODPATH}/$(basename "${DIR}") ${FW_MODPATH}/$(basename "${DIR}").$(date +"%d-%m-%Y_%H-%M-%S")
@popcornmix
Collaborator

Trouble with moving the directory is the size (about 240M).
You can't do that many times without filling an sdcard.

@notro
Contributor
notro commented Aug 21, 2013

The current one isn't that big

$ du -sh rpi-firmware/modules/3.6.11+/
33M     firmware/modules/3.6.11+/

But you're right, it would need some kind of cleanup function. So it's not a very good solution.

@popcornmix
Collaborator

3.10.7 seems to be bigger...

$ du -sh  /lib/modules/3.10.7+/
240M    /lib/modules/3.10.7+/
@licaon-kter

wow 240Mb? I'm did not yet switch to 3.10.x but in 3.6-3.9 it's around ~30-33Mb. Why the sudden 8x enlargement?

@lurch
Contributor
lurch commented Aug 27, 2013

Once upon a time (when the recommended Raspi distro was still Debian Squeeze IIRC) there was an official firmware/kernel update which moved a kernel module from being a loadable module into a compiled-in module, which resulted in a similar duplicate symbol error. At the time I thought about maybe having rpi-update store a (local) list of which kernel modules it had installed, so that the next time you ran rpi-update it could check this list against the current-list-of-modules, and thus be able to delete any old modules that rpi-update itself had installed (and wasn't about to overwrite with a newer version), whilst leaving any custom user-compiled modules alone.
But it seemed like a lot of work so I never got round to it, and for most people the problem was fixed when a new OS image was released, after which the old module never appeared not compiled-in again.

@notro notro added a commit to notro/rpi-build-stdlib that referenced this issue May 23, 2014
@notro notro issue106: Hexxeh/rpi-update#106 efe98a6
@notro notro referenced this issue in raspberrypi/linux Jan 23, 2015
Closed

FBTFT drivers now in staging #767

@popcornmix
Collaborator

Added patch from @notro #106 (comment)

@notro
Contributor
notro commented Feb 18, 2015

Thanks

@notro notro closed this Feb 18, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment