So far, I have not made any fix for the preference issue. But if the problem is still present now that the corrections have been made, please insert three debug lines into /sbin/pup_event_backend_modprobe after line 144 (which begins with "xMODULE=":
Code: Select all
echo "MODULE: $MODULE PREFHIT: $PREFHIT PREFMOD: $PREFMOD xMODULE: $xMODULE" >> /tmp/rerwin-pref.log #rerwin
echo "MODULES: $MODULES" >> /tmp/rerwin-pref.log #rerwin
echo "Blacklist: `cat /tmp/pup_event_prefhit_blacklist`" >> /tmp/rerwin-pref.log #rerwin
Dave, the same version of the modprobe script is used in both kernel-versions of 4.3.1. However, the kernel support of the modprobe command might differ between kernels. Once we understand the problem in both kernels of 4.3.1 and fix it, I can probably retrofit the fix into 412 & 421.MODULE: ltmodem PREFHIT: ltmodem:martian_dev PREFMOD: martian_dev xMODULE: martian_dev
MODULES: martian_dev
ungrab_serial
v8250
ltmodem
Blacklist: blacklist ltmodem
Interestingly, I actually mistyped the preferred module name and it did not impact the result! Looking at the "MODULES" values, since ltmodem is blacklisted, puppy finds whatever is left, excluding the ltmodem dependencies (ungrab... & v8...). Puppy normally chooses the last name in the MODULES list. Part of my fix to that script will be to verify it finds the desired module, in case there are more than one alternative.
Richard