[gentoo-user] [~and64] Headsup for google-chrome users

[gentoo-user] [~and64] Headsup for google-chrome users

[walt]

I just wasted some time figuring out this mess:

I just updated google-chrome, which printed this confusing warning message:

"CONFIG_USED_NS not seen when it should be"

First, there's a typo:  it should read "CONFIG_USER_NS"
                                                  ^  

Then, after I figured out that CONFIG_USER_NS is a kernel config item,
requiring reinstallation of my kernel, I wasted more time figuring out
(for the n'th time) that you shouldn't just change a single kernel config
item and do "make" because that shortcut can break important things.

No, you should do "make clean" first, and then do "make" etc.

Then, after finishing that mess, you then need to re-install ati-drivers
(if you use them) because CONFIG_USER_NS breaks the ati-drivers too.

So, re-install ati-drivers, reboot, etc, all of which will make you late
for work, like I am now :p

Re: [gentoo-user] [~and64] Headsup for google-chrome users

[Alan McKinnon]

On 21/05/2015 14:55, walt wrote:
> I just wasted some time figuring out this mess:
> 
> I just updated google-chrome, which printed this confusing warning message:
> 
> "CONFIG_USED_NS not seen when it should be"
> 
> First, there's a typo:  it should read "CONFIG_USER_NS"
>                                                   ^  
> 
> Then, after I figured out that CONFIG_USER_NS is a kernel config item,
> requiring reinstallation of my kernel, I wasted more time figuring out
> (for the n'th time) that you shouldn't just change a single kernel config
> item and do "make" because that shortcut can break important things.
> 
> No, you should do "make clean" first, and then do "make" etc.
> 
> Then, after finishing that mess, you then need to re-install ati-drivers
> (if you use them) because CONFIG_USER_NS breaks the ati-drivers too.
> 
> So, re-install ati-drivers, reboot, etc, all of which will make you late
> for work, like I am now :p
> 
> 


Ah, the joys of using Gentoo and having to figure that shit out :-)

At least you now know you are on par with maintainers of binary distros.
And that makes you a rock star!

-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] [~and64] Headsup for google-chrome users

[Mike Gilbert]

On Thu, May 21, 2015 at 8:55 AM, walt <w41ter@gmail.com> wrote:
> I just wasted some time figuring out this mess:
>
> I just updated google-chrome, which printed this confusing warning message:
>
> "CONFIG_USED_NS not seen when it should be"
>
> First, there's a typo:  it should read "CONFIG_USER_NS"
>                                                   ^
>

Sorry about that. It's been fixed.

[gentoo-user] Re: [~and64] Headsup for google-chrome users

[Nikos Chantziaras]

On 21/05/15 17:05, Mike Gilbert wrote:
> On Thu, May 21, 2015 at 8:55 AM, walt <w41ter@gmail.com> wrote:
>> I just wasted some time figuring out this mess:
>>
>> I just updated google-chrome, which printed this confusing warning message:
>>
>> "CONFIG_USED_NS not seen when it should be"
>>
>> First, there's a typo:  it should read "CONFIG_USER_NS"
>>                                                    ^
>>
>
> Sorry about that. It's been fixed.

Is the bug referenced in the eclass correct?

   # Warn if the kernel does not support features needed for sandboxing.
   # Bug #363987.

That's:

   https://bugs.gentoo.org/show_bug.cgi?id=363987

Doesn't seem relevant.

Re: [gentoo-user] [~and64] Headsup for google-chrome users

[Dale]

walt wrote:
> I just wasted some time figuring out this mess:
>
> I just updated google-chrome, which printed this confusing warning message:
>
> "CONFIG_USED_NS not seen when it should be"
>
> First, there's a typo:  it should read "CONFIG_USER_NS"
>                                                   ^  
>
> Then, after I figured out that CONFIG_USER_NS is a kernel config item,
> requiring reinstallation of my kernel, I wasted more time figuring out
> (for the n'th time) that you shouldn't just change a single kernel config
> item and do "make" because that shortcut can break important things.
>
> No, you should do "make clean" first, and then do "make" etc.

Doesn't "make clean" clear out your config?  I've changed one thing
before and just run "make" and it work just fine. 

Dale

:-)  :-) 

Re: [gentoo-user] [~and64] Headsup for google-chrome users

[Alec Ten Harmsel]

On 05/21/15 10:57, Dale wrote:
> walt wrote:
>> I just wasted some time figuring out this mess:
>>
>> I just updated google-chrome, which printed this confusing warning message:
>>
>> "CONFIG_USED_NS not seen when it should be"
>>
>> First, there's a typo:  it should read "CONFIG_USER_NS"
>>                                                   ^  
>>
>> Then, after I figured out that CONFIG_USER_NS is a kernel config item,
>> requiring reinstallation of my kernel, I wasted more time figuring out
>> (for the n'th time) that you shouldn't just change a single kernel config
>> item and do "make" because that shortcut can break important things.
>>
>> No, you should do "make clean" first, and then do "make" etc.
> Doesn't "make clean" clear out your config?  I've changed one thing
> before and just run "make" and it work just fine. 
>
> Dale
>
> :-)  :-) 
>


No, "make clean" does not clear your config. It depends on what you
change - I guess their Makefiles/Kconfig doesn't specify all the
dependencies for CONFIG_USER_NS. If you're on a decent machine, the
kernel builds pretty quick anyways, and a clean build will always be
correct.

Alec

Re: [gentoo-user] [~and64] Headsup for google-chrome users

[Neil Bothwick]

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

On Thu, 21 May 2015 09:57:57 -0500, Dale wrote:

> > No, you should do "make clean" first, and then do "make" etc.  
> 
> Doesn't "make clean" clear out your config?  I've changed one thing
> before and just run "make" and it work just fine. 

No.

% make help
Cleaning targets:
  clean           - Remove most generated files but keep the config and
                    enough build support to build external modules
  mrproper        - Remove all generated files + config + various backup files
  distclean       - mrproper + remove editor backup and patch files


-- 
Neil Bothwick

