Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?
On 4/15/22 04:01, Jóhann B. Guðmundsson wrote: On 14.4.2022 23:25, Nikolay Nikolov wrote: On 4/15/22 01:53, Jóhann B. Guðmundsson wrote: On 14.4.2022 22:24, Nikolay Nikolov wrote: On 4/14/22 23:49, Jóhann B. Guðmundsson wrote: On 14.4.2022 18:20, Chris Adams wrote: Once upon a time, Robbie Harwood said: Given there is consensus that legacy BIOS is on its way out I don't think this statement is true, unless Fedora doesn't want to be considered for a bunch of popular VM hosts (e.g. Linode and such) that have no stated plans to support UEFI. Maybe "legacy BIOS on physical hardware" is on its way out It's not an maybe, it is on it's way out either physically or simply via firmware update [1] "In the bios, upgraded to 810 the option to enable legacy boot is greyed out" So how do people propose the situation to be handled when firmware from vendors, disables the legacy boot option via firmware update. Is Fedora supposed to block/blacklist those firmware updates via some plugin in lvfs based on user feedback when their legacy boot mode suddenly stops working or is it expected that upstream lvfs team looks into this or what? Fedora doesn't install these updates. Users install these updates, when they have a problem In the past they did, today users ( including the novice ones ) update it as Gnome notifies them about available update just like they do when they receive anyother software update notification. Really? I didn't know that. At least on my computers, Gnome has never notified me about a BIOS update from my motherboard vendor. Besides, it's proprietary software, so I wouldn't expect Fedora to be offering it by default. Doesn't it need adding an extra software repository? It's fwup/lvfs [1] and nope you dont need to jump through any additional hoops for that, it just work ( or it does not if the vendor is not part of lfvs ). Oh, wow! Yeah, my new desktop has an ASRock motherboard and my laptop is an HP and, and while both vendors (HP and Asus) participate in lvfs, they don't seem to upload a lot of firmware updates (HP has uploaded 34 firmware files, for comparison Dell has uploaded 2033 firmware files). But I'm still surprised that Fedora by default downloads and updates proprietary firmware, downloaded from the Internet. Btw, does this work in legacy boot mode as well? If I recall correctly, someone in the 2020 thread mentioned that fwupd requires boot in UEFI mode, but I don't remember the exact details. And besides, non-UEFI systems don't normally receive BIOS updates that break legacy boot, because legacy boot is the only boot option available, so what is your point, exactly? Obviously this was for dual bios mode ( legacy and uefi ) ( otherwise the option to disable it would not be there ) in which the vendor himself seemingly decided to disable the legacy part of the bios via firmware update which highlight the fact that we somehow need to deal with that situation if we want to continue to support the legacy bios option. How I have no clue, which is why I pointed at an potential lvfs plugin or the lvfs team. I think we should check the BIOS date in the installer and deprecate (as in, print warnings to the user in the installer) legacy boot on newer systems (e.g. newer than 2017 or some other cutoff date, when we decide that UEFI becomes more stable), an by deprecate, I mean, show warnings to the user and suggest that they continue on their own risk. Of course, we should also check for virtual machines, like e.g. QEMU/SeaBIOS, that are known to be stable in legacy BIOS mode and not show the warning in them, even if the BIOS date is new (although SeaBIOS seems to use an old date - 06/23/99). That's something that needs to be worked out with the Anaconda team but I think Javier already provide the best path forward with regards to Anaconda when I started the dialog two years ago but for whatever reason that's not part of Robbie's proposal. What was Javier's proposal? Best regards, Nikolay JBG 1. https://fwupd.org/ ___ devel mailing list --devel@lists.fedoraproject.org To unsubscribe send an email todevel-le...@lists.fedoraproject.org Fedora Code of Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it:https://pagure.io/fedora-infrastructure___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org
Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?
On 4/15/22 01:53, Jóhann B. Guðmundsson wrote: On 14.4.2022 22:24, Nikolay Nikolov wrote: On 4/14/22 23:49, Jóhann B. Guðmundsson wrote: On 14.4.2022 18:20, Chris Adams wrote: Once upon a time, Robbie Harwood said: Given there is consensus that legacy BIOS is on its way out I don't think this statement is true, unless Fedora doesn't want to be considered for a bunch of popular VM hosts (e.g. Linode and such) that have no stated plans to support UEFI. Maybe "legacy BIOS on physical hardware" is on its way out It's not an maybe, it is on it's way out either physically or simply via firmware update [1] "In the bios, upgraded to 810 the option to enable legacy boot is greyed out" So how do people propose the situation to be handled when firmware from vendors, disables the legacy boot option via firmware update. Is Fedora supposed to block/blacklist those firmware updates via some plugin in lvfs based on user feedback when their legacy boot mode suddenly stops working or is it expected that upstream lvfs team looks into this or what? Fedora doesn't install these updates. Users install these updates, when they have a problem In the past they did, today users ( including the novice ones ) update it as Gnome notifies them about available update just like they do when they receive anyother software update notification. Really? I didn't know that. At least on my computers, Gnome has never notified me about a BIOS update from my motherboard vendor. Besides, it's proprietary software, so I wouldn't expect Fedora to be offering it by default. Doesn't it need adding an extra software repository? And besides, non-UEFI systems don't normally receive BIOS updates that break legacy boot, because legacy boot is the only boot option available, so what is your point, exactly? Obviously this was for dual bios mode ( legacy and uefi ) ( otherwise the option to disable it would not be there ) in which the vendor himself seemingly decided to disable the legacy part of the bios via firmware update which highlight the fact that we somehow need to deal with that situation if we want to continue to support the legacy bios option. How I have no clue, which is why I pointed at an potential lvfs plugin or the lvfs team. I think we should check the BIOS date in the installer and deprecate (as in, print warnings to the user in the installer) legacy boot on newer systems (e.g. newer than 2017 or some other cutoff date, when we decide that UEFI becomes more stable), an by deprecate, I mean, show warnings to the user and suggest that they continue on their own risk. Of course, we should also check for virtual machines, like e.g. QEMU/SeaBIOS, that are known to be stable in legacy BIOS mode and not show the warning in them, even if the BIOS date is new (although SeaBIOS seems to use an old date - 06/23/99). Nikolay JBG ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?
On 4/14/22 23:49, Jóhann B. Guðmundsson wrote: On 14.4.2022 18:20, Chris Adams wrote: Once upon a time, Robbie Harwood said: Given there is consensus that legacy BIOS is on its way out I don't think this statement is true, unless Fedora doesn't want to be considered for a bunch of popular VM hosts (e.g. Linode and such) that have no stated plans to support UEFI. Maybe "legacy BIOS on physical hardware" is on its way out It's not an maybe, it is on it's way out either physically or simply via firmware update [1] "In the bios, upgraded to 810 the option to enable legacy boot is greyed out" So how do people propose the situation to be handled when firmware from vendors, disables the legacy boot option via firmware update. Is Fedora supposed to block/blacklist those firmware updates via some plugin in lvfs based on user feedback when their legacy boot mode suddenly stops working or is it expected that upstream lvfs team looks into this or what? Fedora doesn't install these updates. Users install these updates, when they have a problem, which they need to resolve. Most people never update their BIOS [1], because their system is working just fine. Only power users do, and they know how to read changelogs and how to backup their previous working BIOS. So, no, it's not Fedora's problem if a users installs a BIOS update that bricks their system, or renders it unbootable (for whatever reasons, doesn't matter whether they're related to legacy boot or not). We have no obligation to prevent that. The right approach to BIOS update is "don't do it, unless you have to". If it ain't broke, don't fix it. I've been burned so many times, due to buggy BIOS updates, most of them unrelated to legacy boot. We don't prevent BIOS updates that break UEFI or secure boot, or which brick the system, so why should we prevent BIOS updates that break legacy boot? And besides, non-UEFI systems don't normally receive BIOS updates that break legacy boot, because legacy boot is the only boot option available, so what is your point, exactly? If you want to deprecate legacy boot on new installs on UEFI-capable BIOS-es, that's another story. E.g. if the installer detects that the BIOS is modern (e.g. later than 2017-2018) and UEFI capable, but is running in legacy boot mode, it could prints a warning and suggest to the user to restart and turn off legacy boot from the BIOS setup. The installer promises better hardware support, firmware updates and happier times to the user if the operating system is installed in UEFI mode. Finally user decides whether to do that, or choose to continue on their own risk. That is totally reasonable, IMHO. But it is a completely different thing than dropping legacy BIOS support completely. 1. It is indeed still universally called BIOS, even though it's UEFI: https://www.asrock.com/support/BIOSIG.asp?cat=BIOS10 Best regards, Nikolay JBG 1. https://forum-en.msi.com/index.php?threads/msi-pro-dp20z-5m-legacy-boot-how-to-enable-legacy-boot.374479/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
On 4/10/22 16:27, Neal Gompa wrote: On Sat, Apr 9, 2022 at 10:51 PM Gary Buhrmaster wrote: On Wed, Apr 6, 2022 at 6:01 PM Neal Gompa wrote: Moving past the Big Three(tm), the actual cloud providers that matter from a Fedora context are the smaller outfits that principally serve Linux users. These are companies like DigitalOcean, Linode (Akamai), Hetzner, VexxHost, and others who graciously do offer Fedora Linux in their platforms. All of their virtualization platforms are BIOS only right now, and getting them to switch requires them to uplift their platforms to support UEFI in the first place. They may only support Linux users today, but if they want to grow (and while it is possible to survive as a niche service, many see growth as the way to increased revenue/profits (go big or go home)), they are going to get pushed (perhaps kicking and screaming) to support UEFI as at least an alternative moving forward as some of their customers are going to prefer using a single provider, and Windows 11 requires UEFI(*)(**), and it would be a shame if only the big players were eligible for hosting such services(***). Many of these comments seem to be about the date, not the end state (UEFI)(), just like 32-bit x86 and armv7. No one wants their personal ox gored, but there will come a time when it will be time to let old systems go. "We" (and when I say "we", I understand that is mostly not me), are going to have to continue to document (and fix, where "we" have the knowledge) the areas that need improvement for UEFI booting and runtime. Windows is a niche in the server space, rather than the default. And Microsoft didn't even remove the server exception to continue using BIOS until last year from the Windows platform qualification documentation. It's *definitely* going to be a while, especially with Windows Server 2019 being supported until the end of the decade. Just tested installing Windows Server 2019 in a QEMU virtual machine on a 40 GB virtual hard disk and 2 GB RAM. It formatted the disk as MBR and installed just fine, no warnings, no deprecations, no nothing. Mainstream support for Windows Server 2019 ends in January 9, 2024, extended support lasts until January 9, 2029. Windows 11 *does not matter* here. Windows Server is what matters here, and there are no announced Windows Server versions following the Windows 11 platform requirements. I agree. IMO, Windows 11 is only good for home desktop use (and for that purpose, Windows 10 is just as good, there are only cosmetic differences in the UI), it is irrelevant for servers, because of the artificial restrictions that Microsoft puts on their desktop operating systems (limited number of connections, limited number of websites you can host in IIS, etc.) in order to boost their Windows Server sales. Ironically, due to this fact, Windows Server works better as a desktop, than Windows 10 or 11 as a server. At work we use Windows Server for web development in Visual Studio, because it just works better, e.g. you can deploy multiple web sites on your machine, etc. :) -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
On 4/10/22 05:50, Gary Buhrmaster wrote: On Wed, Apr 6, 2022 at 6:01 PM Neal Gompa wrote: Moving past the Big Three(tm), the actual cloud providers that matter from a Fedora context are the smaller outfits that principally serve Linux users. These are companies like DigitalOcean, Linode (Akamai), Hetzner, VexxHost, and others who graciously do offer Fedora Linux in their platforms. All of their virtualization platforms are BIOS only right now, and getting them to switch requires them to uplift their platforms to support UEFI in the first place. They may only support Linux users today, but if they want to grow (and while it is possible to survive as a niche service, many see growth as the way to increased revenue/profits (go big or go home)), they are going to get pushed (perhaps kicking and screaming) to support UEFI as at least an alternative moving forward as some of their customers are going to prefer using a single provider, and Windows 11 requires UEFI(*)(**), and it would be a shame if only the big players were eligible for hosting such services(***). Many of these comments seem to be about the date, not the end state (UEFI)(), just like 32-bit x86 and armv7. No one wants their personal ox gored, but there will come a time when it will be time to let old systems go. Yes, but the whole point is that it's way too early. Windows 10 still supports not only legacy BIOS, but also i686 (which Fedora has dropped support for in Fedora 31; Fedora 30 was EOL'd in May 2020) and Windows 10 will be supported until at least October 14, 2025. For comparison, Fedora 36 will be EOL'd in May 2023. "We" (and when I say "we", I understand that is mostly not me), are going to have to continue to document (and fix, where "we" have the knowledge) the areas that need improvement for UEFI booting and runtime. Gary (*) Technically it is possible to jump through enough hoops to get Windows 11 to run on BIOS only systems, but it is not supported, and may break at any time. Most people prefer something that the vendor supports. BIOS-only users can stay on Windows 10. They have very little reason to upgrade to Windows 11. It's mostly cosmetic changes to the UI and there's no major software product that requires Windows 11, but doesn't run on Windows 10. Adoption of new Windows versions has always been painstakingly slow, even after the old version is EOL'd, people continue to use it (I know it's a bad idea, but people do it anyway - look at how much time it took for people to upgrade from Windows XP, after it was EOL'd). But Windows 10 is still supported, so it can be used, it's not more dangerous than Windows 11. So the question is, why should cloud providers care about Windows 11? Long term, yes, they do care, but none of their Windows users are in a hurry to upgrade, they are fine staying on Windows 10 until 2025, there's nothing in Windows 11 that makes it worth upgrading (in my personal opinion), especially not for server/cloud use. I must check this (please correct me if I'm wrong), but I think Windows Server 2019 still supports legacy BIOS and has extended support until January 2029. (**) Yes, some may prefer living in a Windows-less world, but the reality is that (especially at business scale) there are services and applications that require Windows today, and will likely require Windows for a number of tomorrows. Like I said, Windows 10 supports i686 + Legacy BIOS, as well as x86_64 + Legacy BIOS until at least October 14, 2025. (***) Yes, using multiple cloud providers is often advantageous to avoid vendor lock-in and provider failures, but scale (at one provider) can result in savings (both expense, and duplication of work supporting the different providers' services). There is statement by a VC regarding startups which is (essentially) everyone should start by using AWS, and then have a plan to move off when their scale is sufficient (of course, many startups never survive sufficiently long to move off, and others simply prefer to spend their (precious) engineering resources in other ways). () Yes, some hope coreboot/linuxboot can replace UEFI (and it can in some use cases). But unless/until MS embraces it, UEFI is the answer (even if one is still discussing the question that was asked). I believe the PC-compatible coreboot payloads are the way to go - either coreboot+SeaBIOS or coreboot+TianoCore. I don't know what's the state of TianoCore and whether it works on real hardware. I have one working system with coreboot+SeaBIOS (it's a Chromebook) and I'd like to be able to use it. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
On 4/10/22 09:56, Thomas Schmitt wrote: Hi, Nikolay Nikolov wrote: Maybe I should try adapting my code, so that it finds the GRUB BIOS boot partition and loads it? This would be a nice stunt for which we would have to find a use case. As stated yesterday, the GRUB El Torito image contains a core.img which serves the same purpose as a BIOS partition. The use case I'm thinking about is not for the install image, but for hard disk installations in legacy BIOS mode, that use the GPT partition scheme, instead of the MBR partition scheme. In this case, with my MBR bootloader code, you still need the extra GRUB BIOS boot partition, but it can be moved anywhere on the disk, without breaking the bootloader. In the case of the traditional GRUB MBR code, you would need to boot from a rescue media and reinstall the bootloader, every time this partition is moved (or partition tools should treat it as unmovable, which reduces your flexibility). The disadvantage of my MBR boot code is that it doesn't support really old systems without the INT 13h LBA extensions. And you cannot detect in the distro installer whether the system supports these extensions or not, so if it's installed by default, some old systems would be rendered unbootable. In theory, anything that supports x86_64 should support these extensions (they were introduced in the Windows 95/98 times, when hard drives started hitting the 8 GB mark, while x86_64 appeared much later, in 2003, at the time hard drives were hitting 160GB-200GB as far as I can remember, and the 8 GB limit was becoming a joke), however I don't know what's the reality, BIOSes are surprisingly buggy. the main obstacle is that I'm not familiar with GRUB's code and I don't know what GRUB's next stage needs I myself only learn about GRUB at occasions like this here. There is a vivid community at grub-de...@gnu.org. If you have an interesting use case they might be willing to explain things. But on the other hand the BIOS stuff is old and Vladimir Serbinenko, who created it, is not very busy with GRUB any more. Yeah, I'll join that mailing list and explain the use case I have in mind (the one that I described above). Unfortunately, I'm not familiar with how El Torito works, Roughly: At 2048-byte-LBA 17 (decimal) there is the Boot Record, which points to the El Torito Boot Catalog. The catalog contains entries, which describe boot images. In case of Fedora Live there are three of them: One for BIOS, and two for EFI. The boot image for BIOS is a plain x86 program. The first EFI image is a FAT filesystem with boot programs /EFI/BOOT/BOOT*.EFI for the intended processor architectures (x86-32bit, x86-64bit, ARM-32bit, ... ). The second boot image for EFI (macboot.img) is actually a HFS+ filesystem image which should not be listed in the catalog. That's a hack by Matthew J. Garrett to let the rather dumb ISOLINUX program isohybrid.c find the HFS+ image and mark it by an Apple Partition Map. isohybrid.c does not understand ISO 9660 but it knows the El Torito boot catalog. Fedora does not use isohybrid.c any more, but rather lets libisofs under xorriso create the Apple Partition Map, if at all. Nevertheless, xorriso produces the same inappropriate catalog entry for EFI, which the firmware ignores in favor of the appropriate EFI boot image. (Who am i to change mjg's invention ?) My knowledge about boot lures for various processors and firmwares is compiled at https://dev.lovelyhq.com/libburnia/libisofs/raw/branch/master/doc/boot_sectors.txt Original specs: El Torito: http://web.archive.org/web/20010706014919/http://www.ibm.com/products/surepath/documents/standard/cdrom7.pdf UEFI: https://uefi.org/sites/default/files/resources/UEFI_Spec_2_8_final.pdf Legacy BIOS: Only rumors around. Start exploring at Wikipedia. Re-use your knowledge about BIOS booting from floppy/hard disk/USB flash drive. Thanks for the explanation and the links. I'll check them out. This hybrid USB stick/DVD iso image has always seemed like black magic to me :) It's just a matter of outmost cramming of boot lures which are barely compatible. (The unusual block size 2048 for Apple Partition Map gives room for GPT. Some noop-x86 code at the start of the MBR lets it look like the first block of an Apple Partition Map. It's just weird from the view of specs and BIOS tradition. But it works since 10 years.) I imagine it is like those polyglot programs, that are simultaneously valid in several totally different programming languages: https://en.wikipedia.org/wiki/Polyglot_(computing) AFAIK, Windows only provides an ISO download, that is suitable for burning on optical media and then it boots, but it doesn't work, when you "dd" it to an USB flash drive. I think you need to use special tool, to write it to a USB stick, You are supposed to create a FAT filesystem in a MBR partition of the USB stick with a traditional partition type like 0x0C. Then you copy
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
On 4/10/22 00:30, Thomas Schmitt wrote: Hi, Nikolay Nikolov wrote: I haven't looked at GRUB's MBR code, but there's enough space in the MBR to scan the GPT entries, find a specific GUID partition type and load the first several kilobytes from it and transfer control to it. Well, GRUB goes a different way on legacy BIOS. It boots its core code without knowing about partitions and then loads the modules which its configuration expects to need. I understand GPT is handled by "part_gpt" and MBR partitions by "part_msdos". The code takes up only 262 bytes so far It is astounding what can be squeezed into 440 bytes of x86 machine code. Maybe I should try adapting my code, so that it finds the GRUB BIOS boot partition and loads it? It shouldn't be too hard to do, the main obstacle is that I'm not familiar with GRUB's code and I don't know what GRUB's next stage needs (i.e. at what address it should be loaded, and how it should be called). But regarding size, core.img is apparently less than 32 kb, and it fits between the MBR and the first partition on MBR systems, and my code already loads almost 64kb from a GPT partition, so even if the next GRUB stage needs some special requirements (like moving to a different address, enabling gate A20, entering protected mode, etc), it can be done at least with a wrapper, but perhaps also even in the remaining bytes of my MBR code. --- I meanwhile learned that the El Torito boot image eltorito.img used by grub-mkrescue is not a plain copy of cdboot.img but rather a concatenation of cdboot.img and a core.img : https://www.gnu.org/software/grub/manual/grub/grub.html#Making-a-GRUB-bootable-CD_002dROM "For booting from a CD-ROM, GRUB uses a special image called cdboot.img, which is concatenated with core.img. The core.img used for this should be built with at least the ‘iso9660’ and ‘biosdisk’ modules." So the role of the BIOS partition is properly fulfilled by the El Torito boot image which has 27874 bytes in my example ISO from grub-mkrescue. Unfortunately, I'm not familiar with how El Torito works, I only understand the legacy PC boot process from floppy/hard disk/USB flash drive, but not from optical media. This hybrid USB stick/DVD iso image has always seemed like black magic to me :) And we've been spoiled and expect it to work, but I think it doesn't work with Windows 10, for example. :) AFAIK, Windows only provides an ISO download, that is suitable for burning on optical media and then it boots, but it doesn't work, when you "dd" it to an USB flash drive. I think you need to use special tool, to write it to a USB stick, but I've never done it, I still burn DVD+R for Windows installs :) And what's worse, they now require the rarer and more expensive DVD+R DL discs, since their install image exceeds 4.7 GB :) Have a nice day :) Thomas ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
On 4/9/22 03:07, Chris Murphy wrote: On Fri, Apr 8, 2022 at 4:31 PM Thomas Schmitt wrote: Yeah, I'm not aware off hand of any UEFI that have a problem with the first 440 bytes of LBA 0 being non-zero. If they did, then they would have problems with GPT disks, initialized by Windows 10, because Windows 10 puts its standard non-GPT aware bootloader code there. :) Only Fedora-initialized disks have zeros there. :) I can confirm this, because I have three disks (two 512GB SSDs and one 2TB HDD) on my UEFI-enabled, dual booting between Windows 11 and Fedora, desktop computer. I am aware though, of this tianocore bug [1] where if the active bit on that 0xEE partition is set, the GPT is considered invalid. This is now fixed in Tianocore, but it might be widespread in firmware in hardware. But the idea would be to not set this boot flag on our increasingly hypothetical future ISOs because (a) it might cause UEFI to drop to an EFI shell, if this bug is more widespread (b) we don't really want to work around buggy BIOS firmware anyway, we want them to fail here rather than later. Pretty sure I discovered this bug when testing Fedora 35 Cloud base images, which are GPT with PMBR, and boot both BIOS and UEFI systems. There's jump code in the first 440 bytes of LBA 0, pointing to the core.img in BIOS Boot partition, and also there's an EFI system volume that UEFI firmware discover. But if there are still some systems out there that will face plant on GPT anyway, it's probably best if they face plant when booting the installation media rather than getting all the way to a successful installation, just to face plant upon reboot. Legacy BIOS does not care for partition tables. At least to my knowledge from supporting production of bootable ISOs. My mileage may vary. Problems with partitions will arise only after BIOS handed control to the MBR x86 code on USB stick or the El Torito boot image on DVD. Some legacy BIOS insist on seeing certain MBR structures in LBA 0 or they face plant. This was why Fedora never proceeded with GPT by default on BIOS systems. Too many at the time didn't like the PMBR for one reason or another. I think the more common reason (?) was the single partition in the PMBR didn't have BootIndicator set, hence parted's pmbr_boot flag, which sets this bit. Possibly this here describes what is needed for GRUB if started by legacy BIOS and facing GPT: https://wiki.archlinux.org/title/GRUB#BIOS_systems I understand that the GPT boot partition substitutes for the traditional gap between MBR block and the start of the first MBR partition. 1 MiB of "embedded area" if i remember correctly. yeah that's what I'm calling BIOS boot partition type, it's partition type GUID is 21686148-6449-6E6F-744E-656564454649 which grub-install is looking for, and how it knows where to embed core.img. But as I understand it, the code in the first 440 bytes of LBA 0, written by grub-install as well, is just jump to the LBA for core.img. There's no code to "teach" the computer how to read the GPT and go find BIOS Boot. It's a hard coded LBA to just blindly jump to. I haven't looked at GRUB's MBR code, but there's enough space in the MBR to scan the GPT entries, find a specific GUID partition type and load the first several kilobytes from it and transfer control to it. And this is even without assuming 512-byte sectors. I know this, because I have written such code for my hobby DOS-like OS, which I want to be able to support GPT in BIOS legacy mode, so it can coexist with modern Windows and Linux distros (which boot in UEFI mode, while my OS boots in legacy mode - I can switch between the two modes from my UEFI boot menu). Here's the code I've written (consider it proof of concept), but it can be used by GRUB as well: https://sourceforge.net/p/fpcdos/code/HEAD/tree/trunk/src/gptboot/mbr.asm The code takes up only 262 bytes so far, so it has plenty of bytes to spare (for e.g. nicer diagnostic error messages). The only thing it assumes is that the INT 13h LBA BIOS extensions are available - there's no CHS fallback support. The code *doesn't* assume that the sectors size is 512 bytes, it doesn't assume the GPT partition it is looking for is in a specific position in the table, or starting on a specific LBA, it doesn't assume the number of GPT partitions are less than 128, it doesn't assume that GUID partition entries are 128-byte sized and it doesn't care about the 4 MBR partitions at all, it only searches through the GPT partitions. The code assumes that the GPT partition table is correct, and doesn't do a lot of error checking, e.g. it doesn't check the CRC32 fields in the GPT header. But grub-mkrescue ISOs have GPT without a dedicated boot partition. Probably that job is fulfilled by the El Torito boot image which has a few more KiB than the MBR x86 code. So i assume that face planting will happen only at later stages if the booted system makes false assumptions
Re: RFC: Reduce number of packages that are built for i686
On 11/18/21 00:27, Kevin Fenzi wrote: On Wed, Nov 17, 2021 at 05:58:43PM +, Peter Robinson wrote: What else is there that people care about in Fedora that's only i686? Well, wine? I don't know how much 32bit wine is used these days. And not 'in fedora', but people always bring up steam when these disccussions happen. I wonder why they are sticking with 32bit? Pretty much all Windows applications (including 64-bit ones) are usually distributed as a self-installing 32-bit .exe, using one of the popular installer packages, such as InnoSetup, the Nullsoft installer, etc. That's why 64-bit Windows will probably never drop support for their win32 compatibility layer. Nikolay ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Free Pascal and F35 Mass Rebuild
On 8/8/21 10:10 AM, Mattia Verga via devel wrote: Il 07/08/21 21:30, Nikolay Nikolov ha scritto: On 8/7/21 6:19 PM, Mattia Verga via devel wrote: So, I still haven't seen anything posted in gitlab or mailing lists, so I've posted to the FPC forums: https://forum.lazarus.freepascal.org/index.php/topic,55723.0.html The gitlab repository was supposed to go public today, but yet another issue was discovered in the mantis conversion, so it'll need to be done once again. :( At least the git repo is now finally converted (after 8 attempts :) ), so now we're only waiting for the mantis conversion. Unfortunately, we can't make the repository public before this is done, because anybody, who posts a new bug on the gitlab bug tracker will mess up the mantis conversion. :( Nikolay Oh, I thought it was already public. Isn't https://gitlab.com/freepascal.org/fpc ? The 'source' repository, which contains the actual FPC sources was still private at the time I wrote this email. There were other repositories that were public at this time (Build, Documentation, Pas2JS, etc.) The 'source' repository was finally made public today: https://gitlab.com/freepascal.org/fpc/source Nikolay Mattia ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Free Pascal and F35 Mass Rebuild
On 8/7/21 6:19 PM, Mattia Verga via devel wrote: So, I still haven't seen anything posted in gitlab or mailing lists, so I've posted to the FPC forums: https://forum.lazarus.freepascal.org/index.php/topic,55723.0.html The gitlab repository was supposed to go public today, but yet another issue was discovered in the mantis conversion, so it'll need to be done once again. :( At least the git repo is now finally converted (after 8 attempts :) ), so now we're only waiting for the mantis conversion. Unfortunately, we can't make the repository public before this is done, because anybody, who posts a new bug on the gitlab bug tracker will mess up the mantis conversion. :( Nikolay ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: replace memtest86+ with pcmemtest, needs maintainer
On 8/2/21 9:15 AM, Vitaly Zaitsev via devel wrote: On 02/08/2021 04:04, Chris Murphy wrote: I'm definitely not attached to keeping things the same. The bios memtest86+ is still these days installed to /boot but there hasn't been a menu entry for it for a very long time; in fact maybe it was only ever on netintall or dvd images? I can't remember that far back memtest86+ doesn't support UEFI. It only has a menu entry if the Legacy boot is used. Also memtest86+ doesn't support modern Intel and AMD processors. It will hang on start. The memtest86+, included in the Fedora install media works. AMD Ryzen 9 5900X here, with 128 GB RAM. Unfortunately, it was recently removed from the install media. The memtest86+, installed on your computer in Legacy boot mode and then added to the Grub boot menu, doesn't work and crashes on start on the same computer. That's why I install in UEFI mode, but keep my Fedora 33 install DVD+R disk around and boot it in Legacy mode to run memtest86+ when I need it. The fact that the OS is installed in UEFI mode doesn't matter. Nikolay ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Free Pascal and F35 Mass Rebuild
On 7/27/21 3:59 PM, Artur Frenszek-Iwicki wrote: Thanks for the help, Florian. Unfortunately, I'll have to admit straight away that even though I co-maintain FPC, my knowledge of assembly, ELF and compilers in general is close to non-existent, so I don't really know how to apply the minimal patch you gave. I wanted to submit a bug report upstream to FPC, but it just so happens that the project is currently moving from self-hosted SVN version control + Mantis bug tracker to GitLab, and while this is ongoing, both Mantis and GitLab issues are inaccessible. Yeah, it's best to report it upstream. The GitLab transition should be ready in a day or two, I hope. Alternatively, you can send mail to the [fpc-devel] mailing list. Nikolay ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: The future of legacy BIOS support in Fedora.
On 5/27/21 5:25 PM, Vitaly Zaitsev via devel wrote: On 27.05.2021 16:17, Marius Schwarz wrote: Also, a lot of laptops are installed in Legacy Mode, as setting them up in EFI was impossible. 1. Backup all data. 2. Convert MBR to GPT. 3. Create an ESP partition, add it to the /etc/fstab file and mount. 4. sudo dnf swap grub2 grub2-efi 5. sudo dnf install shim (only if needed). 6. Reboot. That is quite a painful process. And how do you do that on a MBR system that dual boots Fedora and Windows 10? I really don't want to go through the pain of reinstalling Windows and all the programs that I have there. Nikolay ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Unretiring and maintaining the Fish Fillets NG game
On 4/29/21 11:19 AM, Kamil Paral wrote: On Thu, Apr 29, 2021 at 3:59 AM Nikolay Nikolov <mailto:nick...@gmail.com>> wrote: What are the next steps for unretiring these two packages and maintaining them? Hey Nikolay, thanks for taking care of Fish Fillets, it's a great game (and also from my country). Here I found the instructions for unretiring a package: https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers#Claiming_Ownership_of_a_Retired_Package <https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers#Claiming_Ownership_of_a_Retired_Package> Ok, I filed a review request: https://bugzilla.redhat.com/show_bug.cgi?id=1955107 Now I'm waiting for someone to review it. Best regards, Nikolay ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Unretiring and maintaining the Fish Fillets NG game
Hi, After my recent upgrade to Fedora 34, I was disappointed to find out that one of my favorite puzzle games Fish Fillets NG has been retired. So, I decided I should make an effort to get it back from the dead and maintain it. The relevant packages are: fillets-ng fillets-ng-data The fillets-ng-data compiles without changes on f34 and rawhide, but fillets-ng failed, due to incompatibility with newer lua version, so I made a patch. I made koji scratch builds for f34 and rawhide and compilation succeeded on all archs: https://koji.fedoraproject.org/koji/taskinfo?taskID=66893530 https://koji.fedoraproject.org/koji/taskinfo?taskID=66893533 I tested the f34 x86_64 package on my computer and it works. So, now I'm happy once again that I can help these cute little fish find a safe way out from their messy underwater environment. :) Now it's time to share this with other Fedora users :) What are the next steps for unretiring these two packages and maintaining them? Btw, I'm still relatively new to Fedora and package maintenance, but I'm already a maintainer of one package - hedgewars, however that package has never been retired, so I haven't yet gone through the process of unretiring a package. Best regards, Nikolay ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: New memory tester application potentially to replace memtest86+: PCMemTest
On 2/9/21 10:53 AM, Vít Ondruch wrote: Dne 08. 02. 21 v 21:44 Chris Murphy napsal(a): On Mon, Feb 8, 2021 at 2:46 AM Vít Ondruch wrote: Being devils advocate, but should we have the memtest86 or similar by default? I have certainly not used this feature in my 10+ yeas with Fedora. You mean get rid of it (from media and installations)? Yes, that is my proposal. Because we install it unconditionally already, even though it's a BIOS only utility and there isn't a boot entry for it in the bootloader. It's a bit obscure how to use it, given there's no menu entry for it. Ah, good to know that I have it on my system. I'm going to remove it right now. Enjoy the 357 KB space savings. :) I don't think this is utility, which is targets typical Fedora user. Here is PR proposing the removal: https://pagure.io/fedora-kickstarts/pull-request/754 A memory testing utility is certainly something useful in ruling out hardware reasons for system crashes. Even Microsoft has included one in recent versions of Windows. Being BIOS only is a problem, yes, but that makes it even more useful to have on the installation media, because I can enable the legacy BIOS CSM and boot the installation DVD on my UEFI systems, while I can't really install it on my hard drive and enable it in the GRUB menu if I have an UEFI install. Now, I would need to use a different installation media to run this tool for the sake of reducing the >2GB installation image by several kilobytes. Doesn't sound like a great idea to me. I agree it should not be installed by default on UEFI systems and I think it should probably have been enabled by default in the GRUB menu on BIOS systems. I also agree an alternative like PCMemTest is needed for UEFI systems, because not all systems have legacy BIOS CSMs. Nikolay ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Proposal: drop "Test installation media" from live media
On 12/12/20 12:20 AM, Matthew Miller wrote: On Sat, Dec 12, 2020 at 12:15:07AM +0200, Nikolay Nikolov wrote: there's even less reason to skip it. Which really begs the question, why do we even assume the media test is only useful for DVD and not for USB flash? I gave those reasons in my initial message? Have you experienced a specific case where bad USB media caused a corrupt install? No, but I have the habit to always run the media check, before attempting install, so it's unlikely that I've encountered an error like that, since I don't attempt to install from media that fails the test. I only skip the media test in two cases: a) installing in a VM b) installing from a media I've already verified (e.g. when installing on several computers from the same USB flash or DVD, I only verify it the first time for USB, and for DVD, I use the "verify" option in the DVD burning software, so I skip the option even during the first install) So, how can I experience a corrupt install, due to media failure, since I specifically run the media check to ensure this doesn't happen, before I attempt an install? Just because I haven't experienced it, since I always run the test, doesn't mean it won't happen when people skip the media test. Nikolay ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Proposal: drop "Test installation media" from live media
On 12/11/20 8:55 PM, Vitaly Zaitsev via devel wrote: On 11.12.2020 19:07, Matthew Miller wrote: I think since burning spinning optical media is no longer the normal way to do this, we should drop this and just go straight to booting (unless of course a key is hit to stop things and enter boot parameters). USB flash drive can be broken too. I suggest moving it to the Troubleshooting sub-menu instead of completely removing it. I agree. I like to run the test even from USB flash. In fact, strange as it may sound, I've found flash drives to be less reliable in that tools that people use to dump the image to a flash drive don't always do the right thing. DVD burner software always writes the image correctly to a DVD-R or DVD+R disc and usually has an option to verify the burn, which I always use. USB writers often contain bugs or don't verify the written data, so I don't trust any install that haven't booted and run the media self test, regardless of whether it's USB flash or DVD (it's mostly USB flash these days, but I still use DVD for certain systems, where I have trouble booting from USB, due to BIOS bugs). And if I skip the test, it's usually for optical media, not for USB, where I trust the USB writer tools less. And if an install fails, due to failure in the optical media, I usually get useful feedback from the drive (characteristic sound), which makes it clear that the failure is due to unreliable disc or drive, while on USB you usually get nothing, except broken data. Also, the media test is actually faster on USB flash, so there's even less reason to skip it. Which really begs the question, why do we even assume the media test is only useful for DVD and not for USB flash? Nikolay ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
