Hi Vladimir, Thanks for your response. I think my original question was more to do with using lnxboot.img than with Lilo per se, but I totally agree that my "solution" stinks. If there is an easy workaround within Grub then that would save a lot of hassle.
Following your suggestion I made the two files and a quick hexdump+diff reveals that sector 6 has been overwritten. This begins with the characters ZISD and thus led me to the good explanation here: http://www.novell.com/communities/node/5839/grub-and-zisd I have an older version than documented above, so moving the sector doesn't help and sector 6 just gets clobbered every time. The fix suggested on the site shifts up 13 sectors to sector 17. This suggests that newer versions of ZISD use a lot more space and just may not fit alongside Grub2 at all, but I don't have such a version to try. In my case there is only one sector changed, but I have no way to stop that particular sector being clobbered. Is there a way to make Grub skip that sector? Cheers, TIM On Fri, 2010-04-02 at 21:53 +0200, Vladimir 'φ-coder/phcoder' Serbinenko wrote: > Tim Booth wrote: > > Hi All, > > > > Sorry to clog up the developer list with my questions but I've scoured > > the documentation and not found an answer. > > > > I've hit this known problem: > > http://sourceforge.net/apps/mediawiki/bootinfoscript/index.php?title=Boot_Problems:Windows_Writes_To_MBR > > > > Where broken software on Windows is clobbering GRUB2. Modifying the > > corporate Windows installation is not an option, so I'm trying to use > > Lilo in the MBR and immediately chainload Grub. > > > Asking such a lilo question on GRUB list is annoying, especially that > it's not a real solution. > Could you try installing grub to mbr, then dump the MBR gap with > dd if=/dev/sda of=before.bin count=64 > <let windows do its anti-competitive job> > dd if=/dev/sda of=after.bin count=64 > Then send both files to me? Or just say which sectors are modified. > It was reported that only sectore number 32 is modified. If it's > confirmed we can avoid using it unless we need the whole MBR gap (very > uncommon) > > > Now I could install Grub into the (Ubuntu) Linux partition, but it seems > > rather simpler to just ask Lilo to chainload core.img. As far as I can > > tell, the only way to do this is to use lnxboot.img, telling lilo that > > core.img is an initrd. - ie. like this: > > > > ---my /etc/lilo.conf--- > > # Very basic LILO chainloader config > > boot = /dev/sda > > lba32 > > default = chainload_grub2 > > timeout = 0 > > > > image = /boot/grub/lnxboot.img > > append = "prefix=(hd0,5)/boot/grub" > > root=/dev/hda5 > > initrd = /boot/grub/core.img > > label = chainload_grub2 > > ---end--- > > > > But when Grub loads the prefix is set to (hd0,1)/boot/grub and I just > > get a recovery prompt and have to do: > > > > set prefix=(hd0,5)/boot/grub > > insmod normal > > normal > > > > So, is there any way to get the correct prefix passed through? I know > > there are other ways to attack this problem, but as the fix needs to be > > maintained on many machines I'm looking for something as simple as > > possible, and this is the simplest I can come up with, so I thought I'd > > ask this list before abandoning the idea completely. > > > > Cheers, > > > > TIM > > > > > > > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/grub-devel -- To Err is human. To Arrr is Pirate! _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
