Discussion:
Need help in configuring kernel
(too old to reply)
root
2019-07-14 18:20:31 UTC
Permalink
Nearly all machines on my LAN use an Intel Core I7 but
some machines are ten years old. When I build a new
kernel I have always copied over the old .config
file, then run make oldconfig before starting the
build. I default on all the questions by just holding
the enter key down until the options are finished.

I thought this method worked until I found that some
kernels built this way do not boot on older machines.
In particulare using the .config file from linux-4.9.70
does not work building linux-4.14.18 when the
all questions are defaulted. The resulting kernel
just hangs during boot, but there is no panic.

That same kernel boots with no problem on newer
machines.

Similarly, starting with the 4.9.70 .config and
building linux-4.15.2 creates a kernel that hangs
during boot.

Out of curiosity I tried some later kernels and
they would not accept my version of gcc which is
from Slack64-14.2

This isn't a critical problem because I can just run
the older machines with an older kernel, but I would
like a suggestion of how to overcome the problem
should a newer kernel be essential. I simply
don't have the patience (or skill) to separately
decide on each option.

Thanks for any suggestions.
Jim Diamond
2019-07-14 19:44:51 UTC
Permalink
Post by root
Nearly all machines on my LAN use an Intel Core I7 but
some machines are ten years old.
Same here.
Post by root
When I build a new kernel I have always copied over the old .config
file, then run make oldconfig before starting the build. I default
on all the questions by just holding the enter key down until the
options are finished.
Hmmm... In principle, one would like that to work. But there are
things to be said for seeing what is new. I have found the defaults
are not always what I want/
Post by root
I thought this method worked until I found that some kernels built
this way do not boot on older machines. In particulare using the
.config file from linux-4.9.70 does not work building linux-4.14.18
when the all questions are defaulted. The resulting kernel just
hangs during boot, but there is no panic.
Bummer.
Post by root
That same kernel boots with no problem on newer
machines.
Similarly, starting with the 4.9.70 .config and
building linux-4.15.2 creates a kernel that hangs
during boot.
Out of curiosity I tried some later kernels and they would not
accept my version of gcc which is from Slack64-14.2
I find that surprising. I have compiled many versions of the kernel
(up to and including 5.1.12) on S64-14.2 and never have I had the
issue with gcc. I haven't compiled every last version, but I have
compiled these in the 4. series:
4.0.5
4.4.14
4.8.4
4.9.4
4.10.8
4.11.9
4.14.14
4.15.15
4.17.11
4.18.11
4.19.7
Post by root
This isn't a critical problem because I can just run the older
machines with an older kernel, but I would like a suggestion of how
to overcome the problem should a newer kernel be essential. I simply
don't have the patience (or skill) to separately decide on each
option.
That is a painstaking process.
Post by root
Thanks for any suggestions.
(1) Specifically, what kernel gave you gcc problems?
(2) Can you capture the messages when a kernel hangs and report them here?
(3) Accepting the default may have done something horrible like remove
support for your root filesystem (e.g., ext4), your disk driver,
or some such thing. The messages would help debug the problem.


Jim
root
2019-07-14 22:11:51 UTC
Permalink
Post by Jim Diamond
I find that surprising. I have compiled many versions of the kernel
(up to and including 5.1.12) on S64-14.2 and never have I had the
issue with gcc. I haven't compiled every last version, but I have
4.0.5
4.4.14
4.8.4
4.9.4
4.10.8
4.11.9
4.14.14
4.15.15
4.17.11
4.18.11
4.19.7
(1) Specifically, what kernel gave you gcc problems?
(2) Can you capture the messages when a kernel hangs and report them here?
(3) Accepting the default may have done something horrible like remove
support for your root filesystem (e.g., ext4), your disk driver,
or some such thing. The messages would help debug the problem.
Jim
Thanks for responding Jim.

Yesterday I went to https://www.kernel.org/ and
downloaded the tarball for 5.2.1. I could not build
that because of a compiler message, I don't remember the
exact message but it had something like retrocompile in it.

I got the same result when I backed down to 4.19.59.

This morning I pulled the ssd from that system, and
copied over everything from my current system to that.

Just now I downloaded the tarball for 5.2.1 and it is
building. The compile is running on the newly restored
ssd described in the previous paragraph.

After make modules, the build failed on make modules_install
with this error message:

cp: cannot stat './modules.builtin.modinfo': No such file or directory
Makefile:1309: recipe for target '_modinst_' failed
make: *** [_modinst_] Error 1


The two kernels that hung after being built terminated
in different places. The 4.15.2 kernel hung after a message
about usb that ended with btufs, or something like that.

The 4.4.18 kernel hung after a message about the Radeon
video card.

