Hi, I pulled the server net install iso for rawhide, the future Fedora 31, and tried to install it. I used custom install with existing partitions on a bios partitioned disk. It refused to install because it wanted gpt and uefi.
I swap back and forth between predefined partitions, so I always have a working Fedora to fall back on. This has worked fine in the past.
Is gpt and uefi now required for install? I didn't see a way to toggle the setting.
Thanks.
On 5/25/19 4:08 PM, stan wrote:
Hi, I pulled the server net install iso for rawhide, the future Fedora 31, and tried to install it. I used custom install with existing partitions on a bios partitioned disk. It refused to install because it wanted gpt and uefi.
I swap back and forth between predefined partitions, so I always have a working Fedora to fall back on. This has worked fine in the past.
Is gpt and uefi now required for install? I didn't see a way to toggle the setting.
If you are booting in UEFI mode, then yes, they are required. If you don't want that, you need to boot in legacy or CSM mode.
On Sun, 26 May 2019 23:20:08 -0700 Samuel Sieb samuel@sieb.net wrote:
If you are booting in UEFI mode, then yes, they are required. If you don't want that, you need to boot in legacy or CSM mode.
Thanks for the tip. That enables me to see the problem, but not how to correct it. The boot stanza for the iso uses linuxefi and initrdefi. I can edit the stanza just like a regular boot, but if I try to change those to linux16 or initrd16, the default on my system, they are not found. I tried linux too, just in case it had been made generic, but no go. My experience was that no matter how I tried to bypass the efi boot, I did not succeed. I looked at the rest of the suboptions available, and there wasn't one obvious to my eye that implied an override of the efi boot.
Do you have further insight that will enable me to bypass this hurdle?
On Mon, May 27, 2019 at 8:20 AM stan upaitag@zoho.com wrote:
On Sun, 26 May 2019 23:20:08 -0700 Samuel Sieb samuel@sieb.net wrote:
If you are booting in UEFI mode, then yes, they are required. If you don't want that, you need to boot in legacy or CSM mode.
Thanks for the tip. That enables me to see the problem, but not how to correct it. The boot stanza for the iso uses linuxefi and initrdefi. I can edit the stanza just like a regular boot, but if I try to change those to linux16 or initrd16, the default on my system, they are not found. I tried linux too, just in case it had been made generic, but no go. My experience was that no matter how I tried to bypass the efi boot, I did not succeed. I looked at the rest of the suboptions available, and there wasn't one obvious to my eye that implied an override of the efi boot.
Do you have further insight that will enable me to bypass this hurdle?
That you get GRUB from installation media tells me your computer is presenting itself as having UEFI firmware, because on computers with BIOS firmware the installation media will use isolinux as the bootloader, not GRUB. If the firmware is UEFI, GPT partitioning is required (same as Windows) by the installer. It's been this way since forever, at least Fedora 18.
Most UEFI firmware today have a "legacy" option or "uefi enable/disable" option in firmware setup, that will cause a faux-BIOS to be presented instead of UEFI. These days I'm not sure why you'd want to use that, unless you have specific known UEFI firmware bugs that aren't going to be fixed by the manufacturer and also don't have work arounds in either GRUB or the kernel. So I don't really understand why this system has an MBR partitioning scheme in the first place (there are older hardware in the Windows 7 era that were UEFI but shipped with the compatibility support module enabled to present BIOS).
Anyway, you need to be looking in firmware setup for this. Probably. I have seen some computers with in-firmware boot manager that shows a USB boot option with a UEFI prefix suggesting they will only boot in UEFI mode from USB if you choose that option; and still another option for the same USB device but without a UEFI prefix (or with a legacy prefix) and that enables the CSM for that boot - it's not a persistent setting. It's kindof a sneaky user interface convention.
Off topic: Also, FYI, your mail server configuration asks other mail servers to consider your forwarded emails as suspicious, so gmail users likely don't see your emails at all. I found your post in spam. I don't know for sure the proper way to fix it, but a discussion just happened on devel@ about it. I'm inclined to think this is a Fedora mail server misconfiguration and the poster's mail server's dmarc header should be stripped and replaced with its own (i.e. verify the posted email is valid per dmarc/dkim, then strip that header; and resign the message for the list), but ya whatever.
Authentication-Results: mx.google.com; arc=fail (body hash mismatch); spf=pass (google.com: domain of test-bounces@lists.fedoraproject.org designates 209.132.181.2 as permitted sender) smtp.mailfrom=test-bounces@lists.fedoraproject.org; dmarc=fail (p=REJECT sp=REJECT dis=QUARANTINE) header.from=zoho.com
On Mon, 2019-05-27 at 10:00 -0600, Chris Murphy wrote:
On Mon, May 27, 2019 at 8:20 AM stan upaitag@zoho.com wrote:
On Sun, 26 May 2019 23:20:08 -0700 Samuel Sieb samuel@sieb.net wrote:
If you are booting in UEFI mode, then yes, they are required. If you don't want that, you need to boot in legacy or CSM mode.
Thanks for the tip. That enables me to see the problem, but not how to correct it. The boot stanza for the iso uses linuxefi and initrdefi. I can edit the stanza just like a regular boot, but if I try to change those to linux16 or initrd16, the default on my system, they are not found. I tried linux too, just in case it had been made generic, but no go. My experience was that no matter how I tried to bypass the efi boot, I did not succeed. I looked at the rest of the suboptions available, and there wasn't one obvious to my eye that implied an override of the efi boot.
Do you have further insight that will enable me to bypass this hurdle?
That you get GRUB from installation media tells me your computer is presenting itself as having UEFI firmware, because on computers with BIOS firmware the installation media will use isolinux as the bootloader, not GRUB. If the firmware is UEFI, GPT partitioning is required (same as Windows) by the installer. It's been this way since forever, at least Fedora 18.
Right. Nothing has changed in the media here AFAIK. If you boot from the firmware to the Fedora install media in a UEFI-native way, the installer will boot UEFI-native and require you to do a UEFI-native install. If you boot from the firmware to the Fedora install media in a BIOS-native way, the installer will boot BIOS-native and require you to do a BIOS-native install.
This isn't something we (Fedora) control, it's between you and your system's firmware. Either you aren't writing your install media and/or booting them quite the same as you did before, or your firmware's configuration has changed somehow from preferring BIOS-native boot to UEFI-native boot. You should be able to find a way to do a BIOS-native boot in the firmware UI somewhere, though.
On Mon, 27 May 2019 10:00:02 -0600 Chris Murphy lists@colorremedies.com wrote:
That you get GRUB from installation media tells me your computer is presenting itself as having UEFI firmware, because on computers with BIOS firmware the installation media will use isolinux as the bootloader, not GRUB. If the firmware is UEFI, GPT partitioning is required (same as Windows) by the installer. It's been this way since forever, at least Fedora 18.
Yes, the firmware is UEFI. But, the hard drives have been in use with older hardware that wasn't. My understanding is that it is difficult and chancy to convert from legacy partitions to GPT partitioning. Is that false?
I thought that I had done a direct install for Fedora 21. It was the last time that the BFO option worked for direct install from the net instead of using media. It worked great at that point, but has been non-responsive for several versions of Fedora since, or I would be using it still. But that was a long time ago, so I could be wrong. I have been just replicating the existing Fedora, and then enabling rawhide to upgrade. I suppose I could do that again, but I like a fresh install every so often to get rid of cruft.
Most UEFI firmware today have a "legacy" option or "uefi enable/disable" option in firmware setup, that will cause a faux-BIOS to be presented instead of UEFI. These days I'm not sure why you'd want to use that, unless you have specific known UEFI firmware bugs that aren't going to be fixed by the manufacturer and also don't have work arounds in either GRUB or the kernel. So I don't really understand why this system has an MBR partitioning scheme in the first place (there are older hardware in the Windows 7 era that were UEFI but shipped with the compatibility support module enabled to present BIOS).
See above. The firmware must have that because when I first used this MB it allowed me to re-use the old drives with MBR from the failed MB.
Anyway, you need to be looking in firmware setup for this. Probably. I have seen some computers with in-firmware boot manager that shows a USB boot option with a UEFI prefix suggesting they will only boot in UEFI mode from USB if you choose that option; and still another option for the same USB device but without a UEFI prefix (or with a legacy prefix) and that enables the CSM for that boot - it's not a persistent setting. It's kindof a sneaky user interface convention.
I'll look at this. I suspect it will be present and will provide a workaround. At some point I'll have to bite the bullet and switch. I'll probably do it when I purchase a new hard drive. I'm using cd-rom in a dvd drive now, but if I have to I can switch to USB.
Off topic: Also, FYI, your mail server configuration asks other mail servers to consider your forwarded emails as suspicious, so gmail users likely don't see your emails at all. I found your post in spam. I don't know for sure the proper way to fix it, but a discussion just happened on devel@ about it. I'm inclined to think this is a Fedora mail server misconfiguration and the poster's mail server's dmarc header should be stripped and replaced with its own (i.e. verify the posted email is valid per dmarc/dkim, then strip that header; and resign the message for the list), but ya whatever.
Authentication-Results: mx.google.com; arc=fail (body hash mismatch); spf=pass (google.com: domain of test-bounces@lists.fedoraproject.org designates 209.132.181.2 as permitted sender) smtp.mailfrom=test-bounces@lists.fedoraproject.org; dmarc=fail (p=REJECT sp=REJECT dis=QUARANTINE) header.from=zoho.com
I just use a free mail provider, zoho.com. I don't set the parameters. I saw in an email message on one of the Fedora lists that zoho.com had been compromised, and was considered untrusworthy. That is probably why it is marked as such. Maybe I should switch to using my ISP. I used to use a paid email provider, but they suffered an intrusion that put them offline briefly, and I have been leery of continuing with them.
Thanks for your help.
On Mon, May 27, 2019 at 11:19 AM Adam Williamson adamwill@fedoraproject.org wrote:
Either you aren't writing your install media and/or booting them quite the same as you did before,
Yep, I often forget this detail. How was the install media created, exactly? Quite a lot of methods recreated partitions and bootloader stuff on the USB stick, then copy over portions of the Fedora image, and that breaks the special sauce Fedora images use to pretty much boot anything with a single image: UEFI, BIOS, Macs.
On 5/27/19 10:26 AM, stan wrote:
On Mon, 27 May 2019 10:00:02 -0600 Chris Murphy lists@colorremedies.com wrote:
Authentication-Results: mx.google.com; arc=fail (body hash mismatch); spf=pass (google.com: domain of test-bounces@lists.fedoraproject.org designates 209.132.181.2 as permitted sender) smtp.mailfrom=test-bounces@lists.fedoraproject.org; dmarc=fail (p=REJECT sp=REJECT dis=QUARANTINE) header.from=zoho.com
I just use a free mail provider, zoho.com. I don't set the parameters. I saw in an email message on one of the Fedora lists that zoho.com had been compromised, and was considered untrusworthy. That is probably why it is marked as such. Maybe I should switch to using my ISP. I used to use a paid email provider, but they suffered an intrusion that put them offline briefly, and I have been leery of continuing with them.
No, that is something that is specified by the sending domain, zoho.com in this case. Probably the mailing list admins should add that domain to the list of domains that it rewrites addresses from.
On Mon, May 27, 2019 at 11:27 AM stan upaitag@zoho.com wrote:
On Mon, 27 May 2019 10:00:02 -0600 Chris Murphy lists@colorremedies.com wrote:
That you get GRUB from installation media tells me your computer is presenting itself as having UEFI firmware, because on computers with BIOS firmware the installation media will use isolinux as the bootloader, not GRUB. If the firmware is UEFI, GPT partitioning is required (same as Windows) by the installer. It's been this way since forever, at least Fedora 18.
Yes, the firmware is UEFI. But, the hard drives have been in use with older hardware that wasn't. My understanding is that it is difficult and chancy to convert from legacy partitions to GPT partitioning. Is that false?
It should be possible.
# fdisk -l /dev/
ideally the first partition starts at LBA 2048. If not...well cross that bridge later.
Next run gdisk on this device. It will read the MBR, create a GPT from it in memory, and you can write out GPT to disk with the 'w' command. That's it. You need free space on that drive for the installer to create an EFI System partition, which contains bootloader stuff rather than the MBR gap.
Per the UEFI spec, this should not be necessary, but due to past experience with bugs, I would probably opt for zeroing the first 440 bytes of LBA 0 on this drive, which is where the stage 1 (BIOS) GRUB bootloader is located. On UEFI all the GRUB stuff is on the EFI System volume.
# dd if=/dev/zero of=/dev/becareful bs=1 count=440
I thought that I had done a direct install for Fedora 21. It was the last time that the BFO option worked for direct install from the net instead of using media.
This? https://boot.fedoraproject.org/download
That's definitely BIOS only. In theory it could be dual UEFI and BIOS, but no one's done that work and testing. The image would be much bigger. The ones on that page are ~1MiB. I casually estimate a dual UEFI + BIOS image would be ~10MiB.
On Mon, 27 May 2019 11:43:20 -0600 Chris Murphy lists@colorremedies.com wrote:
On Mon, May 27, 2019 at 11:19 AM Adam Williamson adamwill@fedoraproject.org wrote:
Either you aren't writing your install media and/or booting them quite the same as you did before,
Yep, I often forget this detail. How was the install media created, exactly? Quite a lot of methods recreated partitions and bootloader stuff on the USB stick, then copy over portions of the Fedora image, and that breaks the special sauce Fedora images use to pretty much boot anything with a single image: UEFI, BIOS, Macs.
Burned the iso to a cd-rom. Passed checks both during burn and during install.
On Mon, 27 May 2019 12:04:58 -0600 Chris Murphy lists@colorremedies.com wrote:
On Mon, May 27, 2019 at 11:27 AM stan upaitag@zoho.com wrote:
Yes, the firmware is UEFI. But, the hard drives have been in use with older hardware that wasn't. My understanding is that it is difficult and chancy to convert from legacy partitions to GPT partitioning. Is that false?
It should be possible.
# fdisk -l /dev/
ideally the first partition starts at LBA 2048. If not...well cross that bridge later.
Next run gdisk on this device. It will read the MBR, create a GPT from it in memory, and you can write out GPT to disk with the 'w' command. That's it. You need free space on that drive for the installer to create an EFI System partition, which contains bootloader stuff rather than the MBR gap.
Per the UEFI spec, this should not be necessary, but due to past experience with bugs, I would probably opt for zeroing the first 440 bytes of LBA 0 on this drive, which is where the stage 1 (BIOS) GRUB bootloader is located. On UEFI all the GRUB stuff is on the EFI System volume.
# dd if=/dev/zero of=/dev/becareful bs=1 count=440
It seems that the above won't be necessary, as I must have originally formatted the drive as GPT, and forgotten I'd done so.
I was able to switch the firmware to strictly BIOS from UEFI/BIOS hybrid, with UEFI preferred. That allowed the installer to proceed. Unfortunately, it hung while trying to write an mbr, though everything else worked; it installed software, I was able to set users and passwords. I suspect that is because the disk I was installing to is actually formatted with GPT, since it is larger than 2 TiB. It ran for over 20 minutes at almost 100% CPU and didn't complete. So, I killed it. But it had somehow altered something so that when I tried to boot to the other Fedora installed on that disk, it immediately dropped to a grub prompt. It was trying to validate partitions with os-prober at the time I killed it, according to the log, and had hung on the existing Fedora root partition. When I booted in rescue and looked at the disk with fdisk, it declared that all the other partitions on the disk except the ones I had tried to install to were Microsoft data format. That gave me a scare, until I noticed that there was no logical partition. Fortunately I had an older Fedora on another disk that is actually BIOS, and when I booted that from the firmware, I was able to boot and run it. I then ran a mkconfig there, and the os-prober found the original Fedora on the other disk, and created boot stanzas for it. So I was able to get back to my Fedora, the version I am writing this from, in a roundabout way.
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. And, if I install as UEFI, for some reason it doesn't accept the existing ext4 partitions on the gpt formatted drive. Is must be possible to boot a GPT drive from a BIOS mbr because it appears that I was doing that. Or, did the hybrid UEFI/BIOS firmware setting allow both?
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.
Can I actually somehow do a UEFI install to this disk, preserving the existing Fedora and being able to boot to it directly?
I thought that I had done a direct install for Fedora 21. It was the last time that the BFO option worked for direct install from the net instead of using media.
This? https://boot.fedoraproject.org/download
That's definitely BIOS only. In theory it could be dual UEFI and BIOS, but no one's done that work and testing. The image would be much bigger. The ones on that page are ~1MiB. I casually estimate a dual UEFI + BIOS image would be ~10MiB.
Yes, that's the one. The lkrn file that downloads the rest of the boot from the net is ~300kB, but that doesn't actually boot the computer, only downloads the next stage. Just a bootstrap. The actual boot first stage is approximately 30 MiB, if my memory is accurate after all this time. I remember it printing several lines of markers to show its progress. That then downloads anaconda for the actual install, and it proceeds just like a netinstall from that point.
On Mon, 27 May 2019 10:18:43 -0700 Adam Williamson adamwill@fedoraproject.org wrote:
Right. Nothing has changed in the media here AFAIK. If you boot from the firmware to the Fedora install media in a UEFI-native way, the installer will boot UEFI-native and require you to do a UEFI-native install. If you boot from the firmware to the Fedora install media in a BIOS-native way, the installer will boot BIOS-native and require you to do a BIOS-native install.
This isn't something we (Fedora) control, it's between you and your system's firmware. Either you aren't writing your install media and/or booting them quite the same as you did before, or your firmware's configuration has changed somehow from preferring BIOS-native boot to UEFI-native boot. You should be able to find a way to do a BIOS-native boot in the firmware UI somewhere, though.
I think the last time I did a fresh install, I must have been using BIOS on a BIOS formatted disk. This time, I was able to disable UEFI, but then discovered that the disk was formatted with GPT, and that caused problems for the installer. The media isn't the problem since it passed both the burn check and the install check, and seems to work fine otherwise. I'm not sure why UEFI would have had problems with pre-existing ext4 partitions on a GPT formatted disk, but it does and refuses to proceed.
I'll keep plugging away. Thanks.
On 5/27/19 3:07 PM, stan wrote:
I think the last time I did a fresh install, I must have been using BIOS on a BIOS formatted disk. This time, I was able to disable UEFI, but then discovered that the disk was formatted with GPT, and that caused problems for the installer. The media isn't the problem since it passed both the burn check and the install check, and seems to work fine otherwise. I'm not sure why UEFI would have had problems with pre-existing ext4 partitions on a GPT formatted disk, but it does and refuses to proceed.
If you have a GPT formatted disk, why aren't you using UEFI?
You can still do a BIOS install to a GPT formatted drive. You just need to create a BIOS boot partition (not /boot) which is what the installer should be telling you.
On 5/27/19 2:54 PM, stan wrote:
Can I actually somehow do a UEFI install to this disk, preserving the existing Fedora and being able to boot to it directly?
You can't use the grub config file from the old install, but you might be able to boot it if you add entries pointing to the files there. Apparently BLS unifies this, so the same entries can boot in either EFI or BIOS mode.
On Mon, May 27, 2019 at 3:03 PM stan upaitag@zoho.com wrote:
On Mon, 27 May 2019 11:43:20 -0600 Chris Murphy lists@colorremedies.com wrote:
On Mon, May 27, 2019 at 11:19 AM Adam Williamson adamwill@fedoraproject.org wrote:
Either you aren't writing your install media and/or booting them quite the same as you did before,
Yep, I often forget this detail. How was the install media created, exactly? Quite a lot of methods recreated partitions and bootloader stuff on the USB stick, then copy over portions of the Fedora image, and that breaks the special sauce Fedora images use to pretty much boot anything with a single image: UEFI, BIOS, Macs.
Burned the iso to a cd-rom. Passed checks both during burn and during install.
Boot from it again and run
# efibootmgr -v
And report the output.
On Mon, May 27, 2019 at 3:55 PM stan upaitag@zoho.com wrote:
It seems that the above won't be necessary, as I must have originally formatted the drive as GPT, and forgotten I'd done so.
I was able to switch the firmware to strictly BIOS from UEFI/BIOS hybrid, with UEFI preferred. That allowed the installer to proceed. Unfortunately, it hung while trying to write an mbr, though everything else worked; it installed software, I was able to set users and passwords. I suspect that is because the disk I was installing to is actually formatted with GPT, since it is larger than 2 TiB.
The installer will not convert GPT disk to MBR disk, or MBR to GPT. It also won't write an MBR to a 2+TiB drive.
It ran for over 20 minutes at almost 100% CPU and didn't complete. So, I killed it. But it had somehow altered something so that when I tried to boot to the other Fedora installed on that disk, it immediately dropped to a grub prompt. It was trying to validate partitions with os-prober at the time I killed it, according to the log, and had hung on the existing Fedora root partition. When I booted in rescue and looked at the disk with fdisk, it declared that all the other partitions on the disk except the ones I had tried to install to were Microsoft data format. That gave me a scare, until I noticed that there was no logical partition. Fortunately I had an older Fedora on another disk that is actually BIOS, and when I booted that from the firmware, I was able to boot and run it. I then ran a mkconfig there, and the os-prober found the original Fedora on the other disk, and created boot stanzas for it. So I was able to get back to my Fedora, the version I am writing this from, in a roundabout way.
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.
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.
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.
Or, did the hybrid UEFI/BIOS firmware setting allow both?
Running 'efibootmgr' will tell you what firmware is being presented to the kernel.
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.
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.
Chris Murphy lists@colorremedies.com wrote on Mon, 27 May 2019 22:27:16 -0600:
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.
This deserves some attention. I expect to be able to install Fedora in some disk space, and still be able to boot an older Fedora previously installed in other disk space.
I would like the Fedora Installer to be aggressive when it builds its new boot configuration file, and copy as much as it can from old boot configuration data. Certainly it cannot understand everything, but I would prefer a menu item with some comment that Fedora does not know if this will work but has included it because it was found in the existing system, than to find my old configuration was simply discarded by a new Fedora installation.
It may be the best solution is some dual strategy that has the Fedora Installer do what is "easy" (other simple Fedora systems, maybe Windows) and leaves harder cases (unknown systems, unusual configurations, storage volumes that are not accessible during installation) for some utility that can be executed after installation by a user who can quide it to make desired changes to the boot configuration.
"Do no harm." applies here, because recovery of boot configuration data lost during Fedora installation requires knowledge and experience beyond what many users have.
e
On Tue, May 28, 2019 at 9:09 AM Richard Ryniker ryniker@alum.mit.edu wrote:
Chris Murphy lists@colorremedies.com wrote on Mon, 27 May 2019 22:27:16 -0600:
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.
This deserves some attention. I expect to be able to install Fedora in some disk space, and still be able to boot an older Fedora previously installed in other disk space.
For the default installation, that hasn't been the case in a long time. One of the reasons this doesn't work out of the box is anaconda doesn't activate LVs for prior Fedora versions, and therefore grub2-mkconfig doesn't discover them. https://bugzilla.redhat.com/show_bug.cgi?id=825236
The bootloaderspec feature in Fedora 30 makes this use case easier to support, but it's still not going to just work out of the box because each Fedora installation has separate boot volumes, which means the latest installed and active bootloader sees only the latest Fedora version's bootloader configuration files. If Fedora versions share a boot volume, then the latest version bootloader sees both installations and can present them in the GRUB menu, but that's not part of the default/automatic installation behavior.
One possible gotcha is the boot volume needs to be big enough. For a few releases it's been 1GiB which probably is big enough for two Fedora's to share, because we don't use kdump by default whereas I guess it's configured on RHEL and that was the impetus behind the boot volume size change.
Another gotcha is on UEFI, the older Fedora during software updates will (rarely) need to update the bootloader which will step on the binary files in /boot/efi/EFI/fedora, which isn't the end of the world but it's probably better if the old Fedora /etc/fstab is modified to remove the automount of /boot/efi so that the EFI System partition isn't ever updated except by the new Fedora.
I would like the Fedora Installer to be aggressive when it builds its new boot configuration file, and copy as much as it can from old boot configuration data. Certainly it cannot understand everything, but I would prefer a menu item with some comment that Fedora does not know if this will work but has included it because it was found in the existing system, than to find my old configuration was simply discarded by a new Fedora installation.
On BIOS, it's preserved but ignored.
On UEFI the contents of the EFI system partition in EFI/fedora are blown away and replaced. It's been that way since we've had UEFI support as far as I can recall. The nice thing is that on Fedora 30 with BLS support, the grub.cfg on the ESP no longer contains the Fedora menu entries, those are now on the boot volume. So they will be preserved, but again they're ignored out of the box because we don't automatically share boot volumes.
It may be the best solution is some dual strategy that has the Fedora Installer do what is "easy" (other simple Fedora systems, maybe Windows) and leaves harder cases (unknown systems, unusual configurations, storage volumes that are not accessible during installation) for some utility that can be executed after installation by a user who can quide it to make desired changes to the boot configuration.
"Do no harm." applies here, because recovery of boot configuration data lost during Fedora installation requires knowledge and experience beyond what many users have.
Something that has been lost is a way to create the bootloader configuration files if they're deleted. With Fedora 29 and older you can just run grub2-mkconfig and that pile of scripts will discover all the information needed to regenerate menu entries. That's no longer the case, as grub2-mkconfig doesn't create menu entries for Fedora anymore, it'll just recreate a static grub.cfg with the command to look in /boot/loader/entries for *conf files. But if those *conf files are missing, you get no entries in the GRUB menu. How do we recreate them? *shrug* Right now that script is in the kernel RPMs, so you'd need to reinstall a kernel to get a new *conf file in place.
-- Chris Murphy
On Mon, 27 May 2019 10:57:54 -0700 Samuel Sieb samuel@sieb.net wrote:
No, that is something that is specified by the sending domain, zoho.com in this case. Probably the mailing list admins should add that domain to the list of domains that it rewrites addresses from.
Thanks.
Is there something I can do to facilitate that? If I'm sending to the list, might as well be seen by everyone.
On Tue, May 28, 2019 at 12:49 PM stan upaitag@zoho.com wrote:
On Mon, 27 May 2019 10:57:54 -0700 Samuel Sieb samuel@sieb.net wrote:
No, that is something that is specified by the sending domain, zoho.com in this case. Probably the mailing list admins should add that domain to the list of domains that it rewrites addresses from.
Thanks.
Is there something I can do to facilitate that? If I'm sending to the list, might as well be seen by everyone.
It's not. Every single one of your emails goes to spam for me on gmail, no matter how many times I tell gmail it's not spam. It'll be the same for anyone whose ISP is honoring your ISP's dmarc policy, which says to reject/quarantine your emails when forwarded, which is what email servers do. Quite a lot of people are not seeing your emails, I suspect.
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.
On Tue, 28 May 2019 10:26:10 -0600 Chris Murphy lists@colorremedies.com wrote:
On Tue, May 28, 2019 at 9:09 AM Richard Ryniker ryniker@alum.mit.edu wrote:
Chris Murphy lists@colorremedies.com wrote on Mon, 27 May 2019 22:27:16 -0600:
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.
This deserves some attention. I expect to be able to install Fedora in some disk space, and still be able to boot an older Fedora previously installed in other disk space.
I agree with this.
For the default installation, that hasn't been the case in a long time. One of the reasons this doesn't work out of the box is anaconda doesn't activate LVs for prior Fedora versions, and therefore grub2-mkconfig doesn't discover them. https://bugzilla.redhat.com/show_bug.cgi?id=825236
It has worked fine for me until this update. Of course, I used a custom install.
The bootloaderspec feature in Fedora 30 makes this use case easier to support, but it's still not going to just work out of the box because each Fedora installation has separate boot volumes, which means the latest installed and active bootloader sees only the latest Fedora version's bootloader configuration files. If Fedora versions share a boot volume, then the latest version bootloader sees both installations and can present them in the GRUB menu, but that's not part of the default/automatic installation behavior.
One possible gotcha is the boot volume needs to be big enough. For a few releases it's been 1GiB which probably is big enough for two Fedora's to share, because we don't use kdump by default whereas I guess it's configured on RHEL and that was the impetus behind the boot volume size change.
Does this larger boot volume have to be at the start of the drive. Could I re-purpose a swap partition into a boot volume?
So, couldn't there be a utility, which when the user points it at an alternate installation, it creates a link in the boot volume with priority. The way grub(1) used to do with the configfile entry.
Another gotcha is on UEFI, the older Fedora during software updates will (rarely) need to update the bootloader which will step on the binary files in /boot/efi/EFI/fedora, which isn't the end of the world but it's probably better if the old Fedora /etc/fstab is modified to remove the automount of /boot/efi so that the EFI System partition isn't ever updated except by the new Fedora.
For a single large boot directory for all OSs on the system, couldn't there be a directory for each OS, allowing for both update and a boot selection screen (a menu of available OSs).
I would like the Fedora Installer to be aggressive when it builds its new boot configuration file, and copy as much as it can from old boot configuration data. Certainly it cannot understand everything, but I would prefer a menu item with some comment that Fedora does not know if this will work but has included it because it was found in the existing system, than to find my old configuration was simply discarded by a new Fedora installation.
On BIOS, it's preserved but ignored.
On UEFI the contents of the EFI system partition in EFI/fedora are blown away and replaced. It's been that way since we've had UEFI support as far as I can recall. The nice thing is that on Fedora 30 with BLS support, the grub.cfg on the ESP no longer contains the Fedora menu entries, those are now on the boot volume. So they will be preserved, but again they're ignored out of the box because we don't automatically share boot volumes.
I'm not familiar with the term ESP. From context, some kind of partition? Is the boot volume you refer to where the Fedora menu entries are stored /boot? Or a separate partition?
It may be the best solution is some dual strategy that has the Fedora Installer do what is "easy" (other simple Fedora systems, maybe Windows) and leaves harder cases (unknown systems, unusual configurations, storage volumes that are not accessible during installation) for some utility that can be executed after installation by a user who can quide it to make desired changes to the boot configuration.
"Do no harm." applies here, because recovery of boot configuration data lost during Fedora installation requires knowledge and experience beyond what many users have.
Something that has been lost is a way to create the bootloader configuration files if they're deleted. With Fedora 29 and older you can just run grub2-mkconfig and that pile of scripts will discover all the information needed to regenerate menu entries. That's no longer the case, as grub2-mkconfig doesn't create menu entries for Fedora anymore, it'll just recreate a static grub.cfg with the command to look in /boot/loader/entries for *conf files. But if those *conf files are missing, you get no entries in the GRUB menu. How do we recreate them? *shrug* Right now that script is in the kernel RPMs, so you'd need to reinstall a kernel to get a new *conf file in place.
Perhaps that could be the basis for a new utility; point it at /dev/sdx and it creates the *conf files in a directory in the boot directory.
So, what is the benefit of doing it this way? You've described what has been lost, but what has been gained? What's the rationale for doing it this way? Is the trade-off worth it?
My first impression is that this is a step backward. But I hardly understand what is going on here.
On Mon, 27 May 2019 15:31:28 -0700 Samuel Sieb samuel@sieb.net wrote:
If you have a GPT formatted disk, why aren't you using UEFI?
You can still do a BIOS install to a GPT formatted drive. You just need to create a BIOS boot partition (not /boot) which is what the installer should be telling you.
I added this disk to a system that was all BIOS, many years ago, and didn't want the hassle of dealing with this new thing UEFI. The fact that my system would be held hostage to a shim from Microsoft didn't sit well with me, either, though that is probably irrational.
On Mon, 27 May 2019 22:06:32 -0600 Chris Murphy lists@colorremedies.com wrote:
Boot from it again and run
# efibootmgr -v
And report the output.
# efibootmgr -v EFI variables are not supported on this system.
On 5/28/19 1:26 PM, stan wrote:
I added this disk to a system that was all BIOS, many years ago, and didn't want the hassle of dealing with this new thing UEFI. The fact that my system would be held hostage to a shim from Microsoft didn't sit well with me, either, though that is probably irrational.
The shim is open-source and not from Microsoft. But it needs to be signed by them. However, most systems let you add your own signing key as well.
On 5/28/19 1:23 PM, stan wrote:
On Tue, 28 May 2019 10:26:10 -0600 Chris Murphy lists@colorremedies.com wrote:
One possible gotcha is the boot volume needs to be big enough. For a few releases it's been 1GiB which probably is big enough for two Fedora's to share, because we don't use kdump by default whereas I guess it's configured on RHEL and that was the impetus behind the boot volume size change.
Does this larger boot volume have to be at the start of the drive. Could I re-purpose a swap partition into a boot volume?
The /boot partition can be anywhere. I generally don't even create a separate partition, it's just included in /. But if you're wanting to share it, it would need to be separate.
So, couldn't there be a utility, which when the user points it at an alternate installation, it creates a link in the boot volume with priority. The way grub(1) used to do with the configfile entry.
You can still do that. Even with BLS I would expect you could add an entry in the static part of the grub.cfg to point to the other installation.
Another gotcha is on UEFI, the older Fedora during software updates will (rarely) need to update the bootloader which will step on the binary files in /boot/efi/EFI/fedora, which isn't the end of the world but it's probably better if the old Fedora /etc/fstab is modified to remove the automount of /boot/efi so that the EFI System partition isn't ever updated except by the new Fedora.
For a single large boot directory for all OSs on the system, couldn't there be a directory for each OS, allowing for both update and a boot selection screen (a menu of available OSs).
Probably, but you would somehow have to convince each OS install to update its own part.
On UEFI the contents of the EFI system partition in EFI/fedora are blown away and replaced. It's been that way since we've had UEFI support as far as I can recall. The nice thing is that on Fedora 30 with BLS support, the grub.cfg on the ESP no longer contains the Fedora menu entries, those are now on the boot volume. So they will be preserved, but again they're ignored out of the box because we don't automatically share boot volumes.
I'm not familiar with the term ESP. From context, some kind of partition? Is the boot volume you refer to where the Fedora menu entries are stored /boot? Or a separate partition?
It's the EFI boot partition where the firmware knows to find the boot loaders. It's not /boot, it's normally mounted at /boot/efi.
On 5/28/19 1:04 PM, stan wrote:
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:
And, if I install as UEFI, for some reason it doesn't accept the existing ext4 partitions on the gpt formatted drive.
What do you mean by it didn't accept them?
That's a separate bug report, also needs installer logs attached.
Same question. Where are they saved?
If the installation is nearly complete, they are probably in /var/log/anaconda on the installed system. Otherwise, they are in /tmp while the installer is running. You can switch to a console to see them or copy them off.
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.
Yes, that does work and I see you have the BIOS boot partition.
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).
So not an EFI boot.
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.
That confused me at first as well until I realized he meant there are two /boot partitions like the two root partitions.
# 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.
The kernel will mount a partition regardless of what it's labelled as, but the installer might not accept it.
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:
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.
https://bugzilla.redhat.com/show_bug.cgi?id=1714828
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.
I think this might have been my error. After reading about UEFI, I see that it needs a separate /boot/efi partition. I have room on the disk at the start before the first /boot partition, but I didn't create that partition during custom configuration. That could have been why it refused to install to the partitions I created as UEFI.
Again, I'm struck by how clumsy this all seems. I must be missing something. People wouldn't have invested all the effort they did in these new methods if they didn't solve some problem.
On Tue, 28 May 2019 13:46:11 -0700 Samuel Sieb samuel@sieb.net wrote:
I'm still exploring BLS and UEFI, so the questions below might be naive.
On 5/28/19 1:23 PM, stan wrote:
On Tue, 28 May 2019 10:26:10 -0600 Chris Murphy lists@colorremedies.com wrote:
One possible gotcha is the boot volume needs to be big enough. For a few releases it's been 1GiB which probably is big enough for two Fedora's to share, because we don't use kdump by default whereas I guess it's configured on RHEL and that was the impetus behind the boot volume size change.
Does this larger boot volume have to be at the start of the drive. Could I re-purpose a swap partition into a boot volume?
The /boot partition can be anywhere. I generally don't even create a separate partition, it's just included in /. But if you're wanting to share it, it would need to be separate.
I just got into the habit when that was the recommended configuration, and haven't changed.
My understanding, after some reading, is that there has to be a separate /boot/efi partition, and that was where the BLS information resided. Except for people using systemd-boot, as described here, https://bugzilla.redhat.com/show_bug.cgi?id=1714007 and here, https://wiki.archlinux.org/index.php/Systemd-boot
So, couldn't there be a utility, which when the user points it at an alternate installation, it creates a link in the boot volume with priority. The way grub(1) used to do with the configfile entry.
You can still do that. Even with BLS I would expect you could add an entry in the static part of the grub.cfg to point to the other installation.
But aren't all these BLS scriptlets in the same partition for Fedora? I thought that under BLS the grub.cfg was just a dummy place holder, and all the heavy lifting was done by the scriptlets.
Another gotcha is on UEFI, the older Fedora during software updates will (rarely) need to update the bootloader which will step on the binary files in /boot/efi/EFI/fedora, which isn't the end of the world but it's probably better if the old Fedora /etc/fstab is modified to remove the automount of /boot/efi so that the EFI System partition isn't ever updated except by the new Fedora.
For a single large boot directory for all OSs on the system, couldn't there be a directory for each OS, allowing for both update and a boot selection screen (a menu of available OSs).
Probably, but you would somehow have to convince each OS install to update its own part.
Wouldn't that just be a symbolic link from the /boot(/efi) partiition to wherever the BLS scriptlets reside?
On UEFI the contents of the EFI system partition in EFI/fedora are blown away and replaced. It's been that way since we've had UEFI support as far as I can recall. The nice thing is that on Fedora 30 with BLS support, the grub.cfg on the ESP no longer contains the Fedora menu entries, those are now on the boot volume. So they will be preserved, but again they're ignored out of the box because we don't automatically share boot volumes.
I'm not familiar with the term ESP. From context, some kind of partition? Is the boot volume you refer to where the Fedora menu entries are stored /boot? Or a separate partition?
It's the EFI boot partition where the firmware knows to find the boot loaders. It's not /boot, it's normally mounted at /boot/efi.
And I don't have one. I think this is why my attempt to install as UEFI failed, because I used a custom configuration and didn't create a /boot/efi partition. But isn't the /boot/efi partition where the BLS scriptlets reside?
On Tue, 28 May 2019 13:59:07 -0700 Samuel Sieb samuel@sieb.net wrote:
On 5/28/19 1:04 PM, stan wrote:
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:
And, if I install as UEFI, for some reason it doesn't accept the existing ext4 partitions on the gpt formatted drive.
What do you mean by it didn't accept them?
The installer gives an error message, and they are still marked as incomplete in the hub.
That's a separate bug report, also needs installer logs attached.
Same question. Where are they saved?
If the installation is nearly complete, they are probably in /var/log/anaconda on the installed system. Otherwise, they are in /tmp while the installer is running. You can switch to a console to see them or copy them off.
Weren't there, guess it didn't get far enough.
The kernel will mount a partition regardless of what it's labelled as, but the installer might not accept it.
That's interesting. I suppose if it has incorrect data it will crash, and if it has the correct data the partition label doesn't matter.
On 5/28/19 7:31 PM, stan wrote:
On Tue, 28 May 2019 13:46:11 -0700 Samuel Sieb samuel@sieb.net wrote:
The /boot partition can be anywhere. I generally don't even create a separate partition, it's just included in /. But if you're wanting to share it, it would need to be separate.
I just got into the habit when that was the recommended configuration, and haven't changed.
My understanding, after some reading, is that there has to be a separate /boot/efi partition, and that was where the BLS information resided. Except for people using systemd-boot, as described here, https://bugzilla.redhat.com/show_bug.cgi?id=1714007 and here, https://wiki.archlinux.org/index.php/Systemd-boot
The /boot/efi partition is a FAT-formatted partition that is specially marked for the firmware to find. It is possible for the grub configs to be there, but Fedora doesn't put them there. That's how it has been until now. I don't know for sure where the BLS files go.
So, couldn't there be a utility, which when the user points it at an alternate installation, it creates a link in the boot volume with priority. The way grub(1) used to do with the configfile entry.
You can still do that. Even with BLS I would expect you could add an entry in the static part of the grub.cfg to point to the other installation.
But aren't all these BLS scriptlets in the same partition for Fedora? I thought that under BLS the grub.cfg was just a dummy place holder, and all the heavy lifting was done by the scriptlets.
The BLS files are probably in the /boot partition, same as the grub.cfg now. My understanding is that the grub.cfg file is still the initial file loaded and it points to where the BLS files are. (I really need to install a system to see how this really works.) You can still add your own entries to the grub.cfg to do other things. Or you could probably make a BLS file to point to the other OS grub.cfg.
For a single large boot directory for all OSs on the system, couldn't there be a directory for each OS, allowing for both update and a boot selection screen (a menu of available OSs).
Probably, but you would somehow have to convince each OS install to update its own part.
Wouldn't that just be a symbolic link from the /boot(/efi) partiition to wherever the BLS scriptlets reside?
If both installs are using BLS, then you could add something to the main grub.cfg to point to the other set of BLS files as well. In the end, you either have to have separate EFI boot entries for the installs or one of the installs has to have the master config.
I'm not familiar with the term ESP. From context, some kind of partition? Is the boot volume you refer to where the Fedora menu entries are stored /boot? Or a separate partition?
It's the EFI boot partition where the firmware knows to find the boot loaders. It's not /boot, it's normally mounted at /boot/efi.
And I don't have one. I think this is why my attempt to install as UEFI failed, because I used a custom configuration and didn't create a /boot/efi partition. But isn't the /boot/efi partition where the BLS scriptlets reside?
A UEFI install without the ESP will definitely fail, since there will be no place to put the bootloader.
On 5/28/19 7:36 PM, stan wrote:
On Tue, 28 May 2019 13:59:07 -0700 Samuel Sieb samuel@sieb.net wrote:
On 5/28/19 1:04 PM, stan wrote:
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:
And, if I install as UEFI, for some reason it doesn't accept the existing ext4 partitions on the gpt formatted drive.
What do you mean by it didn't accept them?
The installer gives an error message, and they are still marked as incomplete in the hub.
We would need the error message, but from what you mentioned in the other email, it's likely the lack of an EFI boot partition (ESP).
That's a separate bug report, also needs installer logs attached.
Same question. Where are they saved?
If the installation is nearly complete, they are probably in /var/log/anaconda on the installed system. Otherwise, they are in /tmp while the installer is running. You can switch to a console to see them or copy them off.
Weren't there, guess it didn't get far enough.
If it hasn't even set up the partitions then the logs will definitely not be on the hard drive.
The kernel will mount a partition regardless of what it's labelled as, but the installer might not accept it.
That's interesting. I suppose if it has incorrect data it will crash, and if it has the correct data the partition label doesn't matter.
Unless specifically told what to use, the kernel will auto-detect the filesystem. In any case, it doesn't use the partition type to determine what filesystem to choose.
On 5/28/19 10:28 PM, Samuel Sieb wrote:
The /boot/efi partition is a FAT-formatted partition that is specially marked for the firmware to find. It is possible for the grub configs to be there, but Fedora doesn't put them there. That's how it has been until now. I don't know for sure where the BLS files go.
Yes it does. On a UEFI system, grub.cfg lives in /boot/efi/EFI/fedora/.
BLS files go in /boot/loader/entries/.
(I can't figure out how grub figures out where /boot/loader/entries is.)
On 5/29/19 8:15 AM, Ian Pilcher wrote:
On 5/28/19 10:28 PM, Samuel Sieb wrote:
The /boot/efi partition is a FAT-formatted partition that is specially marked for the firmware to find. It is possible for the grub configs to be there, but Fedora doesn't put them there. That's how it has been until now. I don't know for sure where the BLS files go.
Yes it does. On a UEFI system, grub.cfg lives in /boot/efi/EFI/fedora/.
You're right, and I did know that. No idea why I said otherwise. It's the kernel and initrd files that don't go there. That's why I mentioned earlier about each installation needing its own directory.
On Tue, 28 May 2019 20:28:16 -0700 Samuel Sieb samuel@sieb.net wrote:
(I really need to install a system to see how this really works.)
Yeah, I decided that I wanted to install this as UEFI with BLS to see how everything works together. Reading just isn't the same.
If both installs are using BLS, then you could add something to the main grub.cfg to point to the other set of BLS files as well. In the end, you either have to have separate EFI boot entries for the installs or one of the installs has to have the master config.
Exactly.
A UEFI install without the ESP will definitely fail, since there will be no place to put the bootloader.
So, I decided to go for the UEFI install after creating an EFI system partition on the drive.
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 8 6144 2097151 1021.0 MiB EF00 EFI System Partition
And now, no matter what I do in the firmware options, just to be perverse, the CD *will not* boot in UEFI mode. I even tried getting rid of the mbr record during install, but it just told me that it is required for an mbr system, even when I include the /boot/efi partition as part of the install. And then, it continues to loop forever when trying to install the boot record as mbr.
I give up for the time being. It's strange there isn't a switch that I can set to explicitly tell it to install as UEFI.
On 5/29/19 11:52 AM, stan wrote:
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 8 6144 2097151 1021.0 MiB EF00 EFI System
Partition
Please use the fdisk output instead. Partition type names are much more useful than numbers.
And now, no matter what I do in the firmware options, just to be perverse, the CD *will not* boot in UEFI mode. I even tried getting
What happens if you set the firmware to only boot UEFI, no legacy or CSM? Or try using a USB flash drive instead.
rid of the mbr record during install, but it just told me that it is required for an mbr system, even when I include the /boot/efi partition as part of the install. And then, it continues to loop forever when trying to install the boot record as mbr.
How do you get rid of the MBR? Are you referring to the BIOS boot partition? The MBR is the first sector on the hard drive.
I give up for the time being. It's strange there isn't a switch that I can set to explicitly tell it to install as UEFI.
The installer can only go with the mode it was booted in. For one thing, if you aren't in UEFI mode, there is no way to configure the boot loader entry.
On Wed, 29 May 2019 12:12:12 -0700 Samuel Sieb samuel@sieb.net wrote:
Please use the fdisk output instead. Partition type names are much more useful than numbers.
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 /dev/sda8 6144 2097151 2091008 1021M EFI System
What happens if you set the firmware to only boot UEFI, no legacy or CSM? Or try using a USB flash drive instead.
It helpfully resets it to allow CSM when it boots. :-)
How do you get rid of the MBR? Are you referring to the BIOS boot partition? The MBR is the first sector on the hard drive.
Reformat it as something like ext4. I suppose vfat would be better.
The installer can only go with the mode it was booted in. For one thing, if you aren't in UEFI mode, there is no way to configure the boot loader entry.
That explains it. I can try a USB, but it booted UEFI constantly before, so it can, it just isn't. And the setting options for USB are the same as those for CD. I'm going to ponder the situation for a while.
On Tue, May 28, 2019 at 2:46 PM Samuel Sieb samuel@sieb.net wrote:
The /boot partition can be anywhere. I generally don't even create a separate partition, it's just included in /. But if you're wanting to share it, it would need to be separate.
Or mount Fedora n-1 root (somewhere in /run ?) and then bind mount its boot directory to /boot. Frankenfstab? I mean, yeah, you want a separate boot volume if you want grub to have a big picture view of multiple Fedoras; or for that matter any other distro that conforms to bootloaderspec. The reality is the interoperability of bootloaderspec has problems. Similar to GRUB upstream, Fedora's 200+ patches rather makes it like a Fedora specific fork; whereas the bootloaderspec is not exactly implemented by Fedora either. Arguably Fedora's implementation is a superset of the original, because kernel packages detect the use of sd-boot somehow, and will write the bls *conf files to the EFI system volume, which is where sd-boot expects them. Whereas our GRUB blscfg.mod (not upstreamed) will see them most anywhere, I think, which is actually mainly a GRUB feature because it can read files across multiple physical devices. sd-boot does not, and bootloaderspec follows that lineage, where the kernel+initramfs+bootloader *conf files, all exist on the same volume with no way to reference any other volume.
So, couldn't there be a utility, which when the user points it at an alternate installation, it creates a link in the boot volume with priority. The way grub(1) used to do with the configfile entry.
You can still do that. Even with BLS I would expect you could add an entry in the static part of the grub.cfg to point to the other installation.
Yes, you can do that in grub.cfg - strictly speaking it should be done with either 40_custom or 41_custom so that if you did regenerate grub.cfg with grub-mkconfig, you'd still get your 'configfile' forwarder in the new grub.cfg instead of stepping on it.
Another gotcha is on UEFI, the older Fedora during software updates will (rarely) need to update the bootloader which will step on the binary files in /boot/efi/EFI/fedora, which isn't the end of the world but it's probably better if the old Fedora /etc/fstab is modified to remove the automount of /boot/efi so that the EFI System partition isn't ever updated except by the new Fedora.
For a single large boot directory for all OSs on the system, couldn't there be a directory for each OS, allowing for both update and a boot selection screen (a menu of available OSs).
Probably, but you would somehow have to convince each OS install to update its own part.
The EFI system partition location EFI/fedora where we put bootloaders and grub.cfg is basically hardwired. There isn't a way to rename it, e.g. EFI/fedora30 and EFI/fedora31 and keep all the bootloader stuff separate. At least not that I'm aware of - I mean, anything is possible, how invasive that is I have no idea.
The advantage of Fedora's variant of bootloader spec is regardless of UEFI or BIOS, the bootloader menu entries are in the same place: /boot/loader/entries which is on the boot volume mounted at /boot. If you do custom installation on UEFI and BIOS to use a directory instead of separate boot, it's still /boot/loader/entries which happens to be on the root volume mounted at / - so it's the same, BIOS or UEFI.
This kinda gets us away from the confusion of UEFI's grub.cfg being in a different place than on BIOS (which is still true with BLS feature, but grub.cfg is now a static file that we don't really care about anymore in the typical case; so most conversations about menu entries and boot parameters don't need to be firmware specific until you get suspicious the problem relates to it.
On Tue, May 28, 2019 at 8:32 PM stan upaitag@zoho.com wrote:
On Tue, 28 May 2019 13:46:11 -0700 Samuel Sieb samuel@sieb.net wrote:
I'm still exploring BLS and UEFI, so the questions below might be naive.
It is confusing because there's an upstream bootloaderspec that originated along with gummiboot bootloader which became systemd-boot (or sd-boot). The variants are sd-boot, rpm-ostree, and Fedora's GRUB blscfg.mod and kernel install plugins.
Each of these is doing something a little different.
sd-boot expects kernel+initramfs+bls *conf files to all be on the EFI system partition. It is a UEFI bootloader only. And it expects to mount the EFI system partition to either /boot or /efi
My understanding, after some reading, is that there has to be a separate /boot/efi partition, and that was where the BLS information resided.
Out of the box on Fedora 30, whether UEFI or BIOS, the bootloaderspec *conf files (the menu entry drop in scripts) are found in /boot/loader/entries which is a directory on the boot volume mounted at /boot
You can optionally not create a /boot mountpoint using custom partitioning, and in that case /boot/loader/entries is a directory on the root volume mounted at /
Fedora's GRUB, which includes the blscfg.mod (a GRUB module that parses bootloaderspec *conf files) will find them in either location, regardless of firmware type.
So, unlike the upstream bootloaderspec, BLS *conf files are not on the EFI system partition. Pretty much the EFI system partition on Fedora isn't going to be a changing thing anymore. It'll occasionally get some EFI OSLoader (the actual bootloader binaries) updates, and I think fwupd stages firmware updates there for some things (?) that's about it.
But aren't all these BLS scriptlets in the same partition for Fedora? I thought that under BLS the grub.cfg was just a dummy place holder, and all the heavy lifting was done by the scriptlets.
Depends on your point of view. The grub.cfg speaks GRUB language, and the BLS *conf files are a much simpler restricted set of commands. So most of the GRUB environment setup is still done by grub.cfg, but it's also non-changing. What changes everytime there's a kernel update is the menu entry. That's now in a *conf file, one per kernel.
It does very much have the potential to seem like a Choose Your Own Adventure book, because each thing keeps pointing to something else.
GRUB pre-boot environment binary -> grub.cfg -> grubenv & blscfg.mod -> /boot/loader/entries/*conf -> /boot/
So the grub.cfg reads grubenv to know things like default kernel, whether last boot succeeded and if so to hide the GRUB menu and if not to show the GRUB menu, and boot parameters. Then grub.cfg executes the blscfg module which in turn reads and parses the BLS snippets.
Probably, but you would somehow have to convince each OS install to update its own part.
Wouldn't that just be a symbolic link from the /boot(/efi) partiition to wherever the BLS scriptlets reside?
No symlinks on FAT.
As complicated as it seems, the way forward for two or more Fedora's is a separate boot volume that's shared among them. And remove the automount of the EFI system partition on the older distro versions. GRUB + blscfg.mod will see /boot/loader/entries contains a bunch of *conf files, one per each distro specific kernel installed.
OK I just realized a problem. There is only one grubenv and it will define the root file system as a variable that all of the *conf files will pick up and set as a boot parameter.
Option 1: It is possible to change 'options $kernelopts ' by removing $kernelopts and explicitly list the boot parameters you want including a different root. Option 2: It is possible to have two, maybe three, different variables for kernel options in the grubenv, each with a different root; and then just edit the older *conf files to use the proper variable, .e.g. $kernelopts30 or $kernelopts31 Option 3: It is possible to have more than one 'options' key in each *conf file and they are combined
So an fc30 conf file: ... options $kernelopts options root=/dev/mapper/fedora-root30
And fc31 conf file ... options $kernelopts options root=/dev/mapper/fedora-root31
That would cause both fc30 and fc31 to boot with the same kernel options in common except for the root which is explicitly set in the *conf file. I haven't tested how the *conf files are created however; I don't know if they are copied, which would preserve the custom defined root, appropriate for that distro version. So this needs testing and a write up if it works.
And I don't have one. I think this is why my attempt to install as UEFI failed, because I used a custom configuration and didn't create a /boot/efi partition. But isn't the /boot/efi partition where the BLS scriptlets reside?
The installer has a rather explicit bootloader related error message if a /boot/efi mount point is not defined on a computer with UEFI firmware presented. A common test@ axiom is: don't tell us it didn't work or that it failed. Tell us exactly in detail what did happen. i.e. a screenshot or cell photo of the point of failure, and likely also logs.
-- Chris Murphy
On Tue, May 28, 2019 at 9:28 PM Samuel Sieb samuel@sieb.net wrote:
The /boot/efi partition is a FAT-formatted partition that is specially marked for the firmware to find. It is possible for the grub configs to be there, but Fedora doesn't put them there. That's how it has been until now. I don't know for sure where the BLS files go.
Fedora does put the grub.cfg on the EFI system partition at /boot/efi/EFI/fedora/grub.cfg - which is not how upstream does it. Upstream GRUB expects grub-install creates an EFI OSLoader binary that points to where GRUB stores its files which is /boot/grub (upstream doesn't tack on a '2' to everything, that's a Red Hat / Fedora convention). And hence much confusion ensued on Fedora, where to point grub2-mkconfig -o
There are two symlinks on all Fedora installations: lrwxrwxrwx. 1 root root 22 May 20 11:14 grub2.cfg -> ../boot/grub2/grub.cfg lrwxrwxrwx. 1 root root 31 May 20 11:14 grub2-efi.cfg -> ../boot/efi/EFI/fedora/grub.cfg
Blek. I don't like it. But that's the way it is.
BLS files always go in /boot/loader/entries on Fedora - that is from the fully assembled file system and user space perspective. The original bootloaderspec just says $BOOT/loader/entries where $BOOT is the EFI system partition, but Fedora doesn't do that out of the box. You can retrofit it after installation to do it the systemd-boot way, and kernel-install supports it (I'm not sure if it only supports /boot as the mount point for the EFI system partition or also /efi)
The BLS files are probably in the /boot partition, same as the grub.cfg now. My understanding is that the grub.cfg file is still the initial file loaded and it points to where the BLS files are. (I really need to install a system to see how this really works.) You can still add your own entries to the grub.cfg to do other things. Or you could probably make a BLS file to point to the other OS grub.cfg.
BLS files have limited keys, unlike grub.cfg's many commands available - BLS format is similar to the GRUB Legacy *conf file format, except no such concept of physical devices or volumes. All paths in the conf file is relative to the volume the conf file is on.
If both installs are using BLS, then you could add something to the main grub.cfg to point to the other set of BLS files as well. In the end, you either have to have separate EFI boot entries for the installs or one of the installs has to have the master config.
Another thing I just thought of: everytime a new kernel is installed it writes to grubenv the saved_entry variable, setting the most recently installed kernel title. That's now the default boot.
I'm not really sure of a good work around for that, other than manual intervention. In particular you'd want to disable the hidden grub menu variable in grubenv, so that you have a chance of seeing and changing what will boot.
On Wed, 29 May 2019 21:41:13 -0600 Chris Murphy lists@colorremedies.com wrote:
Thanks for the detailed response. That's complicated, and I've saved it for future reference; I'll need to let it settle for a while before reading it again.
No symlinks on FAT.
As complicated as it seems, the way forward for two or more Fedora's is a separate boot volume that's shared among them. And remove the automount of the EFI system partition on the older distro versions. GRUB + blscfg.mod will see /boot/loader/entries contains a bunch of *conf files, one per each distro specific kernel installed.
OK I just realized a problem. There is only one grubenv and it will define the root file system as a variable that all of the *conf files will pick up and set as a boot parameter.
Option 1: It is possible to change 'options $kernelopts ' by removing $kernelopts and explicitly list the boot parameters you want including a different root. Option 2: It is possible to have two, maybe three, different variables for kernel options in the grubenv, each with a different root; and then just edit the older *conf files to use the proper variable, .e.g. $kernelopts30 or $kernelopts31 Option 3: It is possible to have more than one 'options' key in each *conf file and they are combined
So an fc30 conf file: ... options $kernelopts options root=/dev/mapper/fedora-root30
And fc31 conf file ... options $kernelopts options root=/dev/mapper/fedora-root31
That would cause both fc30 and fc31 to boot with the same kernel options in common except for the root which is explicitly set in the *conf file. I haven't tested how the *conf files are created however; I don't know if they are copied, which would preserve the custom defined root, appropriate for that distro version. So this needs testing and a write up if it works.
Would a simple alternative be to install the UEFI Fedora versions on different disks? Each would have their own /boot/efi so they wouldn't step on each other. And just selecting a different disk to boot would select the different version of Fedora on that disk. No solution to the general problem, but an easy implementation if there is more than one disk.
The installer has a rather explicit bootloader related error message if a /boot/efi mount point is not defined on a computer with UEFI firmware presented. A common test@ axiom is: don't tell us it didn't work or that it failed. Tell us exactly in detail what did happen. i.e. a screenshot or cell photo of the point of failure, and likely also logs.
I deleted the mbr partition with gdisk, and retyped all the existing linux partitions to linux filesystem (8300), and the install then succeeded, and seems to be UEFI, though it failed to boot, which I am still investigating. There are BLS entries in /boot/loader/entries.
# fdisk -l /dev/sda
Device Start End Sectors Size Type /dev/sda1 2097152 4194303 2097152 1G Linux filesystem /dev/sda2 4194304 6291455 2097152 1G Linux filesystem /dev/sda3 6291456 48234495 41943040 20G Linux swap /dev/sda4 48234496 572522495 524288000 250G Linux filesystem /dev/sda5 572522496 1096810495 524288000 250G Linux filesystem /dev/sda6 1096810496 5860532223 4763721728 2.2T Linux filesystem /dev/sda8 6144 2097151 2091008 1021M EFI System
On Wed, 29 May 2019 12:12:12 -0700 Samuel Sieb samuel@sieb.net wrote:
Progress report:
I deleted the mbr using gdisk, and put the proper type on the existing linux partitions, and the install succeeded. I think it was failing to install because the installer was confused by the labels on the existing linux partitions not being linux, rather than the mbr. There are entries in the /boot/loader/entries directory, so it is BLS. It failed to boot, though, and I am still investigating that. Looks like this now:
Device Start End Sectors Size Type /dev/sda1 2097152 4194303 2097152 1G Linux filesystem /dev/sda2 4194304 6291455 2097152 1G Linux filesystem /dev/sda3 6291456 48234495 41943040 20G Linux swap /dev/sda4 48234496 572522495 524288000 250G Linux filesystem /dev/sda5 572522496 1096810495 524288000 250G Linux filesystem /dev/sda6 1096810496 5860532223 4763721728 2.2T Linux filesystem /dev/sda8 6144 2097151 2091008 1021M EFI System
The installer can only go with the mode it was booted in. For one thing, if you aren't in UEFI mode, there is no way to configure the boot loader entry.
Maybe this is why it isn't booting, because it didn't declare itself in UEFI mode during install. Something for me to look into. Do you know how to examine the /boot/efi partition? Mount keeps telling me that I am trying to mount it incorrectly, mount -t vfat /dev/sda8 /mnt/to_efi dr-xr-xr-x. 2 0 0 system_u:object_r:mnt_t:s0 4096 May 30 09:33 /mnt/to_efi Is there a special type for /boot/efi even though it is vfat?
On Thu, 30 May 2019 09:38:12 -0700 stan upaitag@zoho.com wrote:
On Wed, 29 May 2019 12:12:12 -0700 Samuel Sieb samuel@sieb.net wrote:
Progress report:
I deleted the mbr using gdisk, and put the proper type on the existing linux partitions, and the install succeeded. I think it was failing to install because the installer was confused by the labels on the existing linux partitions not being linux, rather than the mbr. There are entries in the /boot/loader/entries directory, so it is BLS. It failed to boot, though, and I am still investigating that. Looks like this now:
Device Start End Sectors Size Type /dev/sda1 2097152 4194303 2097152 1G Linux filesystem /dev/sda2 4194304 6291455 2097152 1G Linux filesystem /dev/sda3 6291456 48234495 41943040 20G Linux swap /dev/sda4 48234496 572522495 524288000 250G Linux filesystem /dev/sda5 572522496 1096810495 524288000 250G Linux filesystem /dev/sda6 1096810496 5860532223 4763721728 2.2T Linux filesystem /dev/sda8 6144 2097151 2091008 1021M EFI System
The installer can only go with the mode it was booted in. For one thing, if you aren't in UEFI mode, there is no way to configure the boot loader entry.
Maybe this is why it isn't booting, because it didn't declare itself in UEFI mode during install. Something for me to look into. Do you know how to examine the /boot/efi partition? Mount keeps telling me that I am trying to mount it incorrectly, mount -t vfat /dev/sda8 /mnt/to_efi dr-xr-xr-x. 2 0 0 system_u:object_r:mnt_t:s0 4096 May 30 09:33 /mnt/to_efi Is there a special type for /boot/efi even though it is vfat?
# mount -t vfat /dev/sda8 /mnt/to_efi mount: /mnt/to_efi: wrong fs type, bad option, bad superblock on /dev/sda8, missing codepage or helper program, or other error.
On Wed, May 29, 2019 at 12:53 PM stan upaitag@zoho.com wrote:
So, I decided to go for the UEFI install after creating an EFI system partition on the drive.
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 8 6144 2097151 1021.0 MiB EF00 EFI System Partition
That's a useful size for experimenting with systemd-boot, which expects kernels + initramfs and BLS snippets to all go on the EFI system partition. The Fedora installer's default for the EFI system partition is around 200MiB, and the most I've seen Fedora's bootloaders use is ~14MiB.
And now, no matter what I do in the firmware options, just to be perverse, the CD *will not* boot in UEFI mode.
Some firmware only boot CD's with CSM. Other firmware, you must use the built-in boot manager, which shows what firmware type will be presented when booting the CD, i.e. you'll see the CD listed twice. Once with UEFI listed; and also without or possibly with the word "Legacy"
I even tried getting rid of the mbr record during install, but it just told me that it is required for an mbr system, even when I include the /boot/efi partition as part of the install. And then, it continues to loop forever when trying to install the boot record as mbr.
I cannot parse this at all into actual actions in the installer so I don't know what you're doing and can't tell if it's user error or a bug.
What you still seem confused about is the installer itself has no control over whether the system is booted with UEFI or CSM/BIOS being presented. That is a firmware function, and it's selected at boot time. Once selected, the installer honors it and will only do an installation compatible with the current presentation of the firmware.
After you boot installation media you can check what firmware is presented with # efibootmgr
If entries appear, it's UEFI. If an error appears, it's CSM/BIOS. And if it's CSM/BIOS then defining a /boot/efi mount point is invalid. If you want a UEFI installation, it's mandatory that you figure out a way to boot the install media in UEFI mode. Even if it means you have to create a USB stick, and must abandon CD booting.
I give up for the time being. It's strange there isn't a switch that I can set to explicitly tell it to install as UEFI.
I can understand the confusion but it's not strange. It could be a badly designed user interface by the firmware manufacturer. And it's also possible you've found a firmware bug. You should make sure the firmware is on the latest revision available by the manufacturer. Quite a lot of bugs can be worked around by shim and GRUB but quite a lot of bugs can only be fixed by firmware updates.
On Thu, May 30, 2019 at 10:17 AM stan upaitag@zoho.com wrote:
On Wed, 29 May 2019 21:41:13 -0600 Chris Murphy lists@colorremedies.com wrote:
That would cause both fc30 and fc31 to boot with the same kernel options in common except for the root which is explicitly set in the *conf file. I haven't tested how the *conf files are created however; I don't know if they are copied, which would preserve the custom defined root, appropriate for that distro version. So this needs testing and a write up if it works.
Would a simple alternative be to install the UEFI Fedora versions on different disks?
Yes that would work. But to switch between them, you'd need to use the firmware boot manager; or efibootmgr prior to reboot time; or you need to modify both grub.cfg's on each drive's EFI system partition, to include a menu entry using the 'configfile' command to point at the other grub.cfg. That way, no matter which drive the firmware uses by default (as defined in NVRAM using 'efibootmgr' command) you have a GRUB menu entry to point to the other drive.
On Thu, May 30, 2019 at 10:53 AM stan upaitag@zoho.com wrote:
# mount -t vfat /dev/sda8 /mnt/to_efi mount: /mnt/to_efi: wrong fs type, bad option, bad superblock on /dev/sda8, missing codepage or helper program, or other error.
# blkid # dosfsck -avn /dev/sda8
On 5/30/19 9:52 AM, stan wrote:
# mount -t vfat /dev/sda8 /mnt/to_efi mount: /mnt/to_efi: wrong fs type, bad option, bad superblock on /dev/sda8, missing codepage or helper program, or other error.
Check the journal to see if there is any more info. Also, run "file -s /dev/sda8" to see what is there.
On Thu, 30 May 2019 12:04:31 -0600 Chris Murphy lists@colorremedies.com wrote:
On Thu, May 30, 2019 at 10:53 AM stan upaitag@zoho.com wrote:
# mount -t vfat /dev/sda8 /mnt/to_efi mount: /mnt/to_efi: wrong fs type, bad option, bad superblock on /dev/sda8, missing codepage or helper program, or other error.
# blkid # dosfsck -avn /dev/sda8
# dosfsck -avn /dev/sda8 fsck.fat 4.1 (2017-01-24) Checking we can access the last sector of the filesystem Boot sector contents: System ID "mkfs.fat" Media byte 0xf8 (hard disk) 512 bytes per logical sector 4096 bytes per cluster 32 reserved sectors First FAT starts at byte 16384 (sector 32) 2 FATs, 32 bit entries 2088960 bytes per FAT (= 4080 sectors) Root directory start at cluster 2 (arbitrary size) Data area starts at byte 4194304 (sector 8192) 521984 data clusters (2138046464 bytes) 63 sectors/track, 255 heads 10240 hidden sectors 4184064 sectors total Reclaiming unconnected clusters. Checking free cluster summary. /dev/sda8: 15 files, 1992/521984 clusters
# mount -t vfat /dev/sda8 /mnt/to_efi mount: /mnt/to_efi: wrong fs type, bad option, bad superblock on /dev/sda8, missing codepage or helper program, or other error.
# ls -dnZ /mnt/to_efi dr-xr-xr-x. 2 0 0 system_u:object_r:mnt_t:s0 4096 May 30 09:33 /mnt/to_efi
I'm letting this whole F31 install project slide for a while. It isn't making sense to me that it isn't working, and I seem to just be going around in circles.
On Thu, 30 May 2019 11:50:20 -0700 Samuel Sieb samuel@sieb.net wrote:
On 5/30/19 9:52 AM, stan wrote:
# mount -t vfat /dev/sda8 /mnt/to_efi mount: /mnt/to_efi: wrong fs type, bad option, bad superblock on /dev/sda8, missing codepage or helper program, or other error.
Check the journal to see if there is any more info. Also, run "file -s /dev/sda8" to see what is there.
# file -s /dev/sda8 /dev/sda8: DOS/MBR boot sector, code offset 0x58+2, OEM-ID "mkfs.fat", sectors/cluster 8, Media descriptor 0xf8, sectors/track 63, heads 255, hidden sectors 10240, sectors 4184064 (volumes > 32 MB), FAT (32 bit), sectors/FAT 4080, serial number 0x8c3a0e05, label: "efi_system "
From the journal, May 31 09:55:31 localhost.localdomain kernel: FAT-fs (sda8): IO charset iso8859-1 not found
Isn't that a window's charset? It's crazy that I need that to access a partition. But that shouldn't affect the new install's ability to boot, since it must presumably have that charset available to install everything. And it just drops to a grub prompt when I try to boot it.
I'm taking a break from this as I seem to be spinning my wheels.
On Thu, 30 May 2019 11:53:43 -0600 Chris Murphy lists@colorremedies.com wrote:
That's a useful size for experimenting with systemd-boot, which expects kernels + initramfs and BLS snippets to all go on the EFI system partition. The Fedora installer's default for the EFI system partition is around 200MiB, and the most I've seen Fedora's bootloaders use is ~14MiB.
I'm going to look into alternatives since I seem to be having such little success with the default. I'll investigate sd-boot.
Some firmware only boot CD's with CSM. Other firmware, you must use the built-in boot manager, which shows what firmware type will be presented when booting the CD, i.e. you'll see the CD listed twice. Once with UEFI listed; and also without or possibly with the word "Legacy"
Solved this at least. If I edit the boot line, and knock off quiet, I see something close to "EFI stub: Booting UEFI in secure mode", so I know that I'm booting in UEFI now.
After you boot installation media you can check what firmware is presented with # efibootmgr
If entries appear, it's UEFI. If an error appears, it's CSM/BIOS. And if it's CSM/BIOS then defining a /boot/efi mount point is invalid. If you want a UEFI installation, it's mandatory that you figure out a way to boot the install media in UEFI mode. Even if it means you have to create a USB stick, and must abandon CD booting.
This is a handy way to check and confirm. Good for future reference. But, as I mentioned in other posts, on hold for now.
On Fri, May 31, 2019 at 11:12 AM stan upaitag@zoho.com wrote:
On Thu, 30 May 2019 11:50:20 -0700 Samuel Sieb samuel@sieb.net wrote:
On 5/30/19 9:52 AM, stan wrote:
# mount -t vfat /dev/sda8 /mnt/to_efi mount: /mnt/to_efi: wrong fs type, bad option, bad superblock on /dev/sda8, missing codepage or helper program, or other error.
Check the journal to see if there is any more info. Also, run "file -s /dev/sda8" to see what is there.
# file -s /dev/sda8 /dev/sda8: DOS/MBR boot sector, code offset 0x58+2, OEM-ID "mkfs.fat", sectors/cluster 8, Media descriptor 0xf8, sectors/track 63, heads 255, hidden sectors 10240, sectors 4184064 (volumes > 32 MB), FAT (32 bit), sectors/FAT 4080, serial number 0x8c3a0e05, label: "efi_system "
From the journal, May 31 09:55:31 localhost.localdomain kernel: FAT-fs (sda8): IO charset iso8859-1 not found
How did you format this partition? Did anaconda do it? What install media? I have Fedora 31 clean installed in a VM using UEFI and haven't run into this, so I suspect some kind of confusion. Maybe don't use -t vfat flag and just let it auto detect?
Isn't that a window's charset? It's crazy that I need that to access a partition. But that shouldn't affect the new install's ability to boot, since it must presumably have that charset available to install everything. And it just drops to a grub prompt when I try to boot it.
That you get a GRUB prompt suggests the firmware found GRUB. It either can read this FAT format EFI System partition to read EFI GRUB, or found your old BIOS GRUB. You can maybe determine which one from GRUB environment variables with the 'set' command. But yeah this is deep in the weeds.
I'm taking a break from this as I seem to be spinning my wheels.
That is often the case with Rawhide. But you're also dealing with multiple things all the same time. So it's sortof chaos theory at play that as you work through one problem you run into another one. It's a fine line between sticking with it and literally walking away.
On Sat, 25 May 2019 16:08:02 -0700 stan upaitag@zoho.com wrote:
Hi, I pulled the server net install iso for rawhide, the future Fedora 31, and tried to install it. I used custom install with existing partitions on a bios partitioned disk. It refused to install because it wanted gpt and uefi.
I swap back and forth between predefined partitions, so I always have a working Fedora to fall back on. This has worked fine in the past.
Is gpt and uefi now required for install? I didn't see a way to toggle the setting.
In the end, after many machinations, neither MBR or UEFI would install, always hanging at "installing boot partition". As I mentioned, I opened a bugzilla for this, https://bugzilla.redhat.com/show_bug.cgi?id=1714828 which is still unresolved. The latest rawhide version, 20190604, still exhibits this issue.
So, I downloaded the equivalent F30 netinstall image, and it installed a minimal UEFI install flawlessly. It boots fine, so I could stop here, and just turn on the rawhide repositories to get to F31, but I think I'll keep trying candidates from rawhide, at least for a while.
-
Adam Williamson -
Chris Murphy -
Ian Pilcher -
Richard Ryniker -
Samuel Sieb -
stan