[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Support for mirroring of EFI System Partition


On 2015-09-19, Francesco Poli wrote:
> On Sat, 19 Sep 2015 19:34:14 +0200 Stefan Lippers-Hollmann wrote:
> > On 2015-09-19, Francesco Poli wrote:
> So the user would have to pin grub to its currently installed version
> or completely refrain from upgrading the system, until the dead drive
> gets replaced...
> Frankly speaking, I don't like to inflict this on users, let alone
> putting big warnings that say "do *not* upgrade grub, unless your RAID
> array is completely working!". It looks very fragile: a system waiting
> for a good opportunity to break, just because the user forgot to do
> something and went on with the usual upgrades.

You're right.
...but it's still not a good idea to mess around too much with a degraded
array, it just significantly increases the risks.

> I still fail to see where's the problem with mounting multiple ESPs on
> multiple /boot/efi* mount points: it seems to me that we would have
> (almost) nothing to lose and everything to gain.

There is no problem at all with /mounting/ multiple ESPs anywhere, but 
given a properly braindead mainboard UEFI implementation, your mainboard
might have a problem if it sees more than one single ESP connected to
your system...

Similar issue, take Sony Vaio Duo 11 (SVD1121P2EB) notebook. 
It's (was? it's not mine, so I don't know for sure) shipping with Windows 
8.0 in UEFI and secure boot mode, so UEFI works. You can nuke the existing
Windows installation and install linux from scratch (with secure boot 
disabled), but it won't boot...

Why, because Sony in all its wisdom made its firmware forget UEFI boot 
entries during (re-)boot cycles...

You can configure whatever you want via efibootmgr, it takes the settings
well, everything seems to be fine, but once your reboot, it has forgotten

The only option to boot (in UEFI mode) at all, is using the removable
media path (/EFI/BOOT/BOOTX64.EFI), which windows typically claims for
itself (that's why it's never been noticed in Sony's testing, with 
windows) - grub2 only (optionally) allows installing itself there since
very shortly before jessie's release.

Forgetting UEFI boot entries/ orders like this is a very explicit 
violation of the UEFI specification, but it's still shipping in quantities
of multiple thousands and left unfixed. So the more you diverge not just
from the UEFI specification, but also from the exact kind of usage the
current windows version of the day chooses to employ, the more you'll get
in unchartered territory. And you will encounter blatant firmware bugs,
with no chance to get them fixed, ever[1] - after all, it works with their
default windows image. 

That's why trying to get too smart is usually a bad idea in this domain,
it might work perfectly under ovmf and on your system - but break in 
horrible ways for others.

	Stefan Lippers-Hollmann

[1]	and I'm not even starting with the bug that hard-bricked your
	Samsung notebook mainboard, if your UEFI variable storage 
	(pstore) ever got more than half full.

Attachment: pgpn_Cy_TGcTb.pgp
Description: Digitale Signatur von OpenPGP

Reply to: