On Tue, Feb 24, 2015 at 8:51 AM, Ralf Corsepius <rc040203@xxxxxxxxxx> wrote: > E.g. Some (all?) BIOSes aren't able to boot from non-primary partitions. I'm pretty sure it's a non-factor if GRUB is used because GRUB boot.img (formerly stage1) in the first 440 bytes is just jump code to core.img. It doesn't depend on partitions or the setting of the active flag at all. The limitation might be how big an LBA value it can jump to however, but AFAIK any BIOS in the last ~5 years has 64bit LBA support, while drives are still only 48-bit. I'd think it's quite an old computer for firmware to have less than 48-bit LBA support. For extlinux, yes this is probably an issue because it uses a handful of generic code sets for LBA0's first 440 bytes, which depend on the active flag being set on a primary partition. > With a preinstalled WinXP often having occupied 3 primary partitions (BOOT, > WIN, RECOVER), Installing more than one Linux, required you to install a > linux boot partition as the 4th primary partition. I haven't seen this because in such a case GRUB's ~440 bytes boot.img replaces the Windows code in LBA 0, which instructs a jump to core.img which typically starts at LBA1 (the start of the MBR gap). Once core.img is loaded, GRUB can now read a partition table and filesystem directly, and can find its modules even on an extended partition (even inside LVM, or LVM on RAID even if it's degraded - it's really kinda amazing). > Similar restriction apply elsewhere. E.g. I have an older BIOS system which > for (at least to me) unknown reasons refuses to boot from chained/cascaded > grub partitions beyond some disk-limits. Quite old, either 28-bit LBA limit, or maybe BIOS that still only groks CHS. This is probably in the realm of the crusty INT 13H stuff. > In more complex multiboot configurations (e.g. several different linux > distros, several releases of the same distro, several different > configurations of the same distro), other aspects come into play, which more > or less are personal preference, such as keeping an OSs' partitions > consecutively together, whether to share or not to share boot or swap > partitions etc. Right and this cannot possibly be supported by Fedora absent an agreed upon boot specification. There are attempts, but even our own GRUB patches in the form of bls.mod to implement the freedesktop.org bootloaderspec, does not exactly conform to the spec and ends up having various problems. So we don't interoperate very well with ourselves, we don't interoperate within either of the two bootloader spec variants, we don't have multiple distro support. And GRUB upstream doesn't really seem to care that much about the problem either or it would be entirely solved there. Even if all of that were surmounted, and we had a ratified spec and everyone said they'd conform, we'd still have the reality of doing the implementation work, which is non-trivial and involves more than just GRUB. So... this knowledge acts as an scary inhibitor to even going down the road of settling on a spec, I think. > > Experience tells, any sharing, such as sharing grub or swap partitions, will > fail in longer terms - Unfortunately, some distros' installers by default do > so and automatically try to reuse such partitions (IIRC, anaconda still does > so, till today) > >> So really, if this stuff bothers you, sit down, come up with a rational >> justification for the feature you want, and send it in. Most >> developers in this space do listen, but the normal rules of polite human >> interaction and rational discourse do apply. "Because that's that I >> want" isn't a good way to ask for someone else's time. > > But the converse applies: "A tool which doesn't suffice my needs, will not > be my choice and will loose me as a customer" Yes, but it's a 60+ email thread and the people complaining about Anaconda Manual Partitioning, especially the "custom isn't custom" claim, haven't produced any examples or bugs of what they want to do that the installer won't allow. -- Chris Murphy -- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
