Bug#362028: Found in lenny too

Robert Millan rmh at aybabtu.com
Sun Jul 12 10:52:20 UTC 2009


Hi again,

I have a pair of question/comments.

On Tue, Jun 30, 2009 at 04:42:50PM +0100, Colin Watson wrote:
> 
> (IME installing GRUB as a secondary boot loader is a very common
> request, particularly from people who've put a lot of effort into the
> boot loader currently in their MBR and get upset when a new operating
> system installation decides to trash it. I don't much like it myself as
> a setup, but I think if we want other systems to play nicely with us
> then it behooves us to put some effort into playing nicely with them, so
> I wouldn't like to remove this option from the installer. The
> grub2/os-prober setup looks as though it should work well for a lot of
> people, but it *is* still a bit "we can dual-boot as long as *I* run
> things" :-), and not everyone likes that.)

I understand that;  we will continue to support this option, even if
technically it's a mess to support it, as long as there's significant
user demand for it.  I would prefer if it was discouraged as much as
possible, though.

Users get upset when an installer replaces their MBR without asking for
permission, but there's nothing wrong with asking for permission and then
doing it IMHO.  Users who install to PBR's don't usually understand all
the problems associated with choosing this option (and later they come
to us, complaining their GRUB install just broke).

> Ironically, the problem is with GRUB's use of a couple of functions that
> have this comment above them:
> 
>   /* Linux-only functions, because Linux has a bug that the disk cache for
>      a whole disk is not consistent with the one for a partition of the
>      disk.  */
> 
> Unfortunately, these are used in a way that precisely arranges to run
> into the fact that the buffer caches for two file descriptors open on
> /dev/sda and /dev/sda1 are not necessarily coherent! GRUB opens
> /dev/sda, caches that file descriptor, and then (as part of embed_func)
> opens /dev/sda1 and writes the stage 1.5 to that. install_func then uses
> the cached file descriptor that's still open on /dev/sda and tries to
> read the stage 1.5 back from it. Since the caches aren't coherent, this
> fails in the way that's being observed.
> 
> The simple fix is to call the BLKFLSBUF ioctl on any cached file
> descriptor open on the disk device after writing to the partition
> device. The attached patch (to be installed in
> debian/patches/cache_coherency.diff, with the obvious additional entry
> at the end of debian/patches/00list) does this.

I don't understand this.  If BLKFLSBUF flushes the partition buffer, doesn't
this make the problem go away completely?  Then why is the Linux-specific
code not removed?

(if your aim was to make the patch as unintrusive as possible, I agree it's
a good idea for GRUB Legacy, but I need to know about this for GRUB 2)

> I haven't yet tested whether GRUB 2 suffers from the same problem, but
> will do so.

Please let me know about it.

-- 
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."





More information about the Pkg-grub-devel mailing list