Hi,
When run under VMware, LZMA compressed 2.6.33-rc1 instantly reboots in the
decompression stage. At least I suppose so, because switching to GZIP makes
it work.
Kernel was configured via make oldconfig from a working 2.6.32-rc6. Only other
difference is that kprobes are disabled in 33-rc1 and enabled in 32-rc6.
CPU on the server is Xeon 5110 if it helps.
I can post the .config if needed, in fact since I will be away after today, I
will do it right now. But as a reply to this to ensure at least this post is
not eaten by vger filters.
Tvrtko
.config for working 2.6.33-rc1, if I change compression to LZMA it does not
boot.
Tvrtko
Tvrtko Ursulin wrote:
> Hi,
>
> When run under VMware, LZMA compressed 2.6.33-rc1 instantly reboots in the
> decompression stage. At least I suppose so, because switching to GZIP makes
> it work.
Switch /bin/sh from dash to bash and recompile (actually relink) - it should work.
/mjt
Michael Tokarev wrote:
> Tvrtko Ursulin wrote:
>> Hi,
>>
>> When run under VMware, LZMA compressed 2.6.33-rc1 instantly reboots in the
>> decompression stage. At least I suppose so, because switching to GZIP makes
>> it work.
>
> Switch /bin/sh from dash to bash and recompile (actually relink) - it should work.
>
> /mjt
I can confirm this. A similar issue used to exist for older kernels,
which then got fixed by replacing "echo" with "/bin/echo" in the
size_append command scripts/Makefile.lib . The reason why this was
needed is that some shells (such as dash) have a defective built-in echo
command. Specifying the full path forces to use the system echo command
rather than the broken shell builtin.
In 2.6.33, for some reason, echo has been replaced with printf. With a
_pathless_ printf! The fix is the same as in earlier kernels: add the path.
With the attached patch applied, the kernel compiles correctly even if
sh is linked to dash.
Regards,
Alain
Alain Knaff wrote:
> Michael Tokarev wrote:
>> Tvrtko Ursulin wrote:
>>> Hi,
>>>
>>> When run under VMware, LZMA compressed 2.6.33-rc1 instantly reboots in the
>>> decompression stage. At least I suppose so, because switching to GZIP makes
>>> it work.
>> Switch /bin/sh from dash to bash and recompile (actually relink) - it should work.
>>
>> /mjt
>
> I can confirm this. A similar issue used to exist for older kernels,
> which then got fixed by replacing "echo" with "/bin/echo" in the
> size_append command scripts/Makefile.lib . The reason why this was
> needed is that some shells (such as dash) have a defective built-in echo
> command. Specifying the full path forces to use the system echo command
> rather than the broken shell builtin.
>
> In 2.6.33, for some reason, echo has been replaced with printf. With a
> _pathless_ printf! The fix is the same as in earlier kernels: add the path.
It should be pathless, or else we'll come to issue when printf is in /bin
vs /usr/bin and the like.
But you're wrong, and this has been discussed already in this very thread.
Neither approach is right. The whole issues is not because of "defects"
in sh or printf or echo, but because of over-expectations. POSIX does not
specify that printf should support \x (hexadecimal) escape sequences or
that echo should interpret _any_ escape sequences at all. "Non-defective"
system echo is *extension* to standard. Set $POSIXLY_CORRECT with GNU
echo or printf and you should have the same issue again.
> With the attached patch applied, the kernel compiles correctly even if
> sh is linked to dash.
What I think should be done here is to revert my patch (that replaces
/bin/echo with printf, so that /bin/echo will be used) and test the
real solution, which is to stop doing all this hackery altogether,
and calculate the size the right way instead. Sam already posted a
possible solution, and it seems to be correct.
/mjt
On 12/27/2009 12:19 PM, Michael Tokarev wrote:
>
> What I think should be done here is to revert my patch (that replaces
> /bin/echo with printf, so that /bin/echo will be used) and test the
> real solution, which is to stop doing all this hackery altogether,
> and calculate the size the right way instead. Sam already posted a
> possible solution, and it seems to be correct.
>
Yes, but it moves the calculation from generic to x86-specific code,
which makes it problematic.
I never figured out how to make a generic rule in Kbuild (unlike in
standard GNU make) depend on a helper application, but doing a helper
application for this is probably the sane thing.
Either this, or use Perl, which handles this kind of crap sanely. I'm
really less than half joking.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
>>>>> "H" == H Peter Anvin <[email protected]> writes:
H> On 12/27/2009 12:19 PM, Michael Tokarev wrote:
>>
>> What I think should be done here is to revert my patch (that replaces
>> /bin/echo with printf, so that /bin/echo will be used) and test the
>> real solution, which is to stop doing all this hackery altogether,
>> and calculate the size the right way instead. Sam already posted a
>> possible solution, and it seems to be correct.
>>
H> Yes, but it moves the calculation from generic to x86-specific code,
H> which makes it problematic.
H> I never figured out how to make a generic rule in Kbuild (unlike in
H> standard GNU make) depend on a helper application, but doing a
H> helper application for this is probably the sane thing.
H> Either this, or use Perl, which handles this kind of crap sanely.
H> I'm really less than half joking.
Yeah, I've never understood this mania to purge the build process of
any and all use of perl. If anything, it should *all* be perl so as
to simplify the maint since it's all the same, no matter where you run
perl.
And for those who say "but I need to compile the kernel in my
miniscule, locked down environment" my reply is "cross-compile".
Heck, even pure C code would do the trick here.
John
On 12/28/2009 02:15 PM, John Stoffel wrote:
>
> Heck, even pure C code would do the trick here.
>
C code is fine, but needs a dependency so that it is build before it is
needed.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.