Re: [Xen-devel] [PATCH] libxc: don't fail domain creation when unpacking initrd fails

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 16.10.17 at 17:45, <ian.jackson@xxxxxxxxxxxxx> wrote:
> Jan Beulich writes ("[PATCH] libxc: don't fail domain creation when unpacking 
> initrd fails"):
>> At least Linux kernels have been able to work with gzip-ed initrd for
>> quite some time; initrd compressed with other methods aren't even being
>> attempted to unpack. Furthermore the unzip-ing routine used here isn't
>> capable of dealing with various forms of concatenated files, each of
>> which was gzip-ed separately (it is this particular case which has been
>> the source of observed VM creation failures).
> 
> I'm not sure I really like this approach of attempting to ungzip it
> and then falling back.  (And the size-checking logic is not
> particularly easy to follow.)
> 
> Is there no way to tell that a kernel supports gzipped initrds by
> looking at the kernel ?

Well, Linux kernels have config options controlling their ability. So
even a modern kernel _could_ be configured to require unzipping.
I didn't check whether they announce this anywhere outside the
(possibly) embedded .config, but even if they did this would be
only Linux then. A solution here shouldn't really be OS-specific imo.

>  A heuristic would probably do: it's OK if we
> sometimes insist on decompression ourselves, for a subset of old
> kernels where it's not needed.

Well, I specifically wanted to avoid any guesswork. But if I
simply had reported this as a problem that needs dealing with,
things likely would have gone like for the Python version issue
(which I still haven't got around to), asking me to look into
addressing it. So I thought I'd present a possible solution right
away. To be honest, if you want this to be done some
meaningfully different way which I'm not convinced of, I'm not
sure I'm the one to carry this out, yet I'd still request the
issue to be addressed.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel