If I'm not mistaken, this issue hasn't been resolved...
Since the rescue kernel depends to some extent on the kernel modules
in the root volume, would the right solution be:
- in preuninstall, determine whether the rescue kernel matches the
version being removed, and if so, remove it, and then:
- determine whether the version being removed matches the running
kernel, and if not, then build a rescue kernel for the running kernel
version
Protecting the running kernel is optional, so it's possible that the
running kernel will be the one removed, and in that case I *think*
that the system will end up building a rescue kernel for the version
whose installation triggered the removal of a kernel package. That
rescue kernel might not work, but neither would the version whose
modules were just removed, so the system probably isn't worse off.
(And systems with the normal behavior of protecticong the running
kernel should be safe from this.)
Then the remaining problem is that an awful lot of Fedora systems have
already removed the kernel-modules corresponding to (and supporting)
their rescue kernel, and this approach would leave them in their
current broken state.
On Tue, Mar 1, 2022 at 2:56 PM Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote:
>
> On Tue, Mar 1, 2022 at 3:24 PM Justin Forbes <jmforbes@xxxxxxxxxxx> wrote:
>
> > I am surprised that the rescue kernel would give an indefinite hang or
> > even just a dracut prompt within a release.
>
> The latter case is trivially reproducible on UEFI, with the failure
> being that mounting /boot/efi comes *after* switchroot. After
> switchroot the vfat module in the initramfs is not available, and the
> rootfs lacks matching /usr/lib/modules, therefore it's also not
> available. And thus mount fails and thus dracut shell.
>
> A possible simple work around is having the installer add "nofail"
> mount option to /boot/efi which raises the potential problem that it
> fails to mount for $REASON, and thus silently isn't getting bootloader
> updates. I guess that's better than always getting a dracut prompt?
>
> Also more reliable would be if the rescue boot entry uses
> systemd.whateverisolate=multiuser.target to make sure (a) consistency
> no matter the existence of /usr/lib/modules (b) we don't get hung up
> somehow loading the graphical environment possibly needing things in
> /usr/lib/modules that aren't available.
>
> --
> Chris Murphy
> _______________________________________________
> devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
> Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