Joystick: (n.) a device essential for performing business tasks and
training exercises esp. favored by pilots, tank commanders, riverboat
          gamblers, and medieval warlords.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [gentoo-user] [~and64] Headsup for google-chrome users

[wabenbau]

walt <w41ter@gmail.com> wrote:

[...]
> Then, after I figured out that CONFIG_USER_NS is a kernel config item,
> requiring reinstallation of my kernel, I wasted more time figuring out
> (for the n'th time) that you shouldn't just change a single kernel
> config item and do "make" because that shortcut can break important
> things.
> 
> No, you should do "make clean" first, and then do "make" etc.
[...]

I haven't done a "make clean" for years when I compiled a kernel and I 
never had any problems.

--
Regards
wabe

Re: [gentoo-user] [~and64] Headsup for google-chrome users

[Mike Gilbert]

On Thu, May 21, 2015 at 3:44 PM,  <wabenbau@gmail.com> wrote:
> walt <w41ter@gmail.com> wrote:
>
> [...]
>> Then, after I figured out that CONFIG_USER_NS is a kernel config item,
>> requiring reinstallation of my kernel, I wasted more time figuring out
>> (for the n'th time) that you shouldn't just change a single kernel
>> config item and do "make" because that shortcut can break important
>> things.
>>
>> No, you should do "make clean" first, and then do "make" etc.
> [...]
>
> I haven't done a "make clean" for years when I compiled a kernel and I
> never had any problems.

Then you have not made any critical config changes, or you have been very lucky.

Re: [gentoo-user] [~and64] Headsup for google-chrome users

[Dale]

Mike Gilbert wrote:
> On Thu, May 21, 2015 at 3:44 PM,  <wabenbau@gmail.com> wrote:
>> walt <w41ter@gmail.com> wrote:
>>
>> [...]
>>> Then, after I figured out that CONFIG_USER_NS is a kernel config item,
>>> requiring reinstallation of my kernel, I wasted more time figuring out
>>> (for the n'th time) that you shouldn't just change a single kernel
>>> config item and do "make" because that shortcut can break important
>>> things.
>>>
>>> No, you should do "make clean" first, and then do "make" etc.
>> [...]
>>
>> I haven't done a "make clean" for years when I compiled a kernel and I
>> never had any problems.
> Then you have not made any critical config changes, or you have been very lucky.
>
>

Then so have I.  I have changed one thing a lot of times over the years,
run make and it work fine.  Most of the time, it is when emerge spits
out that a option is needed for a package to work.  Honestly, this is
the first time I recall hearing this should even be done. 

Dale

:-)  :-) 

Re: [gentoo-user] [~and64] Headsup for google-chrome users

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 1578 bytes --]

On Friday 22 May 2015 00:49:54 Dale wrote:
> Mike Gilbert wrote:
> > On Thu, May 21, 2015 at 3:44 PM,  <wabenbau@gmail.com> wrote:
> >> walt <w41ter@gmail.com> wrote:
> >> 
> >> [...]
> >> 
> >>> Then, after I figured out that CONFIG_USER_NS is a kernel config item,
> >>> requiring reinstallation of my kernel, I wasted more time figuring out
> >>> (for the n'th time) that you shouldn't just change a single kernel
> >>> config item and do "make" because that shortcut can break important
> >>> things.
> >>> 
> >>> No, you should do "make clean" first, and then do "make" etc.
> >> 
> >> [...]
> >> 
> >> I haven't done a "make clean" for years when I compiled a kernel and I
> >> never had any problems.
> > 
> > Then you have not made any critical config changes, or you have been very
> > lucky.
> 
> Then so have I.  I have changed one thing a lot of times over the years,
> run make and it work fine.  Most of the time, it is when emerge spits
> out that a option is needed for a package to work.  Honestly, this is
> the first time I recall hearing this should even be done.
> 
> Dale
> 
> :-)  :-)

I knew it should be done, but thought it ought to be done when you want to 
start with a clean slate and I didn't know if I needed to do this, or what a 
clean slate involved exactly.

Since I run 'make oldconfig' I always assumed that I don't need a clean slate, 
plus updating minor versions takes seconds.

So I'm the 3rd one in row to state that I haven't had any deleterious effects 
that I noticed.

-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [gentoo-user] [~and64] Headsup for google-chrome users

[Dale]

Mick wrote:
> On Friday 22 May 2015 00:49:54 Dale wrote:
>> Mike Gilbert wrote:
>>> On Thu, May 21, 2015 at 3:44 PM,  <wabenbau@gmail.com> wrote:
>>>> walt <w41ter@gmail.com> wrote:
>>>>
>>>> [...]
>>>>
>>>>> Then, after I figured out that CONFIG_USER_NS is a kernel config item,
>>>>> requiring reinstallation of my kernel, I wasted more time figuring out
>>>>> (for the n'th time) that you shouldn't just change a single kernel
>>>>> config item and do "make" because that shortcut can break important
>>>>> things.
>>>>>
>>>>> No, you should do "make clean" first, and then do "make" etc.
>>>> [...]
>>>>
>>>> I haven't done a "make clean" for years when I compiled a kernel and I
>>>> never had any problems.
>>> Then you have not made any critical config changes, or you have been very
>>> lucky.
>> Then so have I.  I have changed one thing a lot of times over the years,
>> run make and it work fine.  Most of the time, it is when emerge spits
>> out that a option is needed for a package to work.  Honestly, this is
>> the first time I recall hearing this should even be done.
>>
>> Dale
>>
>> :-)  :-)
> I knew it should be done, but thought it ought to be done when you want to 
> start with a clean slate and I didn't know if I needed to do this, or what a 
> clean slate involved exactly.
>
> Since I run 'make oldconfig' I always assumed that I don't need a clean slate, 
> plus updating minor versions takes seconds.
>
> So I'm the 3rd one in row to state that I haven't had any deleterious effects 
> that I noticed.
>


