ldomctl: segfault on repeated init-system invocation

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

ldomctl: segfault on repeated init-system invocation

Klemens Nanni-2
Following the EXAMPLES section in ldomctl(8) to the letter, ldomctl
dumps core when issuing the `init-system' command for an already
existing logical domain configuration.

How to reproduce on a T5220 running latest snapshots (transscript):

        # ldomctl list
        factory-default [current]
        # mkdir factory-default
        # cd factory-default
        # ldomctl dump
        # cd ..
        # cp -R factory-default openbsd
        # cd openbsd
        # cat >ldom.conf
                domain puffy {
                vcpu 8
                memory 2G
                vdisk "/home/kn/puffy.img"
                vnet
        }
        # ldomctl init-system ldom.conf
        # vi ldom.conf # adjust
        # ldomctl init-system ldom.conf
        Segmentation fault

Sorry for the sparse report: wanted to report this before monday but the
machine is down already.

Reply | Threaded
Open this post in threaded view
|

Re: ldomctl: segfault on repeated init-system invocation

Stefan Sperling-5
On Mon, Apr 09, 2018 at 12:56:04AM +0200, Klemens Nanni wrote:

> Following the EXAMPLES section in ldomctl(8) to the letter, ldomctl
> dumps core when issuing the `init-system' command for an already
> existing logical domain configuration.
>
> How to reproduce on a T5220 running latest snapshots (transscript):
>
> # ldomctl list
> factory-default [current]
> # mkdir factory-default
> # cd factory-default
> # ldomctl dump
> # cd ..
> # cp -R factory-default openbsd
> # cd openbsd
> # cat >ldom.conf
> domain puffy {
> vcpu 8
> memory 2G
> vdisk "/home/kn/puffy.img"
> vnet
> }
> # ldomctl init-system ldom.conf
> # vi ldom.conf # adjust
> # ldomctl init-system ldom.conf
> Segmentation fault
>
> Sorry for the sparse report: wanted to report this before monday but the
> machine is down already.

We'd need at least a traceback from the debugger to do anything about this.