Help with Outreachy Setup

Help with Outreachy Setup

[Rebecca Mckeever]

I am going through the Outreachy setup instructions (https://kernelnewbies.org/OutreachyfirstpatchSetup), and I am stuck at 'Installing the kernel'. My computer is an HP laptop with Intel Core i5-8250U and I'm using Ubuntu.

When I run

    sudo make modules_install install

I receive the following error message:

arch/x86/Makefile:154: CONFIG_X86_X32 enabled but no binutils support
make[2]: *** No rule to make target '/lib/modules/5.17.0-rc8-outreachy+/kernel/arch/x86/crypto/aesni-intel.ko', needed by '__modinst'.  Stop.
make[1]: *** [Makefile:1757: modules_install] Error 2
make: *** [Makefile:350: __build_one_by_one] Error 2

I already have binutils installed:

sudo apt install binutils

Reading package lists... Done
Building dependency tree
Reading state information... Done
binutils is already the newest version (2.34-6ubuntu1.3).

I searched online and couldn't find anything helpful. I tried setting CONFIG_X86_X32 to n in .config and that didn't help. Anyone have suggestions about what else I can do?

Re: Help with Outreachy Setup

[Rebecca Mckeever]

I was able to get it working on a different computer. It still shows the "CONFIG_X86_X32 enabled but no binutils support" message, but there was no error message and I was able to boot into it, so hopefully it's not a problem.

------- Original Message -------

On Saturday, March 26th, 2022 at 21:54, Rebecca Mckeever <rebecca.mckeever@protonmail.com> wrote:

> I am going through the Outreachy setup instructions (https://kernelnewbies.org/OutreachyfirstpatchSetup), and I am stuck at 'Installing the kernel'. My computer is an HP laptop with Intel Core i5-8250U and I'm using Ubuntu.
>
> When I run
>
> sudo make modules_install install
>
> I receive the following error message:
>
> arch/x86/Makefile:154: CONFIG_X86_X32 enabled but no binutils support
>
> make[2]: *** No rule to make target '/lib/modules/5.17.0-rc8-outreachy+/kernel/arch/x86/crypto/aesni-intel.ko', needed by '__modinst'. Stop.
>
> make[1]: *** [Makefile:1757: modules_install] Error 2
>
> make: *** [Makefile:350: __build_one_by_one] Error 2
>
> I already have binutils installed:
>
> sudo apt install binutils
>
> Reading package lists... Done
>
> Building dependency tree
>
> Reading state information... Done
>
> binutils is already the newest version (2.34-6ubuntu1.3).
>
> I searched online and couldn't find anything helpful. I tried setting CONFIG_X86_X32 to n in .config and that didn't help. Anyone have suggestions about what else I can do?

Re: Help with Outreachy Setup

[Stefano Brivio]

Hi Rebecca,

First off, welcome to Outreachy and I'm glad you were able to build the
kernel and boot it! About the issues you hit.

On Sun, 27 Mar 2022 04:58:01 +0000
Rebecca Mckeever <rebecca.mckeever@protonmail.com> wrote:

> I was able to get it working on a different computer. It still shows
> the "CONFIG_X86_X32 enabled but no binutils support" message, but
> there was no error message and I was able to boot into it, so
> hopefully it's not a problem.

CONFIG_X86_X32 enables, I quote from the Kconfig help: "x32 native
32-bit ABI for 64-bit processors" -- which is a memory-saving feature
not commonly enabled.

On 64-bit processors (such as, probably, yours), pointers (that is,
references to data, or functions) use 64 bits. That's convenient, among
other reasons, because 4 GiB of memory nowadays isn't that much and,
using fewer bits, some (further) translation of memory addresses is
needed to address what programs and kernel might want to refer to.

It takes a bit more space, in both programs and kernel. So the kernel
offers, as a rather extreme measure of memory optimisation, the
possibility to keep the storage of pointers to 32 bits. That would be
used mostly by embedded systems, I guess.

To build the kernel with that option, you don't just need binutils, you
would also need binutils with this specific support, which is not
commonly available in distribution. I bet "elf32-86-64" is missing in
the list of supported "targets" when you issue:
	objcopy --help

Anyway, yes, it's just a warning. You can get rid of the warning by
disabling the CONFIG_X86_X32 in your kernel configuration. Maybe you
could make sure you disabled it with the correct syntax with this, from
your kernel tree:
	scripts/config -d CONFIG_X86_X32

...it can still be that it's selected by another option, so it would be
re-enabled automatically. Search for it from 'make menuconfig', typing
'/' (slash) and searching for X86_X32. Then you will see if that's the
case.

The actual build error you got on the other machine is probably a
dependency issue between options, which happens with your particular
configuration, but it really shouldn't happen no matter how your
configuration looks like.

The relevant configuration options are CONFIG_CRYPTO_AES_NI_INTEL and
CONFIG_64BIT -- you could start having a look at the state of those two.

I hope this helps,

-- 
Stefano

Re: Help with Outreachy Setup

[Rebecca Mckeever]

Hi Stefano,

------- Original Message -------

On Sunday, March 27th, 2022 at 03:54, Stefano Brivio <sbrivio@redhat.com> wrote:

> Hi Rebecca,
>
> First off, welcome to Outreachy and I'm glad you were able to build the
>
> kernel and boot it! About the issues you hit.
>
> On Sun, 27 Mar 2022 04:58:01 +0000
>
> Rebecca Mckeever rebecca.mckeever@protonmail.com wrote:
>
> > I was able to get it working on a different computer. It still shows
> >
> > the "CONFIG_X86_X32 enabled but no binutils support" message, but
> >
> > there was no error message and I was able to boot into it, so
> >
> > hopefully it's not a problem.
>
> CONFIG_X86_X32 enables, I quote from the Kconfig help: "x32 native
>
> 32-bit ABI for 64-bit processors" -- which is a memory-saving feature
>
> not commonly enabled.
>
> On 64-bit processors (such as, probably, yours), pointers (that is,
>
> references to data, or functions) use 64 bits. That's convenient, among
>
> other reasons, because 4 GiB of memory nowadays isn't that much and,
>
> using fewer bits, some (further) translation of memory addresses is
>
> needed to address what programs and kernel might want to refer to.
>
> It takes a bit more space, in both programs and kernel. So the kernel
>
> offers, as a rather extreme measure of memory optimisation, the
>
> possibility to keep the storage of pointers to 32 bits. That would be
>
> used mostly by embedded systems, I guess.
>
> To build the kernel with that option, you don't just need binutils, you
>
> would also need binutils with this specific support, which is not
>
> commonly available in distribution. I bet "elf32-86-64" is missing in
>
> the list of supported "targets" when you issue:
>
> objcopy --help

Yes, "elf32-86-64" was missing from the list of targets. But the list did include "elf32-x86-64". Do you know what the difference between them is?

>
> Anyway, yes, it's just a warning. You can get rid of the warning by
>
> disabling the CONFIG_X86_X32 in your kernel configuration. Maybe you
>
> could make sure you disabled it with the correct syntax with this, from
>
> your kernel tree:
>
> scripts/config -d CONFIG_X86_X32
>
> ...it can still be that it's selected by another option, so it would be
>
> re-enabled automatically. Search for it from 'make menuconfig', typing
>
> '/' (slash) and searching for X86_X32. Then you will see if that's the
>
> case.

This worked for me. I was able to recompile without seeing the warning.

>
> The actual build error you got on the other machine is probably a
>
> dependency issue between options, which happens with your particular
>
> configuration, but it really shouldn't happen no matter how your
>
> configuration looks like.
>
> The relevant configuration options are CONFIG_CRYPTO_AES_NI_INTEL and
>
> CONFIG_64BIT -- you could start having a look at the state of those two.
>

CONFIG_CRYPTO_AES_NI_INTEL was set to m. I tried changing it to n and then y, and neither removed the error. Changing CONFIG_64BIT didn't remove the error either. I think I may have made a mistake early in the process and would need to start over to get it working. I will stick with compiling on the other machine for now; I actually prefer it that way.

> I hope this helps,
>
> --
>
> Stefano

Thanks for you help Stefano!

Rebecca

Re: Help with Outreachy Setup

[Stefano Brivio]

On Mon, 28 Mar 2022 23:15:58 +0000
Rebecca Mckeever <rebecca.mckeever@protonmail.com> wrote:

> Hi Stefano,
> 
> ------- Original Message -------
> 
> On Sunday, March 27th, 2022 at 03:54, Stefano Brivio <sbrivio@redhat.com> wrote:
>
> [...]
>
> > To build the kernel with that option, you don't just need binutils, you
> > would also need binutils with this specific support, which is not
> > commonly available in distribution. I bet "elf32-86-64" is missing in
> > the list of supported "targets" when you issue:
> >
> > objcopy --help  
> 
> Yes, "elf32-86-64" was missing from the list of targets. But the list did include "elf32-x86-64". Do you know what the difference between them is?

That was just my typo :( So objcopy supports it. The other component
that needs to support that is ld (the dynamic linker), you could check:

	$ ld --help|grep elf32_x86_64

but I think it's very unlikely that objcopy has that and ld doesn't, so
there must be some other issue. If you're interested, you could try to
add some debugging to that Makefile, it's arch/x86/Makefile.

> > Anyway, yes, it's just a warning. You can get rid of the warning by
> > disabling the CONFIG_X86_X32 in your kernel configuration. Maybe you
> > could make sure you disabled it with the correct syntax with this, from
> > your kernel tree:
> >
> > scripts/config -d CONFIG_X86_X32
> >
> > ...it can still be that it's selected by another option, so it would be
> > re-enabled automatically. Search for it from 'make menuconfig', typing
> > '/' (slash) and searching for X86_X32. Then you will see if that's the
> > case.  
> 
> This worked for me. I was able to recompile without seeing the warning.

Okay, nice!

> > The actual build error you got on the other machine is probably a
> > dependency issue between options, which happens with your particular
> > configuration, but it really shouldn't happen no matter how your
> > configuration looks like.
> >
> > The relevant configuration options are CONFIG_CRYPTO_AES_NI_INTEL and
> > CONFIG_64BIT -- you could start having a look at the state of those two.
> 
> CONFIG_CRYPTO_AES_NI_INTEL was set to m. I tried changing it to n and
> then y, and neither removed the error. Changing CONFIG_64BIT didn't
> remove the error either. I think I may have made a mistake early in the
> process and would need to start over to get it working. I will stick
> with compiling on the other machine for now; I actually prefer it that
> way.

Good, let's try to debug that only if it comes up again.

> Thanks for you help Stefano!

You're welcome!

-- 
Stefano