When I first emerge a new kernel, I run make mrproper to get a good
clean start.  I then copy my old config over to the new kernel.  After
that, I don't run clean or mrproper again for that version.  If I change
something, I run menuconfig, make the change, run make all && make
modules_install and then copy it over.  I don't even want to try and
count the number of times I've changed just one setting because some
package needed it before it would update.  Sometimes, I may change a
kernel several times before I update to a new version. 

I been doing this the same way ever since about 2003.  As some know, if
it would cause a problem, I should have found it by now, at least once. 
;-)

Dale

:-)  :-) 

Re: [gentoo-user] [~and64] Headsup for google-chrome users

[Neil Bothwick]

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

On Fri, 22 May 2015 02:53:17 -0500, Dale wrote:

> > So I'm the 3rd one in row to state that I haven't had any deleterious
> > effects that I noticed.

Make that 4.

> When I first emerge a new kernel, I run make mrproper to get a good
> clean start.

There's no point in that. When you have just emerged the sources, there is
nothing for mrproper to remove.


-- 
Neil Bothwick

"B?#$^f," said Pooh, as line noise garbled his transmission.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [gentoo-user] [~and64] Headsup for google-chrome users

[Dale]

Neil Bothwick wrote:
> On Fri, 22 May 2015 02:53:17 -0500, Dale wrote:
>
>>> So I'm the 3rd one in row to state that I haven't had any deleterious
>>> effects that I noticed.
> Make that 4.
>
>> When I first emerge a new kernel, I run make mrproper to get a good
>> clean start.
> There's no point in that. When you have just emerged the sources, there is
> nothing for mrproper to remove.
>
>


Sometimes, it prints that it removed stuff.  Usually not but once in a
while it says it removed something.  No clue what that was tho. 

Dale

:-)  :-) 

Re: [gentoo-user] [~and64] Headsup for google-chrome users

[Alan McKinnon]

On 22/05/2015 10:38, Neil Bothwick wrote:
> On Fri, 22 May 2015 02:53:17 -0500, Dale wrote:
> 
>>> So I'm the 3rd one in row to state that I haven't had any deleterious
>>> effects that I noticed.
> 
> Make that 4.



/raises hand:

5


Seems like there's a lot of cargo-cult advice around about how to
configure a kernel....

> 
>> When I first emerge a new kernel, I run make mrproper to get a good
>> clean start.
> 
> There's no point in that. When you have just emerged the sources, there is
> nothing for mrproper to remove.
> 
> 


-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] [~and64] Headsup for google-chrome users

[gottlieb]

On Fri, May 22 2015, Alan McKinnon wrote:

> On 22/05/2015 10:38, Neil Bothwick wrote:
>> On Fri, 22 May 2015 02:53:17 -0500, Dale wrote:
>> 
>>>> So I'm the 3rd one in row to state that I haven't had any deleterious
>>>> effects that I noticed.
>> 
>> Make that 4.
>
> /raises hand:
> 5

++1

allan

Re: [gentoo-user] [~and64] Headsup for google-chrome users

[Daniel Frey]

On 05/22/2015 02:19 AM, Alan McKinnon wrote:
> On 22/05/2015 10:38, Neil Bothwick wrote:
>> On Fri, 22 May 2015 02:53:17 -0500, Dale wrote:
>>
>>>> So I'm the 3rd one in row to state that I haven't had any deleterious
>>>> effects that I noticed.
>>
>> Make that 4.
> 
> 
> 
> /raises hand:
> 
> 5
> 

/raises hand too

Make that 6.

I've been compiling kernels since 2003 and never used make clean or make
mrproper. I use make oldconfig all the time.

I didn't even know about make install until I read this thread, I always
manually copied kernels over.

Dan

Re: [gentoo-user] [~and64] Headsup for google-chrome users

[Dale]

Daniel Frey wrote:
> On 05/22/2015 02:19 AM, Alan McKinnon wrote:
>> On 22/05/2015 10:38, Neil Bothwick wrote:
>>> On Fri, 22 May 2015 02:53:17 -0500, Dale wrote:
>>>
>>>>> So I'm the 3rd one in row to state that I haven't had any deleterious
>>>>> effects that I noticed.
>>> Make that 4.
>>
>>
>> /raises hand:
>>
>> 5
>>
> /raises hand too
>
> Make that 6.
>
> I've been compiling kernels since 2003 and never used make clean or make
> mrproper. I use make oldconfig all the time.
>
> I didn't even know about make install until I read this thread, I always
> manually copied kernels over.
>
> Dan
>
>
> .

I have always copied mine over manually too.  I keep quite a few spares
laying around, just in case.  I had one that got corrupted a long time
ago.  After I booted another kernel and looked at the one I was trying
to boot, it was only a few kilo bytes worth.  No clue what happened
there.  I just copied it over again and the size was right.  Then it
booted fine.  Weird. 

Dale

:-)  :-) 

Re: [gentoo-user] [~and64] Headsup for googled the previous one to vmlinu-chrome users

[Neil Bothwick]

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

On Fri, 22 May 2015 12:21:15 -0500, Dale wrote:

> > I didn't even know about make install until I read this thread, I
> > always manually copied kernels over.

> I have always copied mine over manually too.  I keep quite a few spares
> laying around, just in case.

Make install only copies the new kernel, it doesn't touch your existing
ones. However, if you use symlinks in /boot, it links the new
kernel to vmlinuz and the previous one to vmlinuz.old, which removes the
need to alter your grub config.


-- 
Neil Bothwick

Ifyoucanreadthis,youspendtoomuchtimefiguringouttaglines.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [gentoo-user] [~and64] Headsup for googled the previous one to vmlinu-chrome users

[Dale]

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

Neil Bothwick wrote:
> On Fri, 22 May 2015 12:21:15 -0500, Dale wrote:
>
>>> I didn't even know about make install until I read this thread, I
>>> always manually copied kernels over.
>
>> I have always copied mine over manually too.  I keep quite a few spares
>> laying around, just in case.
>
> Make install only copies the new kernel, it doesn't touch your existing
> ones. However, if you use symlinks in /boot, it links the new
> kernel to vmlinuz and the previous one to vmlinuz.old, which removes the
> need to alter your grub config.
>
>

