On Sun, Mar 15, 2009 at 12:56:26AM +0800, Bean wrote: > On Sun, Mar 15, 2009 at 12:37 AM, Robert Millan <r...@aybabtu.com> wrote: > > On Sun, Mar 15, 2009 at 12:16:23AM +0800, Bean wrote: > >> Hi, > >> > >> I've discovered a bug in ext2.c, inside grub_ext2_mount. The mount > >> function must return GRUB_ERR_BAD_FS if something goes wrong, because > >> grub_fs_probe would stop as soon as it sees a non-GRUB_ERR_BAD_FS > >> error, thus preventing other fs driver from detecting the correct fs > >> type. This patch fixes the problem. > > > > I think current behaviour is correct. If a failure is triggered by > > grub_disk_read(), from grub_fs_probe perspective it means something is > > fucked up other than just "this is not the FS we're looking for", so it > > should be aware of the difference. > > > > Or is grub_ext2_read_inode() failure the one that's causing trouble for > > you? > > Hi, > > ext2 only reads the first two sectors in mount, which is normally ok , > but there are exceptions. For example, cpio filesystem could be less > one sector.
I don't understand what you mean here. If grub_disk_read failed, this indicates something's broken down in the disk layer doesn't it? How is the number of sectors related to this? > Also, hostfs always return error in its read function, > which would cause ext2 to fail. The effect can be seen in grub-fstest. > hostfs is the first fs driver to register, and the last to query. When > accessing the (host) device, ext2 cause it to fail before hostfs has a > chance to see it. Why does hostfs fail? Is this intentional? -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
