arealvel wrote:5. Start installation creating Linux partitions as you like (for ex: boot partition [ext2, 300MB], swap partition [6MB] root partition [ext4, free space you want GB]. Assign the booting device to the boot partition you have create (for me it was sda6). You can choose other ways to format with different filesystems and mount points.
What I learn here is that you're not allowed to allocate the boot partition nor to /boot/efi (because Windows use that mount point) neither to root (/) or to any other mount point you have chosen during partition process. Keeping this in mind assign some other mount point for the boot partition (I used /boot/efi/grub).
First, Linux partitions are generally referred to by their mount points; for instance the /home partition or the /boot partition. Note the leading "/", which denotes the start of an absolute Linux path. The main installation partition is mounted at "/", which is pronounced "root", so it's sometimes called the "root partition" -- but note the lack of a leading slash in "root" in this case. Another exception is the swap partition; swap space isn't mounted, so it's just called the "swap partition" (again, no leading slash). There are some other exceptions, like LVM partitions and non-Linux partitions. Among the latter, the EFI System Partition (ESP) is important and is generally referred to as such, but it will also have a Linux mount point -- typically /boot/efi. Unfortunately, the Mint installer uses a somewhat non-standard term for the ESP; IIRC, it calls it the "EFI boot partition." This is a deviation from standard terminology, and given the newness of all of this for many users, such deviations just cause more confusion.
Given all of this, your mounting a "boot partition" at /boot/efi/grub is peculiar at best. The usual configuration for an EFI system includes:
- A Linux root (/) partition
- An optional
- An ESP mounted at /boot/efi
- Additional partitions, as you see fit (/home, swap, and so on).
Mounting an ext2fs partition at /boot/efi/grub is unlikely to have any effect at all in a stock Mint installation, since Mint puts nothing in that directory. You might end up putting some GRUB files there if you install GRUB by hand, though. The result would likely be unbootable, since the files that would most likely reside in /boot/efi/grub would be EFI boot loader files that the EFI must be able to read, and the EFI can't read ext2fs without extra drivers.
mintybits wrote:The whole GPT/EFI support by linux seems to me to be a mess. So the last suggestion to avoid the issue by booting Mint from Windows using EasyBCD is attractive.
The trouble that many people have today is that new computers ship with Windows installed in EFI mode, and configuring a computer to boot one OS in EFI mode and another in BIOS mode is awkward -- most firmwares make it hard to switch boot modes at boot time.
mintybits wrote:My understanding is that GPT/BIOS installation works ok. Although Grub demands a special boot partition which is naff.
Actually, the BIOS Boot Partition for BIOS-mode booting on GPT is far from "naff." In a traditional BIOS/MBR setup, GRUB installs a chunk of code in officially unpartitioned space between the MBR (sector 0) and the start of the first partition. Because this space is officially unpartitioned, it can't be marked out as belonging to GRUB, and in fact some other tools will blindly try to use the same space. That
is naff; creating a partition for GRUB's code is the proper
way to do it!
mintybits wrote:EasyBCD sounds like a convenient alternative for GPT/EFI if you have Windows already installed. There is still a gotcha, tho. The Grub installer seems to be a mess too. It is not properly designed to work when installed to a partition because its location-critical files are not made immutable. It will work most of the time, perhaps always for some, but occasionally it will break and need reinstalling. I dont know whether Easy BCD now gets around this by using its own Grub kernel or not.
If that entire paragraph is meant to apply to EFI-mode booting, then you've got something wrong, or I'm misinterpreting something, because in the EFI scheme, there's no need to mark files as "immutable" (meaning that their locations on the disk cannot be changed); EFI-mode booting is done via file-level access. It's true that some boot loaders require some files to be immutable on BIOS-mode
installations, though. Even then, my understanding is that GRUB requires no immutable files when it uses a BIOS Boot Partition, since the contents of that partition include filesystem drivers with which GRUB reads files from the /boot/grub directory. The BIOS Boot Partition (or its equivalent unprotected code on MBR disks) can't be moved without re-installing GRUB; and if you lack a BIOS Boot Partition, certain files must be immutable. This is all relevant for BIOS-mode booting, though, not for EFI-mode booting.
mintybits wrote:The whole GPT/EFI support by linux seems to me to be a mess.
+1 to that greed pushing human tolerances to the Max!
It's not really greed, except perhaps to the extent that it's contributed to the real problem: Sloppy and variable implementations. The EFI spec is over 2,000 pages long, plus thousands more pages of documentation on system calls and whatnot. Despite this size, the spec leaves out a lot of critical details, and there are features that clearly weren't very well thought-out. (The phrase "designed by committee" comes to mind.) The reference EFI implementation (from which all production EFI implementations are derived) includes bugs, and firmware authors have introduced their own unique bugs. The firmware companies don't seem to have tested with Linux, at least not as a general rule, and by and large the Linux distribution developers have been insufficiently pro-active in developing EFI support. An added problem is the fact that computer manufacturers are installing Windows in ways that are somewhat inconsistent from one manufacturer to another -- they sometimes add their own ESP-like partitions or add their own manufacturer-specific boot loaders to the mix. A feature designed to help with the transition (the Compatibility Support Module, or CSM, which provides BIOS/legacy support) actually complicates matters because a program author can't really know ahead of time whether the computer will boot in BIOS/legacy mode or in EFI mode, or even which modes the computer supports. Distributions haven't been making the boot mode clear to users, and users don't understand the difference. Add Secure Boot to this and it gets even more complex.
Speaking as an author of an EFI tool (rEFInd
), this has all come together to create a mess of implementations that work inconsistently. I've been trying to disentangle this in rEFInd, but the current state of rEFInd and its installation script is admittedly imperfect. There's really nothing I can do about some problems, since they're caused by firmware bugs that can't be worked around. Other problems I have already worked around or plan to work around as best as I can in the future. Similar comments apply to GRUB and to Linux distributions generally.
This will settle down in time; however, some improvements will simply come as firmware bugs get squashed, leaving older systems out in the cold. (Manufacturers seem to lose interest in updating their firmware a few months after releasing the hardware.)
arealvel wrote:Perhaps a conclusion could be that with Windows installed in UEFI mode, you need the other OS also installed UEFI mode for dual-booting]
This is rule #1 for installing on EFI-capable computers. I've said as much many times in this and other forums.
Unfortunately, it's not always easy to do this -- as you've said, boot options are sometimes limited, depending on the media you're using and how they were prepared. Fortunately, it is possible to switch Linux from a BIOS-mode to an EFI-mode installation. In fact, it's fairly easy on a Linux-only computer. It gets harder with Windows (or any other OS) installed in EFI mode, though. I've provided a workaround in the latest rEFInd (0.6.3): The install.sh script will install rEFInd in a way that should
get rEFInd to launch when you next boot in EFI mode, and from there you should
be able to boot either Windows or Linux in EFI mode. That said, this feature has seen minimal testing; it could contain bugs.
arealvel wrote:PS: It occurs now to me that probably the problem was I was using a DVD reader a little dated. So this could be the reason I wasn't able to install from DVD in UEFI mode.
An old DVD drive shouldn't cause problems -- at least, not from a software perspective. (If the DVD drive couldn't read your disc because it was old, that's another matter, of course.) Whether you're using BIOS or EFI, DVD hardware is fairly standardized from a software perspective, and it just serves as a means to get bits from the CD or DVD into memory.