tags 362028 patch user ubuntu-de...@lists.ubuntu.com usertags 362028 ubuntu-patch karmic thanks
On Sat, Aug 09, 2008 at 07:46:08PM +0200, Robert Millan wrote: > On Sat, Aug 09, 2008 at 05:15:07PM +0200, Raphael Champeimont (Almacha) wrote: > > The best is you look at > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=362028 message #40. > > Installing GRUB in a partition together with a filesystem usually works, > but is not well supported, and in general I don't think it's a good idea. (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 ran into this bug as https://bugs.launchpad.net/bugs/185878, and finally got round to reproducing and investigating it myself today. It seems to be fairly easy to reproduce as this sort of thing goes; just doing a straightforward installation on JFS and telling grub-installer to install to /dev/sda1 did it for me. Furthermore, if you zero out the region occupied by the stage 1.5 using dd, you can reproduce it again and again, which obviously made debugging rather easier. 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 haven't yet tested whether GRUB 2 suffers from the same problem, but will do so. Thanks, -- Colin Watson [cjwat...@ubuntu.com] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
