Date: Tue, 5 Apr 2016 23:44:05 +0100 From: Steven Hartland <killing@multiplay.co.uk> To: Warren Block <wblock@wonkity.com> Cc: freebsd-stable@freebsd.org Subject: Re: A gpart(8) mystery on 10.3-RELEASE Message-ID: <57043FB5.7020505@multiplay.co.uk> In-Reply-To: <alpine.BSF.2.20.1604051600250.57361@wonkity.com> References: <alpine.BSF.2.20.1604051125030.14591@mail.fig.ol.no> <5703B0D5.5060701@passap.ru> <alpine.BSF.2.20.1604051335141.57361@wonkity.com> <57042EE2.9030304@multiplay.co.uk> <alpine.BSF.2.20.1604051600250.57361@wonkity.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 05/04/2016 23:09, Warren Block wrote:
> On Tue, 5 Apr 2016, Steven Hartland wrote:
>> On 05/04/2016 20:48, Warren Block wrote:
>
>>> Actually, the more I think about it, using bootcode -p to write the
>>> entire EFI partition seems dangerous. Unless it is surprisingly
>>> smart, it will wipe out any existing stuff on that EFI partition,
>>> which could be any number of important things put there by other
>>> utilities or operating systems, including device drivers.
>>>
>>> The safer way is to mount that partition and copy the boot1.efi file
>>> to it.
>
>> Pretty sure that's not done as you cant guarantee fat support is
>> available.
>
> In the kernel, you mean? True. But odds are good that someone with a
> custom kernel without msdosfs will understand the implications of
> overwriting the EFI partition.
>
> And of course it is safe to create an EFI partition, it would only be
> a problem if one already existed with some extra files on it.
Yes, we remove msdosfs here and it would be PITA to have to add it back
in just to support writing EFI boot fs.
So personally I much prefer the current method. For those that want to
play with the EFI partition then they can do the manual update step
instead easily enough.
Regards
Steve
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?57043FB5.7020505>