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..

hrm...

if I ssh + sudo, it seems that the pty's winsize isn't preserved

I have to manually resize slightly for the system to recognize the size

(I noticed less wasn't outputting correctly)...

[illumos-gate] 17437 Want explicit umc_cs_flags_t enum -- Luqman Aden <luqman⊙oc>

jbk: for loader? or?

you can see in loader properties how big loader things the console tty is

thinks*

no, ssh

to loaded OS

(annoyingly we don't ship 'resize')

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 :)

(or if not, maybe it's something with sudo not carrying them over)

hrm..

64/4/0 PCIe Gen 1x4294967295 pcieb8 Unknown device: 0x347c

a very wide bus? :)

or many lanes

finally, something fast enough for the folks who want CXL

annoyingly that's (obviously) not in our current pci db, though it looks like maybe it's an ice lake controller (from pcisig.com)

jbk github.com/citrus-it/omnios-build/b…ster/build/sudo/files/_omnios_nopty for sudo, perhaps.

and -1 lanes.. fun

andyf: aha! thanks

Looks like we deliver that file in /etc/sudoers.d/

andyf: always the pessimist, glass half -1 rather than glass half 0xffffffff

Whaddya mean richlowe? -1 != 4294967295

(oh... I see... should've scrolled up...)

(or gotten my head out of {,u}int64_t land.)

[data stack has 1 entries, top at 0x0000000000f8ddf8]

[0x0000000000f8ddf8 0]: 4294967295 (0x00000000ffffffff)

:)

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)

IIRC, parted writes out 128 entries by default

(as an example)

or hrm.. it defines it a bit strange, but more than the minimum

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;)

sommerfeld: I have a prototype idmap appearing to work, now to do it properly

yeah, it only works for the minimum though

our "default" is basically coming from vtoc (dkio) translation (even if VTOC_16 can have 16 slices)

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

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

and things like TCG Opal drives very often require your locking ranges to have 4k alignment (even on 512b disks)

(this way there's no danger of a partition going past the end of a locking range)

in 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.

→ CODE REVIEW 3738: 16837 libzfs: pool start needs to be properly aligned with zpool_label_disk() (NEW) | illumos.org/issues/16837

it'd be really nice to just be able to plug in there somehow..

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)

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)

but a concern for boot disks