As is common practice with (at least) SuSE distributions, and as is also required by the ACPI DSDT override mechanism, a Linux initrd may contain more information than just the gzipped file system image. Since grub only looks at the last 8 bytes to determine crc and original size, it must be very careful when interpreting these or attempting to unzip such a file. Currently what happens is that
- if the original size happens to be zero or negative (as it is treated as a signed value), the entire file is ignored (cmp or module simply do nothing) - if the original size happens to be positive, good chances are that grub actually hangs appearantly due to missing validity checks in the unzipping code For the first part, detecting a non-positive original size in gunzip_test_header() should help. For the second part, since gzip detects and reports the presence of additional data past the compressed part, perhaps similar logic should be used here. Ideally, the read would then be failed in a way that the original caller can revert to treat the file as not needing decompression, but in no case should the partially handled file be passed as a module to the kernel or be silently ignored. Thanks, Jan _______________________________________________ Bug-grub mailing list Bug-grub@gnu.org http://lists.gnu.org/mailman/listinfo/bug-grub
