Re: [gentoo-user] Strange hickups while trying to compile a kernel in a chroot

[Rich Freeman]

On Sat, Feb 25, 2017 at 9:26 AM,   wrote:
>
> yes the option was set for what reason ever...I will clear that.
> Next question...: Do I need v86d still then?

Probably not, but I have no idea why you even had it in the first place.

>
> Another thing which drives me crazy:
> Linux-headers!
> emerge insists of installing linux-headers-4.10. I am runnig
> 4.9.12. Unstable is globally set (~amd64).

In general I don't think matching the exact kernel version is
important, though perhaps v86d cares if you need that.

>
> But giviing
>
> emerge sys-kernel/linux-headers-4.9
> or
> emerge 'sys-kernel/linux-headers-4.9'
>
> gives me
>
> !!! 'sys-kernel/linux-headers-4.9' is not a valid package atom.
> !!! Please check ebuild(5) for full details.
>
> Even
>
> emerge sys-kernel/linux-headers-4.10
> or
> emerge 'sys-kernel/linux-headers-4.10'
>
> results in
>
> !!! 'sys-kernel/linux-headers-4.10' is not a valid package atom.
> !!! Please check ebuild(5) for full details.
>

The syntax would be emerge '=sys-kernel/linux-headers-4.9'

The = is critical, since that makes it an atom.  Depending on your
shell you might or might not need quotes.

Again, I'm not sure you really need to worry about it.

-- 
Rich

Re: [gentoo-user] Strange hickups while trying to compile a kernel in a chroot

[Meino . Cramer]

Neil Bothwick  [17-02-25 15:24]:
> On Sat, 25 Feb 2017 13:23:11 +0100, meino.cra...@gmx.de wrote:
> 
> > make bImage fails with
> > 
> > (chroot) make bzImage
> >   CHK include/config/kernel.release
> >   CHK include/generated/uapi/linux/version.h
> >   CHK include/generated/utsrelease.h
> >   CHK include/generated/bounds.h
> >   CHK include/generated/timeconst.h
> >   CHK include/generated/asm-offsets.h
> >   CALLscripts/checksyscalls.sh
> >   CHK include/generated/compile.h
> >   ./scripts/gen_initramfs_list.sh: Cannot open
> > '/usr/share/v86d/initramfs' make[1]: *** [usr/Makefile:73:
> > usr/initramfs_data.cpio.gz] Error 1 make: *** [Makefile:988: usr] Error
> > 2
> > 
> > 
> > I look for the magic v83d and found (being at my old root)
> > 
> > [I] sys-apps/v86d
> >  Available versions:  0.1.10 {debug x86emu}
> >  Installed versions:  0.1.10(02:34:27 02/28/11)(x86emu -debug)
> >  Homepage:
> > https://dev.gentoo.org/~spock/projects/uvesafb/ Description: A
> > daemon to run x86 code in an emulated environment
> > 
> > Is this "quite normal" or does the make process of the kernel make
> > false conclusion while being chrooted?
> > 
> > Do I really need initram? ... For years I though my grub had
> > booted the kernel which runs my linux directlu...
> 
> Since kernel 2.6 (I think) the kernel has always had an initramfs built
> in, this is separate from the standalone initramfs files built by the
> likes of dracut. It is empty by default but it is there, so it is not
> surprising to see build output relating to the intiramfs even if you do
> not use one.
> 
> Are you cross-compiling here? That's the obvious reason for requiring
> v86d. If not, there is no need to chroot to build a kernel, just cd to
> its directory, although chrooting is needed to run make
> {,modules_}install.
> 
> 
> -- 
> Neil Bothwick
> 
> USENET: Uniting Spammers, Erotomaniacs, Newbies, Extroverts and Trolls

Hi Neil,

no, no crosscompiling at this point and for this purpose. I am
building the new root on the same machine as the old one is running.

I simply want to check out, whether essential things work before
finally booting into the new root (to prevent an """endless"""
back-and-forth-booting-experience).

Cheers
Meino

Re: [gentoo-user] Strange hickups while trying to compile a kernel in a chroot

[Meino . Cramer]

Rich Freeman  [17-02-25 15:16]:
> On Sat, Feb 25, 2017 at 8:59 AM,   wrote:
> > Fernando Rodriguez  [17-02-25 14:36]:
> >>
> >> Check the CONFIG_INITRAMFS_SOURCE option.
> >>
> >
> > I will check the configs...may be there is something not readable
> > (permissions) ... I had copied a lot back and forth (I bought one
> > of those crappy harddiscs, which became full after a while...;)
> >
> 
> Did you actually check the CONFIG_INITRAMFS_SOURCE option?  It should
> be blank.  If it is not, then whatever file it points to must exist.
> It might exist on your host, but not in your chroot.
> 
> This option builds a kernel with an embedded initramfs, which is not
> normally something you need.  Some Linux live DVDs might use something
> like this, but normal desktops generally do not.  If your .config file
> originated from one of these that could explain the issue.
> 
> Even if you wanted an initramfs this isn't the way to go about it.
> 
> (A bit of trivia, Linux actually ALWAYS has an embedded initramfs, but
> by default it is empty.)
> 
> -- 
> Rich
> 
Hi Rich,

