Re: The future of legacy BIOS support in Fedora.
On Thu, 2020-07-09 at 11:17 -0700, stan via devel wrote: > On Thu, 09 Jul 2020 18:07:39 +0300 > nick...@gmail.com wrote: > > > Yes, that's why "secure boot" should only be an option and the user > > must have the option to turn it off. Otherwise, it wouldn't be > > possible to do any kernel development on that computer. > > For my edification. I build custom kernels, and sign them using > pesign with my own key that I generated locally, and put in the EFI > key > database. I can then boot the custom kernel in secure mode. Couldn't > I > also sign modules if I ever generated them with that same key? > > That is, isn't this only an issue if the person doing the kernel > development hasn't generated their own key, and isn't signing their > kernels locally? To be honest, I don't know. Do all UEFI secure boot implementations allow you to add your own keys to the list of trusted keys? 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: The future of legacy BIOS support in Fedora.
On Thu, 2020-07-09 at 07:46 -0700, John M. Harris Jr wrote: > On Thursday, July 9, 2020 3:38:54 AM MST Richard Hughes wrote: > > On Wed, 8 Jul 2020 at 22:19, John M. Harris Jr < > > joh...@splentity.com> > > wrote: > > > This is not something that's beneficial here, it's only > > > harming our users. > > > > That seems exceedingly myopic to me. I'm guessing you've not been > > following the last few years of security research, where attacking > > the > > firmware is now the best way to own a machine. And please don't > > lecture me on why BIOS is more secure than UEFI, "compatibility" > > mode > > is implemented *on top of* the UEFI bios these days, rather than as > > a > > completely different software stack. > > "Attacking" the firmware has always been the best option, even with > BIOS boot > systems. For example, coreboot is technically a hostile payload, to > the OEM. > That doesn't mean that it makes any sense to prevent the end user > from > actually owning the hardware they've purchased, and doing with it > what they > please. Yes, that's why "secure boot" should only be an option and the user must have the option to turn it off. Otherwise, it wouldn't be possible to do any kernel development on that computer. > > > > If you've got root, you can STILL do almost anything to the > > > hardware, > > > including disabling various "firmware protection technologies". > > > > I don't think you understand what enabling SecureBoot actually > > does. > > "Secure Boot" doesn't make root non-uid 0, and can't keep root from > controlling system devices, even uploading unsigned firmware to > peripherals. > At the point that anything but the end user gets root on a Fedora > install, all > of these "security gains" provided by creating needless headache for > those > running under "Secure Boot" are null and void. Yeah, for me, it's pretty weak as a mitigation effort, because it will usually only have some protective effect if someone already has root on your computer, and that's already pretty bad. You don't normally want to allow that to happen ever. And when someone has root, they can do pretty much anything. IMHO, it's a lot of effort and inconvenience for very little actual gain. But, that's why it should only be an option and not mandatory. But yes, it might make sense for certain use cases. 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: The future of legacy BIOS support in Fedora.
On Thu, 2020-07-09 at 07:38 -0700, John M. Harris Jr wrote: > On Thursday, July 9, 2020 12:26:27 AM MST Daniel P. Berrangé wrote: > > On Wed, Jul 08, 2020 at 02:17:53PM -0700, John M. Harris Jr wrote: > > > > > On Wednesday, July 8, 2020 10:04:01 AM MST Richard Hughes wrote: > > > > > > > On Wed, 8 Jul 2020 at 16:48, John M. Harris Jr < > > > > joh...@splentity.com> > > > > wrote: > > > > > > > > > needlessly disables a lot of kernel functionality > > > > > > > > > > > > It disables functionality which can destroy platform security. > > > > > > It disables functionality that users need, such as inserting > > > their kernel > > > > > > modules on their own system, or hibernating to disk. Let's be > > > honest about > > > what this does. This is not something that's beneficial here, > > > it's only > > > harming our users. > > > > Some users, not all users. Beware of making sweeping > > generalizations. > > > > I've used Fedora since Fedora Core 5 across countless machines and > > never > > cared about inserting custom kernel modules. Hibernating to disk is > > not > > something I've used on my laptops in probably 10 years either, as > > suspend > > to ram is generally sufficient. Again just my personal experiance. > > > > There's always a tradeoff and it is likely to be different > > depending on > > each users needs. While SecureBoot will disable some functionality > > it is > > not unreasonable to think it is a net win out of the box for a > > potentially > > quite large portion of Fedora's userbase. > > > > Regards, > > Daniel > > Please keep in mind that it disables that functionality only because > of > 'lockdown' patches applied to the Fedora kernel, it's not a normal > part of the > Linux kernel when running under Secure Boot. I have no idea why the > decision > to hurt users was explicitly made here, it doesn't make a lot of > sense. IIRC, if you sign a kernel that can load unsigned modules, you can boot that kernel, then load a custom module, that boots a different kernel or OS (such as Windows) and claim that secure boot was on, even though you have modified and/or injected malicious code into the kernel. In other words, you can circumvent the whole point of using secure boot. If you want that, you might as well just disable secure boot. Otherwise it is a bit like locking your front door, while leaving your back door widely open. You can argue all they long that secure boot doesn't bring you that much security anyway (I'm in that camp, I don't think it's worth the trouble for my home systems, so I disable them even on those that use UEFI), but then, again, as long as it's not mandatory, so the user can choose to turn it off, it should be ok. Some people might decide to make an informed decision to enable it, and that's their decision to make. It's a tradeoff - extra lockdown for some extra security. Maybe only worth it for very important systems. 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: The future of legacy BIOS support in Fedora.
On Mon, 2020-07-06 at 14:51 +0200, Gerd Hoffmann wrote: > Hi, > > > My real problem with grub2 is not that it's complex, but the fact > > that > > it exposes its complexities to the user. > > The config file syntax is a mess indeed. The fact that you need a > config generator tool in the first place speaks volumes ... > > But note that grub config files don't have to be as complex as the > grub2-mkconfig generated ones. > > > I'm willing to try systemd-boot on a virtual machine, to see if it > > makes things easier, but the fact it doesn't support BIOS makes it > > not > > very usable for me. > > https://www.kraxel.org/repos/images/fedora-31-efi-systemd-x86_64.qcow2.xz > Thanks! I downloaded the image and will check it out as soon as I find some free time... :) 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
Re: The future of legacy BIOS support in Fedora.
On Mon, 2020-07-06 at 13:31 +0200, Gerd Hoffmann wrote: > Hi, > > > > btw, sd-boot has a few tricks up its sleeve: if during boot you > > > keep > > > "w" pressed down it will automatically boot into windows, similar > > > if > > > you keep "l" pressed down it will automaticall boot into linux, > > > "a" > > > will boot into macos, all without showing any UI at all. This > > > means > > > the boot menu can be hidden entirely during boot with a zero > > > timeout, > > > but you can still boot into a specific boot entry. > > > > That's actually awful, in my opinion, > > Why? It's nice to have them and I can't see any downsides. > > > and objectively undiscoverable.. > > Indeed. Would be nice to show these hotkeys somewhere. Extend the > help line which is shown when you press '?' for example. > > > If you'd like to see how it should be done, boot a VM with GRUB2 as > > the bootloader. For a short period of time, you'll see a list of > > options, with the default option highlighted. If you don't pick > > something different, or don't need to enter a prompt to recover > > your > > device, it'll automatically boot. > > Well, seems you have never actually used sd-boot ... > > There actually isn't much of a difference between grub2 and systemd- > boot > here. Both can be configured to show or not show a menu. The menu > screen doesn't look fundamentally different either: List of boot > entries for the kernels installed, entry to boot into firmware setup, > default entry highlighted, a few seconds timeout with > countdown. Both > support editing boot entries. > > Yes, unlike grub2 sd-boot has no command prompt. I have not missed > that > so far. The vast majority of cases where I've actually needed the > grub2 > prompt have been grub2 install problems, like grub2 failing to find > its > config file for some reason. That is clearly not something I account > in > favor of grub2 ... > > > GRUB2 is nice in that it's powerful enough for those that need it, > > but > > simple enough for those who don't want the complex features. > > Well, alot of the complex grub features are dragged forward from the > BIOS world to the UEFI world and are somewhat awkward there. > > The BIOS provides block device access at sector level, so the boot > loader has little choice but implementing drivers for all kinds of > stuff. Or use fragile block lists like lilo did in the last century. > > With UEFI much more functionality is provided by the firmware and > there > is little reason for a bootloader to have tons of drivers. With the > exception of filesystem drivers in case you want boot from something > != > vfat. But even that should ideally be implemented as uefi driver not > as > grub2 module. > > If you insist on comparing bloat it will be grub2 which is bloated, > and it comes from being stuck in its own world and carrying its own > implementation for everything instead of using firmware services. > > -rwxr-xr-x. 1 root root 93803 Jun 2 08:19 systemd-bootx64.efi > -rwx--. 1 root root 2513224 Jun 19 18:24 grubx64.efi > > (binaries as shipped by fedora 32). You're right, and that's yet another reason it's not a good idea to use childish names as "systemd-bloat". I agree that grub2 is more bloated and that it doesn't make sense to bring all the complexities of BIOS boot to UEFI. However, the real question is, why does it matter? It's only a boot loader. It does its job in a fraction of a second and then it's all done, and the kernel takes it up from there. None of the "bloated" bootloader code stays in memory. And wasting 2.5 MB instead of 94 KB of disk space would only matter if we lived in the times when hard drives were 10 MB or 20 MB :) It's true that the extra complexity means it's more prone to bugs, but it has already been debugged fairly well and does its job just fine, so what's the problem? My real problem with grub2 is not that it's complex, but the fact that it exposes its complexities to the user. I wish it had an "easy" mode, where you could configure it easily for the common things that 99% of the users would do, such as: 1. setting the boot menu timeout 2. choosing the default boot option - e.g. always Fedora, or always Windows, or always a single entry, or, alternatively, as an option, remember the last chosen option, and just repeat it, if the timeout expires - this is invaluable when you dual boot Windows and have to install Windows updates, because they are notorious for rebooting the system several times, and you can't always sit in front the computer for hours, so that you can catch the 5 seconds when the boot menu appears, so you can choose Windows again. :) 3. changing the kernel boot options 4. adding passwords to certain menu entries These are common things, that I'm reluctant to do, because I'm put off by the complexities of grub2 configuration. I wish it had an easy mode that just covers these common scenarios. I don't want to remove features from it, I think it's
Re: The future of legacy BIOS support in Fedora.
On Sun, 2020-07-05 at 11:50 -0700, John M. Harris Jr wrote: > On Sunday, July 5, 2020 11:31:41 AM MST Solomon Peachy wrote: > > On Sun, Jul 05, 2020 at 10:20:01AM -0700, John M. Harris Jr wrote: > > > Chromebook devices are neither UEFI nor BIOS. You can use GPT > > > disk layout > > > while still booting BIOS, which they also don't do. Chromebook > > > devices > > > either boot with uboot -> depthcharge or Coreboot -> uboot -> > > > depthcharge. I don't see how this helps your argument. > > > > If one adds ChromeOS devices into the numbers I posted, then the > > proportion of BIOS-boot-capable, BIOS-boot-enabled, and/or BIOS- > > only > > devices on the market (and their portion of the total install base) > > goes > > down, not up. > > > > So using the absense of chromebooks in the numbers I referenced > > actually > > boosts, rather than undermines, my argument. Oh, there were > > supposedly > > 17 million chromebooks shipped in 2019, versus 261 million "PCs" > > and > > 12-ish million "servers". > > > > ...Is this horse sufficiently dead yet? > > > > - Solomon > > Actually, Coreboot has a SeaBIOS payload as well, so the x86_64 > Chromebooks > are "BIOS-boot-capable" systems. (Coreboot also has a GRUB payload, > which is > used by early Purism devices, before they switched to SeaBIOS, and is > used by > all x86_64 Libreboot systems). I can also confirm that my Acer C720 Chromebook has a SeaBIOS payload, which is the only way to go, if you want to boot something other than ChromeOS: https://www.chromium.org/a/chromium.org/dev/chromium-os/developer-information-for-chrome-os-devices/acer-c720-chromebook#TOC-Legacy-Boot The default boot method that ChromeOS uses requires the OS to be signed by Google's private key, which is a secret, so you can't boot Fedora or any other distro with it. And AFAIK, you can't install other keys, you're just supposed to use SeaBIOS for other operating systems. I don't know much about newer chromebooks, though. But I wouldn't be surprised if they are the same, since Google doesn't have much reason to adopt UEFI, provided that they control both the software and the hardware and that they have already developed a system that works. Btw, this machine is from 2013. I use it for Coreboot+SeaBIOS experiments. 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
Re: Self Introduction: Nikolay Nikolov
On Sun, 2020-07-05 at 07:09 -0500, Richard Shaw wrote: > On Sat, Jul 4, 2020 at 8:48 PM wrote: > > Hello, > > > > My name is Nikolay Nikolov. I'm a software developer and free/open > > source enthusiast. I've been using Linux since Red Hat Linux 5.0. > > After > > Red Hat Linux 9, I upgraded to Fedora Core 1 and I've used every > > Fedora > > version since then. :) I'm a core developer of the Free Pascal > > Compiler > > ( https://www.freepascal.org/ ). My Free Pascal contributions > > include > > code generator support for some legacy platforms, such as 16-bit > > x86 > > and Z80, as well as modern stuff, such as GDB/MI debugger support > > integration in the Free Pascal IDE, x86 optimizations (for all x86 > > flavours - 16-bit, 32-bit and 64-bit). > > > > I also develop and maintain several open source projects, written > > in > > Pascal. > > > > Things I'm interested in contributing to Fedora: > > > > - co-maintaining the Free Pascal package (fpc) and adding > > crosscompiler > > support for additional targets (e.g. crosscompiling to i386-linux > > from > > x86_64, crosscompiling to win32 and win64, etc.). > > - packaging the DOSBox-X fork of DOSBox: > > https://github.com/joncampbell123/dosbox-x > > - packaging some of my Pascal projects, when they get a release > > - eventually, packaging other programs, written in Free Pascal > > Your timing is impeccable! I'm looking for a co/new maintainer for > the Hedgwars package. I have a couple of offers, but as it's written > mostly in Pascal, I think you would be a good fit! :) > > I can sponsor you if you like unless you really would rather submit > some of your pascal packages first, I wouldn't be the best one for > that. Yes, I can co-maintain Hedgewars as well. :) I still haven't figured out how everything works with the packaging yet, so it'd be much easier for me to start with an existing package, that already conforms to the packaging guidelines and that requires little changes, besides updating to new versions and rebuilding. :) Best regards, Nikolay > > Thanks, > Richard > ___ > 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 ___ 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
Self Introduction: Nikolay Nikolov
Hello, My name is Nikolay Nikolov. I'm a software developer and free/open source enthusiast. I've been using Linux since Red Hat Linux 5.0. After Red Hat Linux 9, I upgraded to Fedora Core 1 and I've used every Fedora version since then. :) I'm a core developer of the Free Pascal Compiler ( https://www.freepascal.org/ ). My Free Pascal contributions include code generator support for some legacy platforms, such as 16-bit x86 and Z80, as well as modern stuff, such as GDB/MI debugger support integration in the Free Pascal IDE, x86 optimizations (for all x86 flavours - 16-bit, 32-bit and 64-bit). I also develop and maintain several open source projects, written in Pascal. Things I'm interested in contributing to Fedora: - co-maintaining the Free Pascal package (fpc) and adding crosscompiler support for additional targets (e.g. crosscompiling to i386-linux from x86_64, crosscompiling to win32 and win64, etc.). - packaging the DOSBox-X fork of DOSBox: https://github.com/joncampbell123/dosbox-x - packaging some of my Pascal projects, when they get a release - eventually, packaging other programs, written in Free Pascal I know the basics about building RPMs, and I even build some of the RPMs for the official Free Pascal release myself, but I still haven't made any official Fedora RPMs (i.e. that strictly conforms to the Fedora packaging guidelines, or that uses Fedora's build infrastructure). I use a lot of systems in order to test Free Pascal's many platforms, including Windows, Mac OS X, various BSD flavours, but Fedora is my primary operating system and the only Linux distribution I use, except for Debian 8 on PowerPC, which I use in the rare circumstances where I need to test the PowerPC code generator or to check if some of my code runs correctly on big endian machines. :) For testing the 16-bit x86 port of Free Pascal, I use the dosbox emulator. I want to package the dosbox-x fork, because it offers better CPU compatibility and long file name support, compared to the regular dosbox. Especially on x86_64 dosbox has a nasty bug, which causes bugs in specifically Free Pascal and Free Pascal-compiled programs, due to inaccurate FPU emulation. The i386 version of dosbox doesn't have this bug (as it uses the actual x86 FPU), but dosbox-x has this fixed also on x86_64 (also by using the actual x86 FPU), so it's a better option than compiling and running a 32-bit dosbox. Dosbox-x offers better emulation accuracy, which allows more programs to run, it can correctly emulate the 4:3 aspect ratio, which makes dos games look the way their designed to look like, etc. 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
Re: The future of legacy BIOS support in Fedora.
On Sat, 2020-07-04 at 09:44 -0400, Solomon Peachy wrote:
> On Sat, Jul 04, 2020 at 01:24:46PM -, ziba wrote:
> > Fedora should absolutely CONTINUE supporting BIOS boot (sometimes
> > wrongly
> > labeled "legacy BIOS").
>
> Yep, Fedora should continue supporting BIOS boot at least for the
> next
> few years. This question will surely be revisited after the
> remaining
> x86 CPU makers join Intel in formally droping BIOS support (and
> quite
> possibly the 16-bit CPU modes needed to boot via BIOS!)
While the former will probably happen, I consider the latter to be
quite unlikely, considering the fact that the CPU can execute 16-bit
instructions even in long mode, so they can never be dropped
completely. Yes, even in x86_64 code (although, a subset of them has
been removed from there). But here's an example of some gcc generated
code:
int main()
{
short a = 5;
short b = 7;
short c = a + b;
}
compiled with: gcc gcc_16bit_example.c
happily produces 16-bit instructions, such as:
40110a: 66 c7 45 fe 05 00 movw $0x5,-0x2(%rbp)
401110: 66 c7 45 fc 07 00 movw $0x7,-0x4(%rbp)
401120: 66 89 45 fa mov%ax,-0x6(%rbp)
(disassembly produced by 'objdump -d a.out')
And for 32-bit code, the CPU needs to support the entire 16-bit
instruction set anyway, because it's a proper subset.
The CPU could probably safely drop real mode if BIOS support is
completely dropped, but since it still needs to maintain support for
the entire 16-bit instruction set, in order to run 32-bit and 64-bit
code, it's unlikely this will save a lot of transistors. And it will
mess up with virtualization hosts, because AFAIK modern Intel CPUs have
hardware virtualization support for real mode as well.
>
> And yes, "legacy BIOS" is an accurate term. It is an obelete, long
> deprecated, and soon-to-be-retired system with insurmountable
> technical
> limitations including a hard 2TB upper limit on drive sizes that
> we've
> been running into for more than a decade.
>
> (2TB SATA drives have been available since at least mid-2009.
> Meanwhile, folks with hardware RAID controllers have been running
> into
> this problem even longer)
Yes, it's one of the reasons I didn't use legacy mode on my server. But
currently, it's a tradeoff - laptops and desktops, for example, rarely
have hard drives larger than 2TB, and quite often UEFI mode is less
stable, due to firmware bugs, etc. Also, there are programs such as
memtest86+ which don't support UEFI yet, so even smart users may
sometimes prefer to use legacy mode, because it simply and objectively
works better for them.
>
> > BIOS will be cherished for decades to come!
>
> s/cherished/despised/
Both are emotional words, that shouldn't be part of an objective and
rational discussion. Despise it how much you want, it hasn't gone away,
and still needs to be supported. Cherish it as much as you want, one
day it will no longer need to be supported. I love old 8-bit and 16-bit
computers, but don't expect Fedora to be able to work on them. :)
>
> Fortunately, decades from now, BIOS systems will only exist in
> museums
> and emulators.
Nobody knows what would happen decades from now. x86 might be obsolete
by them. Or it might still be alive. Let's not worry about that far in
the future. To put things into perspective, I remember when in 1998 my
friends were telling me x86 would be dead in a couple of years, because
Intel's next gen ISA (I think it had the code name Merced at the time,
which later became Itanium) was significantly different. 22 years
later, we're discussing in how many years it's going to be safe to drop
legacy BIOS support, and my 2019 laptop can still boot MS-DOS 6.22, if
I'm crazy enough to try it (and yes, I have tried it, just for fun, it
works, as long as you allocate a primary partition for it in the first
8 GB of the hard drive! :) )
>
> > Fedora does not want to lose out in the huge BIOS based market.
>
> BIOS-based systems make up a miniscule minority of the current
> market.
> Pretending otherwise is delusional, and delusions are no basis for
> technical decisions.
I think the discussion is swaying too much in the direction of a
religious war, with increasingly polarizing opinions on both sides.
Yes, BIOS is legacy, but I find UEFI users to be living in a bubble as
well. Dropping BIOS support entirely is not realistic in the next 5-10
years and the number of users using legacy mode on UEFI is probably
surprisingly high. Behind these are probably a huge number of bugs,
hidden in the current UEFI implementations in computers, that aren't
considered "obsolete". Microsoft's alleged dropping of BIOS support is
also extremely exaggerated - it only applies to the OEM version for new
systems, for existing systems they even support a fully 32-bit version
of Windows 10 and the 64-bit version supports BIOS without any
problems.
I think, if we have to be objective, the
Re: The future of legacy BIOS support in Fedora.
On Thu, 2020-07-02 at 08:24 -0700, Gordon Messmer wrote: > On 7/2/20 3:16 AM, nick...@gmail.com wrote: > > Note that, even though Microsoft is pushing for UEFI on new systems > > in > > the OEM version of Windows, they still support booting in legacy > > BIOS > > mode in the latest Windows 10 version and they even support a 32- > > bit > > version of Windows 10, which Fedora no longer does > > ... > > I'm by no means a Microsoft fan, but these are facts. Fedora is > > pushing > > for hardware obsolescence faster than Microsoft in this regard.:( > > I think that as far as 32-bit support is concerned, the issue was > less > that Fedora pushed for "hardware obsolescence" and more that no one > "pushed" for support. Fedora is a collection of the work of > volunteers, > and supporting 32-bit hardware requires more than simply sending > SRPMs > through the build pipeline. Things break, and over time there were > fewer volunteers willing and able to fix those problems. The way Im > remember it, there were plenty of statements to the effect that as > long > as someone was willing to do that work, Fedora would continue to > publish > a 32-bit release. Yes, I understand the complexities of the issue and the extra maintenance work. I was just correcting something I perceived as misinformation or misunderstanding of what Microsoft supports. They've only disallowed PC vendors such as HP, Dell, Lenovo, etc. from selling *new* computers with the 32-bit version of Windows preinstalled, but they continue to support and update the 32-bit version of Windows 10, even though they've dropped support for Windows 7 and Windows XP. I, personally, am happy with what Fedora supports - the oldest computer I still use regularly is a 2004-2006 Socket 939 desktop with an AMD Athlon 64 X2 4800+ dual core CPU with 4 GB of DDR1 RAM, a PCI Express graphics card, a SATA hard drive and 2 floppies - a 3.5-inch and a 5.25-inch (I've added them just for fun, just because the motherboard has a floppy controller, I don't seriously use them :) ). The x86_64 version of Fedora runs just fine on this computer. And so does the 32- bit of Windows 10, but the 64-bit version has dropped support for it, because it doesn't support a single instruction, that was added later to the AMD64 architecture. Luckily, 64-bit Fedora doesn't require it, so I'm a happy Fedora user! :) And yes, I know it's high time that I upgrade, but this is my last desktop computer (all my newer and more powerful computers have been laptops), and it's just more convenient to use the desktop, while sitting on my desk at home. :) And if I had a 32-bit system still in use, I'd probably have volunteered to help keep the 32-bit x86 Fedora alive, but since the 64- bit version works for me, I don't have much incentive to do it. :) > > That doesn't strictly apply to discussions about dropping BIOS boot > support, but that doesn't look like it will happen any time soon. Yes, these are separate issues and the legacy BIOS support affects much newer systems. And it is also less work to maintain legacy BIOS support, compared to an entire 32-bit version of the operating system. And btw, I generally agree that grub2 is a little overengineered and difficult to configure and I think it would benefit if it supported something like a simpler configuration mode. I like how powerful it is, but I think the main problem is that it exposes too much complexity in its configuration file. 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
Re: The future of legacy BIOS support in Fedora.
On Wed, 2020-07-01 at 21:14 -0400, Sam Varshavchik wrote: > Solomon Peachy writes: > > > Even putting that aside, for the past several years CSM/BIOS has > > been > > slowly bitrotting due to a lack of real testing, as the last few > > Windows > > releases have mandated use of UEFI for preinstalled systems, plus > > the > > EOLing of Windows 7 and (especially) XP. > > That's only because it's Microsoft. Note that, even though Microsoft is pushing for UEFI on new systems in the OEM version of Windows, they still support booting in legacy BIOS mode in the latest Windows 10 version and they even support a 32-bit version of Windows 10, which Fedora no longer does, so you can install and run it on even older hardware than Fedora. Even the latest May 2020 update of Windows 10 has a 32-bit retail version that is directly downloadable from their website: https://www.microsoft.com/en-us/software-download/windows10ISO The only Windows that no longer supports 32-bit systems is Windows Server. So the obsolescence of Windows 7 and XP is irrelevant. I'm by no means a Microsoft fan, but these are facts. Fedora is pushing for hardware obsolescence faster than Microsoft in this regard. :( To be completely fair, I must say that Fedora runs on first generation AMD64 hardware, while the 64-bit version of Windows no longer does, but the 32-bit Windows 10 still works on them, and on even earlier CPUs that are 32-bit only, which Fedora no longer supports. 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
Re: The future of legacy BIOS support in Fedora.
On Wed, 2020-07-01 at 16:32 +, Jóhann B. Guðmundsson wrote:
> On 1.7.2020 16:10, Solomon Peachy wrote:
> > On Wed, Jul 01, 2020 at 05:19:01PM +0200, Roberto Ragusa wrote:
> > > I'm currently using BIOS, grub, grub2 basically everywhere, even
> > > on
> > > fresh new machines,
> > This won't be the case for much longer; Intel will finally drop CSM
> > ("BIOS") support this year.
> >
> > Even putting that aside, for the past several years CSM/BIOS has
> > been
> > slowly bitrotting due to a lack of real testing, as the last few
> > Windows
> > releases have mandated use of UEFI for preinstalled systems, plus
> > the
> > EOLing of Windows 7 and (especially) XP.
>
> AMD is "strongly" recommending UEFI for the windows [1]
>
> So Apple dropped CSM in 2006
And Apple makes what percentage of the computers, used by Fedora users?
:)
>
> Intel in 2020
Which will only apply to new computers. Existing installs from 2017-
2019 will need to be supported for a long time. Like I said in a
different email, top tier PC manufacturers such as Dell and HP have
been selling PCs without Windows, configured in legacy mode by default
and that's probably what most people, who purchased them, use.
>
> AMD is against it's use
Only a recommendation, they aren't mandating it. What matters is what
PC manufacturers will actually ship. AMD doesn't have much control over
that, compared to Intel. But I suspect PC manufacturers will follow
Intel and move to UEFI only as well. But, once again, this is for new
systems. Systems, purchased in 2017-2019 aren't "legacy" and you can't
force people to reinstall their operating systems or risk losing their
data.
>
> Windows has moved on with the curve...
Only for new computers, sold with Windows preinstalled. Existing
Windows 10 installs are still supported. In fact, Fedora has dropped
i686 support before Windows. You can download the latest Windows 10 for
32-bit computers. They've only dropped 32-bit support for OEMs. But
anyhow 32-bit vs 64-bit is a whole different story, this is about the
bootloader.
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
Re: The future of legacy BIOS support in Fedora.
On Wed, 2020-07-01 at 16:30 +0200, Lennart Poettering wrote: > On Mi, 01.07.20 14:45, Hans de Goede (hdego...@redhat.com) wrote: > > > I'm not in the bootloader-team, but I do work very closely with > > them, > > so I have only one question: who is going to pick up the extra > > maintenance load this is going to cause ? > > There are distros already using it. And so far we have been pretty OK > with supporting it upstream and downstream. At least upstream I am > not > aware of any big issues left open. > > Note that sd-boot is a lot simpler than grub, i.e. it doesn't contain > Turing complete programming languages, module loaders, file system > drivers, storage stacks and such. There's simply not that much to > maintain! > > > Also note that this entails a lot more work then just maintaining > > sd-boot, > > anaconda will need to be adjusted, kernel-install scripts will need > > to > > be adjusted, etc. > > kernel-install itself is actually maintained in the same repo as > sd-boot: systemd upstream. They are developed along the same lines > already. > > > Also I wonder, if you are not proposing to completely drop grub2 on > > x86_64 what does offering sd-boot in addition to grub2 actually > > offer as advantages? > > Primarily simplicity, and that it implements the boot loader spec > correctly. > > it automatically discovers windows and Macos installations at each > boot, without any userspace involvement. You can talk to it very > nicely, i.e. implement trivially "boot-into-windows" buttons and such > in GNOME and so on. It makes things very robust, since you don't need > a script that generates a script that generates a script (yeah, > that's > how grub is hooked up). it just works on its own. You drop in boot > menu items, and that's it. You don't need to regenerate stuff, and > you > never have to run an interpretor for a turing complete language. > > By using sd-boot, you can do stuff like "systemctl reboot > --boot-loader-entry=windows", you can do "systemctl reboot > --boot-loader-menu=0", you can do "systemctl kexec" and it boots the > right thing, and so on. > > It also implements boot time assessement that is simple and just > works > (i.e. automatic revert to previous boot menu choice when the one > selected doesn't work). > > Oh, and it as support for seeding the Linux random seed pre-boot > already, in a safe and simple fashion. > > Moreover, it communicates which ESP is used to the host OS, so that > the host can automatically discover what other partitions to mount. > > And the list goes on and on and on. > > All these features are very simple individually, but put together > they > are just a much nicer and expose a much more integrated behaviour > than Grub ever did. > > > sd-boot is simpler and a bit tighter integrated with systemd, which > > would > > mean it is less work to maintain if we use it instead of grub, but > > if we > > use it next to grub then all those advantages fall away. IOW if we > > use > > it next to grub then all I see is a whole lot of extra work, with > > very > > little gain. > > Well, you appear to believe in the race to the bottom, i.e. that the > lowest common denominator should be where the future is. I am pretty > sure it's the wrong approach: pick the simple contender that can do > all the nice things, and has the nice integration, and use it as a > blueprint for the other archs where Grub is still needed, and make > them catch up. > > I mean, I understand you are interested in exotic platforms that lack > modern things like UEFI, but it kinda sucks to hold the boot loader > hostage due to that, and just stick to the terrible ways of > yesteryear > because of it. Note that this is not only about exotic platforms. I can give you examples with: 1. My 2019 HP laptop with an AMD Ryzen CPU. Purchased without Windows, so it came with FreeDOS preinstalled. Obviously, FreeDOS only runs in legacy mode. I just booted from an USB flash drive and installed Fedora on it, without changing the BIOS settings. 2. A 2017 Dell laptop, purchased also without Windows. Came with Ubuntu preinstalled, also in legacy mode. I installed Fedora on it, also without changing the BIOS settings. It's not unrealistic to expect that a lot of people would buy laptops such as these, if they specifically want to run Linux. And it's not unrealistic to expect many users to just install Fedora without changing any BIOS settings, related to legacy vs UEFI boot mode. In fact, most users wouldn't probably know anything about these settings. Both of these computers are very far away from being considered legacy or exotic. They can be switched to UEFI mode, but that requires repartitioning and an OS reinstall (and that gets very complicated when you consider multiboot scenarios with Windows 10 as well). Upgrading these systems without reinstall is possible, but *very* difficult and can't be automated, because, even if in the single OS scenario, it requires the user to change the
Re: The future of legacy BIOS support in Fedora.
On Tue, 2020-06-30 at 21:55 +, Jóhann B. Guðmundsson wrote: > On 30.6.2020 21:14, nick...@gmail.com wrote: > > On Tue, 2020-06-30 at 20:32 +, Jóhann B. Guðmundsson wrote: > > > Grub discourages users who have tried sd-boot from > > > coming/returning > > > to > > > Fedora [1]. > > > > > > Bottom line I think this will be a good move for the distribution > > > and > > > a > > > good time to start looking into and make that move. > > > > > > JBG > > > > > > 1. https://www.reddit.com/r/Fedora/comments/c0f3z5/systemdboot/ > > I read the whole reddit link, but I couldn't understand what's > > wrong > > with grub. The poster admits to having an obsession with keeping > > the > > number of packages to a minimum (I don't know what that has to do > > with > > grub), and doesn't like grub for some unexplained reason. Note that > > I > > have never used sd-boot. So far, I've used LILO (starting with Red > > Hat > > Linux 5.0), grub1 and grub2. These days, I don't even notice the > > boot > > loader. This means it's doing its job properly. :) > > > > Maybe I should try sd-boot in a UEFI VM and see for myself, but can > > someone explain what's the difference? > > > > I have one system where I run Fedora Server in UEFI mode and I > > haven't > > ever had the need to mess with the bootloader. It just shows its > > menu > > for 5 seconds and that's all that it does. I don't understand how > > can > > something like that discourage a user from using Fedora? :) > > Given that you have not changed an entry in your boot loader for > quite > sometime or perhaps ever it would actually be better that you > yourself > setup Fedora using sd-boot as the boot manager and compare changing > an > configuration entry in sd-boot with doing the exact same thing in > Grub2 > and share your feedback and experience of doing so with the rest of > the > community rather then someone provide you with an answer. I would try it, but I don't know how, since Fedora uses GRUB2. Should I install ArchLinux in a VM or is there a way to try it with Fedora? Is there any documentation for how to install it and how to use 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
Re: The future of legacy BIOS support in Fedora.
On Tue, 2020-06-30 at 20:32 +, Jóhann B. Guðmundsson wrote: > > > Grub discourages users who have tried sd-boot from coming/returning > to > Fedora [1]. > > Bottom line I think this will be a good move for the distribution and > a > good time to start looking into and make that move. > > JBG > > 1. https://www.reddit.com/r/Fedora/comments/c0f3z5/systemdboot/ I read the whole reddit link, but I couldn't understand what's wrong with grub. The poster admits to having an obsession with keeping the number of packages to a minimum (I don't know what that has to do with grub), and doesn't like grub for some unexplained reason. Note that I have never used sd-boot. So far, I've used LILO (starting with Red Hat Linux 5.0), grub1 and grub2. These days, I don't even notice the boot loader. This means it's doing its job properly. :) Maybe I should try sd-boot in a UEFI VM and see for myself, but can someone explain what's the difference? I have one system where I run Fedora Server in UEFI mode and I haven't ever had the need to mess with the bootloader. It just shows its menu for 5 seconds and that's all that it does. I don't understand how can something like that discourage a user from using Fedora? :) 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
Re: The future of legacy BIOS support in Fedora.
On Tue, 2020-06-30 at 13:34 +, Jóhann B. Guðmundsson wrote: > Given Hans proposal [1] introduced systemd/grub2/Gnome upstream > changes > it beg the question if now would not be the time to stop supporting > booting in legacy bios mode and move to uefi only supported boot > which > has been available on any common intel based x86 platform since > atleast > 2005. > > Now in 2017 Intel's technical marketing engineer Brian Richardson > revealed in a presentation that the company will require UEFI Class > 3 > and above as in it would remove legacy BIOS support from its client > and > datacenter platforms by 2020 and one might expect AMD to follow Intel > in > this regard. > > So Intel platforms produced this year presumably will be unable > to run > 32-bit operating systems, unable to use related software (at least > natively), and unable to use older hardware, such as RAID HBAs (and > therefore older hard drives that are connected to those HBAs), > network > cards, and even graphics cards that lack UEFI-compatible vBIOS > (launched > before 2012 – 2013) etc. > > This post is just to gather feed back why Fedora should still > continue > to support legacy BIOS boot as opposed to stop supporting it and > potentially drop grub2 and use sd-boot instead. > > Share your thoughts and comments on how such move might affect you > so > feedback can be collected for the future on why such a change might > be > bad, how it might affect the distribution and scope of such change > can > be determined for potential system wide proposal. Reason 1: I don't see a reason for supporting the planned obsolescence that hardware companies try to push on users. Reason 2: I bought my latest laptop in the end of 2019. It's an HP laptop with a Ryzen quad-core CPU. Yes, it has UEFI, but I bought it without Windows, so it came preinstalled with FreeDOS, which runs in legacy mode only. I installed Fedora on it, without switching to UEFI mode. I believe many users who buy laptops without Windows would be using Linux in legacy boot mode, just because it's the only way to boot FreeDOS, and companies such as HP only offer you the option of having Windows or FreeDOS preinstalled. Overall, it is pain and breakage for a portion of the users, while I don't see a particularly strong benefit - testing and maintaining legacy BIOS boot support should be easy, because every VM out there supports it, and it's even the default for most of them. In fact, I've never tried UEFI in a VM, and I have no idea how stable it is. But even if it's stable, I wouldn't want to have to migrate them to UEFI, because that would require repartitioning, which could cause loss of data in case something goes wrong, which leads us to reason 3: Reason 3: Migration path to UEFI boot mode is difficult even for modern systems, that were installed in legacy mode. It requires tinkering with the BIOS settings, which is non-standard and therefore different for every computer, and also repartitioning and reinstall of all operating systems on the computer. Even if this is automated, there are many dangerous scenarios that can cause loss of data. Think about multiboot scenarios, for example, where a user is multibooting Windows 10 and Fedora. We simply can't handle the upgrade in this case, without destroying the Windows 10 installation, even if we are able to upgrade a Fedora only install (and even that is dangerous). 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
