On Sun, Dec 6, 2015 at 12:11 PM, drago01 <drago01@xxxxxxxxx> wrote: > On Sun, Dec 6, 2015 at 7:02 PM, Tomasz Torcz <tomek@xxxxxxxxxxxxxx> wrote: >> Can you list specific cases? It sounds awfully theoretical. > > I got bitten by it before so its not theoretical ... unfortunately I > do not remember the exact versions. I'm willing to bet it happened during the GRUB 2 beta era, when Fedora carried multiple works-in-progress of GRUB 1.9x where the grub.cfg format was in flux, and grubby also had some problems dealing with those changes. It's also possible it happened when Fedora's GRUB introduced linuxefi/initrdefi and linux16/initrd16 which GRUB upstream don't have; so your core.img didn't understand those commands while the grub2-mkconfig produced grub.cfg would have. So yeah it's possible, but it's also unintended. And the same problem could happen whether grubby modifies grub.cfg or grub-mkconfig replaces it. The way this works on UEFI obviates the problem by always replacing grubx64.efi (which contains core.img) anytime the grub2 package is updated. There's no equivalent to this on BIOS computers that won't piss off some significant(ly vocal) minority, but there's still a sane argument for the default behavior rewriting core.img anytime the grub package is updated: and the start of that argument is that reinstalling the bootloader manually is esoteric, and users shouldn't have to know such esoteric things to get their computer to boot or be secure. The reality is that anyone multibooting has to have ninjitsu level bootloader knowledge anyway, so I'd burden those people with managing exceptions rather than single boot users (or even dual boot Fedora+OSX or Fedora+Windows). -- Chris Murphy -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
