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). Could be this the cause of the problem? Any suggestion besides extending the iso9660 module with the support for files stored on multiple extents? 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, -- Carlo Caione | +39.340.80.30.096 | Endless _______________________________________________ Bug-grub mailing list Bug-grub@gnu.org https://lists.gnu.org/mailman/listinfo/bug-grub