I'm sure that works but I've been doing the way I do it because that
works for me.  This is what I end up with:

-rw-r--r-- 1 root root 5148896 Dec  6  2013 /boot/kernel-3.11.6-1
-rw-r--r-- 1 root root 5269728 Mar 23  2014 /boot/kernel-3.13.6-1
-rw-r--r-- 1 root root 5309456 Apr  6  2014 /boot/kernel-3.14.0-1
-rw-r--r-- 1 root root 5370192 Aug 10  2014 /boot/kernel-3.16.0-1
-rw-r--r-- 1 root root 5371280 Oct  6  2014 /boot/kernel-3.16.3-1
-rw-r--r-- 1 root root 5316576 Oct 25  2014 /boot/kernel-3.16.3-2
-rw-r--r-- 1 root root 5388960 May  1 00:53 /boot/kernel-3.18.12-1
-rw-r--r-- 1 root root 5387488 Feb  8 13:10 /boot/kernel-3.18.5-1
-rw-r--r-- 1 root root 5387680 Feb 27 18:03 /boot/kernel-3.18.7-1
-rw-r--r-- 1 root root 5387584 Mar 14 16:56 /boot/kernel-3.18.9-1
 

I also save the config with the same version part as the kernel, that
way I know which config goes with which kernel.  Everyone has their own
way of doing what works for them.  I just prefer to copy my own manually
with a name that makes sense to me.  I don't think make install will do
this the way I do it.

To each his own.

Dale

:-)  :-)


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

Re: [gentoo-user] [~and64] Headsup for googled the previous one to vmlinu-chrome users

[Neil Bothwick]

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

On Fri, 22 May 2015 17:04:49 -0500, Dale wrote:

> I also save the config with the same version part as the kernel, that
> way I know which config goes with which kernel.  Everyone has their own
> way of doing what works for them.  I just prefer to copy my own manually
> with a name that makes sense to me.  I don't think make install will do
> this the way I do it.

make install does it exactly the way you are doing it, but faster and
less prone to error.


-- 
Neil Bothwick

"They that can give up essential liberty to obtain a little
temporary safety, deserve neither liberty nor safety."
    Benjamin Franklin

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [gentoo-user] [~and64] Headsup for googled the previous one to vmlinu-chrome users

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 850 bytes --]

On Friday 22 May 2015 23:13:06 Neil Bothwick wrote:
> On Fri, 22 May 2015 17:04:49 -0500, Dale wrote:
> > I also save the config with the same version part as the kernel, that
> > way I know which config goes with which kernel.  Everyone has their own
> > way of doing what works for them.  I just prefer to copy my own manually
> > with a name that makes sense to me.  I don't think make install will do
> > this the way I do it.
> 
> make install does it exactly the way you are doing it, but faster and
> less prone to error.

Hmm ... I may have used it the wrong way quite a few years ago, but it would 
only keep two kernels at a time or something like that.  That made me carry on 
copying kernel files into boot manually.  In this way at least I know where I 
put them and what options I pass on to them.

-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [gentoo-user] [~and64] Headsup for googled the previous one to vmlinu-chrome users

[Neil Bothwick]

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

On Fri, 22 May 2015 23:29:40 +0100, Mick wrote:

> > make install does it exactly the way you are doing it, but faster and
> > less prone to error.  
> 
> Hmm ... I may have used it the wrong way quite a few years ago, but it
> would only keep two kernels at a time or something like that.  That
> made me carry on copying kernel files into boot manually.  In this way
> at least I know where I put them and what options I pass on to them.

make install installs the kernel it just made. It doesn't, and can't,
touch other kernels. The only change it makes to /boot beyond copying
three files there is to adjust the symlinks if they are already present.

I've never understood the approach of trusting the makefile to configure
your kernel, compile it, compile any number of modules and install all
those modules, but when it comes to copying one file to /boot, that has
to be done manually because the makefile can't be trusted to get things
right.


-- 
Neil Bothwick

Microbiology: staph only.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [gentoo-user] [~and64] Headsup for googled the previous one to vmlinu-chrome users

[Tom H]

On Fri, May 22, 2015 at 6:58 PM, Neil Bothwick <neil@digimed.co.uk> wrote:
> On Fri, 22 May 2015 23:29:40 +0100, Mick wrote:
>>>
>>> make install does it exactly the way you are doing it, but faster and
>>> less prone to error.
>>
>> Hmm ... I may have used it the wrong way quite a few years ago, but it
>> would only keep two kernels at a time or something like that. That
>> made me carry on copying kernel files into boot manually. In this way
>> at least I know where I put them and what options I pass on to them.
>
> make install installs the kernel it just made. It doesn't, and can't,
> touch other kernels. The only change it makes to /boot beyond copying
> three files there is to adjust the symlinks if they are already present.
>
> I've never understood the approach of trusting the makefile to configure
> your kernel, compile it, compile any number of modules and install all
> those modules, but when it comes to copying one file to /boot, that has
> to be done manually because the makefile can't be trusted to get things
> right.

"/sbin/installkernel" renames the already-installed vmlinuz and
System.map if it's installing the same version of the kernel.

Re: [gentoo-user] [~and64] Headsup for googled the previous one to vmlinu-chrome users

[Neil Bothwick]

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

On Fri, 22 May 2015 20:55:39 -0400, Tom H wrote:

> > I've never understood the approach of trusting the makefile to
> > configure your kernel, compile it, compile any number of modules and
> > install all those modules, but when it comes to copying one file
> > to /boot, that has to be done manually because the makefile can't be
> > trusted to get things right.  
> 
> "/sbin/installkernel" renames the already-installed vmlinuz and
> System.map if it's installing the same version of the kernel.

Not if you set LOCALVERSION or LOCALVERSION_AUTO in the kernel config,
then you never get two kernels with the same name.


-- 
Neil Bothwick

Keyboard: (n.) a device used by programmers to write software for a mouse
or joystick and by operators for playing games such as 'word processing.'

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [gentoo-user] [~and64] Headsup for googled the previous one to vmlinu-chrome users

