[SOLVED] Having an Absolutely AWFUL TIME doing this!!!!

rnturn · 03-07-2021, 12:49 PM

Quote:

Originally Posted by berndbausch

Personally, I think instructions like compiling a kernel should be written, not filmed.

So true. Is the the person providing the instruction an author or a movie producer? In many cases, it seems to be neither.

Yeah, I can rewind the video to re-see a bit that I didn't quite get but is not the same as having something that I can highlight if I've printed it out or put a sticky note on if it's an actual manual. (Ah... manuals. 'member them? I fondly remember the Orange/Blue/Gray/White Wall from my DEC days. Got a question? The answer's in The Wall. It may be Appendix J of the Device Drivers manual but it's in there). Besides, if I'm compiling a kernel, how likely is it that I'm going to be able to follow along the instructions in a video? (I'm probably running in single user mode.)

Any detailed written documentation I write is likely to include footnotes. (I can just see readers cringing :^) ). The body of the text contains the instructions. The "why" is in the footnotes (which could be lengthy).

rnturn · 03-07-2021, 12:55 PM

Quote:

Originally Posted by wpeckham

The reason is largely that the compile goes a LOT faster on a platform with greater power and resources. Like, in some cases a DAY faster.

A day? I'm pretty sure I never waited a day for a kernel compilation on my dual Pentium Pro box. Yes, the kernel was smaller back then but still. :^)

rnturn · 03-07-2021, 01:09 PM

Quote:

Originally Posted by SamGearhart172450

When I put this command in, I get this: pi@raspberrypi:~ $ cp /boot/config-$(uname -r) .config
cp: cannot stat '/boot/config-5.10.17-v7l+': No such file or directory

When I put this in, I get this: pi@raspberrypi:~ $ make menuconfig
make: *** No rule to make target 'menuconfig'. Stop.

It just doesn't end with this. And I get other errors also. I think I'm just going to erase the disk, reinstall the OS, and start all over again as I must have corrupted the disk somehow for it to not recognize the make menuconfig command.

I was trying to do this build/compile thing the other day and the make menuconfig DID work and brought up a screen that allowed me to configure the 64 bit kernel. Now nothing happens when I try to do this. What gives here????

It's been ages since I've compiled any kernels but, a question: Are you cleaning out the source tree with "make clean" or "make distclean" between attempts? If not, I'd give that a try.

wpeckham · 03-08-2021, 08:55 AM

Quote:

Originally Posted by rnturn

A day? I'm pretty sure I never waited a day for a kernel compilation on my dual Pentium Pro box. Yes, the kernel was smaller back then but still. :^)

I just checked and my RPi is 2.0! Compiling something the size of the kernel source is "challenging" to say the least.
I suspect speeds are doubled in 3b, and at least doubled again on RPi 4. I still prefer compiling on my Linux (Currently Manjaro) laptop to the RPi standard image and porting it over. Even an underpowered old laptop is generally MUCH faster than an RPi as a development base.
(Possible exception, I have a Pinebook Pro and I love it, but have not tried to use it for development of anything other than Vlang and shell scripts. I am not sure how it would do.)

The best advice I have for doign development directly on an RPi is to develop patience and perserverence. It may need lots of trial and error.

jsbjsb001 · 03-08-2021, 09:13 AM

Quote:

Originally Posted by jpollard

That is because the file isn't supposed to be there. For ARM, the configuration is contained in a module, so you do a "sudo insmod configs", which installs the module in /proc that contains the compressed configuration.

