Re: [gentoo-user] Gentoo-sources: can't make menuconfig with user? User can't access ncurses?

Re: [gentoo-user] Gentoo-sources: can't make menuconfig with user? User can't access ncurses?

[Alan McKinnon]

On Mon, 2 Jan 2012 20:58:18 -0200
Claudio Roberto França Pereira <spideybr@gmail.com> wrote:

> I'm not currently at my Gentoo box, sorry for this, but if I don't
> post this now I'll probably forget to post it at all.
> Anyways, last time I tried upgrading my kernel, I copied my .config
> and ran make menuconfig as my main user, but it whined about missing
> ncurses libraries or something. After su'ing, everything went better
> than expected.
> Was that normal behavior? I remember configuring my kernel as user
> before. Even compiling it as user.


How did you install the kernel sources?

If you downloaded them as a normal user you should be able to make
menuconfig; make; sudo make install just fine.

If portage installed the sources, then you should
configure/compile/install as root. The sources are owned by portage
(IIRC) and you can't su to that user, leaving only root. Or, try adding
yourself to the portage group. Personally I think that's too much
effort for zero gain so I always do it as root.


-- 
Alan McKinnnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Gentoo-sources: can't make menuconfig with user? User can't access ncurses?

[Gregory Shearman]

In linux.gentoo.user, you wrote:
> On Mon, 2 Jan 2012 20:58:18 -0200
> Claudio Roberto França Pereira <spideybr@gmail.com> wrote:
>
>> I'm not currently at my Gentoo box, sorry for this, but if I don't
>> post this now I'll probably forget to post it at all.
>> Anyways, last time I tried upgrading my kernel, I copied my .config
>> and ran make menuconfig as my main user, but it whined about missing
>> ncurses libraries or something. After su'ing, everything went better
>> than expected.
>> Was that normal behavior? I remember configuring my kernel as user
>> before. Even compiling it as user.
>
>
> How did you install the kernel sources?
>
> If you downloaded them as a normal user you should be able to make
> menuconfig; make; sudo make install just fine.
>
> If portage installed the sources, then you should
> configure/compile/install as root. The sources are owned by portage
> (IIRC) and you can't su to that user, leaving only root. Or, try adding
> yourself to the portage group. Personally I think that's too much
> effort for zero gain so I always do it as root.

I use a separate output directory that is under control of the user.
What I do as an ordinary user:

mkdir <kerneloutputdir>

zcat /proc/config.gz > <kerneloutputdir>/.config

# assuming you have this option set in your kernel ie the current kernel
# config saved in /proc/config.gz

cd /usr/src/linux 

# assuming that /usr/src/linux is a soft link to your new kernel
# directory.

make O=<kerneloutputdir> oldconfig

# The "O=" makes sure that any kernel output goes to the directory under
# the permissions and control of the kernel builder user rather than in
# the kernel directory under root permissions.

# If you want to make changes to the new kernel then:

make O=<kerneleoutputdir> menuconfig

You can then proceed with building kernel and modules. Yes, I know that
"make" without a command will automatically build both kernel image and
modules but I prefer to do things explicitly.

make O=<kerneleoutputdir> bzImage
make O=<kerneleoutputdir> modules

You can then install the new kernel and modules as root:

make O=<kerneleoutputdir> modules_install
make O=<kerneleoutputdir> install

You need to set the following environment variable:

KBUILD_OUTPUT=<kerneloutputdir>

This variable ensures that any emerged app can find the kernel output if
necessary. I've created a script in /etc/profile.d that automatically
keeps this environment variable up to date. Oh, remember to unset this
variable if you do *anything* requiring a busybox build (eg genkernel).

An enjoyable side-effect of this system is that when you remove an
obselete kernel from your system using "emerge -C <oldkernelversion>",
everything will be removed because there are no changes, no files added
to those portage added kernel directory.

The kernel builder user does nothing but build new kernels. This user's
home directory is a hierarchy containing current kernel builds.

I've been using this system for years now, on all my gentoo systems. It
is second nature. Of course, the .bash_history of the kernel builder
user is *very* useful for quickly doing all this from the command line.

I used to have a script to automate all this, but it is just as easy to
do from the command line.

-- 
Regards,
Gregory.

Re: [gentoo-user] Gentoo-sources: can't make menuconfig with user? User can't access ncurses?

[Mick]

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