[Tom H]

On Fri, May 22, 2015 at 6:29 PM, Mick <michaelkintzios@gmail.com> wrote:
> On Friday 22 May 2015 23:13:06 Neil Bothwick wrote:
>> On Fri, 22 May 2015 17:04:49 -0500, Dale wrote:
>>>
>>> I also save the config with the same version part as the kernel, that
>>> way I know which config goes with which kernel. Everyone has their own
>>> way of doing what works for them. I just prefer to copy my own manually
>>> with a name that makes sense to me. I don't think make install will do
>>> this the way I do it.
>>
>> make install does it exactly the way you are doing it, but faster and
>> less prone to error.
>
> Hmm ... I may have used it the wrong way quite a few years ago, but it would
> only keep two kernels at a time or something like that. That made me carry on
> copying kernel files into boot manually. In this way at least I know where I
> put them and what options I pass on to them.

Two same-version kernels at a time? That's true because of
"/sbin/installkernel".

Re: [gentoo-user] [~and64] Headsup for googled the previous one to vmlinu-chrome users

[Walter Dnes]

On Fri, May 22, 2015 at 11:29:40PM +0100, Mick wrote
> On Friday 22 May 2015 23:13:06 Neil Bothwick wrote:
> > 
> > make install does it exactly the way you are doing it, but faster and
> > less prone to error.
> 
> Hmm ... I may have used it the wrong way quite a few years ago, but
> it would only keep two kernels at a time or something like that.
> That made me carry on copying kernel files into boot manually.
> In this way at least I know where I put them and what options I pass
> on to them.

  I've automated that process.  I have 2 kernels, "experimental" and
"production".  I use 2 scripts "makeover" and "promote".  When I first
build a new kernel, I run the the "makeover" script, which does make and
overwrites the previous experimental kernel.  Note that this script
*MUST* be executed from the /usr/src/linux/ directory.

#!/bin/bash
make && \
make modules_install && \
cp  arch/x86_64/boot/bzImage /boot/kernel.experimental && \
cp System.map /boot/System.map.experimental && \
cp .config /boot/config.experimental && \
lilo

  When the "experimental" kernel has been running OK for a couple of
weeks, I promote it to "production" with the "promote" script...

#!/bin/bash
cp /boot/System.map.experimental /boot/System.map.production
cp /boot/config.experimental /boot/config.production
cp /boot/kernel.experimental /boot/kernel.production
lilo

  This hooks into my /etc/lilo.conf menu, shown here with comment lines
removed...

###########################################
lba32

boot = /dev/sda
map = /boot/.map

install = /boot/boot-menu.b

menu-scheme=Wb
prompt
timeout=150
delay = 50

image = /boot/kernel.production
        root = /dev/sda5
        label = Production
        read-only # read-only for checking
        append = "noexec=on net.ifnames=0"

image = /boot/kernel.experimental
        root = /dev/sda5
        label = Experimental
        read-only # read-only for checking
        append = "noexec=on net.ifnames=0"
###########################################

  This has saved me on occasion, allowing me to fall back to a working
"production" kernel when things go badly with "experimental".  I then
run my "demote" script.

#!/bin/bash
cp /boot/System.map.production /boot/System.map.experimental
cp /boot/config.production /boot/config.experimental
cp /boot/kernel.production /boot/kernel.experimental
lilo

  I also have my kernels set up so that I can...

zcat /proc/config.gz > /usr/src/linux/.config

...to retrieve a known working .config file from the currently running
kernel.  This puts me back to square 1 with the experimental kernel.

-- 
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

Re: [gentoo-user] [~and64] Headsup for googled the previous one to vmlinu-chrome users

[Dale]

Neil Bothwick wrote:
> On Fri, 22 May 2015 17:04:49 -0500, Dale wrote:
>
>> I also save the config with the same version part as the kernel, that
>> way I know which config goes with which kernel.  Everyone has their own
>> way of doing what works for them.  I just prefer to copy my own manually
>> with a name that makes sense to me.  I don't think make install will do
>> this the way I do it.
> make install does it exactly the way you are doing it, but faster and
> less prone to error.
>
>


Funny, I've yet to screw up copying and naming a kernel.  Also, I get to
name it the way I want to name it not the way someone else wants to name
it.  I sort of doubt that make install will repeat the same naming
scheme I use.  Of course, I haven't tried it in a long time either.  It
wouldn't do what I wanted the last time I read about it so I never used
it.  I haven't seen any need to since I don't update my kernels that
often.  I'm going on two months since my last reboot. 

Dale

:-)  :-) 

Re: [gentoo-user] [~and64] Headsup for google-chrome users

[Daniel Frey]

On 05/22/2015 10:21 AM, Dale wrote:
> 
> I have always copied mine over manually too.  I keep quite a few spares
> laying around, just in case.  I had one that got corrupted a long time
> ago.  After I booted another kernel and looked at the one I was trying
> to boot, it was only a few kilo bytes worth.  No clue what happened
> there.  I just copied it over again and the size was right.  Then it
> booted fine.  Weird. 

I've manually copied the kernel .config over and had that happen. I
remember thinking why is it so small, then I opened it with vim and went
"Ohhhh....." ;-)

Dan

Re: [gentoo-user] [~and64] Headsup for google-chrome users

[Dale]

Daniel Frey wrote:
> On 05/22/2015 10:21 AM, Dale wrote:
>> I have always copied mine over manually too.  I keep quite a few spares
>> laying around, just in case.  I had one that got corrupted a long time
>> ago.  After I booted another kernel and looked at the one I was trying
>> to boot, it was only a few kilo bytes worth.  No clue what happened
>> there.  I just copied it over again and the size was right.  Then it
>> booted fine.  Weird. 
> I've manually copied the kernel .config over and had that happen. I
> remember thinking why is it so small, then I opened it with vim and went
> "Ohhhh....." ;-)
>
> Dan
>
> .
>


