Le jeu. 3 mars 2016 19:17, Andrei Borzenkov <[email protected]> a écrit :
> 03.03.2016 10:33, Michael Chang пишет: > > The kernel bzImage payload length appears to be incorrectly minus by 4 > when > > trying to grub_file_offset_open for the uncompressed vmlinux image. If > gzip > > used as compressor it will lead to the file->size read from offset of > crc32 > > instead of the uncompressed image size. > > > > [1] > > http://www.onicos.com/staff/iz/formats/gzip.html > > --- > > grub-core/loader/i386/xen_file.c | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/grub-core/loader/i386/xen_file.c > b/grub-core/loader/i386/xen_file.c > > index 5836218..37f9ad8 100644 > > --- a/grub-core/loader/i386/xen_file.c > > +++ b/grub-core/loader/i386/xen_file.c > > @@ -55,11 +55,11 @@ grub_xen_file (grub_file_t file) > > grub_dprintf ("xen", "found bzimage payload 0x%llx-0x%llx\n", > > (unsigned long long) (lh.setup_sects + 1) * 512 > > + lh.payload_offset, > > - (unsigned long long) lh.payload_length - 4); > > + (unsigned long long) lh.payload_length); > > > > off_file = grub_file_offset_open (file, (lh.setup_sects + 1) * 512 > > + lh.payload_offset, > > - lh.payload_length - 4); > > + lh.payload_length); > > if (!off_file) > > goto fail; > > > > > Looks strange indeed. I wonder what was original intention, code looked > this way from the very beginning. May be it is required with some other > format? > I don't remember and I haven't kept the image I originally used for this. So I can't check if this doesn't break anything. But it looks like it fixes stuff, so I'm going to commit it > > _______________________________________________ > Grub-devel mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/grub-devel >
_______________________________________________ Grub-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/grub-devel
