Has anyone had any luck running OmniOS on Vultr, or perhaps some other VPS provider(s)?

I've run omnios extensively on AWS, but also tested on Vultr as a backup plan

(There was a report of problem with Vultr and the recent r151046, though.)

Hi ptribble, it's nice to meet you! Thanks for your response. I'm currently failing to get into the installer when booting from the ISO. Do you happen to know if this has ever worked? I see that you wrote a blog post about Installing OmniOS on Vultr with iPXE back in 2020 but I haven't tried that yet. Was this done as a workaround for the ISO

installation method not working?

No, that was because it was much quicker to use iPXE to test a lot of ISO images than go through the slow hassle of uploading them all to Vultr

That makes sense.

I'm pretty sure the standard install from ISO did work at the time I wrote that though, but that's a much older release

I haven't tried it recently because I moved on from the job that needed it

I think I'll try using iPXE later today and see if that still works but I think I'll try an older version of the ISO first to see when it broke. After that, I'll figure out how to get more output for debugging.

Yeah, working out if there's a particular release that broke it would be a good step.

I don't think it's a fundamental issue with the OS, though, because current OmniTribblix (built from the same source) works fine on Vultr

I've used Vultr much more than AWS and Vultr tends to be better value for personal use. If OmniOS is known to work well on AWS I could move forward with that for now but it would be nice to fix this.

That gives me hope, thanks!

I've read there could be problems with OmniOS running on Hyper-V with certain instance types/sizes. Do you happen to recall what you used for testing, so I can rule that out as the issue?

I regularly run OmniOS on digitalocean (using the cloud images) but I haven't tried Vultr.

downloads.omnios.org/media/r151046/omnios-r151046.cloud.vmdk for example

I'm running stable on linode too, with there paravirt option it uses viscsi and vioif, seems mostly stable

Fantastic! Thanks for your input, andyf and sjorge. I'm not surprised but it's good to know that OmniOS runs well on a number of popular VPS providers.

When booting the OmniOS ISO's on Vultr back to r151038 I get `hv_vmbus0: SINT val 200f6`, right after `hv_vmbus0: hypercall_create: Enabling Hypercall interface - SUCCESS!`. On r151030 the system freezes after printing SUCCESS and without printing `hv_vmbus0: SINT val 200f6` and then quietly reboots.

If others have previously used these OmniOS releases, from r151030 up, on Vultr, successfully, is it fair to assume that something has changed on Vultr's end that is causing this?

SIDENOTE: The OpenIndiana `OI-hipster-minimal-20230421.iso` loads, installs and boots as expected.

maybe booting the kernel debugger and eventually setting extra flags might reveal the last state right before the reboot

tomww It's my second day with OmniOS/illumos so that might be a little beyond of my capabilities :-). If you have any suggestions of where to get started learning about that they would be very welcome!

andyf The OmniOS r151046 vmdk worked like a charm on Digital Ocean, once I figured out that the Digital Ocean "Recovery Console" wasn't what I thought.

OK, so it looks like Vultr and Hyper-V don't get along (which is why OmniTribblix works - it doesn't have Hyper-V in the base image)

And OpenIndiana doesn't have Hyper-V support at all, so it'll be fine too.

Ah, that does make sense. Is there a way to disable hyper-v at boot time so I can confirm?

dlyund: please use the May ISO as there has been a CVE in the April ISO

I definitely ran 151030 on Vultr successfully, but that was a while ago.

toasterson Thanks for the advice! I'm still learning my way around; where can I find the May ISO? (The ISO on the download page appears to still be the one from April.)

openindiana.org/downloads shows 20230502 for me

Thank you :-). I'll switch to that OpenIndiana ISO for further testing. I apologise for any confusion, I was looking at the OmniOS download page.

dlyund: Happy to help. Curious about your experiences with the Cloudimage BTW it's new :)

This is an unusual one for me but maybe this is expected: when I run `useradd marksmith` I get a UX (non-warning non-error) `UX: useradd: marksmith name too long`, which doesn't seem to be documented in useradd(8). My customary username seems to comply with the format described in passwd(5). Is this UX message safe to ignore?

