Re: execution order involving the bootloader install

[Chris Murphy <lists@xxxxxxxxxxxxxxxxx>]

On May 23, 2014, at 2:28 PM, Gene Czarcinski <gczarcinski@xxxxxxxxx> wrote:

I will need to look into live KDE.  You said that the problem applied to grub2 and extlinux.  I just found out that you can specify
   liveinst --extlinux
but have not tried it yet to see if it works.

I used extlinux as a boot parameter for KDE live, and anaconda picked it up and used extlinux as the bootloader.

OK.  First of all, you do not need grubby to create the initramfs files.  The kernel rpm (or not kernel-core rpm) has a valid initramfs as part of the rpm.  This is what the bootloaders see if new-kernel-pgm/grubby has yet to run.

new-kernel-pkg --mkinitrd --dracut calls dracut to build the initramfs, the initramfs isn't in the RPM. And grubby is supposed to get called, I think from within new-kernel-pkg, to update any of the supported bootloader configuration files.

Another problem is that anaconda does not do a good job of setting the "value" for the default boot.  For grub2, it is definitely screwed up.  For extlinux, I do not understand what "default" does.  See:
http://www.syslinux.org/wiki/index.php/SYSLINUX#DEFAULT_command

Neither do I. The resulting extlinux.conf has a default line, but it appears to have no effect.

The only reson things mostly work is the if the specified default is not found, the the bootlloader just uses the first one defined.  When the rescue kernel was last, things worked OK.  Now, not so much.

Right, this is what I'm experiencing also.

As far as why this was done, I have asked the question but have yet to hear an answer.  This is not a grubby problem, although pjones did kludged up grubby a little more (very small patch) to make grub.cfg usable.  It sort of works.  The problem was cause by code changed/added in support of OSTree:
http://fedorapeople.org/~walters/fedora-ostree/

It is not clear to me why it needs to fool with the bootloader and when it is executed but the change was made very recently. 

Think of it as booting Btrfs subvolumes (separate fs trees). Whether it's done with directories and hardlinks as ostree does it, or as an fs feature like Btrfs does, in order to switch booting to a different tree you need to do one of two things: 1. Change the bootloader configuration to change to the tree you want to boot; 2. change the name of the tree you want to boot to match the bootloader configuration. The problem with 2 is that you can't use the path name to track each unique tree, because once it's renamed you lose the reference. e.g. the bootloader configuration for ostree looks like it's using bootloaderspec type drop in files and one of the lines looks like this:

linux /ostree/fedora-atomic-449629c60bed8b9232e40855a7ee4e357f7973ace0bfbcb91a6ed0dd07275f5e/vmlinuz-3.15.0-0.rc6.git0.1.fc21.x86_64

For what it's worth, ostree installed to an existing entirely btrfs fs (a boot subvolume is mounted at /boot) seems unaware that it's on btrfs and needs to specify the subvolume. The above line should be

linux /boot/ostree/fedora-atomic-449629c60bed8b9232e40855a7ee4e357f7973ace0bfbcb91a6ed0dd07275f5e/vmlinuz-3.15.0-0.rc6.git0.1.fc21.x86_64

Chris Murphy

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list