Closed probonopd closed 1 year ago
dd if=/dev/random of="${uzip}"/random.data bs=1M count=2
in https://github.com/helloSystem/ISO/commit/c0f278e98fe49908ca7024c40ef2de357e7faf1bSo here we have proof that just adding 2 MB of random data to the contents of the uzip prevents the crash.
This can also happen with, e.g., the Developer ISO.
can add normal Setup OS ? (like a Linux with Calamares ?) and, add support Wi-Fi usb-adapter? - rtl8192eu ? and.. why cannot run .appimage apps ? i just double click on apps, and not run... or, appimage not work here?? in bsd? tested on SMplayer (mpv/mplayer)
hello-0.8.0_0H106-FreeBSD-14.0-amd64.iso crashes with guz_zstd_decompress
Reported upstream: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=267082
Lately, more or less all helloSystem ISOs based on FreeBSD 14.0-CURRENT fail:
ping @cemeyer
With makefs -R 16384
and mkuzip
without -s
it did not crash but the resulting ISO was noticeably larger.
So in the commit above I am trying to increase the cluster size again, but using makefs -R
with the same value as the mkuzip -s
value.
Seems to have worked.
So possibly makefs -R
and mkuzip -s
must always be kept at the same value.
If this is the case, then it would be nice if mkuzip would refuse to create files with different -s
values.
FreeBSD CURRENT has more checks (asserts) enabled than RELEASE, which may be the reason why the error appeared in 14-CURRENT but not in 13.1-RELEASE.
With some 14.0-CURRENT based experimental ISOs, we get a kernel panic:
This is the FreeBSD source code in question: https://github.com/freebsd/freebsd-src/blob/627f1555f571b5328637dbfbe441ed89c84db20c/sys/geom/uzip/g_uzip_zstd.c#L81
drm-510-kmod
which is not even loaded yet at the stage where the crash happens)Conclusion: It seems like with some contents or with some size of the contents, the
mdconfig -a -t vnode-o readonly -f /boot/rootfs.uzip
step fails atguz_zstd_decompress
.