>> Wait what does KARL mean here? > > The random kernel re-linking done before first boot and after each > boot (also used as the basis for syspatch kernel updates).
Ah of course. >> And what's the kernel compile time setting, would this be a patch or >> is there some define somewhere? > > It's the "config bsd root on XXXX swap on YYYY" as you'll see in > the RAMDISK kernel configs. Where in the kernel config can I change it, e.g. override the root(+swap+dump) disk setting with device name strings e.g. "sd0a"? (Possibly DUID string could be interesting.) >> > The boot loader uses BIOS IO functions, if those can't talk to the >> > NVME it's not going to work. >> >> I'm not sure but I think that, while some BIOS:es will not do IO with >> the PCIe NVME, then, I think my BIOS (and then of course some other >> peoples') actually does provide access to the NVME SSD, it's just that >> it won't boot from it. >> >> I'd need to debug this much closer though. > > Do "machine diskinfo". If the NVME is listed there, you may have a chance. Thanks, will do depending on how the debugging continues. >> >> This should be a fundamental and trivial usecase to OpenBSD, however, >> >> last time I tried (then with adding a "boot" command to boot.conf per >> >> http://man.openbsd.org/boot.conf ), I think it not worked out of the >> >> box. >> > >> > It might not be very appealing but afaict the only trivial way to do >> > this is to place root on the USB stick or some other device, and other >> > filesystems on NVME. Like Edgar commented, my experience from before is also that using a root filesystem on a USB drive and then mount all directories separately, is a total pain. (Old OpenBSD versions, or installation guides out there, used a partition "/altroot" for this kind of usecase, though it didn't really solve anything?) Just curious, why is it so difficult to get going, why does not any boot.conf command specify to the kernel what root disk to use, so this way you could locate the kernel to a USB memory stick and then boot the remainder of the system from the device that the kernel but not the BIOS can access? >> boot.conf (http://man.openbsd.org/boot.conf) specifies in three or more >> places, ways to change the boot disk. >> >> First, do "boot hd1a:/bsd", next do "machine boot hd1a", next "set device >> hd1a". >> >> Why would all of these three not be effective? > > "boot hd1a:/bsd" tries to load /bsd from BIOS device hd1. > > "machine boot hd1a" tries to boot the PBR (partition boot record) on > the first partition of BIOS device hd1. > > I haven't used "set device" but I guess it would probably set a default > for "boot". > > In all cases this is talking about a device reachable from BIOS. > To access some other device (NVME, USB drive without BIOS support, etc) > you'd need a driver to talk to the device, which isn't available until > the kernel is running, so isn't useful for loading the kernel initially. Presuming that a disk is accessible through the BIOS IO API (per "machine diskinfo"), .. >> E.g. at completion of the OpenBSD installation do: >> >> echo "set device hd1a" >> /mnt/etc/boot.conf >> installboot -r /mnt sd1 ..should this cause boot code to be written to the USB memory stick sd1, to boot the machine from "hd1a"? >> (Here, sd1 is the OpenBSD installer USB memory stick, and, when >> booting from it, hd0 would be the same USB memory stick, and hd1a would >> be the PCIe NVME.) Ah by the way, do the OpenBSD UEFI loaders (bootia32.efi and bootx64.efi) load any boot.conf file off the EFI partition? I'll let you know any more things I learn about if and how the BIOS supports NVME, and how I eventually solve this, hopefully without needing a custom built kernel! Also still I'm not clear that OpenBSD's UEFI loader is supposed to work for this usecase, will try to reduce. Thanks!
