On Thu, Feb 16, 2017 at 12:37 PM, Carlo Caione <ca...@endlessm.com> wrote: > On Thu, Feb 16, 2017 at 12:32 PM, Thomas Schmitt <scdbac...@gmx.net> wrote: >> Hi, >> >> Carlo Caione wrote: >>> > I think that the problem >>> > here is that endless.squash has been stored in two extents in the >>> > ISO9660 and GRUB doesn't deal fine with that (also according to this >>> > comment >>> > http://git.savannah.gnu.org/cgit/grub.git/tree/grub-core/fs/iso9660.c#n960 >> >> Andrei Borzenkov wrote: >>> This comment could be stale and misleading. >> >> The code of read_node() in iso9660.c looks ready for multi-extent (aka ISO >> level 3). >> >> I have a very densely compressed test ISO for large file support >> http://scdbackup.webframe.org/large.iso.bz2 >> which bunzip2 inflates from 4.5 KiB to 4+ GiB. > > Yeah, I made some more tests and apparently the problem is not in the > ISO9660 module but in the SQUASH4 module. > To be perfectly honest I have already a patch that solves my problem > but I'm having a hard time to understand WHY it solves the issue since > I'm still not really familiar with squashfs (I casually found it > during my debugging). > Of course probably it is only masking a problem somewhere else. Still digging. > > diff --git a/grub-core/fs/squash4.c b/grub-core/fs/squash4.c > index b97b344..4fef813 100644 > --- a/grub-core/fs/squash4.c > +++ b/grub-core/fs/squash4.c > @@ -895,7 +895,7 @@ grub_squash_read_data (struct grub_squash_data *data, > break; > } > > - if (fragment == 0xffffffff) > + if (fragment == 0xffffffff || fragment == 0) > return direct_read (data, ino, off, buf, len); > > err = read_chunk (data, &frag, sizeof (frag),
Hey Vladimir, Any idea about this? -- Carlo Caione | +39.340.80.30.096 | Endless _______________________________________________ Bug-grub mailing list Bug-grub@gnu.org https://lists.gnu.org/mailman/listinfo/bug-grub