yes the option was set for what reason ever...I will clear that.
Next question...: Do I need v86d still then?

Another thing which drives me crazy:
Linux-headers!
emerge insists of installing linux-headers-4.10. I am runnig
4.9.12. Unstable is globally set (~amd64).

But giviing 

emerge sys-kernel/linux-headers-4.9
or
emerge 'sys-kernel/linux-headers-4.9'

gives me

!!! 'sys-kernel/linux-headers-4.9' is not a valid package atom.
!!! Please check ebuild(5) for full details.

Even

emerge sys-kernel/linux-headers-4.10
or
emerge 'sys-kernel/linux-headers-4.10'

results in

!!! 'sys-kernel/linux-headers-4.10' is not a valid package atom.
!!! Please check ebuild(5) for full details.

. I only can do

emerge sys-kernel/linux-headers

but (as mentioned above) it installs 4.10. not 4.9.
v86d does not compile with 4.10.

ebuild (5) suggests to do, what I have done/written above.

Doing a complete rebuild of the root of years of running
gentoo is a hrm. intersting...hrmmmexperience...
;)

Cheers
Meino

Re: [gentoo-user] Strange hickups while trying to compile a kernel in a chroot

[Neil Bothwick]

On Sat, 25 Feb 2017 13:23:11 +0100, meino.cra...@gmx.de wrote:

> make bImage fails with
> 
> (chroot) make bzImage
>   CHK include/config/kernel.release
>   CHK include/generated/uapi/linux/version.h
>   CHK include/generated/utsrelease.h
>   CHK include/generated/bounds.h
>   CHK include/generated/timeconst.h
>   CHK include/generated/asm-offsets.h
>   CALLscripts/checksyscalls.sh
>   CHK include/generated/compile.h
>   ./scripts/gen_initramfs_list.sh: Cannot open
> '/usr/share/v86d/initramfs' make[1]: *** [usr/Makefile:73:
> usr/initramfs_data.cpio.gz] Error 1 make: *** [Makefile:988: usr] Error
> 2
> 
> 
> I look for the magic v83d and found (being at my old root)
> 
> [I] sys-apps/v86d
>  Available versions:  0.1.10 {debug x86emu}
>  Installed versions:  0.1.10(02:34:27 02/28/11)(x86emu -debug)
>  Homepage:
> https://dev.gentoo.org/~spock/projects/uvesafb/ Description: A
> daemon to run x86 code in an emulated environment
> 
> Is this "quite normal" or does the make process of the kernel make
> false conclusion while being chrooted?
> 
> Do I really need initram? ... For years I though my grub had
> booted the kernel which runs my linux directlu...

Since kernel 2.6 (I think) the kernel has always had an initramfs built
in, this is separate from the standalone initramfs files built by the
likes of dracut. It is empty by default but it is there, so it is not
surprising to see build output relating to the intiramfs even if you do
not use one.

Are you cross-compiling here? That's the obvious reason for requiring
v86d. If not, there is no need to chroot to build a kernel, just cd to
its directory, although chrooting is needed to run make
{,modules_}install.


-- 
Neil Bothwick

USENET: Uniting Spammers, Erotomaniacs, Newbies, Extroverts and Trolls


pgpQqHXLbzhrA.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] Strange hickups while trying to compile a kernel in a chroot

[Rich Freeman]

On Sat, Feb 25, 2017 at 8:59 AM,   wrote:
> Fernando Rodriguez  [17-02-25 14:36]:
>>
>> Check the CONFIG_INITRAMFS_SOURCE option.
>>
>
> I will check the configs...may be there is something not readable
> (permissions) ... I had copied a lot back and forth (I bought one
> of those crappy harddiscs, which became full after a while...;)
>

Did you actually check the CONFIG_INITRAMFS_SOURCE option?  It should
be blank.  If it is not, then whatever file it points to must exist.
It might exist on your host, but not in your chroot.

This option builds a kernel with an embedded initramfs, which is not
normally something you need.  Some Linux live DVDs might use something
like this, but normal desktops generally do not.  If your .config file
originated from one of these that could explain the issue.

Even if you wanted an initramfs this isn't the way to go about it.

(A bit of trivia, Linux actually ALWAYS has an embedded initramfs, but
by default it is empty.)

-- 
Rich

Re: [gentoo-user] Strange hickups while trying to compile a kernel in a chroot

[Meino . Cramer]