Well, I think something went goofy at some point since it wasn't the
config.  I did try to open it and got the usual garbage stuff not a text
file.  If I recall correctly, that was on a drive that later died.  It
very well could be that it just went corrupt.  Also, that kernel had
been used before, it just didn't work that time.  It's been a while back
and was on another machine.  So far, the last time I had a kernel fail
on first boot was waaaaaaay back when I was first creating my own
kernels and was learning what options were a must have.  That would be
back around 2003 or so. 

Dang, I'm getting to be a old Linux fart.  ROFL  :-( 

Dale

:-)  :-) 

Re: [gentoo-user] [~and64] Headsup for google-chrome users

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 898 bytes --]

On Friday 22 May 2015 09:38:46 Neil Bothwick wrote:
> On Fri, 22 May 2015 02:53:17 -0500, Dale wrote:
> > > So I'm the 3rd one in row to state that I haven't had any deleterious
> > > effects that I noticed.
> 
> Make that 4.
> 
> > When I first emerge a new kernel, I run make mrproper to get a good
> > clean start.
> 
> There's no point in that. When you have just emerged the sources, there is
> nothing for mrproper to remove.


So, coming back to the OP, is it advisable to ignore this message:

* Messages for package www-client/chromium-43.0.2357.65:                
[27/1984]

 *   USER_NS is required for sandbox to work
 * Please check to make sure these options are set correctly.
 * Failure to do so may cause unexpected problems.

which doesn't even advise where to find USER_NS, or will chromium no longer 
work as it did in the past?

-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [gentoo-user] [~and64] Headsup for google-chrome users

[Alan McKinnon]

On 22/05/2015 12:44, Mick wrote:
> On Friday 22 May 2015 09:38:46 Neil Bothwick wrote:
>> On Fri, 22 May 2015 02:53:17 -0500, Dale wrote:
>>>> So I'm the 3rd one in row to state that I haven't had any deleterious
>>>> effects that I noticed.
>>
>> Make that 4.
>>
>>> When I first emerge a new kernel, I run make mrproper to get a good
>>> clean start.
>>
>> There's no point in that. When you have just emerged the sources, there is
>> nothing for mrproper to remove.
> 
> 
> So, coming back to the OP, is it advisable to ignore this message:


No. It's in the ebuild and we assume the ebuild writer had a reason for
putting it there. The usual reason is that upstream has said their code
requires an option to be set.

Where would you have gotten the idea that ignoring it is good advice?




> 
> * Messages for package www-client/chromium-43.0.2357.65:                
> [27/1984]
> 
>  *   USER_NS is required for sandbox to work
>  * Please check to make sure these options are set correctly.
>  * Failure to do so may cause unexpected problems.
> 
> which doesn't even advise where to find USER_NS, or will chromium no longer 
> work as it did in the past?
> 


-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] [~and64] Headsup for google-chrome users

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 2001 bytes --]

On Friday 22 May 2015 12:09:34 Alan McKinnon wrote:
> On 22/05/2015 12:44, Mick wrote:
> > On Friday 22 May 2015 09:38:46 Neil Bothwick wrote:
> >> On Fri, 22 May 2015 02:53:17 -0500, Dale wrote:
> >>>> So I'm the 3rd one in row to state that I haven't had any deleterious
> >>>> effects that I noticed.
> >> 
> >> Make that 4.
> >> 
> >>> When I first emerge a new kernel, I run make mrproper to get a good
> >>> clean start.
> >> 
> >> There's no point in that. When you have just emerged the sources, there
> >> is nothing for mrproper to remove.
> > 
> > So, coming back to the OP, is it advisable to ignore this message:
> No. It's in the ebuild and we assume the ebuild writer had a reason for
> putting it there. The usual reason is that upstream has said their code
> requires an option to be set.
> 
> Where would you have gotten the idea that ignoring it is good advice?

Because the emerge did not stop to warn me about it, or require me to 
acknowledge before proceeding.  Furthermore it tells me that bad things may 
happen, but doesn't explain what kind of bad things, referring to a URL if 
space does not allow.  At this stage I am guessing that chromium's sandboxing 
mechanism is changed and it now requires a different memory allocation 
mechanism than what I had previously configured in my kernel.  Having to 
configure my kernel to get a browser working sounds quite intrusive so I am 
worried some more.

Looking at the changelog and then at bugs referred to there, I eventually 
arrived at CVE-2015-1252 [1] where the problem is explained:

In any case, I think that something like this should invite user input at the 
start of the ebuild, rather than at the end?  I haven't figured out yet if I 
will need to reinstall chromium after I have reconfigured my kernel ... in 
which case the warning should definitely come at the start of the ebuild.

[1] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-1252

-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

[gentoo-user] Re: [~and64] Headsup for google-chrome users

[walt]

On 05/21/2015 04:49 PM, Dale wrote:
> Mike Gilbert wrote:
>> On Thu, May 21, 2015 at 3:44 PM,  <wabenbau@gmail.com> wrote:
>>> walt <w41ter@gmail.com> wrote:
>>>
>>> [...]
>>>> Then, after I figured out that CONFIG_USER_NS is a kernel config item,
>>>> requiring reinstallation of my kernel, I wasted more time figuring out
>>>> (for the n'th time) that you shouldn't just change a single kernel
>>>> config item and do "make" because that shortcut can break important
>>>> things.
>>>>
>>>> No, you should do "make clean" first, and then do "make" etc.
>>> [...]
>>>
>>> I haven't done a "make clean" for years when I compiled a kernel and I
>>> never had any problems.
>> Then you have not made any critical config changes, or you have been very lucky.
>>
>>
> 
> Then so have I.  I have changed one thing a lot of times over the years,
> run make and it work fine.  Most of the time, it is when emerge spits
> out that a option is needed for a package to work.  Honestly, this is
> the first time I recall hearing this should even be done. 

The first n times I discovered than "make clean" prevents (some) problems
(sometimes) is when I was running the daily unstable kernels directly from
Linus's git repo.

As you would expect, I had to git-bisect a lot of kernel bugs over the years,
and along the way I discovered that doing the exact-same bisect on the exact-
same source code could produce different results -- results that were just
plain wrong sometimes.

That problem disappeared when I started doing "make clean" after every bisect,
painful though it seemed at the time.

I'm now much too old and grouchy to debug unstable kernels every day, though.

Re: [gentoo-user] Re: [~and64] Headsup for google-chrome users

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 1129 bytes --]

