[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Problem with ISO9660 and files stored on multiple extents
From: |
Andrei Borzenkov |
Subject: |
Re: Problem with ISO9660 and files stored on multiple extents |
Date: |
Thu, 16 Feb 2017 06:59:06 +0300 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 |
16.02.2017 00:30, Carlo Caione пишет:
> Hi,
> in our ISO images in the ISO9660 partition we ship a squashfs image
> containing the full OS image.
> At boot GRUB does something like this:
>
> loopback loop_squash ($eosimage)/endless/endless.squash
> loopback loop_img (loop_squash)/endless.img
> set root=(loop_img,gpt3)
>
> This is working fine for our small images without any problem.
>
> The problem arises when the size of endless.squash is >4GB. In this
> case accessing (loop_img) just fails with:
>
> No known filesystem detected
>
> I spent a bit tracking down this issue and 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).
>
This comment could be stale and misleading.
> Could be this the cause of the problem? Any suggestion besides
> extending the iso9660 module with the support for files stored on
> multiple extents?
>
Quick look suggests that it does process multi-extents
while (dirent.flags & FLAG_MORE_EXTENTS)
{
in grub_iso9660_iterate_dir()
I suggest you try to use gdb on grub-fstest binary that allows stepping
through the code to see where it misbehaves.
> This is briefly how I tracked down the issue. When squash_mount() is
> called it tried to access the squashfs image to retrieve the number of
> the fragments, this is done basically reading at sb.unk1offset in the
> squashfs image. This number for images >4GB is clearly wrong. Being
> the image mounted in loopback what happens is that grub is trying to
> read the squashfs file on the ISO9660 partition at file->offset >4GB
> in grub_iso9660_read(). Inspecting the ISO with isoinfo we have:
>
> ---------- 0 0 0 4294965248 Feb 15 2017 [ 13356 FFFF
> ENDLESS.SQUASH;1
> ---------- 0 0 0 269539328 Feb 15 2017 [2110507 00]
> ENDLESS.SQUASH;1
>
> That is in grub_iso9660_read() we are trying to access the second
> extent, reading rubbish.
>
> Is this theory correct?
>
> Thank you,
>
>
- Problem with ISO9660 and files stored on multiple extents, Carlo Caione, 2017/02/15
- Re: Problem with ISO9660 and files stored on multiple extents,
Andrei Borzenkov <=
- Re: Problem with ISO9660 and files stored on multiple extents, Thomas Schmitt, 2017/02/16
- Message not available
- Re: Problem with ISO9660 and files stored on multiple extents, Carlo Caione, 2017/02/16
- Re: Problem with ISO9660 and files stored on multiple extents, Carlo Caione, 2017/02/16
- Re: Problem with ISO9660 and files stored on multiple extents, Vladimir 'phcoder' Serbinenko, 2017/02/16
- Re: Problem with ISO9660 and files stored on multiple extents, Carlo Caione, 2017/02/16
- Re: Problem with ISO9660 and files stored on multiple extents, Vladimir 'phcoder' Serbinenko, 2017/02/16
- Re: Problem with ISO9660 and files stored on multiple extents, Carlo Caione, 2017/02/16
- Re: Problem with ISO9660 and files stored on multiple extents, Vladimir 'phcoder' Serbinenko, 2017/02/16
- Re: Problem with ISO9660 and files stored on multiple extents, Andrei Borzenkov, 2017/02/16
- Re: Problem with ISO9660 and files stored on multiple extents, Carlo Caione, 2017/02/16