[gentoo-amd64] Re: Kernel-3.10 Nvidia Emerge Failure And Other Stuff
Am 05.07.2013 04:28, schrieb Frank Peters: My interpretation of this message in the nvidia-drivers ebuild is that the maintainers assume that you switch to nouveau. I think it means that the problem occurs so frequently that they do not want to be bothered with bug reports -- and rightly so. Yes. My great disappointment is that xorg or nvidia or whoever was responsible had decided to stop the legacy nv driver that was part of xorg itself. I don't do gaming and I have no need for ultra-high performance graphics. The nv driver was always good enough for me. Are you having problems with nouveau? I'm using nouveau for a while now, and it works perfectly most of the time. It also allows you to use modern desktop environments like Gnome 3.x or cinnamon. I use the nouveau stuff that comes with the sources from kernel.org and the corresponding Xorg driver from portage (~amd64). It's working fine. Regards, Sven
[gentoo-amd64] Re: Kernel-3.10 Nvidia Emerge Failure And Other Stuff
Am 01.07.2013 22:35, schrieb Frank Peters: When I encountered this failure I expected that a huge outcry of bug reports would ensue, but so far things have been rather quiet. There are only a few postings of this problem with 3.10-rc1 and not much else. Well, read the messages on the screen when you try to emerge nvidia-drivers. Doesn't it say, that Gentoo only supports the kernels that NVIDIA supports and that you shall not report a bug nvidia-drivers failing? I should perhaps just patiently wait for the eventual rapid fix, because this error is a real show stopper, but I will make an inquiry nonetheless. Has anyone on the list encountered this error with nvidia and kernel-3.10? My interpretation of this message in the nvidia-drivers ebuild is that the maintainers assume that you switch to nouveau. Nouveau works great for office stuff. But when it comes to gaming I'm hitting a few obstacles. For example, 32bit apps (like wine) are stuck with whatever mesa version is supplied by the emul* packages (mesa 9.0.1 or whatever). It's 2013, and Gentoo still doesn't have proper multilib support in the portage tree. Gentoo is certainly to blame here, but I'd even go further and blame autoconf. Regards, Sven
Re: [gentoo-amd64] Re: Kernel-3.10 Nvidia Emerge Failure And Other Stuff
My interpretation of this message in the nvidia-drivers ebuild is that the maintainers assume that you switch to nouveau. I think it means that the problem occurs so frequently that they do not want to be bothered with bug reports -- and rightly so. My great disappointment is that xorg or nvidia or whoever was responsible had decided to stop the legacy nv driver that was part of xorg itself. I don't do gaming and I have no need for ultra-high performance graphics. The nv driver was always good enough for me. But development stopped on nv a few years ago and it no longer supports the newer Nvidia cards. Frank Peters
[gentoo-amd64] Re: Kernel-3.10 Nvidia Emerge Failure And Other Stuff
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
Re: [gentoo-amd64] Re: Kernel-3.10 Nvidia Emerge Failure And Other Stuff
On Tue, 2 Jul 2013 11:29:47 + (UTC) Duncan 1i5t5.dun...@cox.net wrote: First, there is a new kernel option called Kernel support for scripts starting with #!. And no, as you found out it's *NOT* initramfs-only. It's basic kernel functionality that been assumed for (I guess) decades now. 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. I am entirely sure what is happening with this kernel #! option. My boot scripts are very simple and customized for my specific machine (as opposed to having a complex set of highly generalized scripts that attempt to account for every possible situation). Basically, once the kernel loads itself, it invokes the init binary which then uses parameters in /etc/inittab to invoke appropriate scripts (or other binaries). From my inittab, only a single bash script is called for system initialization and this bash script runs just fine _without_ the kernel #! option. However, after this bash initialization script executes, the console login process then begins. My inittab contains this line for login: agetty -n -l /sbin/autologin 38400 tty1 Now /sbin/autologin is another bash script and it is *only at this point* that the boot fails to complete without the kernel #! option. IOW, my bash boot scripts succeed but the bash autologin script fails w/o the kernel #! option. I suspect, although I have not tested it, that if I substitute a normal binary login (i.e. /bin/login) for the bash /sbin/autologin then the boot will be completely successful w/o the kernel #! option. So what does the #! option accomplish? Does it allow the kernel to effect redirection based on #!? This should only be necessary if bash itself is not invoked, but in boot-up based on init and inittab, bash, I believe, is automatically invoked for all scripts. But yet the agetty program, after boot-up is essentially complete, fails to execute the bash script in its parameter list. At this point is it agetty, or the kernel, that is responsible for executing the autologin script? I need to study this more. Frank Peters
[gentoo-amd64] Re: Kernel-3.10 Nvidia Emerge Failure And Other Stuff
Frank Peters posted on Tue, 02 Jul 2013 12:54:54 -0400 as excerpted: (Thanks for the insight into your more direct boot scripts. I've done that with some things here, including with my own custom suspend/ hibernate scripts, but not with my bootscripts.) So what does the #! option accomplish? Does it allow the kernel to effect redirection based on #!? Yes. This should only be necessary if bash itself is not invoked, but in boot-up based on init and inittab, bash, I believe, is automatically invoked for all scripts. But yet the agetty program, after boot-up is essentially complete, fails to execute the bash script in its parameter list. At this point is it agetty, or the kernel, that is responsible for executing the autologin script? Given your customized setup I don't know for sure, but I can make an educated guess that at the point that breaks in that setup, the already running bootscript invokes a second script directly by name, as if it were a binary. With the kernel shebang option, that works as long as that second script is set executable. But without the kernel shebang option, it fails. The alternative that WOULD work, would be to call that second script using an indirect invocation with bash as the command executed directly by the kernel and the second script as a parameter to it, like so: bash (bash options) /path/to/script (script arguments) By doing it that way, the kernel invokes bash, which knows how to handle it, and can (I believe) in fact handle #!/bin/perl and other foreign interpreter shebangs as well, instead of the kernel attempting to execute the script directly, and failing if the kernel doesn't have shebang support loaded. (Altho it'll be obvious to some, it's also worth mentioning that with indirect script invocation via direct invocation of the interpreter, feeding it the script by commandline, the script itself no longer needs to have executable permissions, since bash is perfectly happy to execute any file it is fed on the commandline as long as it can read it, while the kernel refuses to execute files without the executable bit set.) -- 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
