Filesystem Size Used Avail Use% Mounted on
/dev/root 141M 141M 0 100% /
devtmpfs 462M 0 462M 0% /dev
tmpfs 654M 0 654M 0% /dev/shm
tmpfs 654M 12K 654M 1% /tmp
tmpfs 654M 220K 654M 1% /run
tmpfs 654M 0 654M 0% /data
media 654M 0 654M 0% /media
/dev/block/platform/by-name/hbre 171M 91M 75M 56% /usr/hobot
/dev/block/platform/by-name/app 673M 166M 487M 26% /app
/dev/block/platform/by-name/private 242K 14K 211K 7% /private
/dev/block/platform/by-name/userdata 28G 564K 26G 1% /userdata
你这块 / 只有 141M 且已 100% 占满，在板端用 fdisk/resize2fs 是扩不出来的：rootfs 的大小写在烧录镜像的分区表里，而且它后面还紧跟着 hbre、app、private、userdata 这几个分区，没有可用空隙。真要给 / 扩容，只能改镜像的分区表后重新打包、重刷整机（各板型的分区定义在 BSP/构建工程里），代价是整机重来。所以先走不用重烧的路：环境装到有空间的 /userdata（26G 可用）。
先确认 141M 被谁吃掉，顺手能回收一点：
sudo du -xh --max-depth=1 / 2>/dev/null | sort -h | tail -n 15
sudo apt clean
常见占用是 /var/cache/apt 和 /var/log。能回收的量有限，别指望靠它装环境。
装环境重定向到 /userdata：
python3 -m venv /userdata/venv && source /userdata/venv/bin/activate
# conda 装到 /userdata/miniconda3；Docker 把 data-root 指到 /userdata/docker
注意 apt 装的系统包落在 /usr，仍然吃 rootfs，这条路解决不了 apt 装大包；pip/conda/Docker 镜像这类放 /userdata 才有效。
要按你板型给分区表文件位置和重打包步骤，告一下板子型号和 cat /etc/version 的输出，我按对应镜像版本说。官方对分区由构建系统定义、需改分区表后重新打包的说明见构建系统开发指南 - 自定义分区说明（S 系列路径，其他板型以各自 BSP 为准）。
你这块是 X5 SDK 的 Buildroot 镜像，/ 就是 system 分区（141M），后面紧跟着 hbre/app/private/userdata，板端 fdisk/resize2fs 扩不出来。官方做法是改 GPT 分区表里 system 的大小，重编 system.img 后 pack 整包、整机重刷（X5 BSP 搭建开发环境及编译说明）。
在主机 BSP 源码里：
./bd.sh lunch # 选 X5 EVB 对应的板级配置（与你现在这版镜像一致）
ls -l device/board_config.mk # 确认实际生效的配置/分区表
vi device/horizon/x5/board_cfg/soc/x5-soc-debug-gpt.json
# 找到 system 项，把 size 改大，例如 "1024m"（单位 MB），其它字段别动
./bd.sh system clean && ./bd.sh system
./bd.sh pack # 产出 out/product/emmc_disk.img
再用 XBurn/fastboot 刷 out/product/emmc_disk.img，烧写方式见系统镜像烧写。
两个会影响操作的细节：system 变大后 hbre/app/private/userdata 的偏移都会后移，所以不能只单刷 system.img，必须整包刷，/userdata 现有内容先备份；分区表有 debug 和 release 两套 json，你板上的分区名与 x5-soc-debug-gpt.json 这套吻合，但仍以 board_config.mk 指向的为准，改到另一套不会生效。官方也明确写了 system 分区超出预设容量时要通过修改分区表调整，见集成用户软件进系统镜像；根文件系统本身由 bd.sh system 生成，见根文件系统适配指南。
不重刷的话，先把环境放到 /userdata（26G 可用），例如 python3 -m venv /userdata/venv && . /userdata/venv/bin/activate；/app 还有 487M 可放程序。装进 /usr 的部分仍然占 system，那就只能走上面的重打包。
{
"gpt": {
"size": "20k"
},
"mbr": {
"size": "4k"
},
"miniboot": "sub_config/miniboot.json",
"misc": {
"size": "4k"
},
"uboot": {
"part_type": "GOLDEN",
"size": "2m"
},
"ubootenv": {
"size": "256k"
},
"vbmeta": {
"part_type": "GOLDEN",
"size": "16k"
},
"boot": {
"part_type": "GOLDEN",
"size": "12m"
},
"system": {
"fs_type": "ext4",
"part_type": "GOLDEN",
"size": "4000m"
},
"hbre": {
"fs_type": "ext4",
"part_type": "GOLDEN",
"size": "200m"
},
"app": {
"fs_type": "ext4",
"part_type": "GOLDEN",
"size": "700m"
},
"private": {
"fs_type": "ext4",
"part_type": "GOLDEN",
"size": "256k"
},
"userdata": {
"fs_type": "ext4",
"size": "50m"
}
}
先别急着重打包：你贴的这套 json 里 system 是 4000m，但板端 / 只有 141M，两者对不上。第一步应是确认 system 分区的实际大小——如果分区本身已是约 4G，只是里面的 ext4 文件系统没长到分区大小，板端一条 resize2fs 就够了，不用重刷。
ls -l /dev/block/platform/by-name/ # 看 system 指向哪个 mmcblk0pX
cat /proc/partitions # 该分区的 1K blocks 数
把 system 对应分区的 blocks 数和 df -h / 的 141M 比：
- 分区明显大于 141M（板端有
resize2fs的话）：在线扩容，ext4 支持挂载状态下 grow
resize2fs /dev/block/platform/by-name/system
df -h /
- 分区本身就只有 141M 左右：才需要改分区表重打包。改哪一份取决于
device/board_config.mk指向的板级配置（ls -l device/可看软链接）：Debug 配置用x5-soc-debug-gpt.json，Release 配置用x5-soc-release-gpt.json，改错那一份不会生效。改完system的size后./bd.sh pack会重新生成 gpt 和out/product/emmc_disk.img（system.img 内容不变；若构建阶段报容量检查失败，再./bd.sh system clean && ./bd.sh system）。system变大后 hbre/app/private/userdata 的偏移全部后移，只能整包刷，/userdata先备份。
官方对“超出预设容量需通过修改分区表调整”、以及 userdata 默认 50MB 由 U-Boot 启动时扩展到剩余空间，见 集成用户软件进系统镜像；bd.sh/pack/emmc_disk.img 见 搭建开发环境及编译说明。
把上面两条命令的输出贴一下，并说下这份 json 的完整路径，我确认它是不是你镜像实际用的那份。
Welcome to Buildroot
buildroot login: root
Password:
root@buildroot:~# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/root 148M 141M 1.2M 100% /
devtmpfs 462M 0 462M 0% /dev
tmpfs 654M 0 654M 0% /dev/shm
tmpfs 654M 12K 654M 1% /tmp
tmpfs 654M 220K 654M 1% /run
tmpfs 654M 0 654M 0% /data
media 654M 0 654M 0% /media
/dev/block/platform/by-name/hbre 171M 91M 75M 56% /usr/hobot
/dev/block/platform/by-name/app 673M 166M 487M 26% /app
/dev/block/platform/by-name/private 242K 14K 211K 7% /private
/dev/block/platform/by-name/userdata 24G 288K 23G 1% /userdata
root@buildroot:~# ls -l /dev/block/platform/by-name/ # system 指向哪个 mmcblk0pX
total 0
lrwxrwxrwx 1 root root 19 Jan 1 00:00 app → ../../../mmcblk0p11
lrwxrwxrwx 1 root root 16 Jan 1 00:00 blk → ../../../mmcblk0
lrwxrwxrwx 1 root root 18 Jan 1 00:00 boot → ../../../mmcblk0p8
lrwxrwxrwx 1 root root 19 Jan 1 00:00 hbre → ../../../mmcblk0p10
lrwxrwxrwx 1 root root 18 Jan 1 00:00 mbr → ../../../mmcblk0p1
lrwxrwxrwx 1 root root 18 Jan 1 00:00 miniboot → ../../../mmcblk0p2
lrwxrwxrwx 1 root root 18 Jan 1 00:00 miniboot_bak1 → ../../../mmcblk0p3
lrwxrwxrwx 1 root root 18 Jan 1 00:00 misc → ../../../mmcblk0p4
lrwxrwxrwx 1 root root 19 Jan 1 00:00 private → ../../../mmcblk0p12
lrwxrwxrwx 1 root root 18 Jan 1 00:00 system → ../../../mmcblk0p9
lrwxrwxrwx 1 root root 18 Jan 1 00:00 uboot → ../../../mmcblk0p5
lrwxrwxrwx 1 root root 18 Jan 1 00:00 ubootenv → ../../../mmcblk0p6
lrwxrwxrwx 1 root root 19 Jan 1 00:00 userdata → ../../../mmcblk0p13
lrwxrwxrwx 1 root root 18 Jan 1 00:00 vbmeta → ../../../mmcblk0p7
root@buildroot:~# cat /proc/partitions # 该分区的 1K blocks 数
major minor #blocks name
1 0 409600 ram0
1 1 409600 ram1
1 2 409600 ram2
1 3 409600 ram3
1 4 409600 ram4
1 5 409600 ram5
1 6 409600 ram6
1 7 409600 ram7
1 8 409600 ram8
1 9 409600 ram9
1 10 409600 ram10
1 11 409600 ram11
1 12 409600 ram12
1 13 409600 ram13
1 14 409600 ram14
1 15 409600 ram15
31 0 524288 mtdblock0
179 0 30535680 mmcblk0
179 1 4 mmcblk0p1
179 2 2304 mmcblk0p2
179 3 2304 mmcblk0p3
179 4 4 mmcblk0p4
179 5 2048 mmcblk0p5
179 6 256 mmcblk0p6
179 7 16 mmcblk0p7
259 0 12288 mmcblk0p8
259 1 4096000 mmcblk0p9
259 2 204800 mmcblk0p10
259 3 716800 mmcblk0p11
259 4 256 mmcblk0p12
259 5 25498563 mmcblk0p13
179 8 4096 mmcblk0boot0
179 16 4096 mmcblk0boot1
root@buildroot:~# resize2fs /dev/block/platform/by-name/system
resize2fs 1.46.5 (30-Dec-2021)
Filesystem at /dev/block/platform/by-name/system is mounted on /; on-line resizing required
old_desc_blocks = 1, new_desc_blocks = 1
resize2fs: Read-only file system While checking for on-line resizing support
root@buildroot:~# df -h /
Filesystem Size Used Avail Use% Mounted on
/dev/root 148M 141M 1.2M 100% /
root@buildroot:~#
分区本身够大，不用改 json 重打包：/proc/partitions 里 system（mmcblk0p9）是 4096000 个 1K block ≈ 4000MB，和你那份 json 的 4000m 对得上。现在 / 只有 148M，是这个分区里的 ext4 文件系统从没扩到分区大小，不是分区太小。
resize2fs 失败的关键是那句 Read-only file system：/ 当前被当成只读挂载，在线扩容就被拒了。先看挂载选项，再挂成可写重跑：
cat /proc/mounts | grep ' / ' # 这一行同时给出 / 的设备名和 ro/rw
mount -o remount,rw /
resize2fs /dev/block/platform/by-name/system
df -h /
预期 / 从 ~148M 变成接近 3.9G，装环境就有空间了。
两种需要留意的后续：若这一行本来就显示 rw、重试仍报同样的只读错误，说明在线扩容这条路走不通，得换一套可写的 root（例如从 SD 卡启动另一套系统）对 mmcblk0p9 做离线 resize2fs；若只读是镜像挂载设计写死的，重启后会回到只读，往 /usr 装的东西不保留，那类环境放 /app（487M）或 /userdata 更省事。把上面那条 mount 输出贴一下就能确认走哪条。
分区表定义、以及 userdata 默认 50MB 由 U-Boot 启动时扩展到剩余空间可对照 集成用户软件进系统镜像。