15:17:48 <justinw> Hi! Does anyone have any experience getting RHEL9 based distros (Rocky, specifically) to boot as a bhyve hvm on smartos? Would someone mind looking at this vmadm get and tell me if I'm doing something dumb? (vmadm get: https://pastebin.com/W7rx6SNc // booting with: vmadm boot 669bfb47-bdc5-6cd3-efa2-c26ac1ff9c96 order=cd,once=d cdrom=/Rocky-9.1-x86_64-minimal.iso,ide)
15:18:13 <justinw> Over vnc, I get a uefi prompt where it looks like there's only one storage device but I'm really not sure next steps for uefi debugging. :( 
15:19:14 <justinw> Mapping table BLK0: Alias(s) PciRoot(0x0)/Pci(0x4,0x0) ... i'd think with the disk and iso there should be two things? 
15:20:32 <justinw> Oh okay, looks like Pci(0x4,0x0) is the virtio disk 0 and its just not picking up the CD.
15:21:06 <justinw> Do I have to specify in the vmspec json that the machine has a cdrom drive, maybe?
15:47:37 <justinw> Same behavior w/ Debian 11 netinstall ... so I think I'm just doing something dumb. :(
20:17:44 <bahamat> justinw: Start with this: https://github.com/TritonDataCenter/mi-centos-hvm/
20:32:06 <pmooney> how many folks are running smartos under modern qemu/kvm/ovmf?
20:32:57 <pmooney> I just updated my (linux) hypervisor, and now a smartos guest is griping about the garbage smbios info it's getting from that qemu/ovmf combo
20:33:02 <bahamat> We've moved our jenkins agents to running in bhyve instead of kvm.
20:33:31 <bahamat> I've never run it under linux kvm.
20:33:33 <pmooney> the fields for the cpu information have some garbage in them, which makes its way through sysinfo to vminfod, which goes into maintenance
20:33:47 <bahamat> How garbage is it?
20:34:04 <pmooney> "CPU Type": "\x01",
20:34:43 <bahamat> Maybe I need to do something like this? https://github.com/TritonDataCenter/smartos-live/commit/27dee23aaa6837651d8c1d1a376f308344100aca
20:34:54 <bahamat> OS-8428
20:34:55 <jinni> https://smartos.org/bugview/OS-8428
20:35:26 <bahamat> So back story on that, illumos#13560 changed how smbios expresses non-printable characters.
20:35:27 <jinni> https://www.illumos.org/issues/13560
20:35:53 <bahamat> And sysinfo just mostly tries to take a bare string and put quotes around it, which isn't always valid JSON encoded text.
20:36:02 <pmooney> yeah
20:36:21 <bahamat> So in OS-8248 I JSON.stringify()'d those strings.
20:36:21 <jinni> Sorry, OS-8248 is not public.
20:36:34 <bahamat> 8428, even
20:36:53 <bahamat> So maybe I need to do that in more places?
20:37:07 <pmooney> probably anywhere data is being emitted from smbios?
20:38:20 <pmooney> CPU_Version looks like the one straggler
20:38:48 <bahamat> But yours is hanging up on CPU_Type?
20:39:05 <bahamat> Oh, but that's just CPU_Version
20:39:09 <pmooney> Pardon, CPU_Version is the variable name used in the script
20:39:11 <pmooney> yeah
20:39:22 <bahamat> Yeah, ok.
20:39:48 <bahamat> vendor also
20:40:59 <bahamat> Ok, I'll get to that on Monday.
20:41:20 <pmooney> vendor isn't being emitted as part of the json, though
20:41:22 <pmooney> I don't think
20:41:55 <bahamat> Oh, ok, yeah that's just used to check if it's bhyve.
20:42:01 <bahamat> I don't see vendor referenced anywhere else.
20:43:14 <bahamat> If you're in a hurry, and you want to do a PR, I'll fast track it for you (not to dump work on you...)
20:43:55 <bahamat> But otherwise, we just had a release, so I can get you a build early next week.
20:46:22 <bahamat> Sorry about that. I had wondered about CPU_Vendor at the time. I should have just done it along with the rest of them.
20:50:36 <bahamat> If you want to try hotpatching it, I think this will fix it: https://gist.github.com/afb15c96135162e1f93d7e29613da268
20:52:44 <pmooney> that function doesn't output the bits directly
20:52:47 <pmooney> it just sets variables for later use
20:52:51 <pmooney> AFAICT
20:53:09 <bahamat> Yeah, but that's all we need.
20:53:33 <pmooney> will it not be also emitted by output_parsable()"
20:53:34 <bahamat> Once it's strigified, it'll be valid later.
20:53:35 <pmooney> ?
20:54:03 <pmooney> oh, pardon, you're evaling that
20:54:04 <pmooney> yeah
20:54:09 <bahamat> Yeah.
20:57:20 <bahamat> OK, I have a branch here: https://github.com/TritonDataCenter/smartos-live/commit/3d775ed6c7ba3c0ca317dee998197aee93575264
20:57:57 <bahamat> If you can verify that works, I'll get that merged in on Monday, and I can cut a build for you if you'd like.
21:01:23 <pmooney> seems to work
21:01:30 <bahamat> OK, cool.
21:01:34 <pmooney> the sysinfo caching means I don't even need the overlayed version
21:01:44 <pmooney> since the "real" sysinfo just uses the cached version, haha
21:01:46 <pmooney> *cached data
21:01:57 <bahamat> Oh, that's right. Yeah, we did that last time I tested it.
21:02:05 <pmooney> I personally don't need a special build
21:02:19 <pmooney> there's been enough drama lately
21:02:43 <bahamat> Also kind of makes testing it a pain in the ass, because when I was running it repeatedly I had to hack up sysinfo so that it *wouldn't* read or write the cache.
21:02:51 <pmooney> yeah
21:03:47 <bahamat> Ok, smartos-live#1068
21:03:47 <jinni> https://github.com/TritonDataCenter/smartos-live/issues/1068
21:04:03 <bahamat> Can you put a comment there that you tested it and it fixed the issue for you?
21:11:14 <justinw> bahamat: thanks i'll check that out! 
21:15:45 <pmooney> bahamat: added some commentary to the PR
21:16:12 <bahamat> Perfect, thanks!
21:16:40 <pmooney> thanks for looking at it on a saturday
21:17:04 <bahamat> Well, luckily it was one I had remembered from just a few weeks ago.
21:17:25 <bahamat> Having already worked it out then, the fix was simple.
21:17:48 <bahamat> You're just lucky you caught me when I happened to be at my computer.