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
