如果可以让笔记本进入 命令行模式界面的话（非gdm的窗口界面），也可以，这样至少可以确认是否可以进入基本的系统。

试了下，看起来不仅仅是 /etc/rc.local 中初始的逻辑的原因。

制作U盘启动盘后，对应fstab文件、exlinux.conf 文件涉及root分区、boot分区，均采用LABEL方式定位后，Ubuntu系统可以正常启动（启动后，root分区和boot分区的确为U盘上）

然后将这个U盘上的系统，apt remove gnome、ubuntu 相关的包，且 apt autoremove后，当前系统还在运行，但重启之后，会停留在 cool-pi logo的界面卡住不动。因为无其他信息，无法进行排查，这个有方法吗？或者能介绍下 整个boot启动的链路吗？谢谢

在x86机器上的docker环境 ubuntu:20.04 下可以构建成功。arm 笔记本上发现最后一步不形，估计是使用的工具有x86下的二进制文件.

apt install build-essential device-tree-compiler bc python2

./build-loader.sh cm5-notebook

@大法师 谢谢提醒，搞定了！
u盘的两个分区的label都改了下，extlinux下的配置文件改为第二分区的label；修改fstab文件，挂载的boot分区改为按label查找的第一分区的label。

@george 一开始 进入 UMS模式，用另一台电脑用 balenaEtcher 刷最新的Ubuntu镜像，中途另一台电脑故障死机，刷机失败。

之后coolpi笔记本无法进入UMS模式，用64GB USB2.0的sandisk U盘刷了最新的Ubuntu镜像后，插上coolpi笔记本后开机，能看到Ubuntu启动logo，之后就是一直黑屏状态，也无法用 Ctrl + Alt + F1（到F12） 切换到控制台模式。U盘刷Ubuntu的内核5.10版本的那个，也是最终黑屏状态。这个如何恢复？

制作启动U盘的，是用linux 的 dd命令写入img镜像文件的

@george 好我试下，目前因为重刷时断电，得恢复后再测了，目前进不了UMS模式。

问下，linux启动时，在哪个阶段会执行 rc.local 这个文件啊？ alpine 的shell默认只有 /bin/ash，非 /bin/sh 这个是否有影响？

img文件制作，参考了 https://forum.cool-pi.com/topic/600/step-by-step-creation-of-coolpi-image-files?_=1724900039745

alpine 系统采用 官网下载的 minrootfs。通过chroot挂载后可以正常运行。但制作成img后不能启动，不知道问题出在哪里。

镜像里 /etc/fstab 手动编写加了挂载第1个分区到 /boot/firmware； copy了 /boot/firmware 到 这个镜像的第1个分区；copy了 /lib/modules、lib/firmware 到 镜像的第2个分区（root分区，带标签 writable）

@prcups 我现在也改用 6.1内核，目前用下来均正常。按需再定制内核。

我会用docker构建跨平台的镜像，默认内核未开启 CONFIG_BINFMT_MISC，在使用中慢慢弄，也是很好学习的过程。

@prcups 嗯，我网上有查过资料这个卡会有这个问题，新驱动 rtw89 解决了这个问题

@George ok. just suggest for default. I compile and well done.

> lxc-checkconfig
LXC version 5.0.3

--- Namespaces ---
Namespaces: enabled
Utsname namespace: enabled
Ipc namespace: enabled
Pid namespace: enabled
User namespace: enabled
Network namespace: enabled

--- Control groups ---
Cgroups: enabled
Cgroup namespace: enabled
Cgroup v1 mount points: 
Cgroup v2 mount points: 
 - /sys/fs/cgroup
Cgroup device: enabled
Cgroup sched: enabled
Cgroup cpu account: enabled
Cgroup memory controller: enabled
Cgroup cpuset: enabled

--- Misc ---
Veth pair device: enabled, not loaded
Macvlan: enabled, not loaded
Vlan: enabled, not loaded
Bridges: enabled, not loaded
Advanced netfilter: enabled, not loaded
CONFIG_IP_NF_TARGET_MASQUERADE: enabled, not loaded
CONFIG_IP6_NF_TARGET_MASQUERADE: missing
CONFIG_NETFILTER_XT_TARGET_CHECKSUM: enabled, not loaded
CONFIG_NETFILTER_XT_MATCH_COMMENT: enabled, not loaded
FUSE (for use with lxcfs): enabled, not loaded

--- Checkpoint/Restore ---
checkpoint restore: missing
CONFIG_FHANDLE: enabled
CONFIG_EVENTFD: enabled
CONFIG_EPOLL: enabled
CONFIG_UNIX_DIAG: missing
CONFIG_INET_DIAG: missing
CONFIG_PACKET_DIAG: missing
CONFIG_NETLINK_DIAG: missing
File capabilities: enabled

Note : Before booting a new kernel, you can check its configuration
usage : CONFIG=/path/to/config /usr/bin/lxc-checkconfig

Cloudflared 服务对 配置 net.ipv4.ping_group_range 有要求。（看其测试代码验证至少1003）

> sysctl -w net.ipv4.ping_group_range="0 2147483647"

改之前：

>  cat /proc/sys/net/ipv4/ping_group_range
1	0

改之后：

 > cat /proc/sys/net/ipv4/ping_group_range
0	2147483647

目前可以稳定运行超过30分钟了，再观察一阵。

@george 通过另一个 cloudflare tunnel 远程连到 coolpi笔记本上，发现未断开（笔记本上的cloudflare服务从在线管理后台上看有断线过），看起来是 笔记本上安装的 cloudflare服务的问题了。

我后边再看下，也许是网络协议上原因导致cloudflare工作不正常。谢谢～

@george 好的，固件从哪里可以下载？

没有合盖，也连dc电源（合盖会直接休眠了）。 目前断开连接后会过会儿自动重连，大概10～20分钟之间会随机断开。

（刚刚又发生断连了）

@george 是上周淘宝店买的预装的 ubuntu 24.04. （你截图第二个文件）
linux 内核是从这里编译了内核： https://github.com/coolpi-george/coolpi-kernel， 加了一些 网络协议的支持（NFT，dockerd服务必须要开启的）

> lshw
......
  *-network
       description: Wireless interface
       physical id: 12
       bus info: pci@0002:21:00.0
       logical name: wlan1
       serial: c2:4b:24:02:8c:2b
       capabilities: ethernet physical wireless
       configuration: broadcast=yes driver=rtl8852be driverversion=v1.15.10.0.2-1-gef8cc86f5.20220 firmware=N/A link=no multicast=yes wireless=unassociated

使用cloudflared tunnel 实现内网穿透。从cloudflare管理界面看，家里的那台笔记本（cool pi）与cloudflare网络频繁断开，导致我远程连接失败。（可以从cloudflare管理界面看到 笔记本最近一次连接的时间）

如图：上边的为 coolpi笔记本，下边的为另一个设备，也是放家里，在同一个网络。也排查过 coolpi上的cloudflared服务本身未发生重启。

不远程连接，有时候浏览器访问网页也有一定概率提示网页打不开，过会儿刷新重新请求又好了。