sorry to bother you all, I'm thinking about what to install as the main os for my home server, and there's practically no information on ilumos online. and I don't know if it is right for me. I don't know much about virtualization, between esxi or other hypervisors, compared to zones or jails, as well as other stuff like what linux does.

I recently got my hands on a server with two cpus and nearly 200gb of memory, and plenty of linux knowledge, but I also want to try something new, can anyone say if ilumos is a good idea?

Guest57: hard to say. Are you going to get mad when things are subtly different from what you're used to on linux? It may help to spell the OS correctly ("illumos") or search for information about some of the distributions (including omnios, smartos, openindiana)

If you're looking for a server-focused distribution I would start by looking at the OmniOS documentation probably, or perhaps SmartOS as well depending on how you want your system to work

illumos is the core of the operating system (kernel and libc, etc); distributions are what you would actually install

Guest57: e.g., you might start at omnios.org/setup/freshinstall.html

As to whether it's a good idea: only you can answer that! We're all pretty fond of it here, and if you're willing to put effort into exploring we're definitely here to help when you get stuck.

honestly, I was mostly worried about dual cpu support, and just wondering if anyone  thought I would hit any roadblocks there. I'm definitely willing to learn, in my opinion trying to get everything to work just how you want to is the most fun part of a home server.

i have a question, i used to have a pfsense vm in esxi, and through vswitch etc i had the outbound connection on a seperate vnic for the vm. right now im using an actual hardware opnsense firewall but im curious how i would replicate this setup if i wanted to move it to my omnios server to a zone, how would you pass through say igb0 completely to the zone? and is ipfw the only firewall?

actually on that note is there pci passthrough in bhvye? thinking about it i could just pass through the whole controller to a vm of choice

sommerfeld I wouldn't say I'd be very mad, that's like someone biting into an orange and being frustrated about the peel.

someone who enjoys apples might wonder what another fruit may taste like, but if they were expecting every other fruit to taste like apple, they would be better off just enjoying another kind of apple

Guest57: good attitude. Illumos multiprocessor support is generally very good.

well that's great to hear, It appears that my builtin NIC is also supported, so it looks like I am ready to move forward.

oh hey i'm back, turns out BTX crashes even on a USB boot key

i just made a bootable oi USB (2022.10), same problem

this was after updating a 2021.10 to 2022.10

platform is a dell poweredge c6145 with the AMD opteron 6386SE

testing the previous boot image (2021.10)

that works

the new loader works if i can chainload from a previously working loader

i have no idea why that is

despair86 does UEFI boot work and can you mail me BTX dump?

how do i enable output for trace points TRACE_0, TRACE_1 etc? i am specifically interested in those present in strdoioctl. i found the comment in vtrace.h where these macros are defined:

vtrace is a legacy tracing framework that has been subsumed by the DTrace framework. To allow tracing of legacy vtrace points, the points themselves have been retained, and are provided to DTrace via the "vtrace" DTrace provider

however my dtrace -l only lists fbt entry/return probes for strdoioctl and i don't see anything about a vtrace provider either

janosch: Note that the definitions for the TRACE_*() family of macros are under an #if defined(DEBUG) guard.

So you'll need to be running DEBUG bits to be able to use them.

If you're on OmniOS (and possibly other distributions that use IPS) you may be able to do that with "pkg change-variant".

If you're on SmartOS you would need a special DEBUG platform image.

aww, missed the ifdef ... too bad, thanks for pointing out

You're welcome!

tsoome_: this server has no EFI ROM

janosch: DEBUG SmartOS PIs are available for every release.

They are just a bit out of the way. Let me know if you need one for a specific SmartOS release.

And jclulow is right that OmniOS lets you create a BE of your same release bits using `pkg change-variant`... specifically `pkg change-variant {--be-name $NEWBE} debug.illumos=true`

OI too, for completeness.

danmcd: thanks for your offer, but that's not necessary. i do have a debug image at hand as needed.

Thanks andyf -- couldn't remember if OI had done that or not. (Should've assumed they had.)

regarding my work in progress: code.illumos.org/c/illumos-gate/+/2631 . Is is safe for a test to assume that /var/tmp is in ZFS (or at least supports ZFS acls?). That's going to be true on both Openindiana and Omnios but I'm not sure about the environment where someone might run illumos tests on SmartOS...

→ CODE REVIEW 2631: 15353 find -useracl/-groupacl ignores type of acl entry resulting in false positive matches (NEW) | illumos.org/issues/15353

sommerfeld: That will be true on SmartOS if there's a system zpool at all. And I think (danmcd can confirm) that it needs a zpool to run the tests.

it can create a zpool ontop of files, but usually you give it 3 10+gb disks to use for it's tests

ok. so it sounds like a safe-ish assumption to make, then.

Yeah, I think so.

Yeah, /var/tmp is zfs, and when I run tests I always set DISKS to be three small (10G) disks.

DISKS is used by the zfs tests but doesn't seem to be used by util-tests (usr/src/test/util-tests, installs to /opt/util-tests)

Yeah, I don't think we should be using DISKS in util-tests.

(usr/src/test/util-tests/tests/find/findtest.ksh looked the like right home for the regression test at first glance)

That's what I would have done sommerfeld.

So I think you're in the right spot.

ok, thanks.

Sorry I saw jbk earlier mention it.

yeah that's the zfs tests, i should have clarified

@sommerfeld you should probably have the test check whether the FS supports ACLs, and if not, report SKIP (unsupported on this FS)

eg. pathconf _PC_ACL_ENABLED

_ACL_ACE_ENABLED

on what filesystem could we test where that would be a problem?

tmpfs

doesn't the test suite control that, though?

It can control what path it uses. I'm just saying it would be good to check the assumption that the path you chose supports ACLs.

I guess there's no good way to find one that's definitely ok in the test

Right, depends on the system.

I mean, it's a fair guess it's ZFS, but it's still a guess.

I don't remember if there's a way to get that pathconf info from a script though.

gwr: see PM for a little bit of trying to make work for y'all :)

thx :)

gwr: looks like python can see it.

Ooh, see "getconf(1)"

% /usr/bin/getconf ACL_ENABLED /tmp

0

% /usr/bin/getconf ACL_ENABLED /var/tmp

2

good deal.

when I get a chance (not right this moment) I'll add that check.

thanks for taking on some bugs

I'm selfishly starting with the ones I've filed.

that's not selfish

Yeah I think that is the opposite of selfish haha

and then you can create new bugs yourself, so you'll never be out of work:D