On Fri, 2019-11-01 at 12:06 -0400, Bob Goodwin wrote:
On 10/31/19 23:43, Tim via users wrote:
> You could go back to gparted, and remove your partitions, making it
> a
> blank drive.
.
Tim:
That is what the Anaconda installerwanted. I created a new "1 TB"
partition wit gparted and then it went without any problems.It just
popped up the Complete notice, next to reboot on the new installation
on
sata1, I use separate droves for different versions, sata2 has F-30
upgraded on it, and there is another drive, I forget what is there.
I don't know that Fedora 31 will get much use anyway but I have to
give
it a try. This is Fedora 29 and works best for my needs,
unfortunately
it will no longer be supported by Fedora a few weeks. It is the last
that permits running a version of Thunderbird for which there is a
working add-on "Tonequilla" that allows me to have voice messages
associated with message filters. I can be working downstairs and
hear
when a message arrives from a particular source/user for which I
long
ago created voice announcements. That and the white text on black
are
essential requirements for me. I found themes that take care of the
text
color scheme and most likely that will continue to work Well, Fedora
31
is installed and dnf upgrade done, next to reconfigure things to do
what
I want. That generally takes a few days. Upgrading pretty much
eliminates that effort but I wanted to change things enough so the
effort seems justified.
I had a similar experience with a fresh F31 install, which probably is
the root cause of the reported issue. The machine had previously been
upgraded from F25 through F30, but due to an existing kernel selection
issue, I elected to do a fresh install of F31 instead of an upgrade,
and restore a complete /home backup and reconfigure evolution,
reinstall the missing repos and packages. It went pretty smoothly
until I rebooted and it could not find a bootable device.
I initially suspected a grub issue, but it looked ok. I eventually
tracked it down to a curious error in the F31 installer - it installed
an EFI boot image instead of a normal boot image. Since EFI was not in
the BIOS boot sequence, it failed to find the boot disk.
The workaround was simple - just add an EFI boot selection to the BIOS
list before all others, and it now boots as expected. As to why the
installer chose to install an EFI image when the machine was not
configured to use EFI, I have filed a bug on the problem. See
https://bugzilla.redhat.com/show_bug.cgi?id=1767838 for details.
--
John Mellor