Loading "BriskMenuFactory::BriskMenu" Failed

這個 ubuntu window manage (名子忘了)，開機有時會出現 Error:

The panel encountered a problem while loading "BriskMenuFactory::BraskMenu".

有時候重開機就好，有時候會不行。

google 的結果，說暫時沒有解，在 20.10 也有一樣的問題。
遇到的時候，就 logout 再 login 一次就可以了。
-- 真神奇

Try overlayfs in embeddes system.

copy initrd.img-5.4.83-v7+-overlay 出來，rename img.gz, unpack 後，

mkdir out && cd out
cpio -idv < ../initrd.img

---

ref:

• readonly root with overlay

這一篇的方法好像不需要 用到 initramfs，只需要在真正 init 起來之前做就可以。
修改 kernel boot cmd，init=/myinit
然後myinit 就啟動 /bin/sh

進入後，測試 command:
mkdir : OK
mount / /rom : OK
mount -o remount,ro /rom : fail, 說沒有 /proc/mounts

所以 myinit 要加上

mount -t proc none /proc

之後 remount OK

最後是

exec chroot /rom /linuxrc

這樣就可以了。
要測試就把上面改成

/bin/sh

就會開進 shell 測試在這時候的 command 有沒有用。

mount --move 是變更 mount 位置，這樣就不用 unmount 之後再 mount

成功! final version ( /overlay folder must be created in first):

#!/bin/sh

mount -t proc none /proc
mount -t tmpfs none /overlay

mkdir /overlay/lower
mkdir /overlay/upper
mkdir /overlay/worker
mkdir /overlay/newroot

mount / /overlay/lower
mount -o remount,ro /overlay/lower

mount -t overlay overlay -olowerdir=/overlay/lower,upperdir=/overlay/upper,workdir=/overlay/worker /overlay/newroot

exec chroot /overlay/newroot /linuxrc

測試...開機後，在 / create abc, ls to see if exist.
reboot, see abc disappear

用 mount 看：

overlay on / type overlay (rw,relatime,lowerdir=/overlay/lower,upperdir=/overlay/upper,workdir=/overlay/worker)

大概是成功了。

overlay fs

用 pi 來測試功能一下，google 說 pi 的 raspi-config 就有 overlay fs 功能，給 kisok 用。

新 raspios 開啟console uart好像不用 dtoverlay disable_bt 了。
ref: uart configuration

