On Fri, Apr 22, 2016 at 4:20 PM, drsmith <[email protected]> wrote: > Thanks for the input. This system has grub 0.97 and I forgot to mention > that in the original message. Some things may need to be tweaked to be > compatible. This is because commercial software rarely lets you use the > latest and greatest version or it's not supported. > > Also, I'm thinking the references to hd0,msdos2 should probably be > hd1,msdos1 because it is a different disk, rather than a different > partition. > > Are the msdosN references 1 based?
In GRUB legacy this would be rootnoverify (hd1,0) chainloader +1 It counted zero based. Seems odd when the hdN references start > from 0. > > thanks. > > On Thu, Apr 21, 2016 at 11:28 PM, Andrei Borzenkov <[email protected]> > wrote: >> >> 21.04.2016 22:00, drsmith пишет: >> > I'm currently working on installing a server with two logical drives in >> > it: >> > sda and sdb. Each logical drive is going to get an installation of >> > Linux >> > and each install has a different purpose. The first install is mostly >> > used >> > for recovery scenarios while the second would be the production >> > installation. >> > >> > The issue I've run into is that I have two /boot partitions, but the MBR >> > of >> > the first disk only points to one grub.conf file. Manually keeping >> > these >> > synchronized isn't something I'd like to do if I could avoid it. >> > >> > Either I have to have one shared /boot partition that gets mounted by >> > both >> > installations or I have to figure out how to get grub to chainload >> > itself >> > from the second drive. In the chainload scenario, you would see two >> > menus >> > where choosing the install on the second hard drive gives you the menu >> > for >> > that installation. >> > >> > I've run this through the stack-exchange sites and I've tried many >> > searches >> > over the past few days, but information on this seems to be rather >> > scarce. >> > Maybe I'm not thinking of a better possibility. Any insight you could >> > offer would be greatly appreciated. >> > >> >> Assuming that second GRUB is installed in partition, this would be >> something like >> >> menuentry "Chainload GRUB from second partition" --id some-unique-uuid { >> set root=hd0,msdos2 >> chainloader +1 >> } >> >> In this case boot sector is in the second partition boot block. I would >> recommend following practice of searching for partition instead of >> hardcoding device name, so if this partition has file system (e.g. it is >> /boot partition of second install), it would be something like >> >> menuentry "Chainload GRUB from second partition" --id some-unique-uuid { >> set root=hd0,msdos2 >> search --set --hint-bios=hd0,msdos2 --fs-uuid <file-system-uuid> >> chainloader +1 >> } >> >> where FS UUID can be obtained by running in Linux >> >> grub-probe -t fs_uuid /boot >> >> (may be grub2-probe depending on distribution). >> >> It is highly recommended to give each menuentry unique ID (grub-mkconfig >> does it) which can be used later as reference in setting default boot >> choice. Advantage is, this is independent of relative order and allows >> adding and removing menu entries while preserving chosen default. >> >> You can also load directly core.img without installing it, using >> >> multiboot /boot/grub/i386-pc/core.img >> >> Using current version (2.02~beta3) this core.img is created by >> >> grub-install --no-bootsector > > > > _______________________________________________ > Help-grub mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/help-grub > _______________________________________________ Help-grub mailing list [email protected] https://lists.gnu.org/mailman/listinfo/help-grub
