dnf versus yum

Chris Murphy lists at colorremedies.com
Fri Jan 10 20:36:12 UTC 2014


On Jan 10, 2014, at 8:04 AM, Przemek Klosowski <przemek.klosowski at nist.gov> wrote:

> On 01/09/2014 07:23 PM, Reindl Harald wrote:
>> Am 09.01.2014 22:16, schrieb Przemek Klosowski:
>>> I think you can still brick the system with careless yum erases: for instance, deleting grub
>> how would this delete the bootloader in the MBR?
>> you do not need the grub-package installed to have a bootloader
> MBR is just first stage loader---not enough to bring up the system, necessarily. This is tricky: the second stage is owned by grub2 in /usr/lib/grub, and somehow transferred to /boot/grub2 but I am not sure how

The necessary modules to support display, drawing menus, reading the file system in question, is all baked into core.img. The core.img is essentially custom, created by anaconda at install time by calling grub2-install. That is found in /boot/grub2/i386-pc along with other grub modules, not all of which are put into core.img. The core.img is then embedded in the MBR gap. And a small bit of jump code, called boot.img, is placed in the MBR boot strap region (first 440 bytes of LBA 0) to jump to core.img.

However, on UEFI this isn't necessarily the case, where the package contains a prebaked core.img that has a pile of modules already in it, because it's intended to be a one size fits all. This core.img takes the form of /boot/efi/EFI/fedora/grubx64.efi. It's prebaked this way because it's a signed binary, necessary for Secure Boot. If the grub package is yum erased, I'm virtually certain grubx64.efi is also removed, and the system would not be bootable. You'd get some message from shim.efi, and possibly fallback.efi, both of which would still be installed.



Chris Murphy



More information about the devel mailing list