Is there a magic number for LZMA? Should there be?
I accidentally used an uncompressed payload with v2 when it expected a compressed payload, and it gave me the message:
Decoder scratchpad too small!! Decoding error = 1
I think it would be nicer to have an error like:
Payload not compressed with lzma!
Myles
On Fri, Jan 25, 2008 at 10:55:24AM -0700, Myles Watson wrote:
I accidentally used an uncompressed payload with v2 when it expected a compressed payload, and it gave me the message:
Decoder scratchpad too small!! Decoding error = 1
I got this too.
I think it would be nicer to have an error like:
Payload not compressed with lzma!
And we can check it already at build time.
//Peter
On 25.01.2008 18:58, Peter Stuge wrote:
On Fri, Jan 25, 2008 at 10:55:24AM -0700, Myles Watson wrote:
I accidentally used an uncompressed payload with v2 when it expected a compressed payload, and it gave me the message:
Decoder scratchpad too small!! Decoding error = 1I got this too.
I think it would be nicer to have an error like:
Payload not compressed with lzma!And we can check it already at build time.
LZMA compressed payloads to not have a magic number, all you can do is check if the header parameters are in a reasonable range. Sorry. This problem fortunately does not exist in v3 because LAR does the compression itself and notes the compression type in th header.
Regards, Carl-Daniel
On Sat, Jan 26, 2008 at 02:18:39AM +0100, Carl-Daniel Hailfinger wrote:
On 25.01.2008 18:58, Peter Stuge wrote:
On Fri, Jan 25, 2008 at 10:55:24AM -0700, Myles Watson wrote:
I accidentally used an uncompressed payload with v2 when it expected a compressed payload, and it gave me the message:
Decoder scratchpad too small!! Decoding error = 1I got this too.
I think it would be nicer to have an error like:
Payload not compressed with lzma!And we can check it already at build time.
LZMA compressed payloads to not have a magic number, all you can do is check if the header parameters are in a reasonable range. Sorry. This problem fortunately does not exist in v3 because LAR does the compression itself and notes the compression type in th header.
I ran into this runtime error as well today.
Please find a patch attached that makes coreboot a bit smarter in dealing with this situation, and avoids the fatal runtime error.
Thanks, Ward.
-----Original Message----- From: coreboot-bounces@coreboot.org [mailto:coreboot-bounces@coreboot.org] On Behalf Of Ward Vandewege Sent: Wednesday, August 27, 2008 3:02 PM To: Carl-Daniel Hailfinger Cc: coreboot@coreboot.org Subject: [coreboot] [PATCH] Re: LZMA magic number
On Sat, Jan 26, 2008 at 02:18:39AM +0100, Carl-Daniel Hailfinger wrote:
On 25.01.2008 18:58, Peter Stuge wrote:
On Fri, Jan 25, 2008 at 10:55:24AM -0700, Myles Watson wrote:
I accidentally used an uncompressed payload with v2 when it expected a compressed payload, and it gave me the message:
Decoder scratchpad too small!! Decoding error = 1I got this too.
I think it would be nicer to have an error like:
Payload not compressed with lzma!And we can check it already at build time.
LZMA compressed payloads to not have a magic number, all you can do is check if the header parameters are in a reasonable range. Sorry. This problem fortunately does not exist in v3 because LAR does the compression itself and notes the compression type in th header.
I ran into this runtime error as well today.
Please find a patch attached that makes coreboot a bit smarter in dealing with this situation, and avoids the fatal runtime error.
Ward,
I like the idea of assuming no compression if uncompressing it fails. I wonder if it would be better to copy it to dest instead of running it in place.
Thanks, Myles
On Wed, Aug 27, 2008 at 03:22:38PM -0600, Myles Watson wrote:
I like the idea of assuming no compression if uncompressing it fails. I wonder if it would be better to copy it to dest instead of running it in place.
If compression is disabled in Config.lb the current code runs it in place as well. So I guess it's no problem?
Thanks, Ward.
-----Original Message----- From: Ward Vandewege [mailto:ward@gnu.org] Sent: Wednesday, August 27, 2008 3:31 PM To: Myles Watson Cc: 'Carl-Daniel Hailfinger'; coreboot@coreboot.org Subject: Re: [coreboot] [PATCH] Re: LZMA magic number
On Wed, Aug 27, 2008 at 03:22:38PM -0600, Myles Watson wrote:
I like the idea of assuming no compression if uncompressing it fails. I wonder if it would be better to copy it to dest instead of running it in place.
If compression is disabled in Config.lb the current code runs it in place as well. So I guess it's no problem?
Ward,
I should have checked that.
Acked-by: Myles Watson mylesgw@gmail.com
Thanks, Myles
Thanks, Ward.
-- Ward Vandewege ward@fsf.org Free Software Foundation - Senior Systems Administrator
On 27.08.2008 23:39, Myles Watson wrote:
-----Original Message----- From: Ward Vandewege [mailto:ward@gnu.org] Sent: Wednesday, August 27, 2008 3:31 PM To: Myles Watson Cc: 'Carl-Daniel Hailfinger'; coreboot@coreboot.org Subject: Re: [coreboot] [PATCH] Re: LZMA magic number
On Wed, Aug 27, 2008 at 03:22:38PM -0600, Myles Watson wrote:
I like the idea of assuming no compression if uncompressing it fails. I wonder if it would be better to copy it to dest instead of running it in place.
If compression is disabled in Config.lb the current code runs it in place as well. So I guess it's no problem?
Ward,
I should have checked that.
Acked-by: Myles Watson mylesgw@gmail.com
The change looks sensible to me. Since it is tested, here is my ack. Acked-by: Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net
Regards, Carl-Daniel
On Wed, Aug 27, 2008 at 11:48:26PM +0200, Carl-Daniel Hailfinger wrote:
Acked-by: Myles Watson mylesgw@gmail.com
The change looks sensible to me. Since it is tested, here is my ack. Acked-by: Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net
r3542.
Thanks, Ward.
-
Carl-Daniel Hailfinger -
Myles Watson -
Myles Watson -
Peter Stuge -
Ward Vandewege