|
On 05/23/2014 02:56 PM, Chris Murphy
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.
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.
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.
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
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.
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.
Gene
|
