Hi,
I have just repeated the git bisect and confirmed that:
- the problem was introduced in 026cee00
- reverting 026cee00 the problem goes away
That commit includes some modifications in kernel/params.c file. Probably the
bug has been introduced by that modifications.
Best regards,
David
On Thu, Jun 21, 2012 at 4:42 PM, richard -rw- weinberger
wrote:
> On Thu, Jun 21, 2012 at 4:29 PM, David Fernández wrote:
>>
>> What command should I use to revert that specific commit? I'm not an expert
>> in git, in fact I just learnt what a 'git bisect' is after your message
>> ...:-)
>
> E.g:
On Thu, Jun 21, 2012 at 4:29 PM, David Fernández wrote:
>
> What command should I use to revert that specific commit? I'm not an expert
> in git, in fact I just learnt what a 'git bisect' is after your message
> ...:-)
E.g:
$ git show 026cee00 > sucker.diff
$ patch -p1 -R < sucker.diff
--
Thank
On 20/06/12 19:13, richard -rw- weinberger wrote:
> On Wed, Jun 20, 2012 at 7:02 PM, David Fernández wrote:
>> Finally I managed to do the git bisect with your indications. The result:
>>
>> # git bisect bad
>> 026cee0086fe1df4cf74691cf273062cc769617d is the first bad commit
>> commit 026cee0086fe
On Wed, Jun 20, 2012 at 7:02 PM, David Fernández wrote:
> Finally I managed to do the git bisect with your indications. The result:
>
> # git bisect bad
> 026cee0086fe1df4cf74691cf273062cc769617d is the first bad commit
> commit 026cee0086fe1df4cf74691cf273062cc769617d
> Author: Pawel Moll
> Date
On 20/06/12 09:17, richard -rw- weinberger wrote:
> On Wed, Jun 20, 2012 at 12:33 AM, David Fernández wrote:
>> El 19/06/2012, a las 11:03, richard -rw- weinberger escribió:
>>
>>> On Tue, Jun 19, 2012 at 10:55 AM, David Fernández wrote:
Any idea of the cause of the problem? A simple 'diff'
On Wed, Jun 20, 2012 at 12:33 AM, David Fernández wrote:
>
> El 19/06/2012, a las 11:03, richard -rw- weinberger escribió:
>
>> On Tue, Jun 19, 2012 at 10:55 AM, David Fernández wrote:
>>> Any idea of the cause of the problem? A simple 'diff' between 3.3 and
>>> 3.4 versions shows the option pars
El 19/06/2012, a las 11:03, richard -rw- weinberger escribió:
> On Tue, Jun 19, 2012 at 10:55 AM, David Fernández wrote:
>> Any idea of the cause of the problem? A simple 'diff' between 3.3 and
>> 3.4 versions shows the option parsing code has changed significantly.
>
> Can you do a git bisect?
On Tue, Jun 19, 2012 at 10:55 AM, David Fernández wrote:
> Any idea of the cause of the problem? A simple 'diff' between 3.3 and
> 3.4 versions shows the option parsing code has changed significantly.
Can you do a git bisect?
--
Thanks,
//richard
---
Hi,
It seems that the parsing of ubd option is broken in kernels 3.4.X when
using COW filesystems. Let me show the tests I've done so far.
When starting a virtual machine using a cow fs without pathname:
linux-3.4.1 udba=cow_fs,debian.img
it works, but the cow file created is named 'cow_fs,
10 matches
Mail list logo
