[gentoo-amd64] Kernel-3.3.0 and Nvidia-drivers

[gentoo-amd64] Kernel-3.3.0 and Nvidia-drivers

[Frank Peters]

[-- Attachment #1: Type: text/plain, Size: 1717 bytes --]

Linux-3.3.0 is released and, as is my usual habit, I downloaded and compiled
the plain vanilla source.

After rebooting to the command console, and before starting X, I needed
to re-install the nvidia-driver module for the new kernel.  Doing
"emerge nvidia-drivers" gave me the following error (the entire build log
is attached):

>>> Source prepared.
>>> Configuring source in /tmp/portage-acc/tmp/portage/x11-drivers/nvidia-drivers-295.20-r1/work ...
>>> Source configured.
>>> Compiling source in /tmp/portage-acc/tmp/portage/x11-drivers/nvidia-drivers-295.20-r1/work ...
Preparing nvidia module
make -j9 HOSTCC=x86_64-pc-linux-gnu-gcc CROSS_COMPILE=x86_64-pc-linux-gnu- 'LDFLAGS=-m elf_x86_64' IGNORE_CC_MISMATCH=yes V=1 SYSSRC=/usr/src/linux SYSOUT=/lib/modules/3.3.0/build CC=x86_64-pc-linux-gnu-gcc clean module 

*** Unable to determine the target kernel version. ***

make: *** [select_makefile] Error 1
emake failed
ERROR: x11-drivers/nvidia-drivers-295.20-r1 failed (compile phase):
  Unable to emake HOSTCC=x86_64-pc-linux-gnu-gcc CROSS_COMPILE=x86_64-pc-linux-gnu- LDFLAGS=-m elf_x86_64  IGNORE_CC_MISMATCH=yes V=1 SYSSRC=/usr/src/linux 		SYSOUT=/lib/modules/3.3.0/build CC=x86_64-pc-linux-gnu-gcc clean module

Call stack:
    ebuild.sh, line   85:  Called src_compile
  environment, line 3711:  Called linux-mod_src_compile
  environment, line 2668:  Called die
The specific snippet of code:
              eval "emake HOSTCC=\"$(tc-getBUILD_CC)\" 						


The first part of the build log (see attached file) indicates that the
kernel source was correctly found (at /usr/src/linux), but for some
reason the make process fails.

Could this be due to some changes in the kernel-3.3.0 tree?

Frank Peters


[-- Attachment #2: nvidia-build.log --]
[-- Type: text/plain, Size: 4231 bytes --]

^[[32;01m * ^[[39;49;00mPackage:    x11-drivers/nvidia-drivers-295.20-r1
^[[32;01m * ^[[39;49;00mRepository: gentoo
^[[32;01m * ^[[39;49;00mMaintainer: cardoe@gentoo.org jer@gentoo.org,spock@gentoo.org,xarthisius@gentoo.org
^[[32;01m * ^[[39;49;00mUSE:        amd64 elibc_glibc kernel_linux userland_GNU
^[[32;01m * ^[[39;49;00mFEATURES:   sandbox
 ^[[32;01m*^[[0m Determining the location of the kernel source code
 ^[[32;01m*^[[0m Found kernel source directory:
 ^[[32;01m*^[[0m     /usr/src/linux
 ^[[32;01m*^[[0m Found kernel object directory:
 ^[[32;01m*^[[0m     /lib/modules/3.3.0/build
 ^[[32;01m*^[[0m Found sources for kernel version:
 ^[[32;01m*^[[0m     3.3.0
 ^[[32;01m*^[[0m Checking for MTRR support ...
^[[A^[[82C ^[[36m[ ^[[32;01mok^[[36m ]^[[0m
>>> Unpacking source...
>>> Unpacking NVIDIA-Linux-x86_64-295.20.run to /tmp/portage-acc/tmp/portage/x11-drivers/nvidia-drivers-295.20-r1/work
>>> Source unpacked in /tmp/portage-acc/tmp/portage/x11-drivers/nvidia-drivers-295.20-r1/work
>>> Preparing source in /tmp/portage-acc/tmp/portage/x11-drivers/nvidia-drivers-295.20-r1/work ...
 ^[[32;01m*^[[0m Applying 256.35-unified-arch.patch ...
^[[A^[[82C ^[[36m[ ^[[32;01mok^[[36m ]^[[0m
 ^[[32;01m*^[[0m Converting /kernel/Makefile.kbuild to use M= instead of SUBDIRS= ...
^[[A^[[82C ^[[36m[ ^[[32;01mok^[[36m ]^[[0m
>>> Source prepared.
>>> Configuring source in /tmp/portage-acc/tmp/portage/x11-drivers/nvidia-drivers-295.20-r1/work ...
>>> Source configured.
>>> Compiling source in /tmp/portage-acc/tmp/portage/x11-drivers/nvidia-drivers-295.20-r1/work ...
 ^[[32;01m*^[[0m Preparing nvidia module
make -j9 HOSTCC=x86_64-pc-linux-gnu-gcc CROSS_COMPILE=x86_64-pc-linux-gnu- 'LDFLAGS=-m elf_x86_64' IGNORE_CC_MISMATCH=yes V=1 SYSSRC=/usr/src/linux SYSOUT=/lib/modules/3.3.0/build CC=x86_64-pc-linux-gnu-gcc clean module 
If you are using a Linux 2.4 kernel, please make sure
you either have configured kernel sources matching your
kernel or the correct set of kernel headers installed
on your system.

If you are using a Linux 2.6 kernel, please make sure
you have configured kernel sources matching your kernel
installed on your system. If you specified a separate
output directory using either the "KBUILD_OUTPUT" or
the "O" KBUILD parameter, make sure to specify this
directory with the SYSOUT environment variable or with
the equivalent nvidia-installer command line option.

Depending on where and how the kernel sources (or the
kernel headers) were installed, you may need to specify
their location with the SYSSRC environment variable or
the equivalent nvidia-installer command line option.

*** Unable to determine the target kernel version. ***

make: *** [select_makefile] Error 1
emake failed
 ^[[31;01m*^[[0m ERROR: x11-drivers/nvidia-drivers-295.20-r1 failed (compile phase):
 ^[[31;01m*^[[0m   Unable to emake HOSTCC=x86_64-pc-linux-gnu-gcc CROSS_COMPILE=x86_64-pc-linux-gnu- LDFLAGS=-m elf_x86_64  IGNORE_CC_MISMATCH=yes V=1 SYSSRC=/usr/src/linux 		SYSOUT=/lib/modules/3.3.0/build CC=x86_64-pc-linux-gnu-gcc clean module
 ^[[31;01m*^[[0m 
 ^[[31;01m*^[[0m Call stack:
 ^[[31;01m*^[[0m     ebuild.sh, line   85:  Called src_compile
 ^[[31;01m*^[[0m   environment, line 3711:  Called linux-mod_src_compile
 ^[[31;01m*^[[0m   environment, line 2668:  Called die
 ^[[31;01m*^[[0m The specific snippet of code:
 ^[[31;01m*^[[0m               eval "emake HOSTCC=\"$(tc-getBUILD_CC)\" 						CROSS_COMPILE=${CHOST}- 						LDFLAGS=\"$(get_abi_LDFLAGS)\" 						${BUILD_FIXES} 						${BUILD_PARAMS} 						${BUILD_TARGETS} " || die "Unable to emake HOSTCC="$(tc-getBUILD_CC)" CROSS_COMPILE=${CHOST}- LDFLAGS="$(get_abi_LDFLAGS)" ${BUILD_FIXES} ${BUILD_PARAMS} ${BUILD_TARGETS}";
 ^[[31;01m*^[[0m 
 ^[[31;01m*^[[0m If you need support, post the output of 'emerge --info =x11-drivers/nvidia-drivers-295.20-r1',
 ^[[31;01m*^[[0m the complete build log and the output of 'emerge -pqv =x11-drivers/nvidia-drivers-295.20-r1'.
 ^[[31;01m*^[[0m The complete build log is located at '/tmp/portage-acc/log/x11-drivers:nvidia-drivers-295.20-r1:20120319-144118.log'.
 ^[[31;01m*^[[0m The ebuild environment file is located at '/tmp/portage-acc/tmp/portage/x11-drivers/nvidia-drivers-295.20-r1/temp/environment'.
 ^[[31;01m*^[[0m S: '/tmp/portage-acc/tmp/portage/x11-drivers/nvidia-drivers-295.20-r1/work/'

Re: [gentoo-amd64] Kernel-3.3.0 and Nvidia-drivers

[Mark Knecht]

On Mon, Mar 19, 2012 at 9:12 AM, Frank Peters <frank.peters@comcast.net> wrote:
> Linux-3.3.0 is released and, as is my usual habit, I downloaded and compiled
> the plain vanilla source.
>
<SNIP>
> The first part of the build log (see attached file) indicates that the
> kernel source was correctly found (at /usr/src/linux), but for some
> reason the make process fails.
>
> Could this be due to some changes in the kernel-3.3.0 tree?
>
> Frank Peters
>

Possibly this from Google will help?

Good luck & post back,
Mark

Re: [gentoo-amd64] Kernel-3.3.0 and Nvidia-drivers

[Frank Peters]

On Mon, 19 Mar 2012 09:35:34 -0700
Mark Knecht <markknecht@gmail.com> wrote:

> 
> Possibly this from Google will help?
> 

Did you intend to include a link?  If so, it must have gotten
lost somewhere.

Frank Peters

Re: [gentoo-amd64] Kernel-3.3.0 and Nvidia-drivers

[Mark Knecht]

On Mon, Mar 19, 2012 at 12:05 PM, Frank Peters <frank.peters@comcast.net> wrote:
> On Mon, 19 Mar 2012 09:35:34 -0700
> Mark Knecht <markknecht@gmail.com> wrote:
>
>>
>> Possibly this from Google will help?
>>
>
> Did you intend to include a link?  If so, it must have gotten
> lost somewhere.
>
> Frank Peters
>
>

Gadzooks, yes I did. Sorry!

http://weltall.heliohost.org/wordpress/2012/01/20/linux-kernel-3-3-rc1-and-nvidia-drivers/

To be clear, I have no idea if it will solve your exact problem. It
didn't for all.

My experience with nvidia is pretty good if you give them a couple of
days, but very spotty on the first or second day a new kernel minor
rev is released. Nominally I use this page:

http://www.nvidia.com/Download/indexsg.aspx?lang=en-us

and then search out my specific card to determine what _exact_ driver
they want me to run. It almost always requires i run ~amd64.

HTH,
Mark

Re: [gentoo-amd64] Kernel-3.3.0 and Nvidia-drivers

[Frank Peters]

On Mon, 19 Mar 2012 09:35:34 -0700
Mark Knecht <markknecht@gmail.com> wrote:

> 
> Possibly this from Google will help?
> 

OK, I think I've found the URL that you may have intended:

http://weltall.heliohost.org/wordpress/2012/01/20/linux-kernel-3-3-rc1-and-nvidia-drivers/

I followed the second fix that is described and now the nvidia-drivers
emerge and work nicely with linux kernel-3.3.

Thanks for the hint.

There are changes to the kernel-3.3 tree that will have to addressed
by the gentoo nvidia-drivers or other users will hit this problem
as well.

Frank Peters

Re: [gentoo-amd64] Kernel-3.3.0 and Nvidia-drivers

[Mark Knecht]

On Mon, Mar 19, 2012 at 12:30 PM, Frank Peters <frank.peters@comcast.net> wrote:
> On Mon, 19 Mar 2012 09:35:34 -0700
> Mark Knecht <markknecht@gmail.com> wrote:
>
>>
>> Possibly this from Google will help?
>>
>
> OK, I think I've found the URL that you may have intended:
>
> http://weltall.heliohost.org/wordpress/2012/01/20/linux-kernel-3-3-rc1-and-nvidia-drivers/
>
> I followed the second fix that is described and now the nvidia-drivers
> emerge and work nicely with linux kernel-3.3.
>
> Thanks for the hint.
>
> There are changes to the kernel-3.3 tree that will have to addressed
> by the gentoo nvidia-drivers or other users will hit this problem
> as well.
>
> Frank Peters
>
>

Glad you found it. That is the link I just sent along and good to know
it helped a bit.

As I said, on kernel revision number changes I ALWAYS wait a minimum
of 3-5 days before trying to upgrade. nvidia always seems to need at
least a few days to catch up with a new release, or that's been my
experience in the past anyway.

Cheers,
Mark

Re: [gentoo-amd64] Kernel-3.3.0 and Nvidia-drivers

[Paul Hartman]

On Mon, Mar 19, 2012 at 3:08 PM, Mark Knecht <markknecht@gmail.com> wrote:
>
> As I said, on kernel revision number changes I ALWAYS wait a minimum
> of 3-5 days before trying to upgrade. nvidia always seems to need at
> least a few days to catch up with a new release, or that's been my
> experience in the past anyway.

Same here, nvidia-drivers and vmware-modules are why I usually wait
until the .1 release on a new kernel series. :)

Re: [gentoo-amd64] Kernel-3.3.0 and Nvidia-drivers

[Cheng Renquan]

I have switched to nouveau driver, for over 1 year,
using with gnome3 interface, no performance issue, and quite stable,

enjoying every mainline kernel 3.0, 3.1, 3.2, 3.3, no building issue


I think it's time for everyone to give up nvidia-drivers, the blob of binary

On Mon, Mar 19, 2012 at 9:12 AM, Frank Peters <frank.peters@comcast.net> wrote:
> Linux-3.3.0 is released and, as is my usual habit, I downloaded and compiled
> the plain vanilla source.
>
> After rebooting to the command console, and before starting X, I needed
> to re-install the nvidia-driver module for the new kernel.  Doing
> "emerge nvidia-drivers" gave me the following error (the entire build log
> is attached):
>
>>>> Source prepared.
>>>> Configuring source in /tmp/portage-acc/tmp/portage/x11-drivers/nvidia-drivers-295.20-r1/work ...
>>>> Source configured.
>>>> Compiling source in /tmp/portage-acc/tmp/portage/x11-drivers/nvidia-drivers-295.20-r1/work ...
> Preparing nvidia module
> make -j9 HOSTCC=x86_64-pc-linux-gnu-gcc CROSS_COMPILE=x86_64-pc-linux-gnu- 'LDFLAGS=-m elf_x86_64' IGNORE_CC_MISMATCH=yes V=1 SYSSRC=/usr/src/linux SYSOUT=/lib/modules/3.3.0/build CC=x86_64-pc-linux-gnu-gcc clean module
>
> *** Unable to determine the target kernel version. ***

Re: [gentoo-amd64] Kernel-3.3.0 and Nvidia-drivers

[Mark Knecht]

On Mon, Mar 19, 2012 at 12:14 PM, Cheng Renquan <crquan@gmail.com> wrote:
> I have switched to nouveau driver, for over 1 year,
> using with gnome3 interface, no performance issue, and quite stable,
>
> enjoying every mainline kernel 3.0, 3.1, 3.2, 3.3, no building issue
>
>
> I think it's time for everyone to give up nvidia-drivers, the blob of binary
>

And how would one use CUDA if we gave up nvidia-drivers? Does nouveau
support all the CUDA stuff?

Cheers,
Mark

Re: [gentoo-amd64] Kernel-3.3.0 and Nvidia-drivers

[Barry Schwartz]

Mark Knecht <markknecht@gmail.com> skribis:
> And how would one use CUDA if we gave up nvidia-drivers? Does nouveau
> support all the CUDA stuff?

I think they may have reverse engineered CUDA, but whether it is
implemented I don’t know, and I wouldn’t want to be the one to test
it, either. :)

I’m donating processor time with boinc and that’s good enough reason
to use the binary driver if it gives me more processor to donate.

(Waiting before installing anything new is painful, I know, because
with Gentoo you always feel like you want it to be doing something, or
at least that’s my experience. :) )

Re: [gentoo-amd64] Kernel-3.3.0 and Nvidia-drivers

[Mark Knecht]

On Mon, Mar 19, 2012 at 2:28 PM, Barry Schwartz
<chemoelectric@chemoelectric.org> wrote:
> Mark Knecht <markknecht@gmail.com> skribis:
>> And how would one use CUDA if we gave up nvidia-drivers? Does nouveau
>> support all the CUDA stuff?
>
> I think they may have reverse engineered CUDA, but whether it is
> implemented I don’t know, and I wouldn’t want to be the one to test
> it, either. :)
>
> I’m donating processor time with boinc and that’s good enough reason
> to use the binary driver if it gives me more processor to donate.
>
> (Waiting before installing anything new is painful, I know, because
> with Gentoo you always feel like you want it to be doing something, or
> at least that’s my experience. :) )
>

I have no problem with you or anyone else running nouveau. None at all.

I do have a problem with someone saying 'it's time for everyone to
give up nvidia-drivers' without demonstrating they know the full
impact of what they are suggesting. Had Cheng Renquan suggest 'Maybe
people who don't need anything other than basic X capabilities should
consider running nouveau' I wouldn't have even chimed in.

And thanks for running boinc. It's good of you and good for you.

Cheers,
Mark

Re: [gentoo-amd64] Kernel-3.3.0 and Nvidia-drivers

[Barry Schwartz]

Mark Knecht <markknecht@gmail.com> skribis:
> I do have a problem with someone saying 'it's time for everyone to
> give up nvidia-drivers' without demonstrating they know the full
> impact of what they are suggesting. Had Cheng Renquan suggest 'Maybe
> people who don't need anything other than basic X capabilities should
> consider running nouveau' I wouldn't have even chimed in.

Sage Notebook (sage-on-gentoo overlay) can use CUDA as well. I think
you don't have to worry that nvidia-drivers would go away; in the
worst case it would end up in a good overlay. That's unlikely IMO, and
would mostly likely be if there were an established alternative
implementation of CUDA.

Re: [gentoo-amd64] Kernel-3.3.0 and Nvidia-drivers

[Frank Peters]

On Mon, 19 Mar 2012 14:40:34 -0700
Mark Knecht <markknecht@gmail.com> wrote:

> 
> I have no problem with you or anyone else running nouveau. None at all.
> 
> I do have a problem with someone saying 'it's time for everyone to
> give up nvidia-drivers' without demonstrating they know the full
> impact of what they are suggesting. Had Cheng Renquan suggest 'Maybe
> people who don't need anything other than basic X capabilities should
> consider running nouveau' I wouldn't have even chimed in.
> 

I think the main complaint is that the Nvidia drivers are closed
binary blobs while Nouveau is an attempt to create an entirely
open source driver.  The spirit of free software demands that we
support these open initiatives.

Actually, until recently, I was very happy using the legacy open
source xorg nvidia driver known simply as as "nv."  It is still
available in Gentoo as x11-drivers/xf86-video-nv.

Since I do not do gaming or other intensive graphic activities,
I could get by nicely with just nv.  However, the nv driver does
not seem to support the latest hardware too well.  On one of
my machines I have a card based on Nvidia GeForce 210.  Although
the nv driver works with this card, it does not enable the Xv
extension and consequently the graphic response is poor.

On older cards nv does work quite well for ordinary purposes.

Frank Peters

Re: [gentoo-amd64] Kernel-3.3.0 and Nvidia-drivers

[Barry Schwartz]

Frank Peters <frank.peters@comcast.net> skribis:
> I think the main complaint is that the Nvidia drivers are closed
> binary blobs while Nouveau is an attempt to create an entirely
> open source driver.

Unfortunately the nvidia drivers are needed not only for graphics but
also to use the GPU for scientific calculations, including for
donating processor time to medical research, for instance.

[gentoo-amd64] Re: Kernel-3.3.0 and Nvidia-drivers

[Duncan]

Barry Schwartz posted on Tue, 20 Mar 2012 01:20:13 -0500 as excerpted:

> Unfortunately the nvidia drivers are needed not only for graphics but
> also to use the GPU for scientific calculations, including for donating
> processor time to medical research, for instance.

My donation ends where their disrespect for human freedom begins.  (Over 
a decade ago, back on MS, I used to run distributed.net.  However, they 
don't have a freedomware client, or at least didn't back then, and while 
I understand the reasons why -- someone cheating and saying they did the 
work when they didn't, just to get the stats -- that didn't change the 
fact that I wasn't going to run servantware.  But as they say, YMMV.)

-- 
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

[gentoo-amd64] Re: Kernel-3.3.0 and Nvidia-drivers

[Duncan]

Frank Peters posted on Tue, 20 Mar 2012 00:03:06 -0400 as excerpted:

> Actually, until recently, I was very happy using the legacy open source
> xorg nvidia driver known simply as as "nv."  It is still available in
> Gentoo as x11-drivers/xf86-video-nv.
> 
> Since I do not do gaming or other intensive graphic activities, I could
> get by nicely with just nv.  However, the nv driver does not seem to
> support the latest hardware too well.

FWIW, the old nv driver is legacy, now, and won't be supporting new 
hardware.  AFAIK older hardware should be switching as well, for support 
with current software, as nv won't be updated for that any longer, either.

The same thing happened to it as happened to nvidia's proprietary network 
driver some years ago; pretty much everyone involved, including the 
distros that used to ship nv and nvidia itself, seems to have recognized 
that the reverse-engineered work is now better than nvidia's basic 
freedomware stub driver, nv, and nouveau has officially taken its place.

-- 
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] Kernel-3.3.0 and Nvidia-drivers

[Mark Knecht]

On Mon, Mar 19, 2012 at 9:12 AM, Frank Peters <frank.peters@comcast.net> wrote:
> Linux-3.3.0 is released and, as is my usual habit, I downloaded and compiled
> the plain vanilla source.
>
> After rebooting to the command console, and before starting X, I needed
> to re-install the nvidia-driver module for the new kernel.  Doing
> "emerge nvidia-drivers" gave me the following error (the entire build log
> is attached):
>
>>>> Source prepared.
>>>> Configuring source in /tmp/portage-acc/tmp/portage/x11-drivers/nvidia-drivers-295.20-r1/work ...
>>>> Source configured.
>>>> Compiling source in /tmp/portage-acc/tmp/portage/x11-drivers/nvidia-drivers-295.20-r1/work ...
> Preparing nvidia module
> make -j9 HOSTCC=x86_64-pc-linux-gnu-gcc CROSS_COMPILE=x86_64-pc-linux-gnu- 'LDFLAGS=-m elf_x86_64' IGNORE_CC_MISMATCH=yes V=1 SYSSRC=/usr/src/linux SYSOUT=/lib/modules/3.3.0/build CC=x86_64-pc-linux-gnu-gcc clean module
>
> *** Unable to determine the target kernel version. ***
>
> make: *** [select_makefile] Error 1
> emake failed
> ERROR: x11-drivers/nvidia-drivers-295.20-r1 failed (compile phase):
>  Unable to emake HOSTCC=x86_64-pc-linux-gnu-gcc CROSS_COMPILE=x86_64-pc-linux-gnu- LDFLAGS=-m elf_x86_64  IGNORE_CC_MISMATCH=yes V=1 SYSSRC=/usr/src/linux             SYSOUT=/lib/modules/3.3.0/build CC=x86_64-pc-linux-gnu-gcc clean module
>
> Call stack:
>    ebuild.sh, line   85:  Called src_compile
>  environment, line 3711:  Called linux-mod_src_compile
>  environment, line 2668:  Called die
> The specific snippet of code:
>              eval "emake HOSTCC=\"$(tc-getBUILD_CC)\"
>
>
> The first part of the build log (see attached file) indicates that the
> kernel source was correctly found (at /usr/src/linux), but for some
> reason the make process fails.
>
> Could this be due to some changes in the kernel-3.3.0 tree?
>
> Frank Peters
>

Hey Frank,
   I hadn't played with this since you first posted but I've been
waiting for a new nvidia-driver to solve the problem and not seen it.
As my laptop uses vanilla-sources I was stuck but also not really
wanting to do the patch you did.

   Anyway, for kicks this morning I tried gentoo-sources-3.3.0 and
found that nvidia-drivers builds & runs fine with that kernel.

   Don't know if this is helpful but thought I'd let you know that the
gentoo devs seem to know how to fix this for their kernel.

Cheers,
Mark

Re: [gentoo-amd64] Kernel-3.3.0 and Nvidia-drivers

[Frank Peters]

On Thu, 22 Mar 2012 09:03:59 -0700
Mark Knecht <markknecht@gmail.com> wrote:

>
>    I hadn't played with this since you first posted but I've been
> waiting for a new nvidia-driver to solve the problem and not seen it.
> As my laptop uses vanilla-sources I was stuck but also not really
> wanting to do the patch you did.
> 

It's not much of a patch.  It involves only copying a few files
from one directory to another.  Apparently, these files are
auto-generated by the new kernel and placed in the wrong location
(wrong for Nvidia).

>
> Anyway, for kicks this morning I tried gentoo-sources-3.3.0 and
> found that nvidia-drivers builds & runs fine with that kernel.
> 

Out of habit, I still use the kernel sources from kernel.org.
I have an automated build/install for this from a long time
back.  But maybe I'll look into the gentoo-sources one day.
Thanks for the tip.

However, checking the Changelog for gentoo-sources I do not
see any indication of a possible patch to fix 3.3.0.  Maybe
I'm just not looking in the right place.

Frank Peters

Re: [gentoo-amd64] Kernel-3.3.0 and Nvidia-drivers

[Mark Knecht]

On Thu, Mar 22, 2012 at 11:41 AM, Frank Peters <frank.peters@comcast.net> wrote:
> On Thu, 22 Mar 2012 09:03:59 -0700
> Mark Knecht <markknecht@gmail.com> wrote:
>
>>
>>    I hadn't played with this since you first posted but I've been
>> waiting for a new nvidia-driver to solve the problem and not seen it.
>> As my laptop uses vanilla-sources I was stuck but also not really
>> wanting to do the patch you did.
>>
>
> It's not much of a patch.  It involves only copying a few files
> from one directory to another.  Apparently, these files are
> auto-generated by the new kernel and placed in the wrong location
> (wrong for Nvidia).
>
>>
>> Anyway, for kicks this morning I tried gentoo-sources-3.3.0 and
>> found that nvidia-drivers builds & runs fine with that kernel.
>>
>
> Out of habit, I still use the kernel sources from kernel.org.
> I have an automated build/install for this from a long time
> back.  But maybe I'll look into the gentoo-sources one day.
> Thanks for the tip.
>

Ah, so you operate independently as well as outside of the world of
portage do you?!? Shame! ;-)

Anyway, I don't much know what the Gentoo devs do to patch
gentoo-sources. I've gone back and forth between the two at different
times. One reason to stick with gentoo-sources is that vanilla-sources
(and presumably source directly from kernel.org) isn't supported by
Gentoo Security. Not sure how important that is to an individual
though.

> However, checking the Changelog for gentoo-sources I do not
> see any indication of a possible patch to fix 3.3.0.  Maybe
> I'm just not looking in the right place.
>

Dunno. I can only report that my laptop seems happy with
gentoo-source-3.3.0 + nvidia-drivers-295.20-r1. Frame rate is OK. No
weird messages so far in dmesg. Nothing much else to report.

Have fun,
Mark

> Frank Peters
>
>

Re: [gentoo-amd64] Kernel-3.3.0 and Nvidia-drivers

[Barry Schwartz]

Mark Knecht <markknecht@gmail.com> skribis:
> Anyway, I don't much know what the Gentoo devs do to patch
> gentoo-sources. I've gone back and forth between the two at different
> times. One reason to stick with gentoo-sources is that vanilla-sources
> (and presumably source directly from kernel.org) isn't supported by
> Gentoo Security. Not sure how important that is to an individual
> though.

I have found gentoo-sources utterly unreliable and finally settled on
using only vanilla sources, using the ebuild for convenience. The
Gentoo Security warning means essentially nothing to me; it’s not as
if the kernel project is out there purposely creating backdoors that
we can depend on Gentoo to nail shut.

(I’ve recently migrated my system from ~amd64 to amd64 -- yes, it can
be done -- but am still running 3.2.7 rather than the stable
3.2.2. Nevertheless I had to mask the latest ‘stable’ nvidia-drivers;
it made gkrellm crash. In the process of fixing that problem, I
noticed that OpenCL is around as a more generic alternative to CUDA,
so maybe use of that will pick up.)

Re: [gentoo-amd64] Kernel-3.3.0 and Nvidia-drivers

[Barry Schwartz]

Barry Schwartz <chemoelectric@chemoelectric.org> skribis:
> I have found gentoo-sources utterly unreliable and finally settled on
> using only vanilla sources, using the ebuild for convenience.

Not to pick on Gentoo in particular -- I have seen Ubuntu break
otherwise functional kernels with patches, too.

Outside of portage (was Re: [gentoo-amd64] Kernel-3.3.0 and Nvidia-drivers)

[Barry Schwartz]

Frank Peters <frank.peters@comcast.net> skribis:
> Out of habit, I still use the kernel sources from kernel.org.

This makes me curious what other people are using from outside of
Portage. I install Grub outside of Portage, on the grounds that (a) it
is a bad thing to upgrade unless you have to; and (b) the Grub 2
ebuilds were broken anyway, and I didn’t want to switch back to Grub 1
when moving from Exherbo back to Gentoo. So I used the default GNU
install procedure in /usr/local. If the machine boots, the machine
boots, and I’m satisfied.

(I also use only package.use and not make.conf for use flags, a habit
picked up from using Paludis, and recently got rid of package.mask and
use package.accepted_keywords for all my masking. Lots of redundancy
in Portage these days, maybe a bit too much.)

Re: Outside of portage (was Re: [gentoo-amd64] Kernel-3.3.0 and Nvidia-drivers)

[Paul Hartman]

On Thu, Mar 22, 2012 at 4:32 PM, Barry Schwartz
<chemoelectric@chemoelectric.org> wrote:
> Frank Peters <frank.peters@comcast.net> skribis:
>> Out of habit, I still use the kernel sources from kernel.org.
>
> This makes me curious what other people are using from outside of
> Portage. I install Grub outside of Portage, on the grounds that (a) it
> is a bad thing to upgrade unless you have to; and (b) the Grub 2
> ebuilds were broken anyway, and I didn’t want to switch back to Grub 1
> when moving from Exherbo back to Gentoo. So I used the default GNU
> install procedure in /usr/local. If the machine boots, the machine
> boots, and I’m satisfied.
>
> (I also use only package.use and not make.conf for use flags, a habit
> picked up from using Paludis, and recently got rid of package.mask and
> use package.accepted_keywords for all my masking. Lots of redundancy
> in Portage these days, maybe a bit too much.)

I only install things outside of portage into my home directory
(pretending like I don't have root access), or very rarely install a
single binary into /usr/local/bin. For anything else I'll make my own
ebuild (or try to, anyway) and put it in my local overlay.

Re: Outside of portage (was Re: [gentoo-amd64] Kernel-3.3.0 and Nvidia-drivers)

[Barry Schwartz]

Paul Hartman <paul.hartman+gentoo@gmail.com> skribis:
> I only install things outside of portage into my home directory
> (pretending like I don't have root access), or very rarely install a
> single binary into /usr/local/bin. For anything else I'll make my own
> ebuild (or try to, anyway) and put it in my local overlay.

I use local overlays (the main one also available on GitHub) more than
going outside Portage. But it occurred to me that I also install
calibre outside of Portage, in /usr/local; it’s notorious for not
working when repackaged. And I do have parts of TeXLive installed by
Portage because they get pulled in, but if I actually want to use TeX
I have the real, complete TeXLive distribution installed in my home.

Re: Outside of portage (was Re: [gentoo-amd64] Kernel-3.3.0 and Nvidia-drivers)

[Harry Holt]

[-- Attachment #1: Type: text/plain, Size: 1056 bytes --]

The only thing I use outside of Portage is Tomcat.  Because I'm a webapp
developer and the Portage package is a big, steaming PITA.

Sorry about the top-post.  Gmail on Android.

... HE
 On Mar 22, 2012 7:29 PM, "Barry Schwartz" <chemoelectric@chemoelectric.org>
wrote:

> Paul Hartman <paul.hartman+gentoo@gmail.com> skribis:
> > I only install things outside of portage into my home directory
> > (pretending like I don't have root access), or very rarely install a
> > single binary into /usr/local/bin. For anything else I'll make my own
> > ebuild (or try to, anyway) and put it in my local overlay.
>
> I use local overlays (the main one also available on GitHub) more than
> going outside Portage. But it occurred to me that I also install
> calibre outside of Portage, in /usr/local; it’s notorious for not
> working when repackaged. And I do have parts of TeXLive installed by
> Portage because they get pulled in, but if I actually want to use TeX
> I have the real, complete TeXLive distribution installed in my home.
>
>

[-- Attachment #2: Type: text/html, Size: 1422 bytes --]

Re: Outside of portage (was Re: [gentoo-amd64] Kernel-3.3.0 and Nvidia-drivers)

[Benny Pedersen]

Den 2012-03-23 00:33, Harry Holt skrev:
> The only thing I use outside of Portage is Tomcat.  Because Im a
> webapp developer and the Portage package is a big, steaming PITA.

suggestions go into bugs.g.o

> Sorry about the top-post.  Gmail on Android.

stop using it so, it works for your ebuilds, why not here ?

Re: Outside of portage (was Re: [gentoo-amd64] Kernel-3.3.0 and Nvidia-drivers)

[Harry Holt]

[-- Attachment #1: Type: text/plain, Size: 1727 bytes --]

On Fri, Mar 23, 2012 at 4:42 AM, Benny Pedersen <me@junc.org> wrote:

> Den 2012-03-23 00:33, Harry Holt skrev:
>
>> The only thing I use outside of Portage is Tomcat.  Because Im a
>>
>> webapp developer and the Portage package is a big, steaming PITA.
>>
>
> suggestions go into bugs.g.o
>
>
Been there, done that.  Nothing changes, or is really even properly
acknowledged.  For example bug 282071 (
https://bugs.gentoo.org/show_bug.cgi?id=282071) was closed as a duplicate,
even though it's about ROOT and manager, not about "Examples".  The
so-called duplicate 283273 (https://bugs.gentoo.org/show_bug.cgi?id=283273)
is nearly 3 years old with no resolution, or even work-around.

Not even the nearly-as-old bugs submitted to at least document the
brokenness are resolved (https://bugs.gentoo.org/show_bug.cgi?id=277688).

The thing simply has tons of issues that require major pain to work around:

http://forums.gentoo.org/viewtopic-t-713224-start-0-postdays-0-postorder-asc-highlight-.html

http://forums.gentoo.org/viewtopic-t-874051-highlight-tomcat.html

http://forums.gentoo.org/viewtopic-t-886428-highlight-tomcat.html


I doubt there are many people that use it, since it's so much easier just
to download the package from Apache.org and drop it in /opt, and it just
works.

I get that there are issues with the Tomcat up-stream, but it doesn't
change the fact that it takes hours to get it working, and updates often
break the work done to get things properly in place.



>
>  Sorry about the top-post.  Gmail on Android.
>>
>
> stop using it so, it works for your ebuilds, why not here ?
>

Because the benefits outweigh any issues - unlike the Portage Tomcat
package, which is pretty much unusable.

Thx... HH

[-- Attachment #2: Type: text/html, Size: 2960 bytes --]

Re: Outside of portage (was Re: [gentoo-amd64] Kernel-3.3.0 and Nvidia-drivers)

[Gary E. Miller]

[-- Attachment #1: Type: text/plain, Size: 688 bytes --]

Yo Barry!

On Thu, 22 Mar 2012 16:32:55 -0500
Barry Schwartz <chemoelectric@chemoelectric.org> wrote:

> Frank Peters <frank.peters@comcast.net> skribis:
> > Out of habit, I still use the kernel sources from kernel.org.
> 
> This makes me curious what other people are using from outside of
> Portage.

I install Apache, PHP, Mysql and Sendmail from tarballs because the 
ebuilds are not very good and those are performance critical for me.

The rest I let portage manage.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97701
	gem@rellim.com  Tel:+1(541)382-8588

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Outside of portage (was Re: [gentoo-amd64] Kernel-3.3.0 and Nvidia-drivers)

[Mark Knecht]

On Thu, Mar 22, 2012 at 2:32 PM, Barry Schwartz
<chemoelectric@chemoelectric.org> wrote:
> Frank Peters <frank.peters@comcast.net> skribis:
>> Out of habit, I still use the kernel sources from kernel.org.
>
> This makes me curious what other people are using from outside of
> Portage. I install Grub outside of Portage, on the grounds that (a) it
> is a bad thing to upgrade unless you have to; and (b) the Grub 2
> ebuilds were broken anyway, and I didn’t want to switch back to Grub 1
> when moving from Exherbo back to Gentoo. So I used the default GNU
> install procedure in /usr/local. If the machine boots, the machine
> boots, and I’m satisfied.
>
> (I also use only package.use and not make.conf for use flags, a habit
> picked up from using Paludis, and recently got rid of package.mask and
> use package.accepted_keywords for all my masking. Lots of redundancy
> in Portage these days, maybe a bit too much.)
>

In my case nothing outside of portage. I'm not a software developer or
IT professional. I just want my system to work. All my systems are
amd64 stable with a few ~amd64 packages & libraries, as well as a
couple of flags in make.conf but most flags in package.use. I do use a
couple of overlays but I don't maintain any local overlays, again not
wanting to deal with any of that stuff.

I do use package.mask when I want or need to delay something getting
onto one of my machines that I just don't want to deal with until
others have proved it works. (Think about the new udev coming out...)

Cheers,
Mark

Re: Outside of portage (was Re: [gentoo-amd64] Kernel-3.3.0 and Nvidia-drivers)

[Barry Schwartz]

Mark Knecht <markknecht@gmail.com> skribis:
> I do use package.mask when I want or need to delay something getting
> onto one of my machines that I just don't want to deal with until
> others have proved it works. (Think about the new udev coming out...)

I moved most my system other than /home out of LVM and into one big
partition in anticipation of that. No way do I want to use
initramfs. That’s a very good udev to think about before
unmasking. (I’ve had to use rescue CDs due to udev upgrades.)

Linux seems to be heading towards a SunOS-like situation where the
distinction between / and /usr is weak. It’s probably way too late to
go back to having /usr as what we now call /home :)

[gentoo-amd64] Re: Outside of portage (was Re: Kernel-3.3.0 and Nvidia-drivers)

[Duncan]

Barry Schwartz posted on Thu, 22 Mar 2012 16:32:55 -0500 as excerpted:

> Frank Peters <frank.peters@comcast.net> skribis:
>> Out of habit, I still use the kernel sources from kernel.org.
> 
> This makes me curious what other people are using from outside of
> Portage. I install Grub outside of Portage, on the grounds that (a) it
> is a bad thing to upgrade unless you have to; and (b) the Grub 2 ebuilds
> were broken anyway, and I didn’t want to switch back to Grub 1 when
> moving from Exherbo back to Gentoo. So I used the default GNU install
> procedure in /usr/local. If the machine boots, the machine boots, and
> I’m satisfied.
> 
> (I also use only package.use and not make.conf for use flags, a habit
> picked up from using Paludis, and recently got rid of package.mask and
> use package.accepted_keywords for all my masking. Lots of redundancy in
> Portage these days, maybe a bit too much.)

FWIW, I use almost all ebuilds (but for the kernel), but beyond ~amd64/no-
multilib (and ~x86 on my netbook, with a 32-bit chroot build image on my 
main machine, with an rsync script to sync up), I use three overlays 
(kde, mozilla, x11) in addition to my own, unmasking stuff I care about 
that takes too long to show up in ~arch, and a number of -9999 live-git 
packages.

For the kernel, I've been running direct Linus-kernel live-git for quite 
some time now, using my own git-pull, git-whatchanged, make-oldconfig, 
build and install scripts, tho I don't normally update during the 2-weeks 
or so merge window between release and the following -rc1.  Sometimes I 
don't update until rc2 or rc3 if I'm really busy.

This works quite well, giving me a chance to see what's coming.  
Additionally, I get a chance to find, report, and generally get fixed, 
bugs, before they end up in a release kernel.  That's actually the most 
important bit and the reason I run a number of live-git packages.  Git-
bisect is pretty easy, and in a number of cases, I've found that the 
releases simply don't have detailed enough changelogs for me to properly 
trace bugs -- the git commit logs and occasionally the commit sources 
themselves are MUCH more informative, even tho I don't claim to really 
know C/C++ or the like (or even python/perl, but I do OK with bash =:^).

That's precisely why I run openrc-9999 as well.  I had a couple 
experiences where openrc had a regression, and there really isn't a 
proper changelog for it, at least that's easy to view before one actually 
does the install, to be prepared for what's going to be changing.

So eventually I just started running the live-9999 version of openrc, 
updating it perhaps twice a week or so.   I had already created a couple 
scripts to let me view git-whatchanged on the three (all git-based) 
overlays I run, and I expanded them a bit so I could check git-whatchanged 
with openrc-9999 and whatever other live-git based packages I run, as 
well.

Now, with updates a couple times a week, I not only check the whatchanged 
log before I actually do the install, but if anything looks interesting, 
I do a git-show on that specific commit, as well, to see the actual patch.

Then I'm prepared for the etc-updates afterward, and have an idea when/
what might go wrong on the first post-update reboot.  If something /does/ 
go wrong, I can either use init=bash on grub's commandline, or assemble 
md9 (my backup rootfs and /usr/local partitions) instead of md3 (my main 
rootfs and use root=/dev/md9p1 instead of the kernel built-in
root=/dev/md3p1, thus letting me boot, and either fix the problem, or 
emerge the previous binpkg to get back to the old version.

Then I can file the bug, and with openrc as with the kernel, I've 
reported and gotten fixed a number of bugs before they ever made it to a 
full release.  But what's really nice about openrc, unlike the kernel, is 
that enough of it is in shell scripts that I can actually propose patches 
some of the time, spottting and correcting the incorrectly used 
commandline option, or at least understanding and explaining why a change 
to the scripts won't work, even if I'm not sure how to actually make a 
working change that does what they were obviously trying to do.

The only other "regular" live/9999 version package I run is pan, the news 
client, which I use via gmane for following this list, BTW.  I've been 
interested in nntp clients for years, every since I ran the IE/OE4 betas 
back in the MSWindows 95 era, before MSWindows 98.  So when MS decided to 
do the eXPrivacy thing and I switched to Linux in late 2001, after I'd 
gotten settled on Linux and started looking around for a community 
project to contribute to, the nntp client I had chosen was a logical 
first-choice.  So I've been involved with pan upstream since 2002 or so, 
and have been running a live-vcs version since before gnome and with it 
pan, switched from svn to git.

Pan even lost its former primary developer, Charles Kerr, who moved on to 
other things, and the project looked dead for a few years.  But I and a 
couple others kept the lights on in the user list, which continued to 
function, and eventually we attracted one developer, than another and 
another, and now, pan has an active and healthy development community 
once again. =:^)

So of course I want to run pan's live-git/9999 version.  =:^)  There's 
one in the tree, but I run a slightly modified one here, kept in sync 
with upstream, altho I don't always know the proper way to setup the 
newer USE flags, so some of them only have the side I use setup and 
tested.  Plus, the newer version has features that aren't in a full 
release yet, altho there's another release due this spring/summer that 
should have most of them.

Other than that, it depends on what I'm interested in ATM.  Right now, 
I'm following btrfs, so have the -9999/git-live version of btrfs-progs 
installed, tho I'm not actually running a btrfs filesystem yet, as the 
feature I'm most interested in (multi-way mirroring, the feature they 
/call/ raid1 actually isn't, it's only two-way mirroring) isn't there 
yet... they say kernel 3.5-ish.

For a couple months recently I was running the live-git/9999 version of 
phonon-vlc, because it had some patches needed for either the kde 4.8 pre-
releases (which I ran, from the kde overlay... I've not tried full kde 
live tho, at least not since I gave up on it pre-4.0) or for gcc-4.6.x, 
which I unmasked and did a full system rebuild with, a couple months ago.

Awhile back, I was running most of the xorg and mesa stack from live 
packages, because that's where the support for my radeon hd4650 graphics 
card was.  I've not run the xorg/mesa stack live since that support was 
released, but I do sometimes run a couple live-git/9999 xorg packages, 
which are sometimes required to run the latest xorg-server release, or 
because I want to test a new feature in the kernel or mesa, and need a 
live xf86-video-ati to do it, which pulls in a live something else, which 
pulls in two or three other live xorg-releated packages.


You mentioned grub2.  I unmasked and ran the 1.99 version in the tree, 
and have been running the 2.00_betaX versions as well.  Aside from a bit 
of trouble with the initial 1.99 install, and a 2.00_beta1 that would 
boot to the grub menu, but would reboot every time I tried to actually 
boot a kernel, it's been fine.  However, I can mention that while my 
system's legacy-BIOS, I upgraded to GPT partitioning a couple years ago, 
and had the foresight to setup a BIOS-reserved partition on each of my 
four drives.  I've actually been quite happy indeed with how grub2 works 
with that. =:^)

I also run multiple md/raid devices, mostly 4-way RAID-1, and of course, 
grub2 works WAY better with md/raid than did grub-legacy.  But, while 
with most of the system I have a working and backup raid of the same 
size, both 4-way, that wouldn't work for /boot and be able to choose one 
or the other.  So what I did for /boot is split the 4-way in half, into 
two two-way mds, for /boot and the backup /boot.  That sort-of worked OK 
for grub1, getting the job done but managing it was quite complicated.  
By contrast, grub2 makes the boot and backup-boot md/raid management a 
BREEZE! =:^)

But the four drives, two as my main /boot, and the other two as a backup 
/boot, makes upgrading grub a very nearly risk-free exercise, especially 
with GPT and a dedicated BIOS partition for grub2 to use as well. =:^)  I 
have the following set in /etc/portage/env/sys-boot/grub:

# To keep grub from trying to mount /boot,
# on a normally deactivated md.
DONT_MOUNT_BOOT=1

# Just to be safe, since I handle this myself
INSTALL_MASK="$INSTALL_MASK /etc/default /etc/grub.d grub2-mkconfig"
PKG_INSTALL_MASK="$INSTALL_MASK"


I don't know what the package would do if I didn't set the dont-mount 
var, as it can't mount it anyway, since that md/raid device is normally 
not active/assembled.  But with that, it won't even try it.

That means the grub ebuild simply merges it to /usr/* as it normally 
would, and leaves /boot alone.

Then I activate the main boot md and mount it, and run grub2-install 
/dev/sda (the first of the four drives, normally set in BIOS to boot) 
myself.

Then I reboot.  If it doesn't work, I can set the BIOS to boot from sdc 
or sdd instead, where the backup boot is located, with a grub that's 
still the older version.  I can then either fix the issue or revert to 
the older grub, from the backup boot.

When I'm satisfied that the first install is working correctly, then I 
assemble the raid and mount the main /boot again, and run grub2-install 
/dev/sdb (the second spindle on the main /boot).  Then I unmount/stop it 
and assemble and mount the boot backup md/raid, and run grub2-install 
for /dev/sdc and /dev/sdd.

As you can see from the above INSTALL_MASKs I handle the configuration 
manually.  grub2-mkconfig is all but worthless on my system, taking 
longer to install a simple config file than the kernel does to BUILD, or 
at least it did when I tried it back on grub-1.99.  When I profiled/
traced the problem thru the script, it was due to about 50 calls at ~10 
seconds each to grub-probe!

So before I test the backup boot and new grub install to it, I copy over 
any grubenv or *.cfg changes from the main boot to the backup boot.

Then I can reboot again, setting the BIOS to boot from the third or 
fourth drive, to test that.  Once that's tested, I reboot once more and 
set the BIOS back to booting from the first drive and main /boot.


So as you can see, upgrading grub isn't any more dangerous for me than 
upgrading any other package on the system, especially something like 
openrc, which as I said, I run the live version of and generally upgrade 
a couple times a week.  Grub does happen to be a bit more work to 
upgrade, since unlike the rest of the system, at least at this point in 
grub2's life, I upgrade on both the main and backup together, tho only 
after testing main.  For other packages, I only upgrade the backup once 
every few months, after I've rebooted since the last upgrade thereby 
testing that, and everything, all the daemons and bootscripts, xorg/mesa, 
kde, etc, seems to be running normally, preferably when I'm running a 
full kde release version, not a prerelease, which I'm now doing about two 
months out of every six.

-- 
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: Outside of portage (was Re: [gentoo-amd64] Kernel-3.3.0 and Nvidia-drivers)

[Frank Peters]

On Thu, 22 Mar 2012 16:32:55 -0500
Barry Schwartz <chemoelectric@chemoelectric.org> wrote:

> 
> I install Grub outside of Portage, on the grounds that (a) it
> is a bad thing to upgrade unless you have to; and (b) the Grub 2
> ebuilds were broken anyway, and I didn’t want to switch back to Grub 1
> when moving from Exherbo back to Gentoo. So I used the default GNU
> install procedure in /usr/local. If the machine boots, the machine
> boots, and I’m satisfied.
> 

For a person in my situation (i.e. single user, desktop system with no
network beyond ISP connection) -- and I'm sure there are a lot of us
out there -- I cannot see any advantage of grub over lilo.  The Debian
folks rescued lilo from near extinction because they recognized its utility
and there is a gentoo ebuild available.

I hope lilo stays around forever.  It is a sensible choice.

Frank Peters

Re: Outside of portage (was Re: [gentoo-amd64] Kernel-3.3.0 and Nvidia-drivers)

[Barry Schwartz]

Frank Peters <frank.peters@comcast.net> skribis:
> I hope lilo stays around forever.  It is a sensible choice.

Lilo is good; it checks your work for you. The bootloader isn’t really
an operating system feature, in my view, because if you have more than
one OS they are all going to use the same bootloader (not counting
chaining).

Re: Outside of portage (was Re: [gentoo-amd64] Kernel-3.3.0 and Nvidia-drivers)

[Dale]

Barry Schwartz wrote:
> Frank Peters <frank.peters@comcast.net> skribis:
>> I hope lilo stays around forever.  It is a sensible choice.
> 
> Lilo is good; it checks your work for you. The bootloader isn’t really
> an operating system feature, in my view, because if you have more than
> one OS they are all going to use the same bootloader (not counting
> chaining).
> 
> 


This is odd, I switched away from lilo when I was dual booting two Linux
OS's.  The things you are talking about being good are the reasons I
switched.  lol

I been using grub, legacy, for a long time and I have no complaints
about it.  For me, it works better than lilo ever did.  The new grub may
change things tho.  May being the key word.

Dale

:-)  :-)

-- 
I am only responsible for what I said ... Not for what you understood or
how you interpreted my words!

Miss the compile output?  Hint:
EMERGE_DEFAULT_OPTS="--quiet-build=n"

Re: [gentoo-amd64] Kernel-3.3.0 and Nvidia-drivers

[Mark Knecht]

On Mon, Mar 19, 2012 at 9:12 AM, Frank Peters <frank.peters@comcast.net> wrote:
> Linux-3.3.0 is released and, as is my usual habit, I downloaded and compiled
> the plain vanilla source.
>
<SNIP>
>
> Could this be due to some changes in the kernel-3.3.0 tree?
>
> Frank Peters
>

Frank,
   NVidia release 295.33 last night. It's in portage this morning as
of an hour or two ago. The release notes on NVidia's site don't
specifically say anything about the 3.3 kernel but possibly it will
fix your problems with vanilla-sources?

Good luck,
Mark

Re: [gentoo-amd64] Kernel-3.3.0 and Nvidia-drivers

[Mark Knecht]

On Fri, Mar 23, 2012 at 11:28 AM, Mark Knecht <markknecht@gmail.com> wrote:
> On Mon, Mar 19, 2012 at 9:12 AM, Frank Peters <frank.peters@comcast.net> wrote:
>> Linux-3.3.0 is released and, as is my usual habit, I downloaded and compiled
>> the plain vanilla source.
>>
> <SNIP>
>>
>> Could this be due to some changes in the kernel-3.3.0 tree?
>>
>> Frank Peters
>>
>
> Frank,
>   NVidia release 295.33 last night. It's in portage this morning as
> of an hour or two ago. The release notes on NVidia's site don't
> specifically say anything about the 3.3 kernel but possibly it will
> fix your problems with vanilla-sources?
>
> Good luck,
> Mark

Shrug...

Hope you do better then me. This one fails on gentoo-sources-3.3.0
whereas the previous one does not.

Go figure...

- Mark

Re: [gentoo-amd64] Kernel-3.3.0 and Nvidia-drivers

[Frank Peters]

On Fri, 23 Mar 2012 11:28:20 -0700
Mark Knecht <markknecht@gmail.com> wrote:

>    NVidia release 295.33 last night. It's in portage this morning as
> of an hour or two ago. The release notes on NVidia's site don't
> specifically say anything about the 3.3 kernel but possibly it will
> fix your problems with vanilla-sources?
> 

The gentoo package changelog for nvidia does mention the problem and
refers to bug #408841 at bugs.gentoo.org.

As described in the URL that you provided in response to my original
post, the culprit is the location of the generated include files
in kernel 3.3.0.  A simple patch fixes the problem.

With gentoo there are so many places to ask questions -- mailing
lists, forums, and bug sites -- that I am not sure know where to go
for help first.

Frank Peters