Can't stat /proc/sys/vm & K Panic when Flashing eMMC while Running with a Kernel built from Source

GoogleGroups
1

Hi,

I burned a uSD card with bbx15-debian-8.10-console-armhf-2018-01-01-1gb.img.xz which I got from elinux.org. The kernel which comes with that image is 4.4.91-ti-r141. But I have been building kernel version 4.4.110-ti-r142 from source following the instructions on eewiki.net for the BB-X15, and copying the kernel image, dtbs, and modules to that same uSD card which still has the stock kernel on it. Both kernel’s appear to run just fine from uSD card when uname-r is changed in uEnv.txt.

But when I run try to run the eMMC flasher script with the 4.4.110 (built from source) kernel running instead of the “stock kernel” running the flasher script dies when /proc/sys/vm/min_free_kbytes isn’t there and then you see a kernel panic (please see console dump below). However, when I switch the running kernel back to the stock kernel, 4.4.91-ti-r141 which came with that image, the eMMC flasher script again works. I’ve tried running both, /opt/scripts/tools/eMMC/init-eMMC-flasher-v3-no-eeprom.sh and init-eMMC-flasher-v3-x15_b1.sh, both with the same result (I think).

I’m wondering what other crucial step needs to be followed which I missed… I didn’t touch the filesystem which was already part of the 2018-01-01 console BB-X15 image on that uSD card, but when I run “mount” on both kernels, I get differences (see below).

Please take a look at what I’ve posted below and give me some clues as to where to look or what to read up on next…

Thanks!!

*When the kernel built from source (4.4.110) is running from uSD card, and I’m logged in as debian (or have typed sudo su from debian), I’m able to run /sbin/sysctl -n vm.min_free_kbytes both as “debian” and su. So proc appears to be present on the 4.4.110 kernel running from uSD card once logged in:

*When running both kernels from the uSD card, I ran “zcat /proc/config.gz” and the configurations were “pretty similar.” (see diff below):

< # Linux/arm 4.4.91 Kernel Configuration

2

Weird, for now just nuke that sysctr setting, it’s not mandatory, it fixed some randomness on the bones, which have a quarter the memory of the x15…

Regards,

3

Nuking sysctl -n vm.min_free_kbytes in functions.sh::prepare_environment() gets rid of that problem, but script chokes on the next step, determining root drive, apparently due to issues with presence of proc at this point…

echo_broadcast “==> Preparing sysctl”

value_min_free_kbytes=$(sysctl -n vm.min_free_kbytes)

echo_broadcast “==> sysctl: vm.min_free_kbytes=[${value_min_free_kbytes}]”

echo_broadcast “==> sysctl: setting: [sysctl -w vm.min_free_kbytes=16384]”

sysctl -w vm.min_free_kbytes=16384

generate_line 40

One interesting thing… Regarding the flasher script/process, it ALMOST looks like something is tied to the original uname-r associated with the stock image on 2018-01-01…

I tried a brief (horrible hack) experiment where I renamed the stock kernel, from: 4.4.91-ti-r141 to: 4.4.91-ti-r141-stock.

I renamed the vmlinuz image to vmlinuz-4.4.91-ti-r141-stock, the modules directory to 4.4.91-ti-r141-stock, and the dtbs direcfory to uname-r-stock and then set uname-r in uEnv.txt to uname-r-stock and ran the flasher.

I saw the same flasher problem (cannot stat /proc/sys/vm) with the renamed uname-r as with the 4.4.110-ti-r142 image

4

Nuking sysctl -n vm.min_free_kbytes in functions.sh::prepare_environment()
gets rid of that problem, but script chokes on the next step, determining
root drive, apparently due to issues with presence of proc at this point..

# echo_broadcast "==> Preparing sysctl"
# value_min_free_kbytes=$(sysctl -n vm.min_free_kbytes)
# echo_broadcast "==> sysctl:
vm.min_free_kbytes=[${value_min_free_kbytes}]"
# echo_broadcast "==> sysctl: setting: [sysctl -w
vm.min_free_kbytes=16384]"
# sysctl -w vm.min_free_kbytes=16384
# generate_line 40

This now checks for:

/proc/sys/vm/min_free_kbytes

================================================================================
Checking running system
==> Copying: [/dev/mmcblk0] -> [/dev/mmcblk1]
==> lsblk:
----------------------------------------
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
mmcblk1boot0 179:16 0 4M 1 disk
mmcblk1boot1 179:24 0 4M 1 disk
mmcblk0 179:0 0 29G 0 disk
`-mmcblk0p1 179:1 0 846M 0 part /
mmcblk1 179:8 0 3.6G 0 disk
`-mmcblk1p1 179:9 0 3.6G 0 part
----------------------------------------
==> df -h | grep rootfs:
----------------------------------------
modprobe: ERROR: ../libkmod/libkmod.c:557 kmod_search_moddep() could not
open moddep'
==> Giving you time to check...

Humm..

Maybe you need to boot once..

Run:

sudo depmod -a

might as well run, this too...

sudo update-initramfs -ck `uname -r`

or

sudo update-initramfs -uk `uname -r`

then, shutdown and try to flash it..

Regards,

5

Thanks Robert!

Eureka it works!

so long as you keep, initrd.img-4.4.110-ti-r142 in /boot it’s happy…

Regards,

Jeff