Re: [beagleboard] Can't stat /proc/sys/vm & K Panic when Flashing eMMC while Running with a Kernel built from Source
Thanks Robert!
Eureka it works!
so long as you keep, initrd.img-4.4.110-ti-r142 in /boot it's happy..
Regards,
Jeff
On Wednesday, February 14, 2018 at 2:31:34 PM UTC-6, RobertCNelson wrote:
>
> On Wed, Feb 14, 2018 at 2:21 PM, Jeff Andich > wrote:
> > 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
>
>
> https://github.com/RobertCNelson/boot-scripts/commit/89f2e9309c2322c15e2bb6b55afd214313d94842#diff-c483633eab46489e55e2e391823018ad
>
>
>
>
>
> >
> >
>
>
>
> > Checking running system
> > ==> Copying: [/dev/mmcblk0] -> [/dev/mmcblk1]
> > ==> lsblk:
> >
> > NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
> > mmcblk1boot0 179:16 04M 1 disk
> > mmcblk1boot1 179:24 04M 1 disk
> > mmcblk0 179:00 29G 0 disk
> > `-mmcblk0p1 179:10 846M 0 part /
> > mmcblk1 179:80 3.6G 0 disk
> > `-mmcblk1p1 179:90 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,
>
> --
> Robert Nelson
> https://rcn-ee.com/
>
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/beagleboard/e049a300-b1da-4247-8769-a4d64884baae%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Can't stat /proc/sys/vm & K Panic when Flashing eMMC while Running with a Kernel built from Source
On Wed, Feb 14, 2018 at 2:21 PM, Jeff Andich wrote:
> 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
https://github.com/RobertCNelson/boot-scripts/commit/89f2e9309c2322c15e2bb6b55afd214313d94842#diff-c483633eab46489e55e2e391823018ad
>
>
> Checking running system
> ==> Copying: [/dev/mmcblk0] -> [/dev/mmcblk1]
> ==> lsblk:
>
> NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
> mmcblk1boot0 179:16 04M 1 disk
> mmcblk1boot1 179:24 04M 1 disk
> mmcblk0 179:00 29G 0 disk
> `-mmcblk0p1 179:10 846M 0 part /
> mmcblk1 179:80 3.6G 0 disk
> `-mmcblk1p1 179:90 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,
--
Robert Nelson
https://rcn-ee.com/
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/beagleboard/CAOCHtYhYsMvkJxZnfwr4fDae4r7yG4C9DWaSfJZ1t6H6cG36Vw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Can't stat /proc/sys/vm & K Panic when Flashing eMMC while Running with a Kernel built from Source
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-r141to: 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
Prepare environment for flashing
Starting at Mon Jan 1 00:00:01 UTC 2001
==> Giving system time to stablize...
5 4 3 2 1
==> Preparing /tmp
==> Preparing sysctl
sysctl: cannot stat /proc/sys/vm/min_free_kbytes: No such file or directory
Traceback (last called is first):
prepare_environment() in /opt/scripts/tools/eMMC/functions.sh:150
main() in /opt/scripts/tools/eMMC/init-eMMC-flasher-v3-no-eeprom.sh:41
The command value_min_free_kbytes=$(sysctl -n vm.min_free_kbytes) exited
with exit code 255.
Tearing Down script environment
==> Unmounting /tmp
I then did something even potentially worse and renamed the 4.4.110-ti-r142
kernel to 4.4.91-ti-r141 (consistent with the original image name) and ran
the flasher image got a bunch of errors, but it looks like the flash
programming process got a lot further along (see below).
Next, I will try to re-build the 4.4.91-ti-r141 kernel with the same
.config as on the 2018-01-01 image, copy that to the uSD card with uname-r
= 4.4.91-ti-r141, and re-run the flasher.
In the meantime, is there a logical explanation for what I just saw??
Either that the flasher script or the presence of /proc somehow depends on
the original uname-r? Recall that if I copy a kernel with a different
uname-r to uSD card and change uname-r in uEnv.txt that the system boots
with that kernel (from uSD card)..
Thanks!
Jeff
Starting eMMC Flasher from microSD media
Version: [1.20171220: btrfs...]
Prepare environment for flashing
Starting at Mon Jan 1 00:00:58 UTC 2001
==> Giving system time to stablize...
5 4 3 2 1
==> Preparing /tmp
==> Preparing sysctl
==> sysctl: vm.min_free_kbytes=[2479]
==> sysctl: setting: [sysctl -w vm.min_free_kbytes=16384]
vm.min_free_kbytes = 16384
==> Determining root drive
==> console=ttyO2,115200n8 root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait
init=/opth
==> root_drive=[/dev/mmcblk0p1]
> Root drive identified at [/dev/mmcblk0p1]
==> Boot Drive [/dev/mmcblk0p1]
==> Figuring out Source and Destination devices
> Source identified: [/dev/mmcblk0]
> Destination identified: [/dev/mmcblk1]
==> Figuring out machine
> Machine is TI_AM572x_EVM_Rev_A3
> Machine is compatible with BeagleBone Black
5 4 3 2 1
Checking running system
==> Copying: [/dev/mmcblk0] -> [/dev/mmcblk1]
==> lsblk:
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
mmcblk1boot0 179:16 04M 1 disk
mmcblk1boot1 179:24 04M 1 disk
mmcblk0 179:00 29G 0 disk
`-mmcblk0p1 179:10 846M 0 part /
mmcblk1 179:80 3.6G 0 disk
`-mmcblk1p1 179:90 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...
10 9 8 7 6 5 4 3 2 1
===
Re: [beagleboard] Can't stat /proc/sys/vm & K Panic when Flashing eMMC while Running with a Kernel built from Source
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, On Feb 13, 2018 5:17 PM, "Jeff Andich" wrote: > 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 > --- > > # Linux/arm 4.4.110 Kernel Configuration > 1208a1209 > > # CONFIG_NET_DSA is not set > 2809,2810c2810,2811 > < CONFIG_SERIAL_8250_NR_UARTS=6 > < CONFIG_SERIAL_8250_RUNTIME_UARTS=6 > --- > > CONFIG_SERIAL_8250_NR_UARTS=9 > > CONFIG_SERIAL_8250_RUNTIME_UARTS=9 > > > *One thing that's different is the outputs of the "mount" command run on > the two kernels: > > > /dev/mmcblk0p1 on / type ext4 (rw,relatime,errors=remount- > ro,data=ordered) > > devtmpfs on /dev type devtmpfs (rw,relatime,size=824360k,nr_ > inodes=97302,mode=755) > 3,6d4 > < udev on /dev type devtmpfs (rw,relatime,size=10240k,nr_ > inodes=96053,mode=755) > < devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime, > gid=5,mode=620,ptmxmode=000) > < tmpfs on /run type tmpfs (rw,nosuid,relatime,size=372500k,mode=755) > < /dev/mmcblk0p1 on / type ext4 (rw,relatime,errors=remount- > ro,data=ordered) > 8a7,8 > > devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime, > gid=5,mode=620,ptmxmode=000) > > tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755) > 13,17d12 > < cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec, > relatime,freezer) > < cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec, > relatime,blkio) > < cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec, > relatime,perf_event) > < cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec, > relatime,devices) > < cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec, > relatime,cpu,cpuacct) > 19c14,15 > < cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec, > relatime,cpuset) > --- > > cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec, > relatime,cpu,cpuacct) > > cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec, > relatime,perf_event) > 21c17,20 > < systemd-1 on /proc/sys/fs/binfmt_misc type autofs > (rw,relatime,fd=22,pgrp=1,timeout=0,minproto=5,maxproto=5,direct) > --- > > cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec, > relatime,cpuset) > > cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec, > relatime,freezer) > > cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec, > relatime,devices) > > cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec, > relatime,blkio) > 24c23 > < configfs on /sys/kernel/config type configfs (rw,relatime) > --- > > systemd-1 on /proc/sys/fs/binfmt_misc type autofs > (rw,relatime,fd=33,pgrp=1,timeout=0,minproto=5,maxproto=5,direct) > 26c25,26 > < tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime, > size=186252k,mode=700,uid=1000,gid=1000) > --- > > configfs on /sys/kernel/config type configfs (rw,relatime) > > tmpfs on /run/
[beagleboard] Can't stat /proc/sys/vm & K Panic when Flashing eMMC while Running with a Kernel built from Source
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 --- > # Linux/arm 4.4.110 Kernel Configuration 1208a1209 > # CONFIG_NET_DSA is not set 2809,2810c2810,2811 < CONFIG_SERIAL_8250_NR_UARTS=6 < CONFIG_SERIAL_8250_RUNTIME_UARTS=6 --- > CONFIG_SERIAL_8250_NR_UARTS=9 > CONFIG_SERIAL_8250_RUNTIME_UARTS=9 *One thing that's different is the outputs of the "mount" command run on the two kernels: > /dev/mmcblk0p1 on / type ext4 (rw,relatime,errors=remount-ro,data=ordered) > devtmpfs on /dev type devtmpfs (rw,relatime,size=824360k,nr_inodes=97302,mode=755) 3,6d4 < udev on /dev type devtmpfs (rw,relatime,size=10240k,nr_inodes=96053,mode=755) < devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000) < tmpfs on /run type tmpfs (rw,nosuid,relatime,size=372500k,mode=755) < /dev/mmcblk0p1 on / type ext4 (rw,relatime,errors=remount-ro,data=ordered) 8a7,8 > devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000) > tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755) 13,17d12 < cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer) < cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio) < cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event) < cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices) < cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct) 19c14,15 < cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset) --- > cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct) > cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event) 21c17,20 < systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=22,pgrp=1,timeout=0,minproto=5,maxproto=5,direct) --- > cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset) > cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer) > cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices) > cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio) 24c23 < configfs on /sys/kernel/config type configfs (rw,relatime) --- > systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=33,pgrp=1,timeout=0,minproto=5,maxproto=5,direct) 26c25,26 < tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=186252k,mode=700,uid=1000,gid=1000) --- > configfs on /sys/kernel/config type configfs (rw,relatime) > tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=186248k,mode=700,uid=1000,gid=1000) Console dump when attempting to flash the eMMC using kernel 4.4.110-ti-r142 compiled from source * Starting eMMC Flasher from microSD media Version: [1.20171220: btrfs...] ==
