cyric UEFI boot?

tsoome: yes

does it also have BIOS boot for test?

tsoome: is there a way to completely disable the vesa framebuffer on pre-uefi systems and just stick with the default vga text mode?

yes, I think it was -t to /boot/config

should double check...

yes, gptzfsboot(7): -t Keep the VGA text mode for loader(7).

tsoome: sadly it won't allow me to change it to BIOS: "ACPI motherboard layout requires EFI"

cyric ok, in that case, could you get output from memmap from loader ok prompt?

tsoome: so it's just 'echo -t > /boot/config' then?

yes, gptzfsboot does read it and will pass -t to loader

fascinating

the original location actually was #define PATH_DOTCONFIG "/boot.config", then #define PATH_CONFIG "/boot/config" was added, and tbh, we should really clean it and remove PATH_DOTCONFIG:) but it is not on the way and it is not like high priority...

cyric the problem about memory maps is that illumos kernel is expected to be in specific location and if it so happens that UEFI will put something vital there, then Bad Things will happen.

it may or may not be related to 17749, but it is one thing we can check. Another check is to boot with: ok boot -k -B prom_debug=true,kbm_debug=true and see where the crash will happen (hoping that there will be some output). In any case, since there is no kernel banner printed, the crash definitely does happen early enough.

It may also be related to illumos 17699 (fenix) if the hypervisor is advertising RDSEED but not emulating the MSR to disable it.

BUG 17699: Disable RDSEED on vulnerable Zen5 processors (Closed)

↳ illumos.org/issues/17699 | code.illumos.org/c/illumos-gate/+/4429

tsoome: i tried taking (high fps) video and that's the last thing i see (it even has vmware logo that shows on reset): pasteboard.co/RFKHXIYWZpKH.jpg

andyf: it was working with 17699 integrated, i bisected and double-checked that intel microcode update is somehow a problem

tsoome: and here is the memmap output: pasteboard.co/95KqTdnUtcWy.png and pasteboard.co/8IEhhwdPUfsj.png

cyric last thing is hash check? try: ok disable-module-option boot_archive.hash and then boot

if it does work, then bootadm update-archive -f

tsoome: tells me "disable-module-option not found"

sec..

sorry, its disable-module

(and show-module-options)

krtld: failed to open '/platform/i86pc/kernel/amd64/unix'

krtld: bind_primary(): no relocation information found for module /platform/i86pc/kernel/amd64/unix

so, it appears, your boot_archive is damaged.

krtld: error during initial load/link phase

you can try to boot with previous BE (pick one from BE menu)

then beadm mount NEWBE /mnt; bootadm update-archive -R /mnt -f; beadm umount /mnt ; reboot

did that, same issue

if you mount new be to /mnt, compare file sizes ls -l /platform/i86pc/amd64/boot_archive /mnt/platform/i86pc/amd64/boot_archive

they should differ, but not too much...

working 84796291, broken 92768563

hm, ok, gzcat /mnt/platform/i86pc/amd64/boot_archive | digest -a sha1 and compare the result with /mnt/platform/i86pc/amd64/boot_archive.hash content

matches

so the file is good...

boot to ok prompt, enter: ok start but press space to stop the boot. then lsmod -s and compare hashes of boot_archive and from boot_archive.hash

I suppose, they do match as well

yes, they do

so apparently the boot_archive content is getting changed during/after it was copied to final location...

the screenshot tells us its location is 0x10000000 - 0x19240000

just a note that if i build with microcode update reverted, all is good

full clean builds just to be sure (git clean -fdx)

well, the boot_archive did grow and whatever does change the memory there, it does touch the area now...

does your system enable something like boot from network?

from memory map, this memory area, occupied by boot_archive, should be unused....

of course, memory map can change while we are switching boot services off...

it's a vm so there's not really much i could/did enable

right.

tsoome: i have removed some intel ucode files from the be that was failing to boot, and now it's ok, so yes, it's not microcode itself, rather the size of boot_archive

made it back to ~84000000

with vmware it should be possible to find out what is making the change in that memory area -- attach to gdb stub and check the content to find the changed offset and then its about setting up the watch....

but it definitely is nasty situation in many ways.

Starting from the fact that once we do switch Boot Services off, we should own the memory.

oh