From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 150461381F3 for ; Tue, 2 Jul 2013 11:30:08 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 365D6E0AB3; Tue, 2 Jul 2013 11:30:06 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 5D14DE0AAD for ; Tue, 2 Jul 2013 11:30:05 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1UtymZ-0007Yh-EW for gentoo-amd64@lists.gentoo.org; Tue, 02 Jul 2013 13:30:03 +0200 Received: from ip68-231-22-224.ph.ph.cox.net ([68.231.22.224]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 02 Jul 2013 13:30:03 +0200 Received: from 1i5t5.duncan by ip68-231-22-224.ph.ph.cox.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 02 Jul 2013 13:30:03 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-amd64@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-amd64] Re: Kernel-3.10 Nvidia Emerge Failure And Other Stuff Date: Tue, 2 Jul 2013 11:29:47 +0000 (UTC) Message-ID: References: <20130701153542.eedab9994a52502121e7e8e5@comcast.net> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-amd64@lists.gentoo.org Reply-to: gentoo-amd64@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: ip68-231-22-224.ph.ph.cox.net User-Agent: Pan/0.140 (Chocolate Salty Balls; GIT 368aae4 /usr/src/portage/src/egit-src/pan2) X-Archives-Salt: 3cf984cc-b473-49ba-9edc-f6df8ac89a3f X-Archives-Hash: 7d6b770f1cbbb6f1004d573e02e69407 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