1 |
Frank Peters posted on Mon, 01 Jul 2013 15:35:42 -0400 as excerpted: |
2 |
|
3 |
> Kernel-3.10 has just been released and I quickly grabbed the source and |
4 |
> compiled. I usually have no problems with a new kernel but this time |
5 |
> there were a few surprises. |
6 |
> |
7 |
> First, there is a new kernel option called "Kernel support for scripts |
8 |
> starting with #!." This option seemed applicable only to boot scenarios |
9 |
> involving initramfs but unchecking it caused my system to fail to boot. |
10 |
> Because this may cause unexpected problems for others, I mention it |
11 |
> here. |
12 |
|
13 |
That's standard "shebang" (shell bang or hash-bang) support, |
14 |
traditionally used to allow pointing to the interpreter used to interpret |
15 |
a script-executable. It's actually used in a number of contexts, |
16 |
including most *ix interpreters understanding it to allow pointing at a |
17 |
different interpreter as necessary/desired. Bash will use this to invoke |
18 |
the appropriate executable as interpreter, handing it the file it was |
19 |
just sourcing itself to execute, if it encounters a shebang pointing to |
20 |
say perl or python instead of sh or bash, for instance. |
21 |
|
22 |
AFAIK the kernel has long had the option, enabled by default, but it |
23 |
probably moved in the kernel config menu and/or was slightly reworded, so |
24 |
it showed up as new. |
25 |
|
26 |
And no, as you found out it's *NOT* initramfs-only. It's basic kernel |
27 |
functionality that been assumed for (I guess) decades now. The wording |
28 |
in the kconfig help text for that option simply explains that if the |
29 |
support is compiled as a module rather than built-in, you won't be able |
30 |
to run scripts until the module is loaded. Most binary-based distros |
31 |
ship a modules based kernel with initial module loading in an initr*, and |
32 |
often the init in the initr* is a script, thus the warning there. |
33 |
|
34 |
But as you may have noticed, openrc, gentoo's default init system, uses |
35 |
#!/sbin/runscript to point to runscript (part of openrc), as its script |
36 |
interpreter, and it may well be that turning off kernel shebang support |
37 |
screwed you up that way. |
38 |
|
39 |
Regardless, it's basic enough Linux and Unix functionality that you'll |
40 |
nearly always want it enabled and even built-in for any even semi- |
41 |
traditional Linux install. Certain embedded cases may not need it, |
42 |
however, and I'd guess android (now the largest linux kernel deployment |
43 |
by far, well outnumbering traditional gnu/linux deployments) doesn't use |
44 |
it either, tho I don't know enough about android to be sure. Thus the |
45 |
option. |
46 |
|
47 |
> Second, the RTC (real time clock) module option, which has been present |
48 |
> for a long time as a basic kernel driver, has suddenly disappeared. To |
49 |
> get the same functionality, one has to enable the new "PC-style CMOS" |
50 |
> RTC driver, and because this builds a module with a different name |
51 |
> (rtc-cmos vs. rtc) my custom start-up scripts suddenly were broken. It |
52 |
> took a bit of searching to resolve the problem. I suppose that users of |
53 |
> udev may not notice the change, but I mention it just in case others may |
54 |
> experience something similar. |
55 |
|
56 |
Good heads-up. =:^) |
57 |
|
58 |
> However, the main problem for me with kernel-3.20 is that the |
59 |
> nvidia-drivers will fail to emerge. |
60 |
|
61 |
3.10 I think you mean, unless you're a time-traveler just arrived from |
62 |
about two years in our future (the kernel release cycle's about 10 weeks, |
63 |
roughly 5 releases a year), but anyway... |
64 |
|
65 |
As the others have said, that's standard and expected behavior with new |
66 |
kernels and out-of-tree drivers (including but not limited to the nVidia |
67 |
graphics driver) that haven't updated to account for changes to the |
68 |
latest mainline kernel code. |
69 |
|
70 |
See the stable_api_nonsense.txt file in the kernel's Documentation subdir |
71 |
for the official explanation, but it's simply a cost of choosing to keep |
72 |
kernel code out of the main tree (as nvidia has to do due to their |
73 |
refusal to fully open source their code). |
74 |
|
75 |
-- |
76 |
Duncan - List replies preferred. No HTML msgs. |
77 |
"Every nonfree program has a lord, a master -- |
78 |
and if you use the program, he is your master." Richard Stallman |