On Friday 22 May 2015 13:47:28 walt wrote:
> On 05/21/2015 04:49 PM, Dale wrote:

> > Then so have I.  I have changed one thing a lot of times over the years,
> > run make and it work fine.  Most of the time, it is when emerge spits
> > out that a option is needed for a package to work.  Honestly, this is
> > the first time I recall hearing this should even be done.
> 
> The first n times I discovered than "make clean" prevents (some) problems
> (sometimes) is when I was running the daily unstable kernels directly from
> Linus's git repo.
> 
> As you would expect, I had to git-bisect a lot of kernel bugs over the
> years, and along the way I discovered that doing the exact-same bisect on
> the exact- same source code could produce different results -- results
> that were just plain wrong sometimes.
> 
> That problem disappeared when I started doing "make clean" after every
> bisect, painful though it seemed at the time.
> 
> I'm now much too old and grouchy to debug unstable kernels every day,
> though.

Did you also enable CONFIG_MEMCG & MEMCG_KMEM in your kernel?

-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

[gentoo-user] Re: [~and64] Headsup for google-chrome users

[walt]

On 05/22/2015 06:32 AM, Mick wrote:
> On Friday 22 May 2015 13:47:28 walt wrote:
>> On 05/21/2015 04:49 PM, Dale wrote:
> 
>>> Then so have I.  I have changed one thing a lot of times over the years,
>>> run make and it work fine.  Most of the time, it is when emerge spits
>>> out that a option is needed for a package to work.  Honestly, this is
>>> the first time I recall hearing this should even be done.
>>
>> The first n times I discovered than "make clean" prevents (some) problems
>> (sometimes) is when I was running the daily unstable kernels directly from
>> Linus's git repo.
>>
>> As you would expect, I had to git-bisect a lot of kernel bugs over the
>> years, and along the way I discovered that doing the exact-same bisect on
>> the exact- same source code could produce different results -- results
>> that were just plain wrong sometimes.
>>
>> That problem disappeared when I started doing "make clean" after every
>> bisect, painful though it seemed at the time.
>>
>> I'm now much too old and grouchy to debug unstable kernels every day,
>> though.
> 
> Did you also enable CONFIG_MEMCG & MEMCG_KMEM in your kernel?

When I use the search function in "make menuconfig" I don't see any mention
of MEMCG, so I suspect that particular config item must be enabled by some
other config option that I didn't enable (though I don't remember making
that decision one way or the other).

I'm running gentoo-sources-3.14.42, so you can see I've become almost as
grumpy as Volker in my dotage ;)

Re: [gentoo-user] Re: [~and64] Headsup for google-chrome users

[Tom H]

On Fri, May 22, 2015 at 5:13 PM, walt <w41ter@gmail.com> wrote:
> On 05/22/2015 06:32 AM, Mick wrote:
>>
>> Did you also enable CONFIG_MEMCG & MEMCG_KMEM in your kernel?
>
> When I use the search function in "make menuconfig" I don't see any mention
> of MEMCG, so I suspect that particular config item must be enabled by some
> other config option that I didn't enable (though I don't remember making
> that decision one way or the other).
>
> I'm running gentoo-sources-3.14.42.

You must've mistype your search:

$ grep MEMCG init/Kconfig
config MEMCG
config MEMCG_SWAP
depends on MEMCG && SWAP
config MEMCG_SWAP_ENABLED
depends on MEMCG_SWAP
config MEMCG_KMEM
depends on MEMCG
 recommended that the MEMCG and MEMCG_KMEM options also be

The above was from 4.1.0-rc4 but AFAIK it's existed for 2 or 3 years
so you should have it in 3.14.

[gentoo-user] Re: [~and64] Headsup for google-chrome users

[walt]

On 05/22/2015 02:38 PM, Tom H wrote:
> On Fri, May 22, 2015 at 5:13 PM, walt <w41ter@gmail.com> wrote:
>> On 05/22/2015 06:32 AM, Mick wrote:
>>>
>>> Did you also enable CONFIG_MEMCG & MEMCG_KMEM in your kernel?
>>
>> When I use the search function in "make menuconfig" I don't see any mention
>> of MEMCG, so I suspect that particular config item must be enabled by some
>> other config option that I didn't enable (though I don't remember making
>> that decision one way or the other).
>>
>> I'm running gentoo-sources-3.14.42.
> 
> You must've mistype your search:
> 
> $ grep MEMCG init/Kconfig
> config MEMCG
> config MEMCG_SWAP
> depends on MEMCG && SWAP
> config MEMCG_SWAP_ENABLED
> depends on MEMCG_SWAP
> config MEMCG_KMEM
> depends on MEMCG
>  recommended that the MEMCG and MEMCG_KMEM options also be
> 
> The above was from 4.1.0-rc4 but AFAIK it's existed for 2 or 3 years
> so you should have it in 3.14.

Yes, I agree that MEMCG has been in the kernel source code for years.

I want to emphasize (for any future googlers) that the selection (or
de-selection) of kernel config options can change what you can find
or can't find when configuring kernel options in "make menuconfig".

This is important, and I want to drill this concept home in your
(collective) brains.  Configuring the linux kernel is *not* simple.

The kernel devs have been struggling with this idea for years, and
I am certainly no smarter than they are.

Please, just understand that the kernel config scripts are fallible,
just like the people who write them.

Re: [gentoo-user] Re: [~and64] Headsup for google-chrome users

[Neil Bothwick]

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

On Fri, 22 May 2015 15:19:56 -0700, walt wrote:

> I want to emphasize (for any future googlers) that the selection (or
> de-selection) of kernel config options can change what you can find
> or can't find when configuring kernel options in "make menuconfig".

