5 ms·

while fedora defenetly is not my cup of tea, first thing i do when i get a new system(desktop or laptop) is disable legacy bios/CSM whatever it is labeled as. T

by bigpod 4y ago

while fedora defenetly is not my cup of tea, first thing i do when i get a new system(desktop or laptop) is disable legacy bios/CSM whatever it is labeled as. This is to prevent mirriad of issus BIOS brings including its horrible MBR. GPT is million times better and for someone who dual boots on many machines (and has a drive with 14 different operating systems as a test) to all you legacy BIOS and MBR fans MBR doesnt cut it and is cause of many headaches if you dual boot. Remember how some people have had issues with windows destroying booting of linux that is due to MBR being a useless piece of antiquated software and breaking. It wasnt windows's fault its just that its update utility had to overwrite a part of MBR and since MBR was already basically a house of cards all you had to do to break it is have a little mishap and your linux boot is gone (it was same on other side just less people were crying about it because well they blamed windows for breaking itself)

morganvachon 4y ago
This is fine for you and your use case, but some of us (as pointed out in the article) are forced to stay with BIOS either due to owning legacy hardware that is still fully functional and even necessary, or because we use VMs and/or hosted services that require BIOS and don't support UEFI, or both. I'm one of those; I use a few legacy machines locally and I have VPS instances hosted with Vultr. Granted, I don't use Fedora so this doesn't directly affect me yet, but the Linux community has a history of too-early adoption of ideas started at Fedora (systemd, pulseaudio) that take years to reach production-ready status, if ever. At some point those of us who still use legacy hardware at home/work will be forced to either throw out perfectly good machines, or switch to a holdout distro like Slackware or Void (not that there's anything wrong with either of those) and lose valuable time moving our workflow. We'll also be at the mercy of our hosting providers as they decide whether to overhaul their entire hosting backend, or else drop Fedora and any other distro that follows their lead. I get that UEFI is the future of bootstrapping, but it's too early to pull the plug on BIOS.
- TZubiri 4y ago
  At this point we should have learned the lesson from systemd, I think red hat now has a bad enough reputation that everything with their brand is an instant rejection, and any suggestion they throw is taken as a suggestion of what not to do. Red hat flatlined when it was acquired by IBM, a consequence of a free as in free beer model to software.
TZubiri 4y ago
This is the incorrect take on the subject. Dual booting is a feature used by less than one in ten thousand users. Obsoleting BIOS will obsolete millions of hardware pieces.
- AreYouSirius 4y ago
chasil 4y ago
Recovering mbr boot corruption on CentOS is relatively easy. Boot from the install media in rescue mode, chroot into /mnt/sysimage, then grub2-install onto /dev/sda. I've never had to do this outside of the redhat realm, but the procedure is not complex after a few rounds to commit it to memory.
- AreYouSirius 4y ago
viraptor 4y ago
I agree in general, but not with this: "It wasnt windows's fault its just that its update utility had to overwrite a part of MBR". If they cared, they could spend some time to design / document a nice way for systems to redirect to the next entry. They could've used grub and chainload. They could've invited others to collaborate. It was very much in MS interest not to care and I totally blame them for doing just that.
userbinator 4y ago
Ironically, the first thing I do is the opposite. BIOS boot has been simple and reliable for decades, and EFI remains a horrible mess. Remember how some people have had issues with windows destroying booting of linux The MBR is tiny (you could even write out all the entries on paper as a backup, like I became accustomed to many years ago whenever I partitioned a disk) --- and restoring it is also equally straightforward. I don't even know where to begin with troublshooting EFI's horribly overengineered boot entries and NVRAM variables...
tremon 4y ago
to all you legacy BIOS and MBR fans MBR doesnt cut it and is cause of many headaches if you dual boot. That's neither here nor there. You can still perform BIOS boots from a GPT-partitioned disk, in fact it works even better: while in MBR mode the stage1 grub loader must be placed in the unused 31kB between the partition table and the first partition start, GPT allows you to explicitly allocate a partition for the stage1 code. This means no more borkage because Windows overwrote an officially unused part of the disk, and the stage1 payload is no longer limited to 31kB. Point being, your rant has nothing to do with BIOS vs UEFI boot.
feikname 4y ago
> GPT is million times better Agreed. > It wasnt windows's fault its just that its update utility had to overwrite a part of MBR It was a reasonable assumption that whatever drive Windows' was installed on already had a working bootloader installed, otherwise it wouldn't have been able to boot itself to do Windows Update. Windows did NOT have to override it. This was not MBR fault. AFAIK Linux did NOT do the same thing as overriding, which is why it has separate `grub2-install` and `update-grub` commands. Once installed to a drive, `update-grub` will only change the simple config file it reads at boot. Perhaps both of them did override themselves when a bugfix or new feature was available, but I don't think Windows's bootloader changed much after any OS release. Now, GPT/UEFI is a million times better in that aspect because it can allow easily multiple different bootloaders that don't have to know of each other's existence. But I blame Windows in MBR case very much. Also, some though not all motherboards allow you booting from BOTH old-school MBR and newer GPT so you may not need to disable CSM and still eat your GPT cake. This may be useful if you e.g. have an old MBR drive with Linux and another GPT one with Windows.

by bigpod 4y ago

morganvachon 4y ago

This is fine for you and your use case, but some of us (as pointed out in the article) are forced to stay with BIOS either due to owning legacy hardware that is still fully functional and even necessary, or because we use VMs and/or hosted services that require BIOS and don't support UEFI, or both. I'm one of those; I use a few legacy machines locally and I have VPS instances hosted with Vultr. Granted, I don't use Fedora so this doesn't directly affect me yet, but the Linux community has a history of too-early adoption of ideas started at Fedora (systemd, pulseaudio) that take years to reach production-ready status, if ever. At some point those of us who still use legacy hardware at home/work will be forced to either throw out perfectly good machines, or switch to a holdout distro like Slackware or Void (not that there's anything wrong with either of those) and lose valuable time moving our workflow. We'll also be at the mercy of our hosting providers as they decide whether to overhaul their entire hosting backend, or else drop Fedora and any other distro that follows their lead. I get that UEFI is the future of bootstrapping, but it's too early to pull the plug on BIOS.

TZubiri 4y ago
At this point we should have learned the lesson from systemd, I think red hat now has a bad enough reputation that everything with their brand is an instant rejection, and any suggestion they throw is taken as a suggestion of what not to do. Red hat flatlined when it was acquired by IBM, a consequence of a free as in free beer model to software.

TZubiri 4y ago

This is the incorrect take on the subject. Dual booting is a feature used by less than one in ten thousand users. Obsoleting BIOS will obsolete millions of hardware pieces.

AreYouSirius 4y ago

chasil 4y ago

Recovering mbr boot corruption on CentOS is relatively easy. Boot from the install media in rescue mode, chroot into /mnt/sysimage, then grub2-install onto /dev/sda. I've never had to do this outside of the redhat realm, but the procedure is not complex after a few rounds to commit it to memory.

AreYouSirius 4y ago

viraptor 4y ago

I agree in general, but not with this: "It wasnt windows's fault its just that its update utility had to overwrite a part of MBR". If they cared, they could spend some time to design / document a nice way for systems to redirect to the next entry. They could've used grub and chainload. They could've invited others to collaborate. It was very much in MS interest not to care and I totally blame them for doing just that.

userbinator 4y ago

Ironically, the first thing I do is the opposite. BIOS boot has been simple and reliable for decades, and EFI remains a horrible mess. Remember how some people have had issues with windows destroying booting of linux The MBR is tiny (you could even write out all the entries on paper as a backup, like I became accustomed to many years ago whenever I partitioned a disk) --- and restoring it is also equally straightforward. I don't even know where to begin with troublshooting EFI's horribly overengineered boot entries and NVRAM variables...

tremon 4y ago

to all you legacy BIOS and MBR fans MBR doesnt cut it and is cause of many headaches if you dual boot. That's neither here nor there. You can still perform BIOS boots from a GPT-partitioned disk, in fact it works even better: while in MBR mode the stage1 grub loader must be placed in the unused 31kB between the partition table and the first partition start, GPT allows you to explicitly allocate a partition for the stage1 code. This means no more borkage because Windows overwrote an officially unused part of the disk, and the stage1 payload is no longer limited to 31kB. Point being, your rant has nothing to do with BIOS vs UEFI boot.

feikname 4y ago

> GPT is million times better Agreed. > It wasnt windows's fault its just that its update utility had to overwrite a part of MBR It was a reasonable assumption that whatever drive Windows' was installed on already had a working bootloader installed, otherwise it wouldn't have been able to boot itself to do Windows Update. Windows did NOT have to override it. This was not MBR fault. AFAIK Linux did NOT do the same thing as overriding, which is why it has separate `grub2-install` and `update-grub` commands. Once installed to a drive, `update-grub` will only change the simple config file it reads at boot. Perhaps both of them did override themselves when a bugfix or new feature was available, but I don't think Windows's bootloader changed much after any OS release. Now, GPT/UEFI is a million times better in that aspect because it can allow easily multiple different bootloaders that don't have to know of each other's existence. But I blame Windows in MBR case very much. Also, some though not all motherboards allow you booting from BOTH old-school MBR and newer GPT so you may not need to disable CSM and still eat your GPT cake. This may be useful if you e.g. have an old MBR drive with Linux and another GPT one with Windows.