I rebuilt the 4.4.18 kernel and it hung after this line:

[ 13.279566] usbcore:registered new interface driver btusb

I went over to this machine to send this message and
the system continued to boot. It is now hung at
Triggering udeve events: /sbin/udevadm trigger --action=change

I see a problem line above this:
about /proc/bus/usb does not exist.

Finally I got a prompt and I can log in.
root
2019-07-15 00:03:16 UTC
Permalink
Post by root
Yesterday I went to https://www.kernel.org/ and
downloaded the tarball for 5.2.1. I could not build
that because of a compiler message, I don't remember the
exact message but it had something like retrocompile in it.
my gcc is 5.5
Post by root
Just now I downloaded the tarball for 5.2.1 and it is
building. The compile is running on the newly restored
ssd described in the previous paragraph.
After make modules, the build failed on make modules_install
cp: cannot stat './modules.builtin.modinfo': No such file or directory
Makefile:1309: recipe for target '_modinst_' failed
make: *** [_modinst_] Error 1
So I grepped the Documentation to find this command:
make -C /lib/modules/`uname -r`/build M=$PWD modules_install

This appeared suspect, but what the hell, I tried it.
At the time I was running the 4.4.18 kernel I had just
built.

The command did install the modules, but it
overwrote the modules in my /lib/modules/4.4.18 directory.
The /lib/modules/5.2.1 directory was empty.

This sucks badly. So they change the Makefile, and then
we have to read all the .rs files to know how to install
the modules. I also find there is no
make bzImage,
but there is a make zImage.

I have left the detritus of the make and will come back
to it later.
Jerry Peters
2019-07-15 20:21:16 UTC
Permalink
Post by root
Post by Jim Diamond
I find that surprising. I have compiled many versions of the kernel
(up to and including 5.1.12) on S64-14.2 and never have I had the
issue with gcc. I haven't compiled every last version, but I have
4.0.5
4.4.14
4.8.4
4.9.4
4.10.8
4.11.9
4.14.14
4.15.15
4.17.11
4.18.11
4.19.7
(1) Specifically, what kernel gave you gcc problems?
(2) Can you capture the messages when a kernel hangs and report them here?
(3) Accepting the default may have done something horrible like remove
support for your root filesystem (e.g., ext4), your disk driver,
or some such thing. The messages would help debug the problem.
Jim
Thanks for responding Jim.
Yesterday I went to https://www.kernel.org/ and
downloaded the tarball for 5.2.1. I could not build
that because of a compiler message, I don't remember the
exact message but it had something like retrocompile in it.
More like retpoline I suspect. It;s a fix for one of the cpu
hardware security bugs. It needs compiler support to work, so kbuild
warns you when it's on and the compiler doesn't support it. You need
to turn it off. It's under processor type and features:

#
# Processor type and features
#
CONFIG_ZONE_DMA=y
CONFIG_SMP=y
CONFIG_X86_FEATURE_NAMES=y
CONFIG_X86_MPPARSE=y
# CONFIG_GOLDFISH is not set
# CONFIG_RETPOLINE is not set
# CONFIG_X86_CPU_RESCTRL is not set
Post by root
I got the same result when I backed down to 4.19.59.
This morning I pulled the ssd from that system, and
copied over everything from my current system to that.
Just now I downloaded the tarball for 5.2.1 and it is
building. The compile is running on the newly restored
ssd described in the previous paragraph.
After make modules, the build failed on make modules_install
cp: cannot stat './modules.builtin.modinfo': No such file or directory
Makefile:1309: recipe for target '_modinst_' failed
make: *** [_modinst_] Error 1
The two kernels that hung after being built terminated
in different places. The 4.15.2 kernel hung after a message
about usb that ended with btufs, or something like that.
The 4.4.18 kernel hung after a message about the Radeon
video card.
[ 13.279566] usbcore:registered new interface driver btusb
I went over to this machine to send this message and
the system continued to boot. It is now hung at
Triggering udeve events: /sbin/udevadm trigger --action=change
about /proc/bus/usb does not exist.
Finally I got a prompt and I can log in.
root
2019-07-15 20:47:36 UTC
Permalink
Post by Jerry Peters
More like retpoline I suspect. It;s a fix for one of the cpu
hardware security bugs. It needs compiler support to work, so kbuild
warns you when it's on and the compiler doesn't support it. You need
#
# Processor type and features
#
CONFIG_ZONE_DMA=y
CONFIG_SMP=y
CONFIG_X86_FEATURE_NAMES=y
CONFIG_X86_MPPARSE=y
# CONFIG_GOLDFISH is not set
# CONFIG_RETPOLINE is not set
# CONFIG_X86_CPU_RESCTRL is not set
Thanks for responding.
Jerry Peters
2019-07-14 20:46:29 UTC
Permalink
Post by root
Nearly all machines on my LAN use an Intel Core I7 but
some machines are ten years old. When I build a new
kernel I have always copied over the old .config
file, then run make oldconfig before starting the
build. I default on all the questions by just holding
the enter key down until the options are finished.
I thought this method worked until I found that some
kernels built this way do not boot on older machines.
In particulare using the .config file from linux-4.9.70
does not work building linux-4.14.18 when the
all questions are defaulted. The resulting kernel
just hangs during boot, but there is no panic.
That same kernel boots with no problem on newer
machines.
Similarly, starting with the 4.9.70 .config and
building linux-4.15.2 creates a kernel that hangs
during boot.
Out of curiosity I tried some later kernels and
they would not accept my version of gcc which is
from Slack64-14.2
I just compiled 5.1.18 earlier today on a Slack64-14.2 system (won't
switch to 5.2 until it seems reasonably stable). Recently kbuild was
updated to require a somewhat more recent gcc, but even the gcc with
14.1 qualifies (4.8.2). IIRC the oldest gcc accepted is 4.4 or maybe
4.5.

