16.02.2017 19:04, Vladimir 'phcoder' Serbinenko пишет: > On Thu, Feb 16, 2017, 16:56 Carlo Caione <ca...@endlessm.com> wrote: > >> On Thu, Feb 16, 2017 at 4:54 PM, Vladimir 'phcoder' Serbinenko >> <phco...@gmail.com> wrote: >>> >>> >>> On Thu, Feb 16, 2017, 14:14 Carlo Caione <ca...@endlessm.com> wrote: >>>> >>>> On Thu, Feb 16, 2017 at 2:09 PM, Vladimir 'phcoder' Serbinenko >>>> <phco...@gmail.com> wrote: >>>>> >>>>> >>>>> On Thu, Feb 16, 2017, 14:04 Carlo Caione <ca...@endlessm.com> wrote: >>>>>> >>>>>> 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? >>>>> >>>>> How big is the file in question? What is the squash tools version? >>>> >>>> The squash image is 4564504576 >>> >>> I mean the size of file you try to access >> >> In the squashfs image there is one single file of size 11470000128 >> > Then it's possible that your patch is correct. I don't know why the format > changes or what the 0 means in this field >
Looking at current squash tools git, 0 is valid fragment number. Any chance we hit different file type here? Carlo, could you make your squashfs image available? >> >> -- >> Carlo Caione | +39.340.80.30.096 | Endless >> > _______________________________________________ Bug-grub mailing list Bug-grub@gnu.org https://lists.gnu.org/mailman/listinfo/bug-grub