Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

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

Comments

Projects
None yet
4 participants
@notro
Copy link
Contributor

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

This comment has been minimized.

Copy link
Contributor Author

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

This comment has been minimized.

Copy link
Collaborator

commented Aug 21, 2013

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

This comment has been minimized.

Copy link
Contributor Author

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

This comment has been minimized.

Copy link
Contributor Author

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

This comment has been minimized.

Copy link
Collaborator

commented Aug 21, 2013

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

@notro

This comment has been minimized.

Copy link
Contributor Author

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

This comment has been minimized.

Copy link
Collaborator

commented Aug 21, 2013

3.10.7 seems to be bigger...

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

This comment has been minimized.

Copy link

commented Aug 22, 2013

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

This comment has been minimized.

Copy link
Contributor

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 added a commit to notro/rpi-build-stdlib that referenced this issue May 23, 2014

popcornmix added a commit that referenced this issue Feb 18, 2015

@popcornmix

This comment has been minimized.

Copy link
Collaborator

commented Feb 18, 2015

Added patch from @notro #106 (comment)

@notro

This comment has been minimized.

Copy link
Contributor Author

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
You can’t perform that action at this time.