Re: tip: bzip2/lzma now in tip:x86/setup-lzma

["H. Peter Anvin" <hpa@zytor.com>]

Ingo Molnar wrote:
> 
> still fails:
> 
> [    3.196037] initcall inet_init+0x0/0x1e9 returned 0 after 101777 usecs           
> [    3.202886] calling  af_unix_init+0x0/0x55 @ 1                                   
> [    3.207461] NET: Registered protocol family 1                                    
> [    3.211950] initcall af_unix_init+0x0/0x55 returned 0 after 4394 usecs           
> [    3.218624] calling  populate_rootfs+0x0/0xd2 @ 1                                
> [    3.223460] Kernel panic - not syncing: compression method gzip not configured   
> 
> config attached.
> 

Okay, I think I've tracked down the problem.

The issue is that usr/Makefile doesn't correctly filter compression 
methods which we don't support.  This particular case will happen when 
you're building with Ingo's attached configuration *and no bzip2 tool 
installed on the system*.

Basically, the algorithm used in usr/Makefile is simply wrong.

The claim is:

+# Find out "preferred" ramdisk compressor. Order of preference is
+#  1. bzip2 efficient, and likely to be present
+#  2. gzip former default
+#  3. lzma
+#  4. none
+
+# None of the above
+suffix_y                   =
+
+# Lzma, but no gzip nor bzip2
+suffix_$(CONFIG_RD_LZMA)   = .lzma
+
+# Gzip, but no bzip2
+suffix_$(CONFIG_RD_GZIP)   = .gz
+
+# Bzip2
+suffix_$(CONFIG_RD_BZIP2)  = .bz2

This doesn't end up make any sense.  The sanest thing to do is to 
compress with all the compressors that are configured into the kernel, 
and then use the smallest image of the ones that can be produced, 
*including the uncompressed image*.  Including the uncompressed image 
will guarantee that we always have a working option.

	-hpa