> > Thanks. Maybe more feedback will come.
>
> I hope so.
FWIW, I'm an occasional wacom user, but my device is not supported by
OpenBSD, so I can't try the patch. I don't know how hard it would be to
add support.
If it's likely to be an easy change and someone can point me to the
place to make t
> The array "base" which is passed to log_warnx might be uninitialized:
> virtio_get_base doesn't necessarily touch it if it returns -1. Maybe it
> would be better just omit base from the output, e.g.
>
> log_warnx("vm \"%s\" unable to read "
> "base for disk %s", vcp->vcp_name,
>
Hi tech@,
I'm looking at this code starting at line 390 of usr.sbin/vmd/config.c:
n = virtio_get_base(diskfds[i][j], base, sizeof(base),
vmc->vmc_disktypes[i], path);
if (n == 0)
break;
if (n == -1) {
log_warnx("vm \"%s\" unable
Hi tech@,
The below patch removes calls to realpath(3) when looking up a qcow2
base image. Previous thread:
https://marc.info/?t=16156249642&r=1&w=2
In short, the calls were failing inside vmctl, because of unveil. The
other thread has alternative solutions but I think this is simplest.
I in
> > Another thought --- is it necessary to call realpath at all?
>
> Yes, vmd(8) will break if you remove it.
>
> The caveat here is vmd(8) uses realpath and works with realpath, so the
> issue is really vmctl(8). I'm guessing in your test run you ran vmd from
> the directory with the disk image.
> Another thought --- is it necessary to call realpath at all?
>
> --
> James
This patch seems to fix the problem --- just don't call realpath. Maybe
I'm missing something?
I briefly tested vmd as well (just quickly booted up an instance that
uses a qcow2 disk image with a local path to a base
On Sun, Mar 14, 2021 at 12:50:52AM +, James Cook wrote:
> > >>
> > >> I believe the correct fix here is to unveil the base image in the
> > >> virtio_qcow2_get_base function in vioqcow2.c and not move around all the
> > >> unveil calls like
> >>
> >> I believe the correct fix here is to unveil the base image in the
> >> virtio_qcow2_get_base function in vioqcow2.c and not move around all the
> >> unveil calls like you're doing. There's no reason to postpone them.
> >>
> >> I think virtio_qcow2_get_base is only used by vmctl (haven't c
On Sat, Mar 13, 2021 at 08:34:24AM -0500, Dave Voutila wrote:
>
> James Cook writes:
>
> > Currently, "vmctl create -i source.qcow2 dest.qcow" fails when
> > source.qcow2 has a base image, because virtio_qcow2_get_base calls
> > realpath which doesn't in
On Sat, Mar 13, 2021 at 08:40:03AM +, James Cook wrote:
> Currently, "vmctl create -i source.qcow2 dest.qcow" fails when
> source.qcow2 has a base image, because virtio_qcow2_get_base calls
> realpath which doesn't interact well with unveil.
>
> The below patch
Currently, "vmctl create -i source.qcow2 dest.qcow" fails when
source.qcow2 has a base image, because virtio_qcow2_get_base calls
realpath which doesn't interact well with unveil.
The below patch fixes it by delaying the first call to unveil. Caveat:
I have never worked with unveil or any of this
The usr.sbin/vmd/diskfmt regression test was broken, and also
apparently never got listed in the parent Makefile.
Caveat: The test creates a couple of fairly large files; e.g. my own /usr/src
wasn't big enough for them. (Is that why the test was never enabled?)
$ du -ah scribble.*
948Mscri
12 matches
Mail list logo
