Are there any tweaks to help Tribblix boot any faster?

It's actually fairly quick, to be honest, but where does it feel slow?

Honestly, is probably just my old laptop that's slow, and I just wondered if I could trim off a few seconds with some tweaks.

Obviously shortening the timeout on the boot selector, but that doesn't worry me because I'll always just hit enter immediately

On my machine, I look at 4 phases: bios, loader, illumos boot, and graphical startup

And as a rule, time taken is reverse order - waiting for the bios to get its act together is invariably the slow part

I suppose illumos boot is where is like some seconds back

On a more important issue, while you're online Peter, I'm having trouble connecting to wifi.

It seems to connect while I'm still plugged into my ethernet cable, but trying this while not connected, or after unplugging, I have no internet and status shows the link is down

Sadly, as I said yesterday, I've never used wifi on illumos (never had a viable device to test)

Sorry, I was just disconnected so if you replied to my last message I didn't get it.

This is logged, btw, so you can check there too log.omnios.org/illumos

No worries. I'll keep digging. I was on here the other day and some helpful people pointed me to the dladm man page as I was trying to use wifi-config which is apparently depreciated

Anyone else have a Tribblix machine they can test wifi on?

it doesn't matter whether it's tribblix or anything else, unless tribblix chooses to ship out-of-gate drivers

Doesn't have to be Tribblix; all the wifi bits are the same on all the distributions

that being said, wifi works well enough for me on OI using the iwn driver.

I wonder if there's some interference from nwam here

Yeah, I cannot figure it out and feel like I've hit a wall as it should work they way I've set it up. The fact that the connection appears to be up after running the connect-wifi command

But this ONLY happens while conected to ethernet

I might add that I didn't perform any configuration for my ethernet connection at all... so if I've missed a step ?

I plugged in and was online so I thought nothing else of it

Hm, maybe I can export the whole block device (SATA physical drive) and share it over iSCSI ?

Physical drive has NTFS on it..

a better way is to dump the data from the device to a file/zvol

and then you can play (read as corrupt) with it

btw, zfs allows you to have second chance to fail if you did a snapshot of the data

denk, it is all great suggestion. Just this is some non-essential data, like torrents, games that's why it is on NTFS and on separate device in the first place. But great suggestion ;)

well, attach the device to a vm on the host and copy the data

tsoome: it look like efiserialio.c is missing a few bits to be able to drop in (I had wanted to try to at least rig something up to see if there were any other changes within the OS that needed work)

Today I stumbled across the fact that /lib/svc/method/fs-local differs between vanilla gate and OmniOS

Much of this is 11278 (fenix) - is this planned to be upstreamed?

→ BUG 11278: Encrypted ZFS filesystems should be mounted at boot where possible (In Progress)

illumos.org/rb/r/2025 /_\

Looks like it needs dusting off

Changing tack slightly, I just saw a PR for openjdk that checked for success of uname(2) being == 0

Now Linux and FreeBSD say that their implementations do, but SunOS and AIX simply say "non-negative" (ie, -1 is failure)

And indeed, we return 1, which is ... interesting

andyf: Oh, Review Board, that's a blast from the past!

Yeah, well just look at the age of that review

pubs.opengroup.org/onlinepubs/9699919799/functions/uname.html also says non-negative

I mean, that's been shipping in OmniOS for about 4 years, so I would have thought it's a fairly safe fix.

Yep, 0 is fine according to Posix, but so is 1

ptribble: can we just tell openjdk that's wrong?

or, at least, _as well_ tell openjdk

We have a mix of code that does it variously wrong, fwiw

but the most common is assuming that -1 is the only negative number

I've pointed out the wrong assumption, so hopefully it won't be something I have to patch around

I guess maybe I should blame the spec for saying "positive on success, -1 on error" and not covering all the options.

There's even the comment in our source

return (1); /* XXX why 1 and not 0? 1003.1 says "non-negative" */

sigh

... and my rigging of that in loader apparently failed