Re: Installworld: rescue/sh check failed, core dumped

On Jun 2, 2025, at 12:01, bob prohaska <[email protected]> wrote:

> A pair of Pi2 (armv7) hosts running current have refused to
> installworld after what looks like successful buildworlds. 
> 
> The tail of buildworld's log file reports:
> make[1]: /usr/obj/usr/src/arm.armv7/toolchain-metadata.mk:1: Using cached toolchain metadata from build at www.zefox.org on Mon Jun  2 10:13:09 PDT 2025
> --- __installcheck_UGID ---
> --- __installcheck_sh_check ---
> Bad system call (core dumped)
> rescue/sh check failed, installation aborted
> 
> The two hosts have been successfully building and installing world/kernel
> for some months. This error is new to me, if it's self-inflicted please
> tell me what I did wrong. Git pull finds no updates that look related.
> 

Do you strictly follow the recommend ordering that does kernel
(builds/)installation that /usr/src/UPDATING has for:

QUOTE
 	To rebuild everything and install it on the current system.
        -----------------------------------------------------------
        # Note: sometimes if you are running current you gotta do more than
        # is listed here if you are upgrading from a really old current.

        <make sure you have good level 0 dumps>         [2]
        make buildworld
        <make sure any needed PORTS_MODULES are set>    [1]
        make buildkernel KERNCONF=YOUR_KERNEL_HERE
        make installkernel KERNCONF=YOUR_KERNEL_HERE
        <reboot in single user>                         [3]
        etcupdate -p                                    [5]
        make installworld
        etcupdate -B                                    [4]
        make delete-old                                 [6]
        <reboot>
END QUOTE

Note the installation of the updated kernel and the
reboot to have that kernel in use before the
installation of the new world. That is what allows
the installation of and (partial) operation of the
new world to use new system calls.

After rebooting again, only code from the new world
is in use, as all processes are started from scratch.

Starting the new world without having booted the
new kernel would not have any new system calls
(or new changes) available for use by the new world.

Note also the new kernel boot is for "single user"
mode. This minimizes what of the old world is active
during the new world's installation, leaving fewer
chances for conflicts.


As for what commits are related to the changed system
calls:

Sat, 31 May 2025
. . .
    • git: 2761de0832c1 - main - kern: add extended errors support Konstantin Belousov 
    • git: 09dfe066f00c - main - kernel: copyout extended errors to userspace and add exterrctl(2) to control it Konstantin Belousov 
    • git: 92b393c0d287 - main - libsys: export exterrctl symbol Konstantin Belousov 
    • git: d995dc937a3c - main - vm/vm_mmap.c: add two examples of using exterrors Konstantin Belousov 
    • git: 7212b3734593 - main - kinfo_proc: report address of extended kernel error structure Konstantin Belousov 
    • git: b9c8a07d4dd9 - main - C runtime: enable extended error reporting from kernel Konstantin Belousov 
    • git: 98af94cae78a - main - sysconf(3): add _SC_UEXTERR_LEN, the max length of the extended error string Konstantin Belousov 
    • git: a56fe703c206 - main - Provide user interface to retrieve reported extended errors Konstantin Belousov 
    • git: 8e8d3068dcbe - main - amd64 GENERIC: enable bloating kernel with ext errors strings Konstantin Belousov 
    • git: bfe9e97a23af - main - Regen Konstantin Belousov 
    • git: 970a71e1ef9a - main - Rename BLOW_KERNEL_WITH_EXTERR to BLOAT_KERNEL_WITH_EXTERR Konstantin Belousov

Quoting Konstantin Belousov:

"The UPDATING way of update must be followed to letter with the exterr feature."

===
Mark Millard
marklmi at yahoo.com