81–90 of 233 posts
Earlier quoted context omitted.
"Full of faeces from cows" is and remains vulgar no matter how it's spelled.
There's nothing "vulgar" whatsoever about cow dung. It is an eco-friendly, renewable material and commonly used for many sacred rituals in India.
Earlier quoted context omitted.
Actually I do not understand which is the problem of Fedora in this case. The distribution needs to do almost nothing to support either EFI or the legacy BIOS or any other booting method. That is the job of a bootloader package, not of the Linux distribution. For example I am using syslinux as the bootloader for all my computers, while grub is another example of a frequently used bootloader (but which seems to be exc…
1. They no longer need to package bios bootloaders 2. They no longer need to support bios booting in the forums - no asking "how do you boot this? Bios, EFI? Have you tried the other?", no telling people "EFI is required for feature X" 3. They no longer need to maintain the bios boot documentation 4. They no longer need to maintain the bios path in the installer/boot media 5. They no longer need to test the bios path…
Grub 2 is complex to configure, but there are other bootloaders that are much easier to configure, e.g. syslinux.
Restricting the boot method to EFI does not reduce the need for documentation in any way.
The user must still be instructed to enter the BIOS setup and verify whether their computer is not configured to boot in legacy mode, which would prevent booting. Also the user must be instructed to enter the BIOS setup even if the EFI mode is used, because the installation media might not boot anyway, because a wrong boot order is configured for EFI booting, and it must be changed.
The most complex part of the installation is not the booting, but identifying the device where Fedora should be installed, which might be needed to be reformatted and repartitioned.
So a lot of documentation is needed in any case, for novice users.
Removing the booting in legacy mode increases the chances that the installation media will not boot without the user having to modify the BIOS setup, so it increases the chances of the user having to search support in the forums.
UEFI emulation is a thing. For people with legacy-only firmware systems, you too can run UEFI on lazy cloud providers and legacy hardware. I do this on my 14 year old dell laptop just so that all my x86_64 systems have the same boot efistub linux kernel images. All you need is to use one of the EDK DUET bootloader builds such as BootDuet¹, or for an easier user experience CloverBootloader². Only complaint is securebo…
In my Windows 10 setup, Bitlocker refuses to boot without a recovery key when I don't use GRUB to load Windows; presumably, Windows recorded the system state when I enabled Bitlocker, which was booted via Grub. In similar fashion I expect Windows 11 to actually work just fine on systems with a TPM as long as Grub is used every time.
20 of the poster's last 30 submissions have been LWN subscriber links.
I wish people would stop sharing LWN subscriber links for karma. They're not meant to be shared in social news websites. https://lwn.net/op/FAQ.lwn#slinks 20 of the poster's last 30 submissions have been LWN subscriber links.
From your link:
"Where is it appropriate to post a subscriber link?
Almost anywhere. Private mail, messages to project mailing lists, and blog entries are all appropriate. As long as people do not use subscriber links as a way to defeat our attempts to gain subscribers, we are happy to see them shared."
Earlier quoted context omitted.
1. They no longer need to package bios bootloaders 2. They no longer need to support bios booting in the forums - no asking "how do you boot this? Bios, EFI? Have you tried the other?", no telling people "EFI is required for feature X" 3. They no longer need to maintain the bios boot documentation 4. They no longer need to maintain the bios path in the installer/boot media 5. They no longer need to test the bios path…
I agree that restricting the boot method to EFI would reduce the testing time. Grub 2 is complex to configure, but there are other bootloaders that are much easier to configure, e.g. syslinux. Restricting the boot method to EFI does not reduce the need for documentation in any way. The user must still be instructed to enter the BIOS setup and verify whether their computer is not configured to boot in legacy mode, whi…
~~Yes but syslinux is bios-only. So if you have to support EFI too (and you do because there's EFI-only hardware), you now either need to support syslinux and an EFI bootloader, or a bootloader that supports both like Grub 2.~~
Edit: The article seems to suggest that syslinux can be removed if bios boot is no longer supported. I read that as it being bios-only, but it seems to support EFI?
>Restricting the boot method to EFI does not reduce the need for documentation in any way.
You still need documentation, yes. But you no longer need any documentation for booting with BIOS.
You no longer need to say "X is only supported in EFI, if you boot via BIOS you need to do Y" or anything like that, and keep those parts updated.
The part of the docs that says "To boot EFI, do X. To boot BIOS, do Y" can be cut down to "To boot Fedora, ensure X".
That is a reduction in the amount of documentation.
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 doesn…
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.
Earlier quoted context omitted.
I agree that restricting the boot method to EFI would reduce the testing time. Grub 2 is complex to configure, but there are other bootloaders that are much easier to configure, e.g. syslinux. Restricting the boot method to EFI does not reduce the need for documentation in any way. The user must still be instructed to enter the BIOS setup and verify whether their computer is not configured to boot in legacy mode, whi…
>Grub 2 is complex to configure, but there are other bootloaders that are much easier to configure, e.g. syslinux. ~~Yes but syslinux is bios-only. So if you have to support EFI too (and you do because there's EFI-only hardware), you now either need to support syslinux and an EFI bootloader , or a bootloader that supports both like Grub 2.~~ Edit: The article seems to suggest that syslinux can be removed if bios boot…
Earlier quoted context omitted.
- previously, x86 MBR-style partition tables (which were the only thing really supported in Linux) gave you no strong semantic information about what a partition was[1]. GPT may involve GUIDs, but in the grand scheme of things that's a small part of the cost of mounting stuff. - FAT is old, and FAT is well-supported by basically anything, and what features do you want in the partition that contains your bootloader th…
> what features do you want in the partition that contains your bootloader that FAT doesn't support? Well, I'd love to be able to drop a bunch of 8GB (notably FAT doesn't support files this big) LiveDVD disk images on a bare file system and see them in the computer's built-in boot-menu immediately. I already enjoy the fact I don't need a traditional boot loader (like GRUB) to handle multi-OS as I can have 2 independe…
Different systems have different constraints. For example, loading the firmware interface on my systems so it can present a boot menu is way, way slower than rEFInd or Grub. And presents an ugly menu in a non-native resolution for my monitors. And doesn't let me override kernel parameters adhocly at boot time if needed (thought it has been a number of years since I have, I'm reluctant to let go of the option).
Earlier quoted context omitted.
- previously, x86 MBR-style partition tables (which were the only thing really supported in Linux) gave you no strong semantic information about what a partition was[1]. GPT may involve GUIDs, but in the grand scheme of things that's a small part of the cost of mounting stuff. - FAT is old, and FAT is well-supported by basically anything, and what features do you want in the partition that contains your bootloader th…
> previously, x86 MBR-style partition tables (which were the only thing really supported in Linux) gave you no strong semantic information about what a partition was[1] LVM appears to solve this issue as well as the related issue of only supporting a limited number of partitions in BIOS.
The only snag is swap, which I don't believe can be on a subvolume.
vgchange is a struggle for me, from the first time I saw it in HP-UX.