yes. especially name to long

thats legacy

toasterson The CloudImage for OmniOS r150146 worked so well that I didn't realise it was up ;-) . Of course, that's probably as much unfamiliarity with the DigitalOcean interface as anything.

So far so good!

It's cloud-init all the way

Could anyone tell me where loadable kernel modules are located in the omnios/illumos source tree? :-) I'm feeling a tad disoriented down here.

uts usually

Otherwise try src.illumos.org/source

What does uts stand for?

Unix Timesharing System?

yes

Got it. Thanks toasterson and wiedi

dlyund: For more background on where things are see illumos.org/books/dev/layout.html.

Awesome! That's going to be very useful. My thanks to you too rmustacc.

Well, it's been a really enjoyable day exploring. I tripped over a few things -- mostly things that are just different in other Unix-like systems -- but I won't make those mistakes again. pfexec(1) weirded me out a bit, at first, but I'm really loving it now. Things like rebooting using `init 6` still feels a bit strange. I'm sure there's an

underlying logic I don't appreciate yet. Other minor annoyances like the manual being (from my outside perspective) inside out and back to front I can just live with ;-).

Everything feels really solid, with a few oddities e.g. useradd(8) complaining that a username is too long but carrying on, and printing `48 blocks`, could (probably will be) polished up a bit. I'm sure that as users of the system you don't give these things a second thought but the first time you see them, they're a bit mysterious, if not

disconcerting.

Lot's more to learn! My thanks to everyone who helped me with useful suggestions and other assistance.

dlyund: I think we had some tasks to fix them up but previously the community was reluctant to change things. But now people are more open so we could try again.

:-) I imagine little tasks like that should be relatively simple (and safe?), and I'm eager to contribute something back as soon as I can. Is the list of tasks written up somewhere so that I might be able to through it?

(It might take me a couple of weeks to get up to speed and I haven't even tried to build OmniOS yet.)

You dont need to reboot with init 6.

You can just use the reboot(8) command.

The reason you're getting a warning on useradd, which perhaps could be better, is that the system default is to warn when using extended length names which older programs may have issues with.

If you look at useradd, that is configurable in /etc/default/useradd.

By look at it, I mean the manual page.

As for the blocks bit, I'm not sure. Smells like something is copying something and letting that output leak out in a confusing way.

andyf I'm poking the viona copy stuff again, I can just copy over beadm create testing, beadm mount testing /a, copy over viona.ko, ??? somethinbg with the ramdisk, beadm activate -t testing, reboot right?

Thanks for the explanation rmustacc. I see what you mean with useradd(8) and the traditional username length and it seems perfectly reasonable that this warning be configurable. I understand that wording in the useradd(8) man page now too. Perhaps an example of this specific warning could be added to the man page, rather than changing the

behaviour?

The examples in the man page set the expectation that warnings will be prefixed by `WARNING:` but in this case at least, that's not true, so maybe that could be improved, either in useradd itself or the man page?

Looking at /etc/defaults/useradd it occurs to me that the `48 blocks` could have to do with the "ZFS create/destroy operations". If so does that output look familiar?

It looks more like things being copied over to the new home directory from skel with something like cpio.

Yeah, it's github.com/illumos/illumos-gate/blo…md/oamuser/user/homedir.c#L174-L176

:-) That looks like it!

I guess we should use the cpio(1) quiet option (-q) here to "Suppresses the number of blocks message that normally is printed after the copy is completed." Thoughts?

Hi, any chance I'd get wifi to work on omnios if I have intel ac8260?

hm, this tells me no I guess illumos.org/issues/7853

→ BUG 7853: SUPPORT Intel® Dual Band Wireless-AC 8260 (New)

aru_: If you write the drivers :)

eeh, that would be rough introduction to illumos kernel development

true. but many other small taks are there aswell :)

indeed

or did you have something specific in mind?