On 2025-12-09 23:35, Chris wrote:
On 2025-12-09 22:34, Cy Schubert wrote:In message <[email protected]>, Chris writes:--=_1fa5024c3e762cfee18202d6a7376470 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowedOK because I know you're going to ask... :-) framework 13 laptop (MSI Crosshair 18 HX AI A2XWGKG-012US)[1],[2] CPU: Intel Core Ultra 9 Processor 275HX [3] GPU: NVIDIA GeForce RTX 5070 Laptop GPU with NVIDIA Optimus supported [4] LAN: Realtec RTL???? 2.5Gb WiFi: Intel Wi-Fi 6E AX211(2*2 ax) I'm currently unable to boot any of 13.5,14.n,15.n or 16 on this laptop. On 13.5 it hangs on sc (syscons(4)?) connect...Add this, kern.vty=vt to your loader.conf.Really appreciate your taking the time to reply, Cy. Just tried this. But same results. FWIW, I only saw the syscons messageon 13.5. I've since made a 16-CURRENT from the kernel,base and lib32 archivesthat were on ftp.freebsd.org (now missing).If you look at the sc(4) man page you will notice,I know. :)As to how I got my Framework 13 (with AMD chipset) installed, I cloned FreeBSD, including all data, from my HP 840, also running in UEFI mode, changing fstab and rc.conf to customize a few things before booting the Framework laptop. (The HP 840 also uses kern.vty=vt.)Close to what I did to get 16 on my framework 12. All the right bits weren't yet available at that time. All good now tho.
OK after booting 13.5-16 FreeBSD and all the BSD versions I could find. They all ended at either: sc0 failed to probe on isa0 or atrtc1 : Warning: Couldn't map I/O. Which seemed to me, that I simply lost the CON at that point. So since it rebooted some 3 seconds after that point. I looked at the dmesg.boot on my framework 12 to see if I might determine where/what triggered the reboot. Looked like it might be the nvme. So spun up a live Ubuntu image. It gave me a desktop and a dmesg[1]. But no nvme drive! The drive options in the UEFI are fairly basic. Turns out the drive is handled by the Intel VMD Controller. Neither Linux nor BSD understand/have drivers for the VMD Controller. Only Windows. Interestingly, rEFIt[2] does. So I found a keyboard macro that exposes some 300+ additional options/sub-options: ~200+ CPU / ~100+ arbitration and turned off the VMD Controller in the CPU. Now Linux sees and will manage the drive if I ask it to. On a hunch, I decided to give OpenBSD a try. Booted perfectly[3] w/o any problems! Would happily install to the drive if asked to! When did OpenBSD become more advanced than FreeBSD? Here's hoping that the 2 dmesg files attached will help isolate the problem. I'll happily perform any additional tasks requested. Thanks for all your time and consideration! --Chris
To boot the Framework from install media, break to the loader prompt and type in, kern.vty=vt Then boot. Install FreeBSD. Finally, make sure kern.vty=vt is in the installed image's loader.conf before rebooting the image. Hope this helps.
-- There is no such place as the internet
0xE512722F.asc
Description: application/pgp-keys
