03:13:04 <jclulow> tsoome: Sorry, should be unstuck now.
04:34:15 <gitomat> [illumos-gate] 16738 viona should allow configurable packet padding -- Patrick Mooney <pmooney⊙pc>
06:44:20 <tsoome> jclulow thanks!:)
14:28:32 <jimklimov> :)
14:28:34 <jimklimov> +
14:28:37 <jimklimov> +1
15:46:47 <Kurlon_> Playing with some old hardware is kicking my arse. IBM X3550 M3, maxed out with dual X5690 cpus, 288GB RAM, and an LSI 1068E flashed to IT mode with 8 x 120GB Samsung 850 Pros. A solid box for 15yrs ago. I can boot an Omni install stick, make an rpool, install, all is good.
15:47:40 <Kurlon_> I can't get it to boot the install. Box is UEFI, no secureboot, and when I look for a bootloader I can find EFI directories, but no actual boot files?
15:48:55 <Kurlon_> When I'm in OmniOS, I don't know how to find /EFI/Boot to poke at it.
15:59:40 <jbk> i don't think any of the distros mount it on the running system by default
16:00:15 <jbk> if you look at your boot pool (most likely rpool) and the disk(s) in it
16:00:27 <jbk> it's probably slice 0
16:02:23 <jbk> the installer (I'm guessing it's just running 'installboot') should just stick bootx64.efi in \efi\boot...
16:02:35 <jbk> though I have seen where other OSes (like redhat) muck up the efi env vars
16:02:53 <jbk> i think even off the ISO, if you drop to the bootloader (hit esc)
16:03:07 <jbk> you should be able to examine the variables to see what they are
16:03:14 <Kurlon_> Based on Ubuntu not being able to add an entry to the bootorder, I'm guessing the efi vars are garbo on this box.
16:03:25 <andyf> Kurlon_ - Something like https://gist.github.com/citrus-it/66e7b3cfaccb1082818c1222657f0492
16:03:42 <jbk> if tsoome is around, he probably knows better than anyone how to mess w/ those from the bootloader
16:05:01 <andyf> On that example VM, the hypervisor doesn't provide nvram so UEFI ends up storing the variables in the `NvVars` file in that partition.
16:06:02 <andyf> If it's a bhyve VM on OmniOS, you can reset the variables with `zadm efireset <zone>`
16:06:30 <jbk> IIRC, you define the EFI applications to run as BootNNNN (i.e. 'Boot0000=<UEFI device path>/File(\EFI\Boot\bootx64.efi)
16:06:44 <jbk> (it _must_ by 4 digits long)
16:07:32 <jbk> and then there's a 'BootOrder' variable that defines the order to try the entries (e.g. BootOrder=0000,0001,....)
16:09:41 <jbk> if you can boot to a UEFI shell, you can use 'map -b' (-b paginates the results) to see what devices are there -- any UEFI boot partitions it sees will show up as FS0, FS1, etc
16:10:15 <jbk> you can switch to them (e.g. 'fs0:' -- the uefi shell feels a lot like command.com :P)
16:10:24 <jbk> use dir
16:10:25 <jbk> etc
16:10:32 <jbk> cd \efi\boot
16:10:37 <jbk> and if you can see the bootx64.efi
16:10:40 <jbk> you can run it from there
16:14:13 <Kurlon_> A built in UEFI shell would be so nice... got one on a stick around here somewhere.
16:14:47 <jbk> it depends on the manufacturer -- a lot of times it's included as a part of the UEFI firmware image
16:15:14 <Kurlon_> Sadly neither IBM nor HP bothered on this generation of server.
16:16:28 <tsoome> we usually do not mount ESP, this is because in server environment, you have redundant disks in boot pool and then you have ESP in each of them (to make it possible to boot from alternate disk)
16:17:10 <tsoome> and our current setup is refreshing boot blocks/programs  on each boot pool disk automatically based on version information
16:31:29 <Kurlon_> Ok, IMM kinda functioning, got remote console over telnet, web int won't get past login.
16:41:31 <Kurlon_> And... need an old browser 'cause modern ones don't allow secure session cookies over http.
16:42:26 <Kurlon_> Need an old util to generate a cert and get https going
17:44:34 <Kurlon_> Ok, remote console working, now to poke.
17:48:34 <Kurlon_> andyf: No valid FAT on slice 0 on any of my disks.
17:49:52 <Kurlon_> Doing a clean install, one disk, to see what things look like.
17:51:43 <Kurlon_> Clean install letting the installer make rpool, no valid FAT on slice 0.
17:53:19 <Kurlon_> UEFI shell next, see what it's view of the world is.
17:58:13 <andyf> Well that's strange, assuming you left UEFI selected in the installer. I forget exactly what the option shows up as but it's the default.
18:02:43 <Kurlon_> I'm not getting a choice, I'm getting the older installer, dd iso to thumbstick is the only method I've had boot fully.
18:04:01 <Kurlon_> UEFI shell, it sees the EFI part on the disk, has EFI and Boot dirs, but no boot loader file.
18:09:37 <jclulow> "zpool create -B ..." is the thing that makes the ESP (FAT) slice, right
18:09:49 <jclulow> at pool creation time
18:10:59 <jclulow> If you "pfexec fstyp /dev/dsk/c1t0025385C9150D623d0s0" (or similar, with s0 at the end) you should see "pcfs"
18:11:07 <jclulow> for "s1" you should see "zfs"
18:11:32 <jclulow> If not, something has definitely gone awry
18:11:45 <gitomat> [illumos-gate] 16884 viona TSO should better handle csum offloads -- Patrick Mooney <pmooney⊙pc>
19:40:38 <Kurlon_> So, created rpool using -B, fstyp s0 is unknown, s1 is zfs.
19:43:45 <Kurlon_> Ok, now it's showing pcfs post install.
19:48:56 <Kurlon_> Boot entry did not get created.
19:49:29 <Kurlon_> But, I've got bootx64.efi this time.
19:52:00 <Kurlon_> And I'm in.
19:53:00 <Kurlon_> And my horrible bnx eth is working.
21:24:57 <richlowe> tsoome: does -B create and format the ESP, or just create it?
21:25:07 <jbk> it just creates the partition
21:26:03 <jbk> you still have to mkfs it or i think installboot might do it
21:26:17 <jbk> actually looking at installboot, it does appear it will mkfs the ESP partition if needed
21:26:26 <richlowe> ok, that should explain the "unknown" from fstyp then
21:26:32 <richlowe> it really would be, at that point
21:26:57 <richlowe> rather than something having gone wrong, and then fixed itself