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. https://bugzilla.redhat.com/show_bug.cgi?id=1100504
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.
Chris Murphy
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. https://bugzilla.redhat.com/show_bug.cgi?id=1100504
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.
Gene
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. https://bugzilla.redhat.com/show_bug.cgi?id=1100504
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.
Gene
On May 23, 2014, at 7:59 AM, Gene Czarcinski gczarcinski@gmail.com 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. https://bugzilla.redhat.com/show_bug.cgi?id=1100504
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
On 05/23/2014 02:56 PM, Chris Murphy wrote:
On May 23, 2014, at 7:59 AM, Gene Czarcinski <gczarcinski@gmail.com mailto:gczarcinski@gmail.com> 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. https://bugzilla.redhat.com/show_bug.cgi?id=1100504
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
On May 23, 2014, at 2:28 PM, Gene Czarcinski gczarcinski@gmail.com 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
On 05/23/2014 07:35 PM, Chris Murphy wrote:
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.
On Fedora 20 do: rpm -ql kernel | grep boot
and on rawhide/Fedora 21 do: rpm -ql kernel-core | grep boot
The rpm delivers a initramfs and then new-kernel-pkg rebuilds initramfs depending on what is really on you system.
Gene
On May 23, 2014, at 9:17 PM, Gene Czarcinski gczarcinski@gmail.com wrote:
On 05/23/2014 07:35 PM, Chris Murphy wrote:
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.
On Fedora 20 do: rpm -ql kernel | grep boot
and on rawhide/Fedora 21 do: rpm -ql kernel-core | grep boot
The rpm delivers a initramfs and then new-kernel-pkg rebuilds initramfs depending on what is really on you system.
No. The RPM delivers a filename for the initramfs to handoff to dracut to build the file. It's accounted for in the RPM because the RPM is responsible for providing the file, but it's via dracut. During kernel install, the kernel file appears yet the initramfs doesn't, until well into the dracut process creating it.
Also, when I use rpm2cpio kernel-core-3.15.0-0.rc6.git0.1.fc21.x86_64.rpm | cpio -idmv there is no initramfs file extracted from the RPM.
Plus, that .rpm is only 18MB. When extracted with the above command, it's 23.4MB of files. A non-host-only initramfs for that kernel is 44MB, and is already gzipped. That can't be inside an 18MB RPM. Even a smaller host-only RPM can't fit, plus it's useless - it would't work on anything so there'd be no point to include it.
Chris
On 05/23/2014 07:35 PM, Chris Murphy 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, I use LXDe as a light-weight environment for qemu-kvm testing. Indeed, doing "liveinst --exttlinux" results in a extlinux bootloader of the installed system AND the order is screwed up witjh the rescue kernel as default. Not good, not good. I am going to stick some "import pdb;pdm.set_trace()" into install.py to see if I can understand what is going on.
Gene
On 05/23/2014 09:59 AM, Gene Czarcinski 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. https://bugzilla.redhat.com/show_bug.cgi?id=1100504
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.
No problems so far. When you do a netinstall or DVD install, extlinux works well for both ext4 partitions and rootfs on a btrfs subvol with /boot on a ext4 partition. In fact, it even has the rescue kernel now.
I am still trying to figure out what is happening in liveinst.
Chris -- Do you have the anaconda log files from an install (other than a live install) where the config file is bad? I don't want to go back into old releases because they just will not be fixed. If the problem can be duplicated on rawhide, then I would be interested.
Also, I am curious where you got the "Fedora-Live-Workstation-x86_64-rawhide-20140522.iso" since the "Release Engineering Dashboard" says its build failed (and IIRC it failed the last couple of days).
GEne
On May 23, 2014, at 1:07 PM, Gene Czarcinski gczarcinski@gmail.com wrote:
Chris -- Do you have the anaconda log files from an install (other than a live install) where the config file is bad? I don't want to go back into old releases because they just will not be fixed. If the problem can be duplicated on rawhide, then I would be interested.
That is a UEFI based install with Rawhide 20140522. Today I did a BIOS install with Rawhide 20140523 and get the same results, same order of everything. The main difference is UEFI doesn't have a grub2-install command because the bootloader files are installed from RPM, not the grub install command — otherwise the sequence is the same, the end result is the same. And it's also the same for extlinux, as I note in the bug.
Also, I am curious where you got the "Fedora-Live-Workstation-x86_64-rawhide-20140522.iso" since the "Release Engineering Dashboard" says its build failed (and IIRC it failed the last couple of days).
I got it directly from the dashboard yesterday. Today's dashboard says today's build failed, so I used Fedora-Live-KDE-x86_64-rawhide-20140523.iso instead but I get the same results.
Chris Murphy
anaconda-devel@lists.stg.fedoraproject.org
-
Chris Murphy -
Gene Czarcinski