Re: Grub data clobbered by Novell ZENworks (was: Chainloading GRUB2 from Lilo)

[Tim Booth]

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
> address@hidden
> http://lists.gnu.org/mailman/listinfo/grub-devel
-- 
To Err is human.
To Arrr is Pirate!