13:14:24 it was on a dell box, and the only USB would be the virtual devices from the DRAC card (which historically in BMCs have had absolutely terrible implementations).. I'm wonder if it was maybe related to the console timing out or such.. 14:14:23 hrm... 14:15:02 if I ssh + sudo, it seems that the pty's winsize isn't preserved 14:15:24 I have to manually resize slightly for the system to recognize the size 14:15:35 (I noticed less wasn't outputting correctly)... 14:46:27 [illumos-gate] 17437 Want explicit umc_cs_flags_t enum -- Luqman Aden 18:51:13 jbk: for loader? or? 18:51:29 you can see in loader properties how big loader things the console tty is 18:51:32 thinks* 19:03:41 no, ssh 19:03:55 to loaded OS 19:04:07 (annoyingly we don't ship 'resize') 19:05:25 i haven't looked yet to see how sudo creates the new pty, presumably there should be a way to 'inherit' the current values, but i've not done too much in the area, and it's been long enough, I've long since forgotten what I did know :) 19:05:57 (or if not, maybe it's something with sudo not carrying them over) 19:06:08 hrm.. 19:06:13 64/4/0 PCIe Gen 1x4294967295 pcieb8 Unknown device: 0x347c 19:06:25 a very wide bus? :) 19:06:32 or many lanes 19:09:21 finally, something fast enough for the folks who want CXL 19:12:04 annoyingly that's (obviously) not in our current pci db, though it looks like maybe it's an ice lake controller (from pcisig.com) 19:18:12 jbk https://github.com/citrus-it/omnios-build/blob/master/build/sudo/files/_omnios_nopty for sudo, perhaps. 19:18:45 and -1 lanes.. fun 19:19:43 andyf: aha! thanks 19:22:04 Looks like we deliver that file in /etc/sudoers.d/ 19:53:35 andyf: always the pessimist, glass half -1 rather than glass half 0xffffffff 20:08:08 Whaddya mean richlowe? -1 != 4294967295 20:09:02 (oh... I see... should've scrolled up...) 20:09:39 (or gotten my head out of {,u}int64_t land.) 20:13:43 [data stack has 1 entries, top at 0x0000000000f8ddf8] 20:13:44 [0x0000000000f8ddf8 0]: 4294967295 (0x00000000ffffffff) 20:13:45 :) 20:23:46 hrm.. i should file a bug so that disk_label.so will show a GPT with more than 16 entries (even if most are unused) 20:24:16 IIRC, parted writes out 128 entries by default 20:24:27 (as an example) 20:25:55 or hrm.. it defines it a bit strange, but more than the minimum 20:40:08 essentially, the correct number is recorded in GPT (efi_gpt_NumberOfPartitionEntries), 128 is minimum (32 x 512B sectors for partition entry array per specification), but one can allocate more space for that array;) 20:43:12 sommerfeld: I have a prototype idmap appearing to work, now to do it properly 20:44:09 yeah, it only works for the minimum though 20:46:20 our "default" is basically coming from vtoc (dkio) translation (even if VTOC_16 can have 16 slices) 20:49:39 we make our GPT a bit larger than the default so that the backup label will _start_ on an aligned (usually 8 blocks/4k) LBA 20:50:07 because stuff like parted and some other stuff (esp on Linux) get really, really, upset if you leave unallocated space at the end of the disk 20:50:41 and things like TCG Opal drives very often require your locking ranges to have 4k alignment (even on 512b disks) 20:51:06 (this way there's no danger of a partition going past the end of a locking range) 20:54:14 in https://code.illumos.org/c/illumos-gate/+/3738 I did pick the OpenZFS suggestion to use 1MB alignment; but that update itself still needs work, I havent had chance to complete it. 20:54:15 → CODE REVIEW 3738: 16837 libzfs: pool start needs to be properly aligned with zpool_label_disk() (NEW) | https://www.illumos.org/issues/16837 20:58:49 it'd be really nice to just be able to plug in there somehow.. 20:59:48 since if you're using self encrypting disks, you want to be sure the protected range and the partitions line up correctly (and you have to create the protected region before since it erases existing data) 21:00:27 less of a problem if you're just using the whole disk (but it's often nicer if you at least leave the GPT labels outside of there so they're always readable) 21:00:45 but a concern for boot disks