改用 enable_uart=1
就會顯示了。(2021-1-11 的 image)
console 開到一半(通常是 usb hub init 後，就會變成亂碼...最後查到是 micro-usb power 線材的問題。
換上沒有 core 的線材就 OK 了。

用 raspi-config 開啟 overlay 功能，然後 read-only root 回答 Yes。
重開機後， / 就是 overlay 了：

mount:
overlay on / type overlay (rw,noatime,lowerdir=/lower,upperdir=/upper/data,workdir=/upper/work)

boot cmd:

$ cat /proc/cmdline 
coherent_pool=1M 8250.nr_uarts=1 snd_bcm2835.enable_compat_alsa=0 snd_bcm2835.enable_hdmi=1 bcm2708_fb.fbwidth=656 bcm2708_fb.fbheight=416 bcm2708_fb.fbswap=1 vc_mem.mem_base=0x3ec00000 vc_mem.mem_size=0x40000000  boot=overlay console=ttyS0,115200 console=tty1 root=PARTUUID=3661545e-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwai

大概是：boot=overlay, root=UARTUUID...,rootfstype=ext4 之類。

raspberry pi 使用 overlayfs 作為 rootfs 可以參考overlayroot，有一堆都是寫 init script，取代 init，開機後重新 mount root。
raspberry pi 的 script 好像是 /etc/initramfs-tools/scripts/overlay

以前 raspi-config 還沒有 overlayfs 選項時，大概是用這一篇:overlay filesystem raspi 來做。
這一篇:easy change on a read only reaspberry pi 也有說明手動更改跟使用 raspi-config 修改的兩種方法。
這一篇 setting up overlay fs on raspberry pi還提供在 power off 時，把 upper layer 寫回 lower layer 的 方法，聲稱這樣可以大大個減少 sd card write 的次數 (增加壽命)

---

有關 overlayfs 的使用，可以參考play with overlay filesystem
任何兩個 目錄都可以疊成一個 overlay filesystem (目錄)。
以上面 ref 的例子來看。
有 upper, lower 兩個目錄：

charles-chang@beaver:~/test$ tree upper/
upper/
├── dir
│   └── g
├── e
└── f

1 directory, 3 files
charles-chang@beaver:~/test$ tree lower/
lower/
├── a
├── b
├── dir
│   ├── c
│   └── d
└── test

用 mount command 把 upper 疊在 lower 之上，最後成為 'merged' 目錄：

sudo mount -t overlay overlay -olowerdir=./lower,upperdir=./upper,workdir=./work merged

看看 merged 目錄：

tree merged/
merged/
├── a
├── b
├── dir
│   ├── c
│   ├── d
│   └── g
├── e
├── f
└── test

可以看到 upper 跟 lower合併在一起了。
因為 overlayfs 的 lower 是不能更動的，只能藉由 upper 來更動。
所以可以修改 merged 下的 file ，然後去 upper, lower 看看變化。
有一點要注意： lower 的內容在 mount 之後，就不要更動了，否則會有不可預知的問題。

---

在busybox 1.32.1
enable build static
make && sudo make install

buildroot -- build system for qemu

buildroot 竟然變得這麼方便，幫你把 kernel 都弄好了。
clone 下來， 選 qemu 的 defconfig 後就 make，然後 kernel, dtb ,rootfs 都build 好，
接下來用 qemu 來 run 就可以。
以 qemu 來 run..

make qemu_arm_vexpress_defconfig
make

qemu-system-arm -M vexpress-a9 -smp 4 -m 1024M -kernel output/images/zImage -append "root=/dev/mmcblk0 console=ttyAMA0 loglevel=8" -dtb output/images/vexpress-v2p-ca9.dtb -sd output/images/rootfs.ext2 -nographic

就可以用 root 登入。

---

ref:编译运行Linux内核,制作initramfs，并通过qemu+gdb调试
用 qemu 跟 gdb 來 debug kernel:

build kernel and root (initrd):
download kernel source.
make menuconfig (不用改，只是要產生 .config)
make

build tools and shell:
download busybox
make menuconfig ( Build Option -- build static library)
make
sudo make install

create root structure:
.. 先跳過..

---

ref：深入理解 Linux 2.6 的 initramfs 機制 (上)
kernel 用上面的沒關係，記得 menuconfig 要改好。
做好 hello-initramfs 目錄。
build 好 kernel 的 bzImage
用下面command run..

qemu-system-x86_64 -s -kernel linux-4.9.263/arch/x86_64/boot/bzImage --append "console=ttyS0" -nographic

好白痴： could not determine kind of name for C.X509_V_ERR_CA_KEY TOO_SMALL

在make go project時出現這個 error:

could not determine kind of name for C.X509_V_ERR_CA_KEY TOO_SMALL 
...

還有一堆 ssl 的 C.X509.
去看source 果然沒有宣告的地方。
但是在另一個 arm64 的機器上make 是 OK 的。
一直以為是 go version 問題（因為這個 project 曾經發生改版後，go version 過舊問題，也是搞很久)
然後 google 這格 error 竟然完全沒有!!
--- 其實這就代表 project 本身沒問題。是你自己的問題。

後來看到重點： C.

所以是 go 參考 C 的部份...
結果是這個 host 沒有安裝 libssl-dev
apt install libssl-dev 後就OK 了。

搞了兩小時....果然是白痴....

bookmark: build arm natively from x86

買一片 pi4 還是用 vm ?
有 apt 的 distribution build 起來還是比較方便，不用處理 library 問題。
所以...

• bulilding arm conatiner on x86
• run pi over qemu on x86

感覺起來還是在 pi4 上 build 比較快...(NT2000)

HMW and FCW

Headway Monitor Warning , Forward Collision Warning

兩個很像，都是針對前方車輛的距離，速度做出的告警。

• Headway Monitor Warning 是判斷安全車距，安全車距和自己的車速有關，自己的車速越快，安全車距就要越大。
• Forward Collision Warning 是判斷撞上前車的時間，除了車距外，還跟相對速度有關。

兩個都用到和前車的距離，但是一個用自己的車速，一個用相對的車速。
車距用影像可以得到，自己的車速就要用GPS 或是車速線
相對車速就可以用影像得到。

所以兩者需要的 資料還是有一點不一樣。

但是只要做得出 HMW，就能做出 FCW，不做白不做....