Fernando Rodriguez  [17-02-25 14:36]:
> On 02/25/2017 07:23 AM, meino.cra...@gmx.de wrote:
> > hi,
> > 
> > I am trying to build a linux kernel (vanilla from ftp.kernel.org)
> > in my chrooted new root.
> > 
> > make modules install
> > 
> > failed
> > 
> > with:
> > 
> >   CHK include/config/kernel.release
> >   CHK include/generated/uapi/linux/version.h
> >   CHK include/generated/utsrelease.h
> >   CHK include/generated/bounds.h
> >   CHK include/generated/timeconst.h
> >   CHK include/generated/asm-offsets.h
> >   CALLscripts/checksyscalls.sh
> >   CHK include/generated/compile.h
> >   ./scripts/gen_initramfs_list.sh: Cannot open '/usr/share/v86d/initramfs'
> > make[1]: *** [usr/Makefile:73: usr/initramfs_data.cpio.gz] Error 1
> > make: *** [Makefile:988: usr] Error 2
> > 
> > 
> > make bImage fails with
> > 
> > (chroot) make bzImage
> >   CHK include/config/kernel.release
> >   CHK include/generated/uapi/linux/version.h
> >   CHK include/generated/utsrelease.h
> >   CHK include/generated/bounds.h
> >   CHK include/generated/timeconst.h
> >   CHK include/generated/asm-offsets.h
> >   CALLscripts/checksyscalls.sh
> >   CHK include/generated/compile.h
> >   ./scripts/gen_initramfs_list.sh: Cannot open '/usr/share/v86d/initramfs'
> > make[1]: *** [usr/Makefile:73: usr/initramfs_data.cpio.gz] Error 1
> > make: *** [Makefile:988: usr] Error 2
> > 
> > 
> > I look for the magic v83d and found (being at my old root)
> > 
> > [I] sys-apps/v86d
> >  Available versions:  0.1.10 {debug x86emu}
> >  Installed versions:  0.1.10(02:34:27 02/28/11)(x86emu -debug)
> >  Homepage:https://dev.gentoo.org/~spock/projects/uvesafb/
> >  Description: A daemon to run x86 code in an emulated 
> > environment
> > 
> > Is this "quite normal" or does the make process of the kernel make
> > false conclusion while being chrooted?
> > 
> > Do I really need initram? ... For years I though my grub had
> > booted the kernel which runs my linux directlu...
> > 
> > My commandline to build the kernel at my old root was:
> > 
> >  kernel=/boot/vmlinuz-4091200-64-RT && make -j7 all && make -j7 
> > modules_install && /bin/cp -f ./arch/x86_64/boot/bzImage* $kernel; emerge 
> > nvidia-drivers ;emerge app-emulation/virtualbox-modules ;grub-mkconfig -o 
> > /boot/grub/grub.cfg
> > 
> > whjch had.
> > 
> > v86d is not installed yet and of course I will install it if needed.
> > But I want to get shure, that the chrooted environment has not
> > confused the kernel build process...
> > 
> > Thanks for any help in advance!
> > Cheers
> > Meino
> 
> Check the CONFIG_INITRAMFS_SOURCE option.
> 
> How did you configure the kernel? Did you used the .config file from
> your root system or perhaps ran make oldconfig (I think it tries to use
> /proc/config.gz if it can't find it in /boot)?
> 
> 
> 
> -- 
> 
> Fernando Rodriguez
> 

Hi Fernando,

I used the config I used for building the kernel of the 'old' root.
The new root is intended to replace the old root on the same machine.
Its even the same kernel source...
So everything should fine.
Even if it will use /proc/config.gz it will find the config of
the current kernel running the old root (and that way the chrooted
rooot).

scratching my head...

I will check the configs...may be there is something not readable
(permissions) ... I had copied a lot back and forth (I bought one
of those crappy harddiscs, which became full after a while...;)

Cheers
Meino

Re: [gentoo-user] Strange hickups while trying to compile a kernel in a chroot

[Fernando Rodriguez]

On 02/25/2017 07:23 AM, meino.cra...@gmx.de wrote:
> hi,
> 
> I am trying to build a linux kernel (vanilla from ftp.kernel.org)
> in my chrooted new root.
> 
> make modules install
> 
> failed
> 
> with:
> 
>   CHK include/config/kernel.release
>   CHK include/generated/uapi/linux/version.h
>   CHK include/generated/utsrelease.h
>   CHK include/generated/bounds.h
>   CHK include/generated/timeconst.h
>   CHK include/generated/asm-offsets.h
>   CALLscripts/checksyscalls.sh
>   CHK include/generated/compile.h
>   ./scripts/gen_initramfs_list.sh: Cannot open '/usr/share/v86d/initramfs'
> make[1]: *** [usr/Makefile:73: usr/initramfs_data.cpio.gz] Error 1
> make: *** [Makefile:988: usr] Error 2
> 
> 
> make bImage fails with
> 
> (chroot) make bzImage
>   CHK include/config/kernel.release
>   CHK include/generated/uapi/linux/version.h
>   CHK include/generated/utsrelease.h
>   CHK include/generated/bounds.h
>   CHK include/generated/timeconst.h
>   CHK include/generated/asm-offsets.h
>   CALLscripts/checksyscalls.sh
>   CHK include/generated/compile.h
>   ./scripts/gen_initramfs_list.sh: Cannot open '/usr/share/v86d/initramfs'
> make[1]: *** [usr/Makefile:73: usr/initramfs_data.cpio.gz] Error 1
> make: *** [Makefile:988: usr] Error 2
> 
> 
> I look for the magic v83d and found (being at my old root)
> 
> [I] sys-apps/v86d
>  Available versions:  0.1.10 {debug x86emu}
>  Installed versions:  0.1.10(02:34:27 02/28/11)(x86emu -debug)
>  Homepage:https://dev.gentoo.org/~spock/projects/uvesafb/
>  Description: A daemon to run x86 code in an emulated environment
> 
> Is this "quite normal" or does the make process of the kernel make
> false conclusion while being chrooted?
> 
> Do I really need initram? ... For years I though my grub had
> booted the kernel which runs my linux directlu...
> 
> My commandline to build the kernel at my old root was:
> 
>  kernel=/boot/vmlinuz-4091200-64-RT && make -j7 all && make -j7 
> modules_install && /bin/cp -f ./arch/x86_64/boot/bzImage* $kernel; emerge 
> nvidia-drivers ;emerge app-emulation/virtualbox-modules ;grub-mkconfig -o 
> /boot/grub/grub.cfg
> 
> whjch had.
> 
> v86d is not installed yet and of course I will install it if needed.
> But I want to get shure, that the chrooted environment has not
> confused the kernel build process...
> 
> Thanks for any help in advance!
> Cheers
> Meino

Check the CONFIG_INITRAMFS_SOURCE option.

How did you configure the kernel? Did you used the .config file from
your root system or perhaps ran make oldconfig (I think it tries to use
/proc/config.gz if it can't find it in /boot)?



-- 

Fernando Rodriguez

[gentoo-user] Strange hickups while trying to compile a kernel in a chroot

[Meino . Cramer]

hi,

I am trying to build a linux kernel (vanilla from ftp.kernel.org)
in my chrooted new root.

make modules install

failed

with:

  CHK include/config/kernel.release
  CHK include/generated/uapi/linux/version.h
  CHK include/generated/utsrelease.h
  CHK include/generated/bounds.h
  CHK include/generated/timeconst.h
  CHK include/generated/asm-offsets.h
  CALLscripts/checksyscalls.sh
  CHK include/generated/compile.h
  ./scripts/gen_initramfs_list.sh: Cannot open '/usr/share/v86d/initramfs'
make[1]: *** [usr/Makefile:73: usr/initramfs_data.cpio.gz] Error 1
make: *** [Makefile:988: usr] Error 2


make bImage fails with

(chroot) make bzImage
  CHK include/config/kernel.release
  CHK include/generated/uapi/linux/version.h
  CHK include/generated/utsrelease.h
  CHK include/generated/bounds.h
  CHK include/generated/timeconst.h
  CHK include/generated/asm-offsets.h
  CALLscripts/checksyscalls.sh
  CHK include/generated/compile.h
  ./scripts/gen_initramfs_list.sh: Cannot open '/usr/share/v86d/initramfs'
make[1]: *** [usr/Makefile:73: usr/initramfs_data.cpio.gz] Error 1
make: *** [Makefile:988: usr] Error 2


I look for the magic v83d and found (being at my old root)

[I] sys-apps/v86d
 Available versions:  0.1.10 {debug x86emu}
 Installed versions:  0.1.10(02:34:27 02/28/11)(x86emu -debug)
 Homepage:https://dev.gentoo.org/~spock/projects/uvesafb/
 Description: A daemon to run x86 code in an emulated environment

Is this "quite normal" or does the make process of the kernel make
false conclusion while being chrooted?

Do I really need initram? ... For years I though my grub had
booted the kernel which runs my linux directlu...

My commandline to build the kernel at my old root was:

 kernel=/boot/vmlinuz-4091200-64-RT && make -j7 all && make -j7 modules_install 
&& /bin/cp -f ./arch/x86_64/boot/bzImage* $kernel; emerge nvidia-drivers 
;emerge app-emulation/virtualbox-modules ;grub-mkconfig -o /boot/grub/grub.cfg

whjch had.

v86d is not installed yet and of course I will install it if needed.
But I want to get shure, that the chrooted environment has not
confused the kernel build process...

Thanks for any help in advance!
Cheers
Meino