Errors when building a kernel

[Ralf Mardorf]

On Sat, 22 Aug 2015 08:32:35 -0400, Tom H wrote:
>There's nothing difficult with "make menuconfig" because you can
>search for a specific config value with "/" except that you like to
>ask for help but never seem to like the advice that's given.

This is the first reply to help me with the issue ;).

So I can search for "CONFIG_MPILIB" and likely will find what options I
need to check and/or uncheck to get rid of it?

Thank you.



Send from the wrong account:

Date: Sat, 22 Aug 2015 15:06:15 +0200
From: Ralf
To: ubuntu-devel-discuss at lists.ubuntu.com
Subject: Re: Errors when building a kernel


On Sat, 22 Aug 2015 14:10:01 +0200, Oliver Grawert wrote:
>hi,
>
>Am Samstag, den 22.08.2015, 13:21 +0200 schrieb Ralf Mardorf:
>
>> 
>> Perhaps you understand an analogy. Doing it that way would be like
>> measuring with a meter, that is powered by the same current source as
>> the circuit you'll measure. IOW I quasi try to archive "galvanic
>> isolation" from Ubuntu configs and Ubuntu/Debian rules, to build a
>> kernel for Ubuntu. This usually doesn't cause issues, neither for
>> vanilla, nor for vanilla rt patched kernels, from kernel.org. Now it
>> does cause an issue and I ask for help to do it that way. I know how
>> to do it in other ways. Perhaps you understand the "galvanic
>> isolation" analogy.
>> 
>let me answer with an analogy then ... say you want to measure security
>aspects of a set of tires on a specific car (grip, temperature etc).
>
>to compare these tires against another set, would you trust the values
>you get when you replace the brakes and engine of said car at the same
>time you replace the tires for your measurement or would you rather use
>the same car unmodified and only put on different rubber ?
>
>if you change all aspects at the same time you are effectively
>measuring two sets of tires on two different cars, the data you
>collect doesn't really tell anything about the quality of the tires in
>the end (except that you know they behave different on different cars).
>
>robie pointed you to a PPA that has mainline debs, did you check if
>your drives wake up when running these ? that would be a very simple
>thing to test even without the effort of building anything at all and
>could easily already point out if an ubuntu config or patch are at
>fault here. It would give you a very valuable data point to start from
>with your research and narrow down the possible aspects to inspect
>further.
>
>also note that an ubuntu kernel package is more than vmlinuz and
>modules ... there are configs and postinst scripts run at install time
>of the deb. given that make-kpkg is a debian tool that nobody in ubuntu
>uses for building kernel packages I wouldn't expect the resulting
>package to apply the right postinst/preinst config at all for example
>or set up /etc/kernel in the same way as an ubuntu built kernel package
>does ... sure, you might be lucky and the setup might be the same (I
>have no idea if anyone from the kernel team ever looked at make-kpkg
>settings to syncronize them with an actual ubuntu kernel package
>build), but why risk that if you can easily reduce the possible
>differences by just using the right tree in the documented way.
>
>ciao
>	oli
>
>

Removing modules from the config that anyway don't get loaded doesn't
matter, so your analogy doesn't fit, but my analogy perfectly fits,
since I try to avoid everything Ubuntu related. JFTR I only try to help
Ubuntu developers by pointing out that the issue _is not_ kernel
related. The problem is that tons of packages 1. are already installed
by a minimal install, even if the user doesn't want any of those
packages and 2. a lot of stuff is auto started, even if you don't want
it. IOW regarding the green drive issue I need to check all init
scripts, systemd units and desktop files and what ever else auto starts
things that a user didn't install or a user installed, but only want
to run on demand. Unfortunately the bug gets assigned against linux,
while I didn't filed it against any package.

To build the same kernel for audio usage and not for a bugtracker
report, I would use an Ubuntu config, edit real-time options and build
the kernel likely without running into that many incompatibilities.

In the end my intention is to help Ubuntu Studio developer once I was
able to set up a minimal Wily install. If you follow the Ubuntu Studio
mailing list, you'll see that for this flavour the Ubuntu policy could
be a show stopper, that's why I don't care that much about Ubuntu's
policy.

Instead of debate on principles, it would be useful if you could help
to troubleshoot.

De facto Wily will be released soon and it's still buggy. IMO
troubleshooting the kernel, when the kernel most likely isn't the
culprit, is the major issue. I neither see how it helps to test another
kernel prepared in what Ubuntu way ever, nor why there is the need to
discuss everything.

Note, upstream (not Debian, the real upstream for e.g. a much used MUA
and one and the other audio application) discourage users to use Ubuntu
flavours. Some usage and work-flows are not focus of Ubuntu
maintainers. That's ok, it's just a pity that it seems to be impossible
to help without endless discussions.

I already stopped reporting bugs, e.g. for synaptic, because it's that
time consuming. I never experienced helping to fix bugs as that
complicated and counterproductive as I do now for Ubuntu.