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=flowed

OK 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 message
on 13.5. I've since made a 16-CURRENT from the kernel,base and lib32 archives
that 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

Attachment: 0xE512722F.asc
Description: application/pgp-keys

Reply via email to