ISO: Boot failures: `md1.uzip: UZIP(zlib) inflate() failed`, kernel panics and `errno EFAULT`

Boot failures: md1.uzip: UZIP(zlib) inflate() failed, kernel panics and errno EFAULT

From opening post https://github.com/helloSystem/ISO/issues/102#issue-787438326

– and from https://github.com/helloSystem/ISO/issues/102#issuecomment-761793443

… a panic with a visible backtrace: …

12.1-RELEASE and 12.2-RELEASE as bases for helloSystem

FreeBSD bug 254318 – [panic] when a specific sequence of read requests is issued to a geom_uzip device the kernel panics

• covers helloSystem boot time system crash and md1.uzip: UZIP(zlib) inflate() failed scenarios.

I might treat helloSystem boot time sudden restarts as symptomatic of system crashes, with possibly the same cause.

13.⋯

Bug 254318 observes:

… On FreeBSD/amd64 13.0-RC2 a different symptom is observed:

• There is no kernel panic, but some of the read requests fail with errno EFAULT even though they should succeed.

On FreeBSD/amd64 14.0-CURRENT (from FreeBSD-14.0-CURRENT-amd64-20210311-15565e0a217-257277-disc1.iso) the behaviour is the same as on 13.0-RC2. …

Advice received via e-mail, quoted without attribution with permission, with added emphasis:

… a controlled environment where you can easily run experiments and will be an experiment in itself:

Install pristine FreeBSD 12.1 on a VM, then after normal multi-user boot try executing the commands that helloSystem executes in its init.sh script.

The most important command is the mdconfig that makes data/system.uzip into a read-only md1 device.

You can read from this device which will force the decompression that fails to happen.

You can try without the ‘zfs recv’ command and even without ‘zfs send’, reading with dd from the md1 device instead.

If you manage to reproduce the issue on pristine FreeBSD, you will get more interest from FreeBSD developers.

You can use the same pristine FreeBSD 12.1 system to try decompressing the .uzip file of many different helloSystem ISO’s which would allow you to see if the problem is data-dependent. …

https://www.freebsd.org/cgi/man.cgi?query=mdconfig&sektion=8&manpath=FreeBSD+12.1-RELEASE+and+Ports

0.4.0 (0D13) and 0.4.0 (0D18)

Booted more than once without error in a VirtualBox guest (0D18).

Mostly without error with an Ergo Vista 631 (0D13 on a USB flash drive).

On the Ergo:

FreeBSD% sudo dmesg | grep rtc
atrtc0: <AT realtime clock> port 0x70-0x71 irq 8 on acpi0
atrtc0: registered as a time-of-day clock, resolution 1.000000s
atrtc0: <AT realtime clock> port 0x70-0x71 irq 8 on acpi0
atrtc0: registered as a time-of-day clock, resolution 1.000000s
FreeBSD% date ; uname -v ; uptime ; pkg query '%o %v %R' hello 
Sun Jan 24 02:54:43 EST 2021
FreeBSD 12.1-RELEASE r354233 GENERIC 
 2:54AM  up 14 mins, 0 users, load averages: 0.45, 0.50, 0.36
helloSystem 0.4.0_0D13 unknown-repository
FreeBSD% 

It would be nice to have OpenZFS but IIRC it’s not packaged where you want it