Re: execution order involving the bootloader install

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On May 23, 2014, at 7:59 AM, Gene Czarcinski <gczarcinski@xxxxxxxxx> wrote:

On 05/23/2014 07:32 AM, Gene Czarcinski wrote:
On 05/22/2014 08:16 PM, Chris Murphy wrote:
Observations with today's Rawhide: Fedora-Live-Workstation-x86_64-rawhide-20140522.iso

First, the grub.cfg is hosed. The rescue boot entry is listed first, and is the default. It should be reversed.

I don't know which component's bug this is, anaconda for calling grub2-mkconfig before the kernel and initrd have even been created, or grubby for not adding the entry in the right location. So before I file anymore bugs I'd like to know whether grub2-mkconfig is really supposed to be called before all kernels and initramfs's are in /boot, and the expectation is that grubby will fix all missing items in the grub.cfg.

The change is in install.py and was done intentionally in support of OSTree.  I do not completely understand the reasoning.

I am currently testing doing a forced extlinux as the bootloader situation.  I first installed into a virtual system with regular partitions using a Fedora 20 DVD iso and it successfully installed and rebooted.  I am now in the process of testing a forced extlinux bootloader for a simple network install.  I do know that some of my patches fixing/enhancing extlinux as the bootloader are screwed by the change.

With grub2 and the latest grubby-8.25-1, you can reboot an install of a livecd system but, as you say, the default is the rescue system because the specified value in /boot/grub2/grubenv is not valid.

I believe that the OSTree enhancement with respect to the bootloader needs to be explained,  discussed, and tested a bit more before deploying the implemention.  Yes, I know it is rawhide and thus can/will break things.  But, anything dealing with the bootloader is both complicated and mostly pretty fragile.
Well, it looks like extlinux as the bootloader may be broken.  I am going to give it one more try, create a distribution DVD iso based on rawhide, and boot that specifying  extlinux on the command line.  It is a bit difficult trying to figure out what info to collect.  The package installation completed and it is sitting there, consuming 99% of a virtual cpu, and executing "gtk-update-icon".  I think it is going to take an updates.img with some pdb tracing inserted to see what is going on.

With rawhide 20140523 live KDE, the same problem affects GRUB2 and extlinux. Extlinux doesn't use grubenv, its conf file has a separate default line and it's set to "default Fedora 21 Rescue c80f5da5274a456b83c73b3e3ab8b0bc (3.15.0-0.rc6.git0.1.fc21.x86_64)". I've updated bug 1100504 to reflect this.

I don't even understand how this is intended to work. Is the initial bootloader configuration file expected to be an entryless shell? And then grubby populates it as kernels get installed? Or other?

The anaconda program.log will show when the grub configuration file is written since it's a separate command/script that gets run to do this, grub2-mkconfig. There isn't an equivalent for extlinux.conf, anaconda creates this itself and doesn't say in the log when it's created - if it happens before or after dracut creates the initramfs's.


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

[Index of Archives]     [Kickstart]     [Fedora Users]     [Fedora Legacy List]     [Fedora Maintainers]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]
  Powered by Linux