hello, what is the command to disable a zone (vm) from autobooting?

I currently have booted into single user mode to try to disable zones from booting on the next reboot

you can try to svcadm disable system/zones

see zones(7)

Yes, but that will stop all Vm's from booting. I want to set certain zones to autoboot=diabled

I am a bit rusty on my solaris skills ;-)  zonecfg -z UUID .... and then something more

ou. yes, in that case, in zonecfg enter info and then set autoboot to false;)

how do i get the current config a specific zone ?

Roelf09: zonecfg -z $zonename

starts the zone config editor.

"info" displays zone properties; "info autoboot" is the one you likely want to see

"set autoboot=false" will turn off auto-boot of the zone.

It seems that when you go to single user mode all vm's are already on autoboot=false. So it seems imposible to mark them that way for the multiboot ?

if they are marked autoboot=false then they shouldn't be brought up by svc:/system/zones .. but it's possible that something else could be starting them at boot time by invoking zoneadm -z $zone boot

see /lib/svc/method/svc-zones: " Boot the installed zones for which the "autoboot" zone property is

set and invoke the sysboot hook for all other installed zones.

Roelf09: You can look at the autoboot property for all zones with something like: zoneadm list -cin | xargs -t -I% zonecfg -z % info autoboot

zoneadm list -cin | xargs -t -I% zonecfg -z % info autoboot  gives an error on every line "% Bogus zone name"

hmz... whilst trying to figure out how to read the dump file I discovered that the server has been auto rebooted multiple times in last hours and was able to heal itself.

Everything is up and running again so it seems

zoneadm list -cin | xargs -t -I% zonecfg -z % info autoboot gives an error on every line "% Bogus zone name"  => turned out I typed an "l" (L)  instead of capital I (i)

sommerfeld: you had a prototype of a sqlite3 system once. Do you still? I know it has ABI issues, that isn't a problem for me

Trying to evaluate the merits of how to fix this

"prototype" somewhat overstates it.

API and binary on-disk format issues, too.

But what I have so far might be a useful first step

my first bit of evaluation was looking at taking sqlite 2 dumps and importing them into a sqlite3 database via the CLI.

second bit was building sqlite3 as part of illumos-gate

the second bit I can just take and use, if necessary, since arm has no abi.

it just puts us on the hook to fix it so we can integrate eventually

but there are many things on many such hooks

not least an entirely distinct libm, a libsqlite-sys.so.3 would not be out of place.

libsqlite3-sys is what I called it (I think it will need to coexist in-tree for a while..)

I'll push something to gerrit as a WIP and post a link here

thanks

code.illumos.org/c/illumos-gate/+/4254 code.illumos.org/c/illumos-gate/+/4255 code.illumos.org/c/illumos-gate/+/4256

→ CODE REVIEW 4254: sqlite: hack up sqlite2 shell to dump tables in ways more compatible with sqlite3 (NEW)

→ CODE REVIEW 4255: XXXXX add sqlite3 3.47.2 amalgamation to common sources (NEW)

→ CODE REVIEW 4256: YYYYY build libsqlite3-sys (NEW)

i'd name the sqlite3 versions of the database *.db3 vs *.db for the sqlite2

several of them are ephemeral (like the idmap cache db) which makes the on-disk format conversion problem mostly go away.

my problem is that the bug I have is in the sqlite printf implementation (at least, the bug I'm chasing. I haven't checked if it fixes my symptoms). It is not 64bit safe

I am assuming sqlite3 no doubt is

it seems safer to me to try to use sqlite3 than to homebrew a fix -- even a little fix -- in here.

(it does `va_arg(ap,int)` when it means `va_arg(ap, unsigned int)`, at least)

and that does seem to be my larger issue.

but the risks of fix v. sqlite3 are I have to admit something I don't know right now.

jclulow asked how smf was working, and the answer is basically that SMF doesn't deal in integers with the 31 bit set.

and smb either does not, or doesn't work. it's untested to my knowledge

`realvalue` is also `LONGDOUBLE_TYPE` but va_arg'd a `double`

I'm guessing they mostly mis promote, rather than read the wrong amount and throw everything off.

richlowe: agreed on migrating to 3 vs trying to fix 2

(and idmap ephemeral id's all have bit 31 set..)

yes, indeed, this is my fix

so I know what's wrong, and it's perhaps more worrying about what else might be wrong.

probably danmcd gets to update to add sqlite3 to his list of 2038 blockers, since it intends on 64bit-izing things as the primary fix

which sqlite2 won't accept, apparently.

I think the way to go is to integrate libsqlite3-sys, then convert everything in illumos-gate but svc.configd, then get svc.configd

Yes. and for arm64-gate right now it would be all 3 and a most unfortunate flag-day

and there's a tension between just converting over to 3 as quickly as possible vs taking the time to tweak the schemas to use features now present in sqlite3

(one of the things my fiddling with dump/reload uncovered is that a lot of the content of the SMF database is long hex strings. would be half the size stored as BLOBs.

just pushed a predraft IPD for sqlite3

oooh

it's very predrafty

it looks very doable, though.