On install of Fedora-Rawhide-20181127.n.0 DVD or netinst (Server or minimal package sets behave the same), it seems that no BLS loader entries are produced. The installed system then boots to the grub rescue shell. Live install tests seem to have passed. If I run 'new-kernel-pkg --mkinitrd --dracut --depmod --update 4.20.0-0.rc4.git0.1.fc30.x86_64' - the same command anaconda runs in post-install - in the installed system chroot, I see these errors: rpm-sort: Invalid input The param is incorrect but I think they're a consequence (rather than a cause) of /boot/loader/entries being empty. I'm guessing this is somehow related to the installed package set, but still trying to figure it out.
(In reply to Adam Williamson from comment #0) > On install of Fedora-Rawhide-20181127.n.0 DVD or netinst (Server or minimal > package sets behave the same), it seems that no BLS loader entries are > produced. The installed system then boots to the grub rescue shell. Live > install tests seem to have passed. > > If I run 'new-kernel-pkg --mkinitrd --dracut --depmod --update > 4.20.0-0.rc4.git0.1.fc30.x86_64' - the same command anaconda runs in > post-install - in the installed system chroot, I see these errors: > > rpm-sort: Invalid input > The param is incorrect > > but I think they're a consequence (rather than a cause) of > /boot/loader/entries being empty. > > I'm guessing this is somehow related to the installed package set, but still > trying to figure it out. Yes, this is caused by the grubby-deprecated package being installed: # rpm -qa | grep grubby grubby-8.40-21.fc30.x86_64 grubby-deprecated-8.40-21.fc30.x86_64 This package is just for cases where a BLS setup won't be used and the old grubby tool is needed. Since new-kernel-pkg is installed by grubby-deprecated, the kernel-install scripts install the kernel the old way without adding BLS entries to /boot/loader/entries.
It's caused by this commit: https://pagure.io/fedora-comps/c/299cd1d5e3fa38c367bc0ba263189ce24678c20d?branch=master
"Since new-kernel-pkg is installed by grubby-deprecated, the kernel-install scripts install the kernel the old way without adding BLS entries to /boot/loader/entries." That must have changed at some point, though. We are actually expressly running 'new-kernel-pkg' during anaconda post install in order to *get BLS entries created*, in the live image case - see https://bugzilla.redhat.com/show_bug.cgi?id=1648472 . What else has changed here?
(In reply to Adam Williamson from comment #3) > "Since new-kernel-pkg is installed by grubby-deprecated, the kernel-install > scripts install the kernel the old way without adding BLS entries to > /boot/loader/entries." > > That must have changed at some point, though. We are actually expressly > running 'new-kernel-pkg' during anaconda post install in order to *get BLS > entries created*, in the live image case - see > https://bugzilla.redhat.com/show_bug.cgi?id=1648472 . What else has changed > here? No, we are running "kernel-install" as the workaround made in commit https://github.com/rhinstaller/anaconda/pull/1688/commits/e5619c9d0948. What changed is what I mentioned in Comment 2, that grubby-deprecated was added in the core group.
OK. I forgot that change was specific to the live payload, yeah. So, we can try to figure out a different way to achieve what peter wanted to achieve with the comps change...still, it seems worrying that just the presence of grubby-deprecated in the install package set makes the system unbootable. Is it possible to change that?
I'd suggest we move the entries to anaconda-tools . I think being in that group would ensure the packages get into at least the Workstation and Server trees. Is that sufficient, or where else do they need to get to?
For now I've tried moving them to @arm-tools: https://pagure.io/fedora-comps/c/4c2694e1d8b349e6f2c00f8c1fc27102e9471435?branch=master Let's see how that goes. Please let me know if it turns out not to do the job you were trying to do by adding them to @core...
(In reply to Adam Williamson from comment #5) > OK. I forgot that change was specific to the live payload, yeah. So, we can > try to figure out a different way to achieve what peter wanted to achieve I think moving grubby-deprecated to @arm-tools makes sense, but grubby should be available for the other arches. So I've proposed to move to @standard as you suggested: https://pagure.io/fedora-comps/c/f74c7196dcb > with the comps change...still, it seems worrying that just the presence of > grubby-deprecated in the install package set makes the system unbootable. Is > it possible to change that? Yes, I agree with you. Specially since nothing prevents a user to install grubby-deprecated using a custom kickstart file. So I've proposed the following change for Anaconda, to disable BLS if new-kernel-pkg was installed: https://github.com/rhinstaller/anaconda/pull/1708
As the comps changes are merged now, setting MODIFIED. Next time we get a compose we'll see how things stand. The last couple of attempts failed due to unrelated dependency issues.
(In reply to Adam Williamson from comment #9) > As the comps changes are merged now, setting MODIFIED. Next time we get a > compose we'll see how things stand. The last couple of attempts failed due > to unrelated dependency issues. I don't think we can set it to modified yet, since this will only be partially solved in the compose. The problem could still be triggered by adding a grubby-deprecated package in a kickstart file as I mentioned in Comment 8.
Well, the default install case is the most important one, and that is resolved now. If you want to keep it open to track the kickstart case, let's downgrade the severity and take it off the blocker list.
(In reply to Javier Martinez Canillas from comment #8) > (In reply to Adam Williamson from comment #5) > > OK. I forgot that change was specific to the live payload, yeah. So, we can > > try to figure out a different way to achieve what peter wanted to achieve > > I think moving grubby-deprecated to @arm-tools makes sense, but grubby > should be available for the other arches. So I've proposed to move to > @standard as you suggested: > > https://pagure.io/fedora-comps/c/f74c7196dcb > > > with the comps change...still, it seems worrying that just the presence of > > grubby-deprecated in the install package set makes the system unbootable. Is > > it possible to change that? > > Yes, I agree with you. Specially since nothing prevents a user to install > grubby-deprecated using a custom kickstart file. > > So I've proposed the following change for Anaconda, to disable BLS if > new-kernel-pkg was installed: > > https://github.com/rhinstaller/anaconda/pull/1708 The Anaconda change was merged, so this bug can be closed now.