bzDisk compression Q; boot debug Q

bzDisk compression Q; boot debug Q

[D. Stimits]

First I have a question about the compression of bzDisk. While trying to
debug the reason for a modular boot failure versus a successful
non-module boot (XFS filesystem for root), I found that I can mount my
initial ramdisk on loopback as a means of examining which modules are
available to it. However, it doesn't actually point out which modules
were loaded at the time when a filesystem mount fails. Viewing ramdisk
is via:
gzip -dc your.img > somefile
mount -o loop somefile somedir

Question 1, how hard would it be to cause failure of mount of root
filesystem to also output a list of current modules it has loaded?

Question 2, apparently ramdisk uses gzip compression; the name of the
kernel from make bzImage seems to maybe refer to bzip2 compression. Is
the kernel image using gzip or bzip2 compression for bzImage? Would
anything be gained in reducing boot size requirements by running bzip2
compression for any initial ramdisk, versus gzip compression?

D. Stimits, stimits@idcomm.com

RE: bzDisk compression Q; boot debug Q

[Khachaturov, Vassilii]

> Question 2, apparently ramdisk uses gzip compression; the name of the
> kernel from make bzImage seems to maybe refer to bzip2 compression. Is
> the kernel image using gzip or bzip2 compression for bzImage? Would
bzImage stands for "big zImage" - this is a format invented for kernels that
don't fit into zImage. bzip2 has nothing to do with it :)

Re: bzDisk compression Q; boot debug Q

[D. Stimits]

"Khachaturov, Vassilii" wrote:
> 
> > Question 2, apparently ramdisk uses gzip compression; the name of the
> > kernel from make bzImage seems to maybe refer to bzip2 compression. Is
> > the kernel image using gzip or bzip2 compression for bzImage? Would
> bzImage stands for "big zImage" - this is a format invented for kernels that
> don't fit into zImage. bzip2 has nothing to do with it :)

Compression is one of those areas someone is always claiming to own a
part of, so it is a pain to deal with. But I still curious, how
effective is the compression that "big zImage" uses, compared to
something like bzip2? If the algorithm is the same as what gzip uses,
I'd imagine that some of my current 1.6 MB boot images could be brought
down to 1.44 MB. But then it would also have to be self-extracting,
which complicates it, so I'm wondering how effective this current
compression is, and if a more bzip2-like system would be beneficial as
kernels get larger?

D. Stimits, stimits@idcomm.com

Re: bzDisk compression Q; boot debug Q

[Holger Lubitz]

"D. Stimits" proclaimed:
> down to 1.44 MB. But then it would also have to be self-extracting,
> which complicates it, so I'm wondering how effective this current
> compression is, and if a more bzip2-like system would be beneficial as
> kernels get larger?

bzip2 has pretty large memory requirements, consuming up to 8 MB in
addition to the data being uncompressed.
Although thats less of an issue now than it was some years ago, i still
doubt that the kernel is going to be bzip2 compressed any time soon.

if you're looking for better compression, you might want to examine upx
(http://wildsau.idv.uni-linz.ac.at/mfx/upx.html). The kernel image
compression is still experimental, but already usable. kernels tend to
get ~100 K smaller compared to the usual gzip compressed bzImage.

Holger

Re: bzDisk compression Q; boot debug Q

[D. Stimits]

Holger Lubitz wrote:
> 
> "D. Stimits" proclaimed:
> > down to 1.44 MB. But then it would also have to be self-extracting,
> > which complicates it, so I'm wondering how effective this current
> > compression is, and if a more bzip2-like system would be beneficial as
> > kernels get larger?
> 
> bzip2 has pretty large memory requirements, consuming up to 8 MB in
> addition to the data being uncompressed.
> Although thats less of an issue now than it was some years ago, i still
> doubt that the kernel is going to be bzip2 compressed any time soon.
> 
> if you're looking for better compression, you might want to examine upx
> (http://wildsau.idv.uni-linz.ac.at/mfx/upx.html). The kernel image
> compression is still experimental, but already usable. kernels tend to
> get ~100 K smaller compared to the usual gzip compressed bzImage.

Interesting stuff...and the license is non-commercial as well.

D. Stimits, stimits@idcomm.com

> 
> Holger
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/