Re: vmctl: invalid parent template error
On Mon, Aug 12, 2019 at 06:20:23PM +0200, Anton Lindqvist wrote:
> On Mon, Aug 12, 2019 at 02:52:46PM +0200, Klemens Nanni wrote:
> > On Mon, Aug 12, 2019 at 02:14:42PM +0200, Anton Lindqvist wrote:
> > > Hi,
> > > I recently fat fingered the vm template passed to vmctl and was greeted
> > > with the following error:
> > >
> > > vmctl: start vm command failed: Operation not permitted
> > >
> > > I think we can be more specific in order to improve usability:
> > I agree, but your wording implies the template might be there but vmd
> > failed to find it. Also, "parent" and "template" seems too much; we
> > have no other templates, so may I suggest one of the simpler
> >
> > invalid template
> > template does not exist
> >
>
> Updated diff changing the error message to invalid template.
>
I'm ok with this.
-ml
> Index: vmctl/vmctl.c
> ===
> RCS file: /cvs/src/usr.sbin/vmctl/vmctl.c,v
> retrieving revision 1.69
> diff -u -p -r1.69 vmctl.c
> --- vmctl/vmctl.c 22 May 2019 16:19:21 - 1.69
> +++ vmctl/vmctl.c 12 Aug 2019 16:18:22 -
> @@ -249,6 +249,10 @@ vm_start_complete(struct imsg *imsg, int
> "file");
> *ret = ENOENT;
> break;
> + case VMD_PARENT_INVALID:
> + warnx("invalid template");
> + *ret = EINVAL;
> + break;
> default:
> errno = res;
> warn("start vm command failed");
> Index: vmd/vmd.c
> ===
> RCS file: /cvs/src/usr.sbin/vmd/vmd.c,v
> retrieving revision 1.114
> diff -u -p -r1.114 vmd.c
> --- vmd/vmd.c 28 Jun 2019 13:32:51 - 1.114
> +++ vmd/vmd.c 12 Aug 2019 16:18:22 -
> @@ -1373,8 +1373,13 @@ vm_instance(struct privsep *ps, struct v
>
> /* return without error if the parent is NULL (nothing to inherit) */
> if ((vmc->vmc_flags & VMOP_CREATE_INSTANCE) == 0 ||
> - (*vm_parent = vm_getbyname(vmc->vmc_instance)) == NULL)
> + vmc->vmc_instance[0] == '\0')
> return (0);
> +
> + if ((*vm_parent = vm_getbyname(vmc->vmc_instance)) == NULL) {
> + errno = VMD_PARENT_INVALID;
> + return (-1);
> + }
>
> errno = 0;
> vmcp = &(*vm_parent)->vm_params;
> Index: vmd/vmd.h
> ===
> RCS file: /cvs/src/usr.sbin/vmd/vmd.h,v
> retrieving revision 1.95
> diff -u -p -r1.95 vmd.h
> --- vmd/vmd.h 17 Jul 2019 05:51:07 - 1.95
> +++ vmd/vmd.h 12 Aug 2019 16:18:22 -
> @@ -72,6 +72,7 @@
> #define VMD_VM_STOP_INVALID 1004
> #define VMD_CDROM_MISSING1005
> #define VMD_CDROM_INVALID1006
> +#define VMD_PARENT_INVALID 1007
>
> /* Image file signatures */
> #define VM_MAGIC_QCOW"QFI\xfb"
>
Re: Fix a segmentation fault in awk
Frederic Cambus [f...@statdns.com] wrote: > > [1] http://distcache.FreeBSD.org/ports-distfiles/nawk-20121220/awk.tar.gz > Following the lack of hosting from Bell Labs, the post-2012 tree is on Github. Brian Kernighan's page now points to: https://github.com/onetrueawk/awk Looking through the history it includes some fixes from OpenBSD. Chris
Re: Fix a segmentation fault in awk
Andras Farkas [deepbluemist...@gmail.com] wrote: > On Mon, Aug 12, 2019 at 3:45 PM Frederic Cambus wrote: > > Hi tech@, > > Here is a diff to fix a segmentation fault in awk, from upstream > > version 20121220 [1]. Upstream fix didn't check for strdup return value > > so I added the check. > I've always been curious, why isn't the latest version of awk, the > 2012 version, used in OpenBSD? There may be a reason, but I've never > been able to figure it out. Ironically the last update was in 2011. Todd Miller has been keeping it up-to- date until that point. It'd make sense for someone to analyze the local changes and import the newer version. The only reason seems to be that the work needs to be done. Importing the fix is a good first step. Chris
Re: pms: add extra ic type for elantech ps/2 touchpads
Hi Alexander, thanks for these hints and the diff. I think if we add those ic types, pms should also identify the models with hardware buttons properly (not all v4 models are clickpads). This looks like a trivial extension, I will propose a patch soon. On 8/11/19 6:55 PM, Alexander Cronheim wrote: > A little more information after looking around a bit. > > The linux [1] and freebsd [2] drivers accept all elantech touchpads > with ic types from 6 up to 15 as using the v4 protocol. > > The following patch extends the accepted ic types to that > range (from the current set consisting of 6, 8, and 15). > > I cannot, however, test touchpads with ic types other than 13. > > 1. > https://github.com/torvalds/linux/commit/10d900303f1c3a821eb0bef4e7b7ece16768fba4#diff-e91bc4802c6797fe9acbdca0ed240be9 > 2. > https://github.com/freebsd/freebsd/commit/8b5fc46c359e276d4545b531a3d3eb15762d1783#diff-fac99891d1c5da0f566dbcc68ba62b22 > > Index: pms.c > === > RCS file: /cvs/src/sys/dev/pckbc/pms.c,v > retrieving revision 1.88 > diff -u -p -r1.88 pms.c > --- pms.c 26 Jan 2019 11:57:21 - 1.88 > +++ pms.c 11 Aug 2019 16:36:30 - > @@ -1945,9 +1945,7 @@ elantech_get_hwinfo_v4(struct pms_softc > if (synaptics_query(sc, ELANTECH_QUE_FW_VER, _version)) > return (-1); > > - if ((fw_version & 0x0f) >> 16 != 6 > - && (fw_version & 0x0f) >> 16 != 8 > - && (fw_version & 0x0f) >> 16 != 15) > + if ((fw_version & 0x0f) >> 16 < 6) > return (-1); > > elantech->fw_version = fw_version; > >
Re: Fix a segmentation fault in awk
On Mon, Aug 12, 2019 at 3:45 PM Frederic Cambus wrote: > Hi tech@, > Here is a diff to fix a segmentation fault in awk, from upstream > version 20121220 [1]. Upstream fix didn't check for strdup return value > so I added the check. I've always been curious, why isn't the latest version of awk, the 2012 version, used in OpenBSD? There may be a reason, but I've never been able to figure it out.
Fix a segmentation fault in awk
Hi tech@,
Here is a diff to fix a segmentation fault in awk, from upstream
version 20121220 [1]. Upstream fix didn't check for strdup return value
so I added the check.
I've been seeing some awk.core files in my home directory for a while
now, and finally decided to try investigating why it happened. It turns
out misc/mc calls awk to process file information when navigating through
ZIP files, and it sometimes causes awk to segfault.
[1] http://distcache.FreeBSD.org/ports-distfiles/nawk-20121220/awk.tar.gz
Comments? OK?
Index: usr.bin/awk/run.c
===
RCS file: /cvs/src/usr.bin/awk/run.c,v
retrieving revision 1.42
diff -u -p -r1.42 run.c
--- usr.bin/awk/run.c 9 Oct 2017 14:51:31 - 1.42
+++ usr.bin/awk/run.c 12 Aug 2019 18:01:14 -
@@ -1217,13 +1217,15 @@ Cell *dopa2(Node **a, int n)/* a[0], a[
Cell *split(Node **a, int nnn) /* split(a[0], a[1], a[2]); a[3] is type */
{
Cell *x = 0, *y, *ap;
- char *s;
+ char *s, *origs;
int sep;
char *t, temp, num[50], *fs = 0;
int n, tempstat, arg3type;
y = execute(a[0]); /* source string */
- s = getsval(y);
+ origs = s = strdup(getsval(y));
+ if (s == NULL)
+ FATAL("out of space in split");
arg3type = ptoi(a[3]);
if (a[2] == 0) /* fs string */
fs = *FS;
@@ -1343,6 +1345,7 @@ Cell *split(Node **a, int nnn)/* split(
}
tempfree(ap);
tempfree(y);
+ free(origs);
if (a[2] != 0 && arg3type == STRING) {
tempfree(x);
}
Re: bgpd reset idle hold values on neighbor clear
+1 from a lowly user :)
On Mon, 12 Aug 2019 at 15:43, Stuart Henderson wrote:
>
> On 2019/08/12 16:18, Claudio Jeker wrote:
> > I just changed the way IdleHold time is reset to the default values.
> > Another place I think it makes sense to reset these backoff values is
> > when an admin issues a bgpctl nei 192.0.2.2 clear or up.
> >
> > This should help bringing sessions up between systems after instabilities
> > (or in my case when testing too much and therefor reseting the session
> > over and over again).
> >
> > OK?
>
> Been there done that - yes please! OK.
>
> > --
> > :wq Claudio
> >
> > Index: control.c
> > ===
> > RCS file: /cvs/src/usr.sbin/bgpd/control.c,v
> > retrieving revision 1.98
> > diff -u -p -r1.98 control.c
> > --- control.c 8 Aug 2019 20:06:29 - 1.98
> > +++ control.c 12 Aug 2019 14:11:12 -
> > @@ -376,6 +376,9 @@ control_dispatch_msg(struct pollfd *pfd,
> > bgp_fsm(p, EVNT_START);
> > p->conf.down = 0;
> > p->conf.shutcomm[0] = '\0';
> > + p->IdleHoldTime =
> > + INTERVAL_IDLE_HOLD_INITIAL;
> > + p->errcnt = 0;
> > control_result(c, CTL_RES_OK);
> > break;
> > case IMSG_CTL_NEIGHBOR_DOWN:
> > @@ -390,6 +393,9 @@ control_dispatch_msg(struct pollfd *pfd,
> > strlcpy(p->conf.shutcomm,
> > neighbor->shutcomm,
> > sizeof(neighbor->shutcomm));
> > + p->IdleHoldTime =
> > + INTERVAL_IDLE_HOLD_INITIAL;
> > + p->errcnt = 0;
> > if (!p->conf.down) {
> > session_stop(p,
> > ERR_CEASE_ADMIN_RESET);
> >
>
--
Kindest regards,
Tom Smyth.
Re: iked(8): move CERTREQ handler out of parser
One more update: I moved to ikev2_handle_certreq() calls somewhere else where
they fit better.
I'd be happy to get some feedback from different iked setups,
in my tests all seems to work as intended. In the best case you
won't notice any difference at all (only the CERTREQ handling will
happen a bit later in recv function).
Here is the diff:
Index: iked.h
===
RCS file: /mount/openbsd/cvs/src/sbin/iked/iked.h,v
retrieving revision 1.121
diff -u -p -u -r1.121 iked.h
--- iked.h 11 May 2019 16:30:23 - 1.121
+++ iked.h 12 Aug 2019 15:19:56 -
@@ -536,6 +536,10 @@ struct iked_message {
struct iked_id msg_cert;
struct ibuf *msg_cookie;
+ uint8_t msg_certreq_type; /* CR Encoding*/
+ struct ibuf *msg_certreq_auth; /* CR Authority */
+ struct ibuf *msg_certreq_ocsp; /* CR OCSP values */
+
/* MOBIKE */
int msg_update_sa_addresses;
struct ibuf *msg_cookie2;
Index: ikev2.c
===
RCS file: /mount/openbsd/cvs/src/sbin/iked/ikev2.c,v
retrieving revision 1.171
diff -u -p -u -r1.171 ikev2.c
--- ikev2.c 11 May 2019 16:30:23 - 1.171
+++ ikev2.c 12 Aug 2019 16:03:46 -
@@ -82,6 +82,8 @@ intikev2_send_error(struct iked *, str
struct iked_message *, uint8_t);
int ikev2_send_init_error(struct iked *, struct iked_message *);
+int ikev2_handle_certreq(struct iked*, struct iked_message *);
+
int ikev2_send_create_child_sa(struct iked *, struct iked_sa *,
struct iked_spi *, uint8_t);
int ikev2_ikesa_enable(struct iked *, struct iked_sa *, struct iked_sa *);
@@ -874,6 +876,9 @@ ikev2_init_recv(struct iked *env, struct
"IKE_SA_INIT exchange", __func__);
break;
}
+ if (ikev2_handle_certreq(env, msg) != 0)
+ return;
+
(void)ikev2_init_auth(env, msg);
break;
case IKEV2_EXCHANGE_IKE_AUTH:
@@ -2384,6 +2389,9 @@ ikev2_resp_recv(struct iked *env, struct
sa->sa_policy->pol_auth.auth_eap)
sa_state(env, sa, IKEV2_STATE_EAP);
+ if (ikev2_handle_certreq(env, msg) != 0)
+ return;
+
if (ikev2_ike_auth_recv(env, sa, msg) != 0) {
log_debug("%s: failed to send auth response", __func__);
ikev2_send_error(env, sa, msg, hdr->ike_exchange);
@@ -2996,6 +3004,46 @@ ikev2_set_sa_proposal(struct iked_sa *sa
return (-1);
}
}
+ return (0);
+}
+
+int
+ikev2_handle_certreq(struct iked* env, struct iked_message *msg)
+{
+ struct iked_sa *sa;
+
+ if ((sa = msg->msg_sa) == NULL)
+ return (-1);
+
+ if (msg->msg_certreq_type != IKEV2_CERT_NONE) {
+ /* Optional certreq for PSK */
+ if (sa->sa_hdr.sh_initiator)
+ sa->sa_stateinit |= IKED_REQ_CERT;
+ else
+ sa->sa_statevalid |= IKED_REQ_CERT;
+
+ ca_setreq(env, sa, >sa_policy->pol_localid,
+ msg->msg_certreq_type,
+ ibuf_data(msg->msg_certreq_auth),
+ ibuf_length(msg->msg_certreq_auth),
+ PROC_CERT);
+ }
+
+ if (msg->msg_certreq_ocsp != NULL) {
+ ca_setreq(env, sa, >sa_policy->pol_localid,
+ IKEV2_CERT_OCSP,
+ ibuf_data(msg->msg_certreq_auth),
+ ibuf_length(msg->msg_certreq_auth),
+ PROC_CERT);
+ }
+
+ /* Cleanup */
+ ibuf_release(msg->msg_certreq_auth);
+ msg->msg_certreq_auth = NULL;
+ ibuf_release(msg->msg_certreq_ocsp);
+ msg->msg_certreq_ocsp = NULL;
+ msg->msg_certreq_type = IKEV2_CERT_NONE;
+
return (0);
}
Index: ikev2_pld.c
===
RCS file: /mount/openbsd/cvs/src/sbin/iked/ikev2_pld.c,v
retrieving revision 1.71
diff -u -p -u -r1.71 ikev2_pld.c
--- ikev2_pld.c 11 May 2019 16:30:23 - 1.71
+++ ikev2_pld.c 12 Aug 2019 15:52:02 -
@@ -826,7 +826,6 @@ int
ikev2_pld_certreq(struct iked *env, struct ikev2_payload *pld,
struct iked_message *msg, size_t offset, size_t left)
{
- struct iked_sa *sa = msg->msg_sa;
struct ikev2_certcert;
uint8_t *buf;
ssize_t len;
@@ -847,27 +846,39 @@ ikev2_pld_certreq(struct iked *env, stru
if (!ikev2_msg_frompeer(msg))
return (0);
- if (cert.cert_type == IKEV2_CERT_X509_CERT) {
-
Re: vmctl: invalid parent template error
On Mon, Aug 12, 2019 at 02:52:46PM +0200, Klemens Nanni wrote:
> On Mon, Aug 12, 2019 at 02:14:42PM +0200, Anton Lindqvist wrote:
> > Hi,
> > I recently fat fingered the vm template passed to vmctl and was greeted
> > with the following error:
> >
> > vmctl: start vm command failed: Operation not permitted
> >
> > I think we can be more specific in order to improve usability:
> I agree, but your wording implies the template might be there but vmd
> failed to find it. Also, "parent" and "template" seems too much; we
> have no other templates, so may I suggest one of the simpler
>
> invalid template
> template does not exist
>
Updated diff changing the error message to invalid template.
Index: vmctl/vmctl.c
===
RCS file: /cvs/src/usr.sbin/vmctl/vmctl.c,v
retrieving revision 1.69
diff -u -p -r1.69 vmctl.c
--- vmctl/vmctl.c 22 May 2019 16:19:21 - 1.69
+++ vmctl/vmctl.c 12 Aug 2019 16:18:22 -
@@ -249,6 +249,10 @@ vm_start_complete(struct imsg *imsg, int
"file");
*ret = ENOENT;
break;
+ case VMD_PARENT_INVALID:
+ warnx("invalid template");
+ *ret = EINVAL;
+ break;
default:
errno = res;
warn("start vm command failed");
Index: vmd/vmd.c
===
RCS file: /cvs/src/usr.sbin/vmd/vmd.c,v
retrieving revision 1.114
diff -u -p -r1.114 vmd.c
--- vmd/vmd.c 28 Jun 2019 13:32:51 - 1.114
+++ vmd/vmd.c 12 Aug 2019 16:18:22 -
@@ -1373,8 +1373,13 @@ vm_instance(struct privsep *ps, struct v
/* return without error if the parent is NULL (nothing to inherit) */
if ((vmc->vmc_flags & VMOP_CREATE_INSTANCE) == 0 ||
- (*vm_parent = vm_getbyname(vmc->vmc_instance)) == NULL)
+ vmc->vmc_instance[0] == '\0')
return (0);
+
+ if ((*vm_parent = vm_getbyname(vmc->vmc_instance)) == NULL) {
+ errno = VMD_PARENT_INVALID;
+ return (-1);
+ }
errno = 0;
vmcp = &(*vm_parent)->vm_params;
Index: vmd/vmd.h
===
RCS file: /cvs/src/usr.sbin/vmd/vmd.h,v
retrieving revision 1.95
diff -u -p -r1.95 vmd.h
--- vmd/vmd.h 17 Jul 2019 05:51:07 - 1.95
+++ vmd/vmd.h 12 Aug 2019 16:18:22 -
@@ -72,6 +72,7 @@
#define VMD_VM_STOP_INVALID1004
#define VMD_CDROM_MISSING 1005
#define VMD_CDROM_INVALID 1006
+#define VMD_PARENT_INVALID 1007
/* Image file signatures */
#define VM_MAGIC_QCOW "QFI\xfb"
Re: bgpd reset idle hold values on neighbor clear
On 2019/08/12 16:18, Claudio Jeker wrote:
> I just changed the way IdleHold time is reset to the default values.
> Another place I think it makes sense to reset these backoff values is
> when an admin issues a bgpctl nei 192.0.2.2 clear or up.
>
> This should help bringing sessions up between systems after instabilities
> (or in my case when testing too much and therefor reseting the session
> over and over again).
>
> OK?
Been there done that - yes please! OK.
> --
> :wq Claudio
>
> Index: control.c
> ===
> RCS file: /cvs/src/usr.sbin/bgpd/control.c,v
> retrieving revision 1.98
> diff -u -p -r1.98 control.c
> --- control.c 8 Aug 2019 20:06:29 - 1.98
> +++ control.c 12 Aug 2019 14:11:12 -
> @@ -376,6 +376,9 @@ control_dispatch_msg(struct pollfd *pfd,
> bgp_fsm(p, EVNT_START);
> p->conf.down = 0;
> p->conf.shutcomm[0] = '\0';
> + p->IdleHoldTime =
> + INTERVAL_IDLE_HOLD_INITIAL;
> + p->errcnt = 0;
> control_result(c, CTL_RES_OK);
> break;
> case IMSG_CTL_NEIGHBOR_DOWN:
> @@ -390,6 +393,9 @@ control_dispatch_msg(struct pollfd *pfd,
> strlcpy(p->conf.shutcomm,
> neighbor->shutcomm,
> sizeof(neighbor->shutcomm));
> + p->IdleHoldTime =
> + INTERVAL_IDLE_HOLD_INITIAL;
> + p->errcnt = 0;
> if (!p->conf.down) {
> session_stop(p,
> ERR_CEASE_ADMIN_RESET);
>
Re: bgpd reset idle hold values on neighbor clear
Gee, I just sent you a private email about exactly that :)
I fully support that. Otherwise the workflow includes a piece of
"did it really come back up? Oh I better check. Oh it didn't,
I have to down it then up it"
And then, between the check and forcing it down, it may in fact
have come up!
Claudio Jeker wrote:
> I just changed the way IdleHold time is reset to the default values.
> Another place I think it makes sense to reset these backoff values is
> when an admin issues a bgpctl nei 192.0.2.2 clear or up.
>
> This should help bringing sessions up between systems after instabilities
> (or in my case when testing too much and therefor reseting the session
> over and over again).
>
> OK?
> --
> :wq Claudio
>
> Index: control.c
> ===
> RCS file: /cvs/src/usr.sbin/bgpd/control.c,v
> retrieving revision 1.98
> diff -u -p -r1.98 control.c
> --- control.c 8 Aug 2019 20:06:29 - 1.98
> +++ control.c 12 Aug 2019 14:11:12 -
> @@ -376,6 +376,9 @@ control_dispatch_msg(struct pollfd *pfd,
> bgp_fsm(p, EVNT_START);
> p->conf.down = 0;
> p->conf.shutcomm[0] = '\0';
> + p->IdleHoldTime =
> + INTERVAL_IDLE_HOLD_INITIAL;
> + p->errcnt = 0;
> control_result(c, CTL_RES_OK);
> break;
> case IMSG_CTL_NEIGHBOR_DOWN:
> @@ -390,6 +393,9 @@ control_dispatch_msg(struct pollfd *pfd,
> strlcpy(p->conf.shutcomm,
> neighbor->shutcomm,
> sizeof(neighbor->shutcomm));
> + p->IdleHoldTime =
> + INTERVAL_IDLE_HOLD_INITIAL;
> + p->errcnt = 0;
> if (!p->conf.down) {
> session_stop(p,
> ERR_CEASE_ADMIN_RESET);
>
bgpd reset idle hold values on neighbor clear
I just changed the way IdleHold time is reset to the default values.
Another place I think it makes sense to reset these backoff values is
when an admin issues a bgpctl nei 192.0.2.2 clear or up.
This should help bringing sessions up between systems after instabilities
(or in my case when testing too much and therefor reseting the session
over and over again).
OK?
--
:wq Claudio
Index: control.c
===
RCS file: /cvs/src/usr.sbin/bgpd/control.c,v
retrieving revision 1.98
diff -u -p -r1.98 control.c
--- control.c 8 Aug 2019 20:06:29 - 1.98
+++ control.c 12 Aug 2019 14:11:12 -
@@ -376,6 +376,9 @@ control_dispatch_msg(struct pollfd *pfd,
bgp_fsm(p, EVNT_START);
p->conf.down = 0;
p->conf.shutcomm[0] = '\0';
+ p->IdleHoldTime =
+ INTERVAL_IDLE_HOLD_INITIAL;
+ p->errcnt = 0;
control_result(c, CTL_RES_OK);
break;
case IMSG_CTL_NEIGHBOR_DOWN:
@@ -390,6 +393,9 @@ control_dispatch_msg(struct pollfd *pfd,
strlcpy(p->conf.shutcomm,
neighbor->shutcomm,
sizeof(neighbor->shutcomm));
+ p->IdleHoldTime =
+ INTERVAL_IDLE_HOLD_INITIAL;
+ p->errcnt = 0;
if (!p->conf.down) {
session_stop(p,
ERR_CEASE_ADMIN_RESET);
Re: arm64 glass console
> Date: Mon, 12 Aug 2019 14:17:55 +0200 > From: Krystian Lewandowski > > Hi, > had a chance to build efiboot with the patch eventually. > > Works fine on: > - Pinebook 11" (1080p) > - A64+ with 1080p display via HDMI Thanks! I have committed a axppmic(4) diff based on your code for the battery sensors. However, it will only enable the additional sensors if you have a very recent Linux device tree (not packaged yet). If you know how to build device trees from the Linux source tree, you could try that out. But please be aware that you need the kernel changes I made over the weekend for that to work. If you want to test my changes (I might have broken something) it is probably easier quickly add the driver and add something like: sc->sc_sensdata = axp803_battery_sensdata; in axppmic_attach_common(). Cheers, Mark
Re: arm64 glass console
Hi, had a chance to build efiboot with the patch eventually. Works fine on: - Pinebook 11" (1080p) - A64+ with 1080p display via HDMI -- Krystian
Re: vmctl: invalid parent template error
On Mon, Aug 12, 2019 at 02:14:42PM +0200, Anton Lindqvist wrote: > Hi, > I recently fat fingered the vm template passed to vmctl and was greeted > with the following error: > > vmctl: start vm command failed: Operation not permitted > > I think we can be more specific in order to improve usability: I agree, but your wording implies the template might be there but vmd failed to find it. Also, "parent" and "template" seems too much; we have no other templates, so may I suggest one of the simpler invalid template template does not exist
vmctl: invalid parent template error
Hi,
I recently fat fingered the vm template passed to vmctl and was greeted
with the following error:
vmctl: start vm command failed: Operation not permitted
I think we can be more specific in order to improve usability:
vmctl: could not find specified parent template
Comments? OK?
Index: vmctl/vmctl.c
===
RCS file: /cvs/src/usr.sbin/vmctl/vmctl.c,v
retrieving revision 1.69
diff -u -p -r1.69 vmctl.c
--- vmctl/vmctl.c 22 May 2019 16:19:21 - 1.69
+++ vmctl/vmctl.c 5 Aug 2019 15:11:38 -
@@ -249,6 +249,10 @@ vm_start_complete(struct imsg *imsg, int
"file");
*ret = ENOENT;
break;
+ case VMD_PARENT_INVALID:
+ warnx("could not find specified parent
template");
+ *ret = EINVAL;
+ break;
default:
errno = res;
warn("start vm command failed");
Index: vmd/vmd.c
===
RCS file: /cvs/src/usr.sbin/vmd/vmd.c,v
retrieving revision 1.114
diff -u -p -r1.114 vmd.c
--- vmd/vmd.c 28 Jun 2019 13:32:51 - 1.114
+++ vmd/vmd.c 5 Aug 2019 15:11:38 -
@@ -1373,8 +1373,13 @@ vm_instance(struct privsep *ps, struct v
/* return without error if the parent is NULL (nothing to inherit) */
if ((vmc->vmc_flags & VMOP_CREATE_INSTANCE) == 0 ||
- (*vm_parent = vm_getbyname(vmc->vmc_instance)) == NULL)
+ vmc->vmc_instance[0] == '\0')
return (0);
+
+ if ((*vm_parent = vm_getbyname(vmc->vmc_instance)) == NULL) {
+ errno = VMD_PARENT_INVALID;
+ return (-1);
+ }
errno = 0;
vmcp = &(*vm_parent)->vm_params;
Index: vmd/vmd.h
===
RCS file: /cvs/src/usr.sbin/vmd/vmd.h,v
retrieving revision 1.95
diff -u -p -r1.95 vmd.h
--- vmd/vmd.h 17 Jul 2019 05:51:07 - 1.95
+++ vmd/vmd.h 5 Aug 2019 15:11:38 -
@@ -72,6 +72,7 @@
#define VMD_VM_STOP_INVALID1004
#define VMD_CDROM_MISSING 1005
#define VMD_CDROM_INVALID 1006
+#define VMD_PARENT_INVALID 1007
/* Image file signatures */
#define VM_MAGIC_QCOW "QFI\xfb"
