Ethan Benson wrote: > i was going to look at this again to see what i could come up with. > one really tricky problem is it seems you often MUST recompile the mol > modules against the exact kernel source of the running kernel. > otherwise they don't work. > > on my system when i upgraded to 2.2.19 and force load the 2.2.18 mol > modules mol bitches that the kernel patches don't match mol or > somesuch rubbish. i think this happened from 2.2.17 -> 2.2.18 as > well.
In the 0.9.57 announcement they talk about less dependency on the kernel - wonder if that will help for these issues? They say 'it might be necessary to recompile MOL from the source in certain cases' for 2.4 kernels... > my idea is to take the module sources from mol and put them in thier > own package, say mol-modules-src or something. this package should > depend on kernel-headers and would allow the user to build just the > modules against thier running kernel. > > i am not sure if this would work though, if i get bored agian i may > mess with it. If the new version doesn't fix it, I think this would be a good idea. > one other thing i have found, it seems that non-root users cannot run > mol for the first time, even with a setuid patcher, since AFAICT its > the wrapper shell script that loads the modules, this of course fails > if your not root. an ugly solution to this is add a initscript to > run the patcher and then install the mol modules... but then again > allowing non-root users to run mol may be a huge security hole anyway. You mean MacOS is the security hole? :) -- Earthling Michel Dänzer (MrCooper) \ Debian GNU/Linux (powerpc) developer CS student, Free Software enthusiast \ XFree86 and DRI project member
