i tihnk those are for older disks that misreport their block size, so it's overriding that

tozhu: I would probably leave the BIOS settings alone unless you're having a specific issue.

Hi Jclulow, Thank you

I'm getting the following error while building nightly and I have no idea what to do :) "nightly: Error: could not bootstrap tools"

It starts at "Warning: Command failed for target `smatch.o'". Should I disable smatch?

Well, disabling smatch didn't help.

You should be able to find more information in `log/latest/nightly.log`. Can you find why it's failing to build smatch.o?

andyf oh, looks like it was gcc issues, the path was wrong.

andyf danke, as always

Which .env file are you using with nightly, and what distribution are you running on?

andyf I'm on OmniOS r151050, however I am building illumos-gate from illumos, without omni(1).

Instructions for building are at illumos.org/docs/developers/build but if you're running OmniOS you can use one of the files under /opt/onbld/env/

Try `nightly /opt/onbld/env/omnios-illumos-gate` as a starting point

Well,`./usr/src/tools/scripts/nightly /opt/onbld/env/omnios-illumos-gate` to be exact

andyf default config says python39, but r151050 comes with 3.12, now I'm getting mv: cannot access ../__pycache__/CStyle.cpython-39.pyc

That file (/opt/onbld/env/omnios-illumos-gate) should be right - it has "export PYTHON3_VERSION=3.12" on line 306

andyf thanks! I just got there :D I should read faster :D

it's building! thanks!

finally, an operational question that's been killing me for years. in other Unix systems like FreeBSD I set variables using sysctl, how can I set things in illumos, like ARC max?

look at /etc/system

Persistently, you can set them in the `/etc/system` file or an individual file under `/etc/system.d/`

Some can be tuned on the fly with `mdb -kw`, but it depends on how they're used, when they're read etc.

I see, now I need to figure out how to setup ARC max.

Also whether it's something that makes sense. The ARC uses otherwise unused memory and will shrink automatically when there is memory pressure. It's generally a good thing to use that memory as a filesystem cache.

andyf oh yeah, indeed, I just like having a static max arc so no surprises

Hi, what is a good ressource to obtain infos about Image Packaging System? How does it work? How does it work with zones? What are the pros and why is it so slow compared to other tools I know :-)

ZFS is intended to be completely self tuning. It doesn't always get it right though (e.g. github.com/oxidecomputer/helios/blo…ates/files/gimlet-system-zfs%3Adbuf)

andyf I have an idea for a feature but I have no idea if it's even important. I'd like to implement `kstat -d` which shows a description of a stat or a variable.

andyf danke for the link

unixery-u1 - docs.openindiana.org/dev/pdf/ips-dev-guide.pdf is a good place to start for an overview.

thanks

unixery-u1 you can start here: github.com/omniosorg/pkg5, here docs.openindiana.org/dev/pdf/ips-dev-guide.pdf and this video by Ian Murdock youtube.com/watch?v=uBTR611oqZA

It is slow mostly because it works by taking the IPS image (e.g. / in the GZ) to a target state, regardless of the starting state. The actual guts of this process is an extremely fast SAT solver.

Compare that to systems which download and unpack an archive to install a new package, for example

wow it's been building for 30 minutes. How long does it take usually?

antranigv - depends on the machine. 30-90 minutes

here's my machine: build0.illumos.am

it ain't much, but it can get things done.

Probably not much longer then :)

real 59m34.110s

well, that's good

do I need to reboot to get into my nightly build, or can I just chroot into it? I prefer to chroot since my changes are mostly in Userland.

looks like I can chroot into /code/illumos-gate/proto/root_i386

and the problem with chrooting is that I might not be able to use a debugger :/

You should be able to, just not on the kernel

For testing userland things you can chroot, or just run the new binaries, or set LD_LIBRARY_PATH and run the binaries.. whatever works to test it

Otherwise you should use `/opt/onbld/bin/onu` to create a new boot environment with the bits you just built

and reboto into it

*reboot

andyf the problem is that I'm modifying cut, which is a link to ksh, I think

Yes, and very probably part of libcmd.so.1

chroot should work, or you could do

LD_LIBRARY_PATH=/code/illumos-gate/proto/root_i386/usr/lib /code/illumos-gate/proto/root_i386/usr/bin/cut

That should run your new code

andyf weeee it works, thanks.

If you are in a build environment (entered with ./usr/src/tools/scripts/bldenv /opt/onbld/env/omnios-illumos-gate) you can use $ROOT to refer to the proto root, which simplifies things a little

LD_LIBRARY_PATH=$ROOT/usr/lib $ROOT/usr/bin/cut

Hi there,can't reboot omnios any help?

My son tried to installed win on another disk,now the disk on omnios doesn't boot

boot a live system and try `zpool import`

if you will not see your pool, well, amen...

Tried with -D

Is there anyway to access to the data?

the pool might not be destroyed

just do `zpool import` off a booted ISO

that will list all of the pools it thinks it can import

windows might have just overwritten the bootloader

That's it overwritten

How can I restore

bootadm?

But I need to repool

what do you mean 'repool'? if booting off ISO and zpool import shows the pool is there, what's there is probably fine.. you could import it and run a scrub if you wanted to be really sure

I got 3 disk the one in charge is c4t4d0 but doing zpool import it show c3t3d1 that I presume the usb omnios

diskinfo should show you more info on the disks