Now, once the module in loaded the build system SHOULD be able to find it (most architectures have it in /boot, but because ARM is using a UEFI boot, it doesn't put it there - note, I don't have any other system that uses a UEFI boot so I don't know how they handle it).
...

While I can't comment on how ARM systems do it; On my x86 machine, the config for the running kernel is in both /boot and /proc And my machine is a UEFI machine, with Linux booted in EFI mode.

Code:

bash-5.1$ uname -a
Linux jamespc 5.10.14-desktop-1omv4002 #1 SMP PREEMPT Mon Feb 8 18:13:34 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
bash-5.1$ ls -la /boot/config*
-rw-r--r-- 1 root root 240023 Feb  9 04:53 /boot/config-5.10.14-desktop-1omv4002

What does UEFI have to do with it, out of interest?

jpollard · 03-08-2021, 09:30 AM

Quote:

Originally Posted by jsbjsb001

While I can't comment on how ARM systems do it; On my x86 machine, the config for the running kernel is in both /boot and /proc And my machine is a UEFI machine, with Linux booted in EFI mode.

Code:

bash-5.1$ uname -a
Linux jamespc 5.10.14-desktop-1omv4002 #1 SMP PREEMPT Mon Feb 8 18:13:34 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
bash-5.1$ ls -la /boot/config*
-rw-r--r-- 1 root root 240023 Feb  9 04:53 /boot/config-5.10.14-desktop-1omv4002

What does UEFI have to do with it, out of interest?

Absolutely nothing - it just takes up space. On the earlier Pi releases that amount was fairly small, and not generally for things other than the kernel. The problem with the /proc entry is that it takes memory. Also something not exactly available in quantity (even with 1GB Pi2 it is still short). The only issues with UEFI is that /boot has to be a Windows filesystem, and that can cause problems with fragmentation.

jsbjsb001 · 03-08-2021, 09:45 AM

Thanks jpollard.

So ARM has a module for kernel configs because ARM systems don't have much memory compared to the average x86 system?

computersavvy · 03-08-2021, 11:01 AM

Quote:

Originally Posted by rnturn

A day? I'm pretty sure I never waited a day for a kernel compilation on my dual Pentium Pro box. Yes, the kernel was smaller back then but still. :^)

Think machine types!
A desktop with a threadripper CPU vs a Raspberry Pi 4 using an arm CPU. There will be a HUGE difference in the compile time. The OP was asking about compiling the kernel on the Pi.

computersavvy · 03-08-2021, 02:20 PM

Quote:

Originally Posted by jsbjsb001

Thanks jpollard.

So ARM has a module for kernel configs because ARM systems don't have much memory compared to the average x86 system?

Yes, the Pi (depending upon the version) can have as little as 1G memory (or less) and the early ones only had support for very small SD cards. Even the 4B is only capable of a max of 8G memory but is available with 2G or 4G as well.
The kernel config module is loaded for boot then unloaded to free memory.

Remember, that is the original Raspbian OS. Today on my RPI 4B I have been running Raspbian (Debian Buster based), Ubuntu 20.10, and Fedora 33. On Fedora and on Ubuntu the kernel config file IS in /boot. Fedora and Ubuntu are also 64 bit and Raspi is 32 bit.

Raspi supports (almost) all rpi versions. Zero, 2, 3, & 4 are all indicated in the installed kernels. I am unsure about the rpi nano & 1. Because of the limited memory and SD card sizes supported on some the approach to the kernel config is different. For the same reason, most would never consider compiling a kernel on the Pi, but would cross-compile on a larger and faster machine.

jpollard · 03-08-2021, 05:23 PM

Quote:

Originally Posted by jsbjsb001

Thanks jpollard.

So ARM has a module for kernel configs because ARM systems don't have much memory compared to the average x86 system?

that has been my assumption. A 512MB system just doesn't have space, and (at the time), an 8GB SDcard was fairly normal. Decompressing the system (first boot operation) didn't appear to extend the /boot partition, but did extend the root partition. So the rather small /boot (small here means I don't remember what it was, 256MB on vfat is what my Pi 3 has with 47MB used, the Pi 1 might have had only 100MB) just didn't leave much after the kernel+ other files needed for the ARM boot.

Loading the configs module made sense as it isn't needed very often and resided on the root filesystem (there could be multiple, depending on the number of kernels you have).

It did make the configurations fairly easy to access if you wanted the current one (not so easy for the others...)

SamGearhart172450 · 03-08-2021, 07:41 PM

I believe I got it accomplished. It now says 5.10.20-v7l+ instead of the usual output of 5.10.11-v7l+ when I put the uname -r command in.Can anybody confirm that 5.10.20-v7l+ is the latest version? Thanks again.

jsbjsb001 · 03-09-2021, 12:46 AM

Thanks computersavvy, and thanks again jpollard.

Quote:

Originally Posted by SamGearhart172450

I believe I got it accomplished. It now says 5.10.20-v7l+ instead of the usual output of 5.10.11-v7l+ when I put the uname -r command in.Can anybody confirm that 5.10.20-v7l+ is the latest version? Thanks again.

Take a look at the kernel log by running the following command,

Code:

dmesg | less

and look at the first line of the output you get. Then have a look here and scroll down to the heading "Checking if your new boot entry works". Does the kernel version match the one you built (and presumably installed)? Does the username match the user you built it under? If the answer is yes and yes, then yes, you done it!

Although, if you are asking if 5.10.20-v71l is the latest version available, then no, it isn't.