On 2025/7/8 23:32, Gao Xiang wrote:
On 2025/7/8 23:22, Jan Kiszka wrote:
On 08.07.25 17:12, Gao Xiang wrote:
Hi Jan,
On 2025/7/8 20:43, Jan Kiszka wrote:
On 08.07.25 14:41, Jan Kiszka wrote:
Hi all,
for some days, I'm trying to understand if we have an integration issue
with erofs or rather some upstream bug. After playing with various
parameters, it rather looks like the latter:
$ ls -l erofs-dir/
total 132
-rwxr-xr-x 1 1000 users 132868 Jul 8 10:50 dash
(from Debian bookworm)
$ mkfs.erofs -z lz4hc erofs.img erofs-dir/
mkfs.erofs 1.8.6 (trixie version, but same happens with bookworm 1.5)
Build completed.
------
Filesystem UUID: aae0b2f0-4ee4-4850-af49-3c1aad7fa30c
Filesystem total blocks: 17 (of 4096-byte blocks)
Filesystem total inodes: 2
Filesystem total metadata blocks: 1
Filesystem total deduplicated bytes (of source files): 0
Now I have 6.15-rc5 and a defconfig-close setting for the 32-bit ARM
target BeagleBone Black. When booting into init=/bin/sh, then running
# mount -t erofs /dev/mmcblk0p1 /mnt
erofs (device mmcblk0p1): mounted with root inode @ nid 36.
# /mnt/dash
Segmentation fault
Two extra quick questions:
- If the segfault happens, then if you run /mnt/dash again, does
segfault still happen?
- If the /mnt/dash segfault happens, then if you run
cat /mnt/dash > /dev/null
/mnt/dash
does segfault still happen?
Thanks,
Gao Xiang
