08:04:30 cyric UEFI boot? 09:04:17 tsoome: yes 10:01:12 does it also have BIOS boot for test? 10:03:46 tsoome: is there a way to completely disable the vesa framebuffer on pre-uefi systems and just stick with the default vga text mode? 10:07:17 yes, I think it was -t to /boot/config 10:07:24 should double check... 10:08:32 yes, gptzfsboot(7): -t Keep the VGA text mode for loader(7). 10:08:38 tsoome: sadly it won't allow me to change it to BIOS: "ACPI motherboard layout requires EFI" 10:09:16 cyric ok, in that case, could you get output from memmap from loader ok prompt? 10:10:36 tsoome: so it's just 'echo -t > /boot/config' then? 10:11:49 yes, gptzfsboot does read it and will pass -t to loader 10:12:02 fascinating 10:15:15 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... 10:17:33 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. 10:21:00 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. 10:22:14 It may also be related to illumos 17699 (fenix) if the hypervisor is advertising RDSEED but not emulating the MSR to disable it. 10:22:15 BUG 17699: Disable RDSEED on vulnerable Zen5 processors (Closed) 10:22:15 ↳ https://www.illumos.org/issues/17699 | https://code.illumos.org/c/illumos-gate/+/4429 12:55:00 tsoome: i tried taking (high fps) video and that's the last thing i see (it even has vmware logo that shows on reset): https://pasteboard.co/RFKHXIYWZpKH.jpg 12:55:40 andyf: it was working with 17699 integrated, i bisected and double-checked that intel microcode update is somehow a problem 13:04:12 tsoome: and here is the memmap output: https://pasteboard.co/95KqTdnUtcWy.png and https://pasteboard.co/8IEhhwdPUfsj.png 16:36:30 cyric last thing is hash check? try: ok disable-module-option boot_archive.hash and then boot 16:38:02 if it does work, then bootadm update-archive -f 17:11:05 tsoome: tells me "disable-module-option not found" 17:11:33 sec.. 17:12:01 sorry, its disable-module 17:12:24 (and show-module-options) 17:13:11 krtld: failed to open '/platform/i86pc/kernel/amd64/unix' 17:13:47 krtld: bind_primary(): no relocation information found for module /platform/i86pc/kernel/amd64/unix 17:14:16 so, it appears, your boot_archive is damaged. 17:14:23 krtld: error during initial load/link phase 17:14:38 you can try to boot with previous BE (pick one from BE menu) 17:15:15 then beadm mount NEWBE /mnt; bootadm update-archive -R /mnt -f; beadm umount /mnt ; reboot 17:17:43 did that, same issue 17:19:59 if you mount new be to /mnt, compare file sizes ls -l /platform/i86pc/amd64/boot_archive /mnt/platform/i86pc/amd64/boot_archive 17:21:01 they should differ, but not too much... 17:22:31 working 84796291, broken 92768563 17:25:28 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 17:26:21 matches 17:26:32 so the file is good... 17:28:08 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 17:28:20 I suppose, they do match as well 17:29:15 yes, they do 17:30:38 so apparently the boot_archive content is getting changed during/after it was copied to final location... 17:33:00 the screenshot tells us its location is 0x10000000 - 0x19240000 17:33:30 just a note that if i build with microcode update reverted, all is good 17:33:57 full clean builds just to be sure (git clean -fdx) 17:42:20 well, the boot_archive did grow and whatever does change the memory there, it does touch the area now... 17:43:03 does your system enable something like boot from network? 17:44:10 from memory map, this memory area, occupied by boot_archive, should be unused.... 17:45:50 of course, memory map can change while we are switching boot services off... 17:50:09 it's a vm so there's not really much i could/did enable 17:50:18 right. 18:02:29 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 18:02:47 made it back to ~84000000 18:31:07 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.... 18:32:55 but it definitely is nasty situation in many ways. 18:34:38 Starting from the fact that once we do switch Boot Services off, we should own the memory. 18:45:33 oh