On Mon, 27 May 2019 22:27:16 -0600 Chris Murphy lists@colorremedies.com wrote:
On Mon, May 27, 2019 at 3:55 PM stan upaitag@zoho.com wrote:
It ran for over 20 minutes at almost 100% CPU and didn't complete. So, I killed it.
The installation failure needs a bug report with all the installer logs attached, and a description of reproduce steps, and the before and after state.
Where do I find these logs? I'm not in an active system when I'm reading them, the install has failed.
Before and after state for what? It's a 250 GiB partition.
The issue seems to be that hybrid installs are not allowed. If I install as BIOS, then I have to use BIOS partitioning, not gpt.
Not correct. The installer does support GPT when booted with BIOS firmware. It just doesn't support MBR with UEFI firmware.
And, if I install as UEFI, for some reason it doesn't accept the existing ext4 partitions on the gpt formatted drive.
That's a separate bug report, also needs installer logs attached.
Same question. Where are they saved?
Is must be possible to boot a GPT drive from a BIOS mbr because it appears that I was doing that.
I can't parse this.
The existing F28 on this GPT disk was booting just fine before I tried to install F31. Turn the machine on, and F28 running resulted.
Or, did the hybrid UEFI/BIOS firmware setting allow both?
Running 'efibootmgr' will tell you what firmware is being presented to the kernel.
# efibootmgr -v EFI variables are not supported on this system (from F28, /dev/sda5, on the GPT drive).
Here's the partition table for the disk from gdisk -l.
Number Start (sector) End (sector) Size Code Name 1 2097152 4194303 1024.0 MiB 8300 2 4194304 6291455 1024.0 MiB 0700 3 6291456 48234495 20.0 GiB 8200 4 48234496 572522495 250.0 GiB 8300 5 572522496 1096810495 250.0 GiB 0700 6 1096810496 5860532223 2.2 TiB 0700 7 2048 6143 2.0 MiB EF02
The first two partitions are boot, then swap, then two root partitions, then data. The code for the partitions I was trying to install from the iso to are now 8300, the existing Fedora is 0700.
That's all suspicious because 0700 for a boot volume isn't correct, and suggests an old version of parted created that partition. Also partition 3 cannot be a root partition, the type code is for swap.
# fdisk -l /dev/sda Disk /dev/sda: 2.7 TiB, 3000592982016 bytes, 5860533168 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disklabel type: gpt Disk identifier: 363C9B1D-DBA5-41AE-A74B-6DD5F974ED6D
Device Start End Sectors Size Type /dev/sda1 2097152 4194303 2097152 1G Linux filesystem /dev/sda2 4194304 6291455 2097152 1G Microsoft basic data /dev/sda3 6291456 48234495 41943040 20G Linux swap /dev/sda4 48234496 572522495 524288000 250G Linux filesystem /dev/sda5 572522496 1096810495 524288000 250G Microsoft basic data /dev/sda6 1096810496 5860532223 4763721728 2.2T Microsoft basic data /dev/sda7 2048 6143 4096 2M BIOS boot
Partition table entries are not in disk order.
I'm typing from /dev/sda5. So, 0700 *is* a linux filesystem on this disk, not Microsoft basic data.
Can I actually somehow do a UEFI install to this disk, preserving the existing Fedora and being able to boot to it directly?
Dual Fedora's isn't officially supported. The installer almost always steps on the previous Fedora's bootloader making it unbootable, in favor of a new bootloader for the new Fedora installation. Sometimes grub2-mkconfig finds the old Fedora and will add entries for it in the grub.cfg, sometimes not. If root is a plain partition, it'll be discovered probably, and if it's LVM, the installer doesn't activate LVM for other installations so os-prober won't see them and won't create menu entries.
So you'll have to jerry-rig it yourself after the new installation.
See my comments about this on another reply in this thread.