On Tuesday 03 Jan 2012 01:13:17 Gregory Shearman wrote:
> In linux.gentoo.user, you wrote:
> > On Mon, 2 Jan 2012 20:58:18 -0200
> > 
> > Claudio Roberto França Pereira <spideybr@gmail.com> wrote:
> >> I'm not currently at my Gentoo box, sorry for this, but if I don't
> >> post this now I'll probably forget to post it at all.
> >> Anyways, last time I tried upgrading my kernel, I copied my .config
> >> and ran make menuconfig as my main user, but it whined about missing
> >> ncurses libraries or something. After su'ing, everything went better
> >> than expected.
> >> Was that normal behavior? I remember configuring my kernel as user
> >> before. Even compiling it as user.
> > 
> > How did you install the kernel sources?
> > 
> > If you downloaded them as a normal user you should be able to make
> > menuconfig; make; sudo make install just fine.
> > 
> > If portage installed the sources, then you should
> > configure/compile/install as root. The sources are owned by portage
> > (IIRC) and you can't su to that user, leaving only root. Or, try adding
> > yourself to the portage group. Personally I think that's too much
> > effort for zero gain so I always do it as root.
> 
> I use a separate output directory that is under control of the user.
> What I do as an ordinary user:
> 
> mkdir <kerneloutputdir>
> 
> zcat /proc/config.gz > <kerneloutputdir>/.config
> 
> # assuming you have this option set in your kernel ie the current kernel
> # config saved in /proc/config.gz
> 
> cd /usr/src/linux
> 
> # assuming that /usr/src/linux is a soft link to your new kernel
> # directory.
> 
> make O=<kerneloutputdir> oldconfig
> 
> # The "O=" makes sure that any kernel output goes to the directory under
> # the permissions and control of the kernel builder user rather than in
> # the kernel directory under root permissions.
> 
> # If you want to make changes to the new kernel then:
> 
> make O=<kerneleoutputdir> menuconfig
> 
> You can then proceed with building kernel and modules. Yes, I know that
> "make" without a command will automatically build both kernel image and
> modules but I prefer to do things explicitly.
> 
> make O=<kerneleoutputdir> bzImage
> make O=<kerneleoutputdir> modules
> 
> You can then install the new kernel and modules as root:
> 
> make O=<kerneleoutputdir> modules_install
> make O=<kerneleoutputdir> install
> 
> You need to set the following environment variable:
> 
> KBUILD_OUTPUT=<kerneloutputdir>
> 
> This variable ensures that any emerged app can find the kernel output if
> necessary. I've created a script in /etc/profile.d that automatically
> keeps this environment variable up to date. Oh, remember to unset this
> variable if you do *anything* requiring a busybox build (eg genkernel).
> 
> An enjoyable side-effect of this system is that when you remove an
> obselete kernel from your system using "emerge -C <oldkernelversion>",
> everything will be removed because there are no changes, no files added
> to those portage added kernel directory.
> 
> The kernel builder user does nothing but build new kernels. This user's
> home directory is a hierarchy containing current kernel builds.
> 
> I've been using this system for years now, on all my gentoo systems. It
> is second nature. Of course, the .bash_history of the kernel builder
> user is *very* useful for quickly doing all this from the command line.
> 
> I used to have a script to automate all this, but it is just as easy to
> do from the command line.

What is the benefit of this approach vis a vis su to root first as the gentoo 
handbook suggests?
-- 
Regards,
Mick

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

Re: [gentoo-user] Gentoo-sources: can't make menuconfig with user? User can't access ncurses?

[Gregory Shearman]

In linux.gentoo.user, Mick wrote:
>>
>> I use a separate output directory that is under control of the user.
>> What I do as an ordinary user:
>>
>> mkdir <kerneloutputdir>
>>
>> zcat /proc/config.gz > <kerneloutputdir>/.config
>>
>> # assuming you have this option set in your kernel ie the current
>> kernel # config saved in /proc/config.gz
>>
>> cd /usr/src/linux
>>
>> # assuming that /usr/src/linux is a soft link to your new kernel #
>> directory.
>>
>> make O=<kerneloutputdir> oldconfig
>>
>> # The "O=" makes sure that any kernel output goes to the directory
>> under # the permissions and control of the kernel builder user rather
>> than in # the kernel directory under root permissions.
>>
>> # If you want to make changes to the new kernel then:
>>
>> make O=<kerneleoutputdir> menuconfig
>>
>> You can then proceed with building kernel and modules. Yes, I know
>> that "make" without a command will automatically build both kernel
>> image and modules but I prefer to do things explicitly.
>>
>> make O=<kerneleoutputdir> bzImage make O=<kerneleoutputdir> modules
>>
>> You can then install the new kernel and modules as root:
>>
>> make O=<kerneleoutputdir> modules_install make O=<kerneleoutputdir>
>> install
>>
>> You need to set the following environment variable:
>>
>> KBUILD_OUTPUT=<kerneloutputdir>
>>
>> This variable ensures that any emerged app can find the kernel output
>> if necessary. I've created a script in /etc/profile.d that
>> automatically keeps this environment variable up to date. Oh,
>> remember to unset this variable if you do *anything* requiring a
>> busybox build (eg genkernel).
>>
>> An enjoyable side-effect of this system is that when you remove an
>> obselete kernel from your system using "emerge -C
>> <oldkernelversion>", everything will be removed because there are no
>> changes, no files added to those portage added kernel directory.
>>
>> The kernel builder user does nothing but build new kernels. This
>> user's home directory is a hierarchy containing current kernel
>> builds.
>>
>> I've been using this system for years now, on all my gentoo systems.
>> It is second nature. Of course, the .bash_history of the kernel
>> builder user is *very* useful for quickly doing all this from the
>> command line.
>>
>> I used to have a script to automate all this, but it is just as easy
>> to do from the command line.
>
> What is the benefit of this approach vis a vis su to root first as the
> gentoo handbook suggests?

You've answered your own question. I'm of the opinion that it is far
better to do the absolute *minimum* commands as the superuser, for your
own system security. My way of compiling a new kernel means that only
the "install" commands are done as superuser.

-- 
Regards,
Gregory.