On 10/16/17 11:48 AM, Andrew Cooper wrote:
> On 16/10/17 17:19, Jan Beulich wrote:
> On 16.10.17 at 17:45, wrote:
>
> I've been bitten by this issue several times before, and a fix would be
> nice.
Same here.
>
> IMO, the toolstack should not be making assumptions about the initrd,
> and
>>> On 19.10.17 at 17:06, wrote:
> Jan Beulich writes ("Re: [PATCH] libxc: don't fail domain creation when
> unpacking initrd fails"):
>> On 16.10.17 at 18:43, wrote:
>> > I'm afraid I still find the patch less clear than it could be.
>> > The new semantics of xc_dom_ramdisk_check_size are awkwa
Jan:
> [...] As quite often when changing code I'm not very
> familiar with, I had tried to minimize the amount of changes needed. E.g.
> I did consider dropping xc_dom_ramdisk_check_size() altogether in favor
> of some other function (or even doing what is needed in its only caller),
> but that wo
>>> On 16.10.17 at 18:43, wrote:
> Jan Beulich writes ("Re: [PATCH] libxc: don't fail domain creation when
> unpacking initrd fails"):
>> On 16.10.17 at 17:45, wrote:
>> > Is there no way to tell that a kernel supports gzipped initrds by
>> > looking at the kernel ?
>>
>> Well, Linux kernels ha
>>> Ian Jackson 10/16/17 6:52 PM >>>
>Jan Beulich writes ("Re: [PATCH] libxc: don't fail domain creation when
>unpacking initrd fails"):
>> On 16.10.17 at 17:45, wrote:
>> > Is there no way to tell that a kernel supports gzipped initrds by
>> > looking at the kernel ?
>>
>> Well, Linux kernels
Andrew Cooper writes ("Re: [Xen-devel] [PATCH] libxc: don't fail domain
creation when unpacking initrd fails"):
> IMO, the toolstack should not be making assumptions about the initrd,
> and shouldn't be touching it. It is the users responsibility to provide
> an ini
Jan Beulich writes ("Re: [PATCH] libxc: don't fail domain creation when
unpacking initrd fails"):
> On 16.10.17 at 17:45, wrote:
> > 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
On 16/10/17 17:19, Jan Beulich wrote:
On 16.10.17 at 17:45, 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 oth
>>> On 16.10.17 at 17:45, 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 un
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 u
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
11 matches
Mail list logo
