omniosorg / pkg5 Goto Github PK
View Code? Open in Web Editor NEWImage Packaging System
Home Page: https://omnios.org/
License: Other
Image Packaging System
Home Page: https://omnios.org/
License: Other
When setting promiscphys
to true for the bhyve brand, we also need to set promisc-filtered
to off on the vnic.
I'm not really sure what the proper fix is, do we set it via zadm for the persistant vnics and in the brand for the temporary ones? Or do we just set the linkprop accordingly based on promiscphys before starting bhyve? The later seems more inline to me wrt what a user would expect if he sets promiscphys=true regardless of where the vnic's are coming from.
Currently it's not possible to have a brand automatically create vrrp vnics:
dladm create-vnic -m vrrp -l ixgbe0 -V 98 -A inet -v 110 ldap1vip0
I had a look at shared/vnic.ksh and it seems like it should be possible to add this without too much trouble but I am not sure this is the best approach, I'd like some feedback before further fleshing this out.
I was thinking something along the lines of:
--- a 2021-12-12 22:48:29.000000000 +0100
+++ b 2021-12-12 22:58:04.000000000 +0100
@@ -1,5 +1,5 @@
function config_vnics {
- demand_vnics | while read nic global mac vlan addr; do
+ demand_vnics | while read nic global mac vlan addr vrid vridfamily; do
[ -n "$global" -a "$global" != "-" ] || continue
if [ "$global" = "auto" ]; then
if [ "$addr" = "-" ]; then
@@ -15,6 +15,16 @@
"$nic"
fi
fi
+ if [ "$mac"] = "vrrp" ]; then
+ [ "$vrid" != "-" ] || \
+ fail_fatal "Invalid configuration for %s mac cannot be 'vrrp' if no vrid specified!"
+
+ # fallback to inet for vridfamily if not specified
+ [ "$vridfamily" = "-" ] && vridfamily="inet"
+
+ [ "$vridfamily" = "inet" -a "$vridfamily" = "inet6" ] || \
+ fail_fatal "Invalid configuration for %s vrid_family needs to be either 'inet' or 'inet6'!"
+ fi
if dladm show-vnic -p -o LINK $nic >/dev/null 2>&1; then
# VNIC already exists
continue
@@ -23,6 +33,7 @@
opt=
[ "$mac" != "-" ] && opt+=" -m $mac"
+ [ "$vrid" != "-" ] && opt+=" -V $vrid -A $vridfamily"
[ "$vlan" != "-" -a "$vlan" != "0" ] && opt+=" -v $vlan"
if ! dladm create-vnic -l $global $opt $nic; then
fail_fatal "Could not create VNIC %s/%s" \
Full function below for easier reading:
function config_vnics {
demand_vnics | while read nic global mac vlan addr vrid vridfamily; do
[ -n "$global" -a "$global" != "-" ] || continue
if [ "$global" = "auto" ]; then
if [ "$addr" = "-" ]; then
fail_fatal "%s %s" \
"Cannot use 'auto' global NIC" \
"without allowed-address."
fi
global="`route -n get "$addr" | nawk '
/ interface:/ {print $2; exit}'`"
if [ -z "$global" ]; then
fail_fatal \
"Could not determine global-nic for %s" \
"$nic"
fi
fi
if [ "$mac"] = "vrrp" ]; then
[ "$vrid" != "-" ] || \
fail_fatal "Invalid configuration for %s mac cannot be 'vrrp' if no vrid specified!"
# fallback to inet for vridfamily if not specified
[ "$vridfamily" = "-" ] && vridfamily="inet"
[ "$vridfamily" = "inet" -a "$vridfamily" = "inet6" ] || \
fail_fatal "Invalid configuration for %s vrid_family needs to be either 'inet' or 'inet6'!"
fi
if dladm show-vnic -p -o LINK $nic >/dev/null 2>&1; then
# VNIC already exists
continue
fi
log "Creating VNIC $nic/$global (mac: $mac, vlan: $vlan)"
opt=
[ "$mac" != "-" ] && opt+=" -m $mac"
[ "$vrid" != "-" ] && opt+=" -V $vrid -A $vridfamily"
[ "$vlan" != "-" -a "$vlan" != "0" ] && opt+=" -v $vlan"
if ! dladm create-vnic -l $global $opt $nic; then
fail_fatal "Could not create VNIC %s/%s" \
"$nic" "$global"
fi
if [ "$mac" = "-" ]; then
# Record the assigned MAC address in the zone config
mac=`dladm show-vnic -p -o MACADDRESS $nic`
[ -n "$mac" ] && zonecfg -z $ZONENAME \
"select net physical=$nic; " \
"set mac-addr=$mac; " \
"end; exit"
fi
done
}
This is just a rough untested idea on how I would like to implement it, there is no vrid and vridfamily parsing added higher up to the awk script yet.
sjorge@saturn:/usr/lib/brand/shared$ dladm create-vnic 2>&1 | grep -B 2 -A 1 vrid
create-vnic [-t] -l <link> [-m <value> | auto |
{factory [-n <slot-id>]} | {random [-r <prefix>]} |
{vrrp -V <vrid> -A {inet | inet6}} [-v <vid> [-f]]
[-p <prop>=<value>[,...]] <vnic-link>
Does this approach look good? If so flash this out more (update the awk parsing and such) and give it a spin.
An alternative idea I had was just to be able to feed it a vrrp mac e.g. 0:0:5e:0:1:62
for inet and 0:0:5e:0:2:62
for inet6 and then parse those to extract the vrid and vrid family from them, this is doable because the VRRP mac follow the same format:
0:0:5e:0:
prefix, 1
for IPv4 (inet) or 2
for IPv6 (inet6), XX
is the vrid in hex, so it's certainly possible to parse the required info from this, but I feel this would make for a lot of complex parsing in ksh which I prefer to avoid, simply creating a vnic with one of those mac addresses is not sufficient to make vrrpadm create-router happy, I tried.
Edit: some more context, https://blackdot.be/2021/12/using-vrrp-inside-a-lipkg-zone-on-omnios/ manually creating the vnic first and just passing it in works as a workaround but I would prefer not to manually have to create any vnics.
The --origin-uri
(-O
) flag to pkg set-publisher
will remove and replace all existing origin type publisher entries from the configuration.
There does not appear to be an analogous flag for replacing all current mirror type publisher entries; --add-mirror
(-m
) and --remove-mirror
(-M
) both require understanding the current state before specifying a new one.
Basically it would be good to be able to do something like:
pkg set-publisher \
-O https://pkg.omnios.org/r151046/core/ \
-I https://us-west.mirror.omnios.org/r151046/core/ \
omnios
And end up replacing any existing origin and mirror records for the omnios publisher.
I suspect it would also be good to have a --no-mirrors
flag as well, that would remove all mirror entries altogether, in case the new repository doesn't actually come with a mirror anymore; i.e.,
pkg set-publisher \
-O https://pkg.omnios.org/r151046/core/ \
--no-mirrors \
omnios
This would replace all origin entries and remove any mirror entries (if any are present) in one operation.
{
"autoboot" : "false",
"bootdisk" : {
"blocksize" : "4K",
"path" : "rpool/vms/rcon1/disk0",
"size" : "10G",
"sparse" : "false"
},
"bootrom" : "BHYVE_RELEASE",
"brand" : "bhyve",
"diskif" : "nvme",
"hostbridge" : "i440fx",
"net" : [
{
"global-nic" : "ixgbe0",
"mac-addr" : "00:22:06:eb:5c:9f",
"physical" : "rcon1",
"vlan-id" : "10"
}
],
"ppt": [ "ppt0" ],
"netif" : "virtio-net",
"ram" : "1G",
"rng" : "on",
"vcpus" : "1,sockets=1,cores=1,threads=1",
"vga" : "off",
"vnc" : "off",
"xhci" : "off",
"zonename" : "rcon1",
"zonepath" : "/zones/rcon1"
}
root@jupiter:~# zfs list -r rpool/vms
NAME USED AVAIL REFER MOUNTPOINT
rpool/vms 124G 126G 256K /zones
... other hvm/zones here ...
rpool/vms/rcon1 10.6G 126G 224K /zones/rcon1
rpool/vms/rcon1/disk0 10.6G 136G 112K -
Having a zvol (bootdisk or regular disks) under the zonepath used to work fine, but this now fails, no 100% sure this is a brand or zadm issue.
It used to work fine before, but now it fails with Zonepath /zones/rcon1 is on a nosuid file system.
When the zvol is create it looks like it creates the parent rpool/vms/rcon1 which is mounted on /zones/rcon1, so far so good. However this dataset has setuid set to off with SOURCE set to temporary.
Creating the parent manually first sees to fix this (I set all properties to the values my existing bhyve VM's had on those datasets)
Perhaps somewhere the order in which the zvol vs dataset create got swapped recently.
It would be good to at least have a flag that would allow for idempotent use of pkg install blah
, such that if blah
is already installed and no action is required we can drive on successfully instead of exiting non-zero. Today, to work around this, folks always have to do something like pkg info -q blah
to try and guess if the package is installed before putting it in the list. This is even more tedious if you have a list of multiple packages, as if some of them are not installed we will successfully install the missing ones, but if all of them are installed we fail with the error.
In the pkgfmt(1) manual page, there is at least one misspelling of the command name as pkgfmr
.
When TERM=256+color, I've seen exceptions in pkg.
When TERM=dumb, there was no exception.
Logged into the console of omnioscce, I see:
pfexec env TERM='xterm+256color' pkg refresh
Traceback (most recent call last):
File "/usr/bin/pkg", line 5452, in handle_errors
__ret = func(*args, **kwargs)
File "/usr/bin/pkg", line 5354, in main_func
return func(api_inst, pargs)
File "/usr/bin/pkg", line 3449, in publisher_refresh
return __refresh(api_inst, pargs, full_refresh=full_refresh)
File "/usr/bin/pkg", line 3413, in __refresh
immediate=True, pubs=pubs)
File "/usr/lib/python2.7/vendor-packages/pkg/client/api.py", line 2987, in refresh
pubs=pubs, immediate=immediate)
File "/usr/lib/python2.7/vendor-packages/pkg/client/api.py", line 3011, in __refresh
progtrack=self.__progresstracker)
File "/usr/lib/python2.7/vendor-packages/pkg/client/image.py", line 3318, in refresh_publishers
progtrack.refresh_start_pub(pub)
File "/usr/lib/python2.7/vendor-packages/pkg/client/progress.py", line 1220, in refresh_start_pub
self._refresh_output_progress(outspec)
File "/usr/lib/python2.7/vendor-packages/pkg/client/progress.py", line 2850, in _refresh_output_progress
self._pe.cprint(msg, end="", erase=True)
File "/usr/lib/python2.7/vendor-packages/pkg/client/printengine.py", line 155, in cprint
self.erase()
File "/usr/lib/python2.7/vendor-packages/pkg/client/printengine.py", line 139, in erase
self.putp(self.__cr)
File "/usr/lib/python2.7/vendor-packages/pkg/client/printengine.py", line 119, in putp
self._out_file.write(self.__putp_re.sub("", string))
TypeError: expected string or buffer
at printengine.py" line 139, in the call to self.putp(self.__cr)
self.__cr is None even though cr should be defined as \r in xterm+256color.
I set a breakpoing on POSIXPrintEngine.init, and after:
self.__cr = curses.tigetstr("cr")
the value of self._POSIXPrintEngine__cr was None.
So, somehow, it is getting a null value for 'cr' from terminfo.
Setting TERM to dumb is a workaround:
pfexec env TERM='dumb' pkg refresh
Refreshing catalog 'omnios' ... Done
When applying a hotfix from a local archive, pkg will first display the path correctly:
Resolved URL to: file:///tmp/amd-hma-exclusion.p5p
Retrieving installed package list...
Scanning package archive...
pkg://omnios/system/kernel/[email protected]:20200828T150837Z will be updated.
...
and then fail, because it broke the URL:
The origin URIs for 'omnios' do not appear to point to a valid pkg repository.
...
PUBLISHER TYPE STATUS P LOCATION
omnios origin online F file:///tmp/pkg_hfa__o5dv8t4_amd-hma-exclusion.p5p/
omnios origin online F http://pkg.bb-c.de/omnios/034-core/
It will also leave the broken origin in all NGZs that it wants to recurse into.
Hello,
Hope this is the right repo.
I applied a hot fix per andyf's advice. I noticed today when trying to apply the latest OmniOS upgrade that all my NGZs have a lingering file://tmp/...
omnios publisher that is invalid:
| WARNING: Errors were encountered when attempting to retrieve package
| catalog information. Packages added to the affected publisher repositories since
| the last retrieval may not be available.
|
| Errors were encountered when attempting to contact 1 of 2 repositories for publisher 'omnios'.
|
| Unable to contact valid package repository: file:///tmp/pkg_hfa_2074x57__OS-8027.p5p/
| Encountered the following error(s):
| file protocol error: code: E_HTTP_NOT_FOUND (22) reason: The path '/tmp/pkg_hfa_2074x57__OS-8027.p5p' does not contain a valid package repository.
| Repository URL: 'file:///tmp/pkg_hfa_2074x57__OS-8027.p5p'.
The GZ does not have that tmp publisher.
Thank you.
I've noticed the bhyve man page and your web site, https://omnios.org/info/bhyve_kvm_brand.html, do not document the vnc=wait
setting.
The us-west mirror is apparently down right now, and pkg
commands appear to get stuck trying to contact it:
DOWNLOAD PKGS FILES XFER (MB) SPEED
ooce/server/nginx 0/2 0/27 0.0/0.7 --
It appears the system will wait rather a long time for a connection timeout, and may keep trying even after the first few tries fail. Because --disable
works at the publisher level, rather than the mirror level, one must remove the mirror configuration altogether to bypass the issue.
The pkg
command should probably:
Consider a large package that has many loosely related drivers:
We'd like to be able to take the derelict driver out into a new package, pkg:/driver/derelict, while leaving the others alone for now. The end result should look like:
Distributions generally have a metapackage that contain a list of driver packages that are relevant to the install media or system they are producing; ideally this need not be all drivers. As part of building new illumos packages, a distribution could include (if they wish!) a depend type=require action in their metapackages and the driver would then be explicitly included in media. Because pkg:/barge does not depend on the new pkg:/driver/derelict, new distribution releases are able to exclude the driver in question if it is not relevant to them, thus reducing the size of the software in their base install.
Unfortunately, this falls down for updating existing systems. If you had pkg:/[email protected] previously, you would have had (and could have been depending upon!) the driver derelict shipped in that package. Once your system updates to pkg:/[email protected], that driver is no longer in that package, and will be removed from the disk! If you needed that driver to boot, your system would not boot any longer.
The classical strategy for dealing with this is to make the old package, which is being split up, depend on the new package; i.e.,
This is regrettable, because it is not possible, then, to install barge without getting derelict, thus ultimately defeating the point of splitting up the packages in the first place.
Another option is to split up barge even more completely and turn the old package into a meta-package itself; e.g.,
Distribution meta-packages would then be altered not to install pkg:/barge at all, and instead install the subset of the new packages which are relevant. End users could ultimately uninstall pkg:/barge at their leisure, provided they don't uninstall whichever of the drivers are useful to them, and also don't use the relatively recent pkg autoremove
functionality which uninstalls packages that were not themselves explicitly marked as manually installed by the operator.
This is not ideal, though, for all cases; e.g., if you're trying to remove portions of a package that is itself a legitimate package that needs to continue to exist; e.g., /system/kernel.
What I think would be neat instead is a new action type: depend type=upgrade which would, when put on the package pkg:/barge:
This would afford us a one-time installation of pkg:/driver/derelict, on upgrade of pkg:/barge across the transition where it was split out, that would not keep bringing it back from the dead if the user decided themselves to uninstall it.
An illumos contributor was recently confused by a message output from our build that asked them to run pkgfmt
without the -c
or -d
options to reformat a manifest file. Unfortunately it was not immediately obvious that the tool operates by default (it seems) in the V2 format mode, which we don't use in illumos. You can override the format in use with the PKGFMT_OUTPUT
environment variable, as the build does, but it seems like there is also an undocumented -f
flag for this?
It'd be good to document the flag and the environment variable, and likely to specifically call out in the manual page that illumos only uses the V1 output format.
root@jupiter:/zones/hydrogen/root/tmp# tail zone.log
[Tue Jun 22 13:36:33 CEST 2021] Waiting for bhyve to exit
[Tue Jun 22 13:36:34 CEST 2021] Waiting for bhyve to exit
[Tue Jun 22 13:36:35 CEST 2021] Waiting for bhyve to exit
[Tue Jun 22 13:36:36 CEST 2021] Waiting for bhyve to exit
[Tue Jun 22 13:36:37 CEST 2021] Waiting for bhyve to exit
[Tue Jun 22 13:36:38 CEST 2021] Waiting for bhyve to exit
[Tue Jun 22 13:36:39 CEST 2021] Waiting for bhyve to exit
[Tue Jun 22 13:36:40 CEST 2021] Waiting for bhyve to exit
[Tue Jun 22 13:36:41 CEST 2021] Waiting for bhyve to exit
[Tue Jun 22 13:36:42 CEST 2021] Waiting for bhyve to exit
root@jupiter:/zones/hydrogen/root/tmp# mount | grep hydrogen
/zones/hydrogen on rpool/vms/hydrogen read/write/setuid/devices/nonbmand/exec/xattr/atime/dev=415000b on Wed Jun 16 21:48:38 2021
/zones/hydrogen/root/dev on /dev read/write/setuid/devices/dev=89c0007 on Tue Jun 22 13:38:45 2021
/zones/hydrogen/root/lib on /lib read only/setuid/nodevices/nosub/dev=4150002 on Tue Jun 22 13:38:45 2021
/zones/hydrogen/root/sbin on /sbin read only/setuid/nodevices/nosub/dev=4150002 on Tue Jun 22 13:38:45 2021
/zones/hydrogen/root/usr on /usr read only/setuid/nodevices/nosub/dev=4150002 on Tue Jun 22 13:38:45 2021
/zones/hydrogen/root/var/run on swap read/write/setuid/nodevices/xattr/size=50m/zone=hydrogen/dev=8b4001d on Tue Jun 22 13:38:45 2021
/zones/hydrogen/root/proc on proc read/write/setuid/nodevices/zone=hydrogen/dev=8a4000a on Tue Jun 22 13:38:45 2021
/zones/hydrogen/root/etc/mnttab on mnttab read/write/setuid/nodevices/zone=hydrogen/dev=8b0000b on Tue Jun 22 13:38:45 2021
/zones/hydrogen/root/etc/svc/volatile on swap read/write/setuid/nodevices/xattr/size=10m/zone=hydrogen/dev=8b4001e on Tue Jun 22 13:38:45 2021
It writes to this file 1x second, and that is not on tmpfs!
Though you can indicate to wait by setting the vnc
attribute using full options
such as unix=/tmp/vm.vnc,wait
, may I suggest another mode for vnc
: off, on, wait,
options
where wait
is the same as unix=/tmp/vm.vnc,wait
.
Thank you.
Hello,
I've noticed some modifications that may need fix-ups to comply with section 3.3 of CDDL, "You may not remove or alter any copyright ... notices contained within the Covered Software, or any notices of licensing or any descriptive text giving attribution to any Contributor ...."
"Covered Software means (a) the Original Software, or (b) Modifications, or (c) the combination of files containing Original Software with files containing Modifications, in each case including portions thereof."
In #208:
Greetings,
I've hit an issue with cloning ipkg zones running a development build of illumos. I've narrowed this issue down to /usr/lib/brand/ipkg/system-configure
. That file appears to come from this repo hence the issue report here.
When I tried to clone a zone from a development build of Illumos-gate, I would get an error saying Zone: unconfigure failed
. After a bit of digging I found that this was coming from /usr/lib/brand/ipkg/{clone,system-unconfigure}
. I added the -x
ksh flag to the top of each of these files to get output and replaced the zlogin
redirect within system-unconfigure
from /dev/null
to a file in the /tmp
directory so I could actually see what's going on. The output of those failed runs with -x
set is available here.
What's happening here is in system-unconfigure
a sed
is running on /etc/ssh/sshd_config
but /etc/ssh
does not exist so the command is failing and derailing the whole zone clone.
As a quick workaround which allows the clone to succeed, I did the following
diff --git a/system-unconfigure.orig b/usr/lib/brand/ipkg/system-unconfigure
index 681a25a..48f8c21 100755
--- a/system-unconfigure.orig
+++ b/usr/lib/brand/ipkg/system-unconfigure
@@ -191,7 +191,9 @@ reset_init_default
blank_root_pw
clear_logs
disable_ldap
-reset_ssh_config
+if [[ -d $ALTROOT/etc/ssh ]]; then
+ reset_ssh_config
+fi
# Vim hints
# vim:ts=4:sw=4:et:fdm=marker
However, it's not clear to me if this is a reasonable thing to do, or if it's a treatment of a symptom that's ignoring a deeper issue.
An example is isc-dhcp, which has /usr/sbin/dhcpd. If this package be installed in a sparse zone, then pkg install
reports no error, but /usr/sbin/dhcpd is not installed because filesystem /usr is shared and read-only in the zone.
At the very least, pkg install
should emit a warning for the omitted file, but really, pkg install
should fail because the package has not been installed.
Right now, if you list the contents of a package or set of packages with a filter, and that filter does not match any actions that exist within the package, pkg contents
fails with a generic exit status:
$ pkg contents -t depend -a type=optional -H -o fmri SUNWcs
pkg: contents: no matching actions found in the listed packages
$ echo $?
1
It seems useful to be able to distinguish the "no matching actions found in the listed packages" case from other errors without parsing the human-readable error message.
It might even make sense to add a new flag (perhaps -q) to just squelch this error altogether and exit 0 in this case.
Couldn't find where this package is coming from, so might be the wrong repo.
I added this to /etc/sudo.conf
Plugin sudoers_policy sudoers.so ldap_conf=/etc/sudo.conf.ldap
I had this as sudo.conf.ldap
URI ldap://ldap.acheron.be
BASE dc=acheron,dc=be
SUDOERS_BASE ou=sudoers,dc=acheron,dc=be
BINDDN cn=proxyagent,dc=acheron,dc=be
BINDPW xxxx
SSL start_tls
This works fine on SmartOS but fails with:
sjorge@ldap1:/$ sudo -l
sudo: start_tls specified but LDAP libs do not support ldap_start_tls_s() or ldap_start_tls_s_np()
sudo: ldap_sasl_bind_s(): Confidentiality required
The following does work:
URI ldaps://ldap.acheron.be
BASE dc=acheron,dc=be
SUDOERS_BASE ou=sudoers,dc=acheron,dc=be
BINDDN cn=proxyagent,dc=acheron,dc=be
BINDPW xxxx
TLS_CERT /var/ldap/cert7.db
Given it needs a cert7.db to work, I'm guessing it is using the illumos LDAP and not openldap libraries.
They do not seem to expose start_tls.
However the manpage (sudoers.ldap) does mention starttls support, I think updating the manpage to not mention it is probably the correct fix, unless we want to pull in openldap but I don't think we want that....
manpage fragment:
SSL start_tls
If the SSL parameter is set to start_tls, the LDAP server
connection is initiated normally and TLS encryption is begun before
the bind credentials are sent. This has the advantage of not
requiring a dedicated port for encrypted communications. This
parameter is only supported by LDAP servers that honor the
start_tls extension, such as the OpenLDAP and IBM Tivoli Directory
servers.
While waiting on the freeradius package I started looking at some other things on my TODO list...
I setup 2 VMs with bhyve that each get a USB controller.
However on the VM with ppt0 sees the actual device.
{
"acpi" : "on",
"autoboot" : "false",
"bootargs" : "",
"bootdisk" : {
"blocksize" : "4K",
"path" : "rpool/vms/rcon1/disk0",
"size" : "10G",
"sparse" : "false"
},
"bootorder" : "cd",
"bootrom" : "BHYVE_RELEASE",
"brand" : "bhyve",
"diskif" : "nvme",
"fs-allowed" : "",
"hostbridge" : "i440fx",
"hostid" : "",
"ip-type" : "exclusive",
"limitpriv" : "default",
"net" : [
{
"global-nic" : "ixgbe0",
"mac-addr" : "00:22:06:eb:5c:9f",
"physical" : "rcon1",
"vlan-id" : "110"
}
],
"netif" : "virtio-net",
"pool" : "",
"ppt" : [
"ppt0"
],
"ram" : "1G",
"rng" : "on",
"scheduling-class" : "",
"type" : "generic",
"vcpus" : "1,sockets=1,cores=1,threads=1",
"vga" : "off",
"vnc" : "off",
"xhci" : "off",
"zonename" : "rcon1",
"zonepath" : "/zones/rcon1"
}
{
"acpi" : "on",
"autoboot" : "false",
"bootargs" : "",
"bootdisk" : {
"blocksize" : "4K",
"path" : "rpool/vms/rcon2/disk0",
"size" : "10G",
"sparse" : "false"
},
"bootorder" : "cd",
"bootrom" : "BHYVE_RELEASE",
"brand" : "bhyve",
"diskif" : "nvme",
"fs-allowed" : "",
"hostbridge" : "i440fx",
"hostid" : "",
"ip-type" : "exclusive",
"limitpriv" : "default",
"net" : [
{
"global-nic" : "ixgbe0",
"mac-addr" : "00:22:06:ae:a3:64",
"physical" : "rcon2",
"vlan-id" : "110"
}
],
"netif" : "virtio-net",
"pool" : "",
"ppt" : [
"ppt1"
],
"ram" : "1G",
"rng" : "on",
"scheduling-class" : "",
"type" : "generic",
"vcpus" : "1,sockets=1,cores=1,threads=1",
"vga" : "off",
"vnc" : "off",
"xhci" : "off",
"zonename" : "rcon2",
"zonepath" : "/zones/rcon2"
}
{
"devices": [
{"dev":"/dev/ppt0","path":"/pci@5e,0/pci8086,2032@2/pci12d8,8608@0/pci12d8,8608@1/pci1912,15@0","vendor-id":"1912","device-id":"15","subsystem-vendor-id":"1912","subsystem-id":"15","revision-id":"2","label":"Renesas Technology Corp. uPD720202 USB 3.0 Host Controller"},
{"dev":"/dev/ppt1","path":"/pci@5e,0/pci8086,2032@2/pci12d8,8608@0/pci12d8,8608@5/pci1912,15@0","vendor-id":"1912","device-id":"15","subsystem-vendor-id":"1912","subsystem-id":"15","revision-id":"2","label":"Renesas Technology Corp. uPD720202 USB 3.0 Host Controller"},
{"dev":"/dev/ppt2","path":"/pci@5e,0/pci8086,2032@2/pci12d8,8608@0/pci12d8,8608@7/pci1912,15@0","vendor-id":"1912","device-id":"15","subsystem-vendor-id":"1912","subsystem-id":"15","revision-id":"2","label":"Renesas Technology Corp. uPD720202 USB 3.0 Host Controller"},
{"dev":"/dev/ppt3","path":"/pci@5e,0/pci8086,2032@2/pci12d8,8608@0/pci12d8,8608@9/pci1912,15@0","vendor-id":"1912","device-id":"15","subsystem-vendor-id":"1912","subsystem-id":"15","revision-id":"2","label":"Renesas Technology Corp. uPD720202 USB 3.0 Host Controller"},
{"dev":"/dev/ppt4","path":"/pci@5e,0/pci8086,2030@0/pci8086,37c0@0/pci8086,37c5@3/pci15d9,37d2@0","vendor-id":"8086","device-id":"37d2","subsystem-vendor-id":"15d9","subsystem-id":"37d2","revision-id":"9","label":"Intel Corporation Ethernet Connection X722 for 10GBASE-T"},
{"dev":"/dev/ppt5","path":"/pci@5e,0/pci8086,2030@0/pci8086,37c0@0/pci8086,37c5@3/pci15d9,37d2@0,1","vendor-id":"8086","device-id":"37d2","subsystem-vendor-id":"15d9","subsystem-id":"37d2","revision-id":"9","label":"Intel Corporation Ethernet Connection X722 for 10GBASE-T"}
]
}
#
# Generated from zone configuration
#
acpi_tables=false
memory.size=1G
memory.wired=true
x86.strictmsr=true
x86.vmexit_on_hlt=true
uuid=2ac52335-162b-c06b-d9c0-e0eff49d4b59
smbios.manufacturer=OmniOS
smbios.product=OmniOS HVM
smbios.version=1.0
smbios.serial=2ac52335-162b-c06b-d9c0-e0eff49d4b59
smbios.sku=001
smbios.family=Virtual Machine
cpus=1
sockets=1
cores=1
threads=1
lpc.bootrom=/usr/share/bhyve/firmware/BHYVE_RELEASE.fd
lpc.com1.path=/dev/zconsole
pci.0.0.0.device=hostbridge
pci.0.0.0.model=i440fx
pci.0.1.0.device=lpc
pci.0.4.0.device=nvme
pci.0.4.0.path=/dev/zvol/rdsk/rpool/vms/rcon1/disk0
pci.0.6.0.device=virtio-net
pci.0.6.0.backend=dlpi
pci.0.6.0.vnic=rcon1
pci.0.9.0.device=passthru
pci.0.9.0.path=/dev/ppt0
pci.0.10.0.device=virtio-rnd
name=rcon1
# Generated from zone configuration
#
acpi_tables=false
memory.size=1G
memory.wired=true
x86.strictmsr=true
x86.vmexit_on_hlt=true
uuid=17f57668-b2b9-c188-dac6-e44919140731
smbios.manufacturer=OmniOS
smbios.product=OmniOS HVM
smbios.version=1.0
smbios.serial=17f57668-b2b9-c188-dac6-e44919140731
smbios.sku=001
smbios.family=Virtual Machine
cpus=1
sockets=1
cores=1
threads=1
lpc.bootrom=/usr/share/bhyve/firmware/BHYVE_RELEASE.fd
lpc.com1.path=/dev/zconsole
pci.0.0.0.device=hostbridge
pci.0.0.0.model=i440fx
pci.0.1.0.device=lpc
pci.0.4.0.device=nvme
pci.0.4.0.path=/dev/zvol/rdsk/rpool/vms/rcon2/disk0
pci.0.6.0.device=virtio-net
pci.0.6.0.backend=dlpi
pci.0.6.0.vnic=rcon2
pci.0.9.1.device=passthru
pci.0.9.1.path=/dev/ppt1
pci.0.10.0.device=virtio-rnd
name=rcon2
And here we see our problem! The non working VM has:
pci.0.9.1.device=passthru
pci.0.9.1.path=/dev/ppt1
There is nothing in function 0 (0.9.0
) so bhyve ignores this device as it always needs to start at function 0.
At present, we have two distinct operations:
pkg install
, which can add packages to a system, or change the installed version to a specific (perhaps older!) version or even a version from a specific other publisherpkg uninstall
, which removes packages from the systemSometimes, when trying to move between production and development bits, it seems that it can be impossible to get from the current state to an intended target state because these two distinct operations may require the transition through an illegal state to get to the legal target state. For example:
newthing
) was added to a development version of illumos-gate, which is depended upon by SUNWcs
, and version-locked through osnet-incorporation
osnet-incorporation
newthing
that can be installed, now, because it only exists in the version of the OS bits that we already haveWhat we would like to be able to do is something like:
pkg modify -v +osnet-incorporation@$oldversion -newthing
This would attempt, as a single operation, to change the osnet-incorporation
version (which would also end up changing the version of most OS packages like SUNWcs
) and concurrently remove newthing
from the image. The target state should then be legal, and there should be no need to move through an invalid intermediate state to get there.
The manual doesn't mention the abort
operation. It does mention an exit
operation that seems perhaps a superset, but then does go on to talk about the behaviour of -O
and -P
in the case of an abort operation.
If abort
isn't obselete in favour of exit
(?) it should be documented
This seems to happen when looking at package information summery.
Seems to match the following bug in OpenIndiana: https://www.illumos.org/issues/12742
fixed by the following commit: OpenIndiana/pkg5@8b58c72
Merging arm64-gate to illumos-gate this morning, I hit upon changes to pkg:/system/ficl that completely mis-sorted the manifest.
I think this is because the conditions for $(i386_ONLY) are followed by spaces, and so they get sorted to the top as if they were different actions file
dir
etc. They shouldn't, pkgfmt should eat that whitespace or something.
I am aware that this is likely at best difficult and at worst impossible to coordinate an update to fix, given that illumos-gate enforces this and distribution-drift would be difficult to deal with, but thought it should be recorded.
for posterity, what pkgfmt does is this
#
# The default for payload-bearing actions in this package is to appear in the
# global zone only. See the include file for greater detail, as well as
# information about overriding the defaults.
#
$(i386_ONLY) dir path=usr/bin group=bin
$(i386_ONLY) dir path=usr/bin/$(ARCH32) group=bin
$(i386_ONLY) file path=usr/bin/$(ARCH32)/ficl-sys group=sys mode=0555
$(i386_ONLY) file path=usr/bin/ficl-sys group=sys mode=0555
set name=pkg.fmri \
value=pkg:/system/[email protected],$(PKGVERS_BUILTON)-$(PKGVERS_BRANCH)
set name=pkg.summary value="FICL Forth Implementation"
set name=pkg.description value="Forth Inspired Command Language"
set name=info.classification value=org.opensolaris.category.2008:System/Core
set name=variant.arch value=$(ARCH)
dir path=usr group=sys
dir path=usr/lib group=bin
dir path=usr/lib/$(ARCH64) group=bin
file path=usr/lib/$(ARCH64)/libficl-sys.so.4.1.0 group=sys mode=0755
file path=usr/lib/libficl-sys.so.4.1.0 group=sys mode=0755
license lic_CDDL license=lic_CDDL
license usr/src/common/ficl/LICENSE license=usr/src/common/ficl/LICENSE
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.