reassign 839843 lxc-templates 3.0.3-1
thanks
On 2019-01-10 18:12, Pierre-Elliott Bécue wrote:
Matthew, I'm really sorry about the bad experience you've met in 2016.
I
guess you don't have the reply to Christian question three years after.
I'll let the bug open, but I guess it'll never find a solution.
Well, as you surmised I don't have much direct info at this stage, esp.
since this happened on a work machine at a job I have since left.
However looking back at Christian's questions, and comparing that to the
current LXC code and the basics of what I know I was trying to do at the
time, I think I now understand what went wrong.
As you can guess from the directory names, I was working on
instantiating a CentOS container.
Looking at the lxc-centos template in current Buster, I see this code:
##########
revert()
{
echo "Interrupted, so cleaning up"
lxc-destroy -n $name
# maybe was interrupted before copy config
rm -rf $path
echo "exiting..."
exit 1
}
trap revert SIGHUP SIGINT SIGTERM
##########
And now the horror show makes a little more sense. I suspect, in trying
to work out how to change where it created the original rootfs from
being under /var to the destination I wanted (a container-named folder
in that /scratch filesystem), I had used --path /scratch. I probably
then realized it was creating the rootfs as /scratch/rootfs not
/scratch/container-name, and hit Ctrl-C. And that triggered the revert
code above, which ran the rm -rf /scratch.
I note that only some of the templates have this pattern -- archlinux,
centos, fedora, fedora-legacy, pld, and void-linux. The lxc-debian
template does not, though it does have a SIGINT handler, that cleans up
something different and which looks guaranteed to be "safe".
So, I guess this bug needs to be reassigned to lxc-templates. I've
tried to do that above, hopefully I didn't fat finger it :)