But it doesn't change what can be found with the menuconfig search
function. That will show options that cannot be enabled, and tell you
which options you need to set before you can enable it.


-- 
Neil Bothwick

A Microsoft joke (is that a tautology?)

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [gentoo-user] Re: [~and64] Headsup for google-chrome users

[Tom H]

On Fri, May 22, 2015 at 6:19 PM, walt <w41ter@gmail.com> wrote:
> On 05/22/2015 02:38 PM, Tom H wrote:
>> On Fri, May 22, 2015 at 5:13 PM, walt <w41ter@gmail.com> wrote:
>>> On 05/22/2015 06:32 AM, Mick wrote:
>>>>
>>>> Did you also enable CONFIG_MEMCG & MEMCG_KMEM in your kernel?
>>>
>>> When I use the search function in "make menuconfig" I don't see any mention
>>> of MEMCG, so I suspect that particular config item must be enabled by some
>>> other config option that I didn't enable (though I don't remember making
>>> that decision one way or the other).
>>>
>>> I'm running gentoo-sources-3.14.42.
>>
>> You must've mistype your search:
>>
>> $ grep MEMCG init/Kconfig
>> config MEMCG
>> config MEMCG_SWAP
>> depends on MEMCG && SWAP
>> config MEMCG_SWAP_ENABLED
>> depends on MEMCG_SWAP
>> config MEMCG_KMEM
>> depends on MEMCG
>>  recommended that the MEMCG and MEMCG_KMEM options also be
>>
>> The above was from 4.1.0-rc4 but AFAIK it's existed for 2 or 3 years
>> so you should have it in 3.14.
>
> Yes, I agree that MEMCG has been in the kernel source code for years.
>
> I want to emphasize (for any future googlers) that the selection (or
> de-selection) of kernel config options can change what you can find
> or can't find when configuring kernel options in "make menuconfig".

But no matter what you've selected, "/MEMCG" within "make menuconfig"
will find configs that contain "MEMCG".

Re: [gentoo-user] Re: [~and64] Headsup for google-chrome users

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 1155 bytes --]

On Friday 22 May 2015 22:38:52 Tom H wrote:
> On Fri, May 22, 2015 at 5:13 PM, walt <w41ter@gmail.com> wrote:
> > On 05/22/2015 06:32 AM, Mick wrote:
> >> Did you also enable CONFIG_MEMCG & MEMCG_KMEM in your kernel?
> > 
> > When I use the search function in "make menuconfig" I don't see any
> > mention of MEMCG, so I suspect that particular config item must be
> > enabled by some other config option that I didn't enable (though I don't
> > remember making that decision one way or the other).
> > 
> > I'm running gentoo-sources-3.14.42.
> 
> You must've mistype your search:
> 
> $ grep MEMCG init/Kconfig
> config MEMCG
> config MEMCG_SWAP
> depends on MEMCG && SWAP
> config MEMCG_SWAP_ENABLED
> depends on MEMCG_SWAP
> config MEMCG_KMEM
> depends on MEMCG
>  recommended that the MEMCG and MEMCG_KMEM options also be
> 
> The above was from 4.1.0-rc4 but AFAIK it's existed for 2 or 3 years
> so you should have it in 3.14.

I'm on gentoo-sources-3.18.12 and the help page on module USER_NS mentioned 
considering enabling MEMCG and MEMCG_KMEM.  I don't know if chromium needs 
these or not.

-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

[gentoo-user] Re: [~and64] Headsup for google-chrome users

[Quanyang Liu]

On Thu, May 21 2015 at 20:55:52 +0800, walt wrote:
> I just wasted some time figuring out this mess:
>
> ......
> 
> So, re-install ati-drivers, reboot, etc, all of which will make you late
> for work, like I am now :p

Hi all, but I just found another problem.

I now use xmonad, and always shift chrome to 7th workspace. And for the
new version chrome, it has no focus after being shifted. I can type in
the start page (if I set it to some website,
i.e. https://www.google.com ), but can't type in the address bar (if
there is no start page). And the title bar is always gray untill I click
the browser.

Does anyone have the same problem? And how can I solve it?

-- 
Thanks,
Quanyang

[gentoo-user] Re: [~and64] Headsup for google-chrome users

[walt]

On 05/22/2015 03:15 AM, Quanyang Liu wrote:
> On Thu, May 21 2015 at 20:55:52 +0800, walt wrote:
>> I just wasted some time figuring out this mess:
>>
>> ......
>>
>> So, re-install ati-drivers, reboot, etc, all of which will make you late
>> for work, like I am now :p
> 
> Hi all, but I just found another problem.
> 
> I now use xmonad, and always shift chrome to 7th workspace. And for the
> new version chrome, it has no focus after being shifted. I can type in
> the start page (if I set it to some website,
> i.e. https://www.google.com ), but can't type in the address bar (if
> there is no start page). And the title bar is always gray until I click
> the browser.
 
I'd suggest posting this question in a new thread because you are describing
a different problem from the one I had.  More people will see your question
that way.

Re: [gentoo-user] [~and64] Headsup for google-chrome users

[Behrouz Khosravi]

On Thursday, May 21, 2015 05:55:52 AM walt wrote:


Thanks. I also saw that message, but after checking the kernel, ignored it!

> I just wasted some time figuring out this mess:
> 
> I just updated google-chrome, which printed this confusing warning message:
> 
> "CONFIG_USED_NS not seen when it should be"
> 
> First, there's a typo:  it should read "CONFIG_USER_NS"
>                                                   ^
> 
> Then, after I figured out that CONFIG_USER_NS is a kernel config item,
> requiring reinstallation of my kernel, I wasted more time figuring out
> (for the n'th time) that you shouldn't just change a single kernel config
> item and do "make" because that shortcut can break important things.
> 
> No, you should do "make clean" first, and then do "make" etc.
> 
> Then, after finishing that mess, you then need to re-install ati-drivers
> (if you use them) because CONFIG_USER_NS breaks the ati-drivers too.
> 
> So, re-install ati-drivers, reboot, etc, all of which will make you late
> for work, like I am now :p