----- Original Message ----- > > > > > On Mon, Sep 19, 2011 at 10:53 AM, Doug Ledford < dledf...@redhat.com > > wrote: > > > > > Like I said, not true. The grub package is designed to be updateable > without requiring an mbr reinstall. What's more is I had a look at > the stage1.[hS] files in the grub shipped in FC-1 and RHEL-5, and > just like I said, they are indeed binary compatible. So even if the > grub user space application pulls its MBR from a statically linked > copy of the MBR, it will still work with pretty much any stage1.5 or > stage2 you find in a guest. > > > > > > Pretty much any? Hmm are you saying that random other linux > distribution's grub binaries are garunteed(or promised/expected) to > be binary compatible?
Can I guarantee it, no. I didn't look at their stage1.[hS] files. However, as I said in my original comment about this, the stage1 loader is *dirt simple*. There is a very low chance that it will be incompatible simply due to the fact that almost nothing interesting happens there. There is a much greater chance in the stage1.5 files though. But, since the grub command line utility, when used as I directed, reads the stage1.5 and stage2 files from the filesystem and doesn't try to use its own internal version of those files, incompatibility at that layer isn't a problem. > Other distributors do have the ability to > patch that 1.5 stage code in non-binary compatible ways don't they? They do. But unless they have assembler code masochists, they likely don't. > We aren't talking strictly about the Fedora/RHEL ecosystem are we? > Just because RHEL and Fedora have chosen not to include binary > incompatible patches, doesn't mean its a truism across the guest OS > landscape does it? No, but again, the chances of a binary incompatible stage1 are very low. > Is that binary compatibility tested for as part of operation? You would have to ask the grub maintainer about that. I just know that a grub update does not reinstall the stage1 or stage1.5 files, while the stage2 file is replaced in the filesystem, meaning that the previous stage1.5 file will attempt to use the new stage2 file in chain loading fashion. Whether or not that is ever tested or just assumed to work I can't speak to. > Is that > compatibility strictly a consequence of distribution level decision > making concerning Fedora and RHEL? Between the stage1.5 and stage2, that could very well be. Between the stage1 and stage1.5, it's more a consequence of the fact that the stage1 loader has one very distinct job to perform, in a very small amount of instruction space, and you don't go around adding features to the stage1 loader, it simply doesn't have the room for it. > Is that binary compatibility > guaranteed or promised from other distribution's grub1 variants > being shipped? No clue. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
