I've had two different Lincoln Mark VIIIs - one 1993, and currently one 1996 LSC.  Both are "first generation" ('93-'96) Mark VIIIs, but I'm fairly certain this will also apply to "second generation" ('97-'98) models.

The problem is that the oil filter is in one of the most inconvenient places ever conceivable.  Usually, with relatively little trouble, I can get my arm in well enough to unscrew and pull the filter off.  But, when it comes to actually getting the filter out from the confined space that is its home, there always seems to be some form of creative contortionism required and I can never seem to remember how it is I got the thing out the last time.

Is there any "easy way" to go about doing this?  Is there some trick or special technique I might be missing out on?


Question: Raspbian kernel source compilation configuration
Answer: No, that's the correct behavior of make oldconfig command.

It picks up the available .config, in this case belonging to an older kernel version, and produces a new .config file making the proper corrections where possible and asking to the user whenever new and empty entries are found.

As you can see in your screenshot, the make oldconfig command is giving itself the proper [Y/n/m] answers until it's able to do so. When it encounters the CONFIG_ARPD line and it needs to embed/disable it (the module option is not given for this entry), the script finds that the entry is present in the kernel you want to compile but not in the .config you supplied. Given that the script has no clue of what to do, it asks to the user.

Now the problem is: what answers should I give to the make oldconfig command? Unfortunately there is no simple, algorithmic answer to this question and this is why the Linux kernel compilation is still artisanry. As a general rule of thumb, apart of googling for the simbol name (e.g. what is CONFIG_ARPD?), whenever you encounter a new driver that you never heard of, it's safe to say [m] because modules almost always just increase your kernel size, giving (almost always) no other performance hit until they're actually loaded and used. Conversely, if you say CONFIG_NETFILTER=y or even worst CONFIG_SMP=y you must know that just for enabling one of this (huge) key-features, your Linux kernel will be slower compared to a UP (UniProcessor == non-SMP) kernel with Netfilter disabled, because this kernel entries translate one-to-one to large #ifdef blocks that are enabled, compiled and executed.