Hi 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 everything. 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. Regards 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