Colin Watson <cjwatson <at> ubuntu.com> writes: > ... > Yes, you can do this by using 'grub-install /dev/sda1' (or whatever the > device name for your /boot partition is).
Thanks for your help, but no, it appears you cannot do this by simply using "grub-install /dev/sdx". I tried this, and yes, it did make the target partition bootable (it contained a Grub loader in its PBR). However, to ensure the disk MBR had also been updated and was now getting its core.img file from the /boot partition and not from the sectors immediately following it, I built a dummy track containing just the MBR post-"grub-install" and nothing but zeros after, and then I copied it to /dev/sda: dd if=/dev/zero of=/track.image bs=512 count=63 dd if=/dev/sda of=/track.image bs=512 count=1 conv=notrunc dd if=/track.image of=/dev/sda bs=512 count=63 If the MBR no longer needs the embedded core.img, then it being replaced with empty sectors shouldn't bother Grub the slightest. Unfortunately, upon reboot I was greeted only with the word "GRUB" and a blinking cursor, which I took to mean it couldn't find core.img and was unable to proceed. It would be nice if Grub2 could both make a partition bootable and also install an MBR that relied on that partition (rather than the embedded core.img). I know this is "dangerous," but it is necessary sometimes, and it was not at all difficult to accomplish with legacy Grub. > Note that this setup typically requires the use of blocklists, which are > inherently unreliable. For example, you may find that you need to > re-run grub-install after certain filesystem operations; see the "And > blocklists?" section of http://grub.enbug.org/BIOS_Boot_Partition for a > description of the problem. This problem was present in GRUB Legacy as > well, although it did not warn about it. > _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