There should be a localmodconfig target that will generate a
configuration for the machine it's run on.
Post by root
This isn't a critical problem because I can just run
the older machines with an older kernel, but I would
like a suggestion of how to overcome the problem
should a newer kernel be essential. I simply
don't have the patience (or skill) to separately
decide on each option.
Thanks for any suggestions.
root
2019-07-14 23:53:41 UTC
Permalink
Post by Jerry Peters
I just compiled 5.1.18 earlier today on a Slack64-14.2 system (won't
switch to 5.2 until it seems reasonably stable). Recently kbuild was
updated to require a somewhat more recent gcc, but even the gcc with
14.1 qualifies (4.8.2). IIRC the oldest gcc accepted is 4.4 or maybe
4.5.
There should be a localmodconfig target that will generate a
configuration for the machine it's run on.
What is a localmodconfig target? When I was compiling 5.2.1
I found there is no make modules_install? More about that
in my follow up.
Jerry Peters
2019-07-15 20:24:16 UTC
Permalink
Post by root
Post by Jerry Peters
I just compiled 5.1.18 earlier today on a Slack64-14.2 system (won't
switch to 5.2 until it seems reasonably stable). Recently kbuild was
updated to require a somewhat more recent gcc, but even the gcc with
14.1 qualifies (4.8.2). IIRC the oldest gcc accepted is 4.4 or maybe
4.5.
There should be a localmodconfig target that will generate a
configuration for the machine it's run on.
What is a localmodconfig target? When I was compiling 5.2.1
I found there is no make modules_install? More about that
in my follow up.
It generates a config for the specific machine it's run on, based on
the currently loaded modules, I assume.
root
2019-07-15 20:53:02 UTC
Permalink
Post by Jerry Peters
Post by root
Post by Jerry Peters
I just compiled 5.1.18 earlier today on a Slack64-14.2 system (won't
switch to 5.2 until it seems reasonably stable). Recently kbuild was
updated to require a somewhat more recent gcc, but even the gcc with
14.1 qualifies (4.8.2). IIRC the oldest gcc accepted is 4.4 or maybe
4.5.
There should be a localmodconfig target that will generate a
configuration for the machine it's run on.
What is a localmodconfig target? When I was compiling 5.2.1
I found there is no make modules_install? More about that
in my follow up.
It generates a config for the specific machine it's run on, based on
the currently loaded modules, I assume.
It has been my policy for a long time to (m) everything except
a (very) few items I want in the kernel. That way I can port
around different machines. Thanks for clearing up my confustion.
Jerry Peters
2019-07-16 20:20:14 UTC
Permalink
Post by root
Post by Jerry Peters
Post by root
Post by Jerry Peters
I just compiled 5.1.18 earlier today on a Slack64-14.2 system (won't
switch to 5.2 until it seems reasonably stable). Recently kbuild was
updated to require a somewhat more recent gcc, but even the gcc with
14.1 qualifies (4.8.2). IIRC the oldest gcc accepted is 4.4 or maybe
4.5.
There should be a localmodconfig target that will generate a
configuration for the machine it's run on.
What is a localmodconfig target? When I was compiling 5.2.1
I found there is no make modules_install? More about that
in my follow up.
It generates a config for the specific machine it's run on, based on
the currently loaded modules, I assume.
It has been my policy for a long time to (m) everything except
a (very) few items I want in the kernel. That way I can port
around different machines. Thanks for clearing up my confustion.
To see all of the kernel make targets do 'make help'.

Loading...