I looked at that, and it tells me in the first transaction (that night)

that it updated a bunch of packages and removed kmod-VirtualBox.

[I presume now was when Discover insisted I reboot.]

The next transaction (10 minutes later), it was trying to install

a new version of kmod-VirtualBox.  But it failed!

[Here I presume, the system auto-rebooted.

The next transaction (another 10 minutes later), it was trying to install

that same new version of kmod-VirtualBox. And again it failed.

[And here I presume, was another auto-reboot. But this time,

 I was dropped into 'emergency boot mode due to the

 "can't mount /boot/efi" issue.]

On Tue, Jan 18, 2022 at 11:23 AM stan via users <users@lists.fedoraproject.org> wrote:

> If you were installing something, try dnf history.
> In boot, there should be a config file for that latest kernel.  Run the command
> grep -i vfat config[latest kernel text]
> If there is no vfat, this will show it, but I think all fedora kernels
> are built with drivers for vfat built in. 
> CONFIG_VFAT_FS=y

I see the latest version of config is the same as the older versions of config...

and they all contain:

CONFIG_VFAT_FS=m

(So if I wanted to pursue this, I think I'd have to go into the initramfs to

see if the VFAT module was in there.  But since I'm back into a working state

I'm declaring my problem solved (see below).)

>> 3/ I don't think I'll ever use 'discover' again.
>>    It seems tedious, doesn't provide any status feedback on what it's
>> doing. And it always seems to want to reboot.
>>    What was wrong with the old 'new rpm download/install'
>> procedure/utility?
>
>It is for people only familiar with gui interfaces who don't
>understand, or care to understand, what is going on under the hood.
>Mac or Windows users, or people who have no computer experience and
>just want a utility to go on the web, send some emails, maybe do a
>little spreadsheet or word processing.  i.e.  Fedora trying to appeal
>to a broader audience than its original technical base.  

I knew why it's being done, but it's a BAD design decision.

But I'd have to say "Please stop making Linus (or Fedora) as bad as MS Windows".

My GF is constantly asking me why Windows is doing this or that while

shutting down, and I have to tell her "I don't know.  It doesn't tell you."

She asks: "How long will it take before it shuts down?"

I answer: "We have no idea what it's doing, or when it will be done.

"For all I know it will probably reboot a few times too, before it actually will be done."

"It could take minutes or hours... we have no way of knowing."

On a lark, today I saw that Discover was telling me there were updates.

I asked it to show me what.

After a number of minutes it told me... 7 packages.

OK, I did a 'dnf update' instead.

After 30 seconds it had fetched and installed all 7 packages.

Then I tried 'discover' again.

After another few minutes of fetching, it told me it (still) had to update those 7 packages.

I asked it to refresh, and then asked again.

Another few minutes later, it still thought it needed to install those 7 packages.

What!

So I killed off 'discover' on the task bar.

Here is is, 2 hours later, and I see the icon has re-appeared on the task bar.

It tells me it has 22 packages to update.

But dnf tells me it is up to date.

Does dnf use a different set of repo servers than 'discover' does ?

Does discover query a different local RPM db?

It seems so.

-----

Anyway, the update to my status is that I removed the 5 kernel related packages,

and then did the 'dnf upgrade' to reinstall them, and my system is now in a

working state with that latest kernel update that had failed on me 2 days ago.

Problem averted.

Thanks for all the input.

Fulko