[gentoo-amd64] Re: Kernel-3.10 Nvidia Emerge Failure And Other Stuff

[Duncan <1i5t5.duncan@cox.net>]

Frank Peters posted on Mon, 01 Jul 2013 15:35:42 -0400 as excerpted:

> Kernel-3.10 has just been released and I quickly grabbed the source and
> compiled.  I usually have no problems with a new kernel but this time
> there were a few surprises.
> 
> First, there is a new kernel option called "Kernel support for scripts
> starting with #!."  This option seemed applicable only to boot scenarios
> involving initramfs but unchecking it caused my system to fail to boot.
> Because this may cause unexpected problems for others, I mention it
> here.

That's standard "shebang" (shell bang or hash-bang) support, 
traditionally used to allow pointing to the interpreter used to interpret 
a script-executable.  It's actually used in a number of contexts, 
including most *ix interpreters understanding it to allow pointing at a 
different interpreter as necessary/desired.  Bash will use this to invoke 
the appropriate executable as interpreter, handing it the file it was 
just sourcing itself to execute, if it encounters a shebang pointing to 
say perl or python instead of sh or bash, for instance.

AFAIK the kernel has long had the option, enabled by default, but it 
probably moved in the kernel config menu and/or was slightly reworded, so 
it showed up as new.

And no, as you found out it's *NOT* initramfs-only.  It's basic kernel 
functionality that been assumed for (I guess) decades now.  The wording 
in the kconfig help text for that option simply explains that if the 
support is compiled as a module rather than built-in, you won't be able 
to run scripts until the module is loaded.  Most binary-based distros 
ship a modules based kernel with initial module loading in an initr*, and 
often the init in the initr* is a script, thus the warning there.

But as you may have noticed, openrc, gentoo's default init system, uses 
#!/sbin/runscript to point to runscript (part of openrc), as its script 
interpreter, and it may well be that turning off kernel shebang support 
screwed you up that way.

Regardless, it's basic enough Linux and Unix functionality that you'll 
nearly always want it enabled and even built-in for any even semi-
traditional Linux install.  Certain embedded cases may not need it, 
however, and I'd guess android (now the largest linux kernel deployment 
by far, well outnumbering traditional gnu/linux deployments) doesn't use 
it either, tho I don't know enough about android to be sure.  Thus the 
option.

> Second, the RTC (real time clock) module option, which has been present
> for a long time as a basic kernel driver, has suddenly disappeared.  To
> get the same functionality, one has to enable the new "PC-style CMOS"
> RTC driver, and because this builds a module with a different name
> (rtc-cmos vs. rtc) my custom start-up scripts suddenly were broken.  It
> took a bit of searching to resolve the problem.  I suppose that users of
> udev may not notice the change, but I mention it just in case others may
>  experience something similar.

Good heads-up. =:^)

> However, the main problem for me with kernel-3.20 is that the
> nvidia-drivers will fail to emerge.

3.10 I think you mean, unless you're a time-traveler just arrived from 
about two years in our future (the kernel release cycle's about 10 weeks, 
roughly 5 releases a year), but anyway...

As the others have said, that's standard and expected behavior with new 
kernels and out-of-tree drivers (including but not limited to the nVidia 
graphics driver) that haven't updated to account for changes to the 
latest mainline kernel code.

See the stable_api_nonsense.txt file in the kernel's Documentation subdir 
for the official explanation, but it's simply a cost of choosing to keep  
kernel code out of the main tree (as nvidia has to do due to their 
refusal to fully open source their code).

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman