svn commit: r296428 - head/sys/boot/common

Nikolai Lifanov lifanov at mail.lifanov.com
Sun Mar 6 23:44:22 UTC 2016


On March 6, 2016 4:13:34 PM EST, Dimitry Andric <dim at FreeBSD.org> wrote:
>On 06 Mar 2016, at 20:57, Nikolai Lifanov <lifanov at mail.lifanov.com>
>wrote:
>> 
>> On 2016-03-06 11:17, Dimitry Andric wrote:
>>> On 06 Mar 2016, at 17:00, Oliver Pinter
><oliver.pinter at hardenedbsd.org> wrote:
>>>> On 3/6/16, Dimitry Andric <dim at freebsd.org> wrote:
>>>>> Author: dim
>>>>> Date: Sun Mar  6 15:57:43 2016
>>>>> New Revision: 296428
>>>>> URL: https://svnweb.freebsd.org/changeset/base/296428
>>>>> Log:
>>>>> Since kernel modules can now contain sections of type
>SHT_AMD64_UNWIND,
>>>>> the boot loader should not skip over these anymore while loading
>images.
>>>>> Otherwise the kernel can still panic when it doesn't find the
>.eh_frame
>>>>> section belonging to the .rela.eh_frame section.
>>>>> Unfortunately this will require installing boot loaders from
>sys/boot
>>>>> before attempting to boot with a new kernel.
>>>> Could you please add a note about this to UPDATING file?
>>> I am a bit torn on this, because normally we always tell people to
>>> install the kernel first, reboot, then run make installworld (which
>also
>>> installs the boot loaders).
>>> However, in this case, people might depend on their boot loader
>loading
>>> modules which are required to make the system boot at all.  So if
>they
>>> happened to forget updating their boot loader first, a panic might
>be
>>> the result.
>>> I wonder what a failsafe and acceptable upgrade scenario is, in this
>>> case.  Normally the procedure is something like:
>>>  make buildworld
>>>  make buildkernel (with KERNCONF=whatever, if needed)
>>>  make installkernel (again with KERNCONF, if needed)
>>>  reboot (to single user, but cheating is possible usually)
>>>  mergemaster -p
>>>  make installworld
>>> This could maybe be modified to:
>>>  make buildworld
>>>  make buildkernel (with KERNCONF=whatever, if needed)
>>>  make installkernel (again with KERNCONF, if needed)
>>>  make -C sys/boot install
>>>  reboot (to single user, but cheating is possible usually)
>>>  mergemaster -p
>>>  make installworld
>>> E.g. insert the step which installs the boot loaders just after (or
>>> before) the step which installs the kernel.
>>> Is something like this acceptable as a one-time workaround, or maybe
>it
>>> is better in general, in case we ever add other new features to the
>boot
>>> loaders?
>>> -Dimitry
>> 
>> In my opinion, boot *blocks* (boot1) should be updated seldomly and
>not on every install.
>> All (?) instances of not updating these resulting in a failed boot
>have an UPDATING
>> entry or a similar warning (like the one during "zpool upgrade").
>
>Well, each time you run make installworld, almost all the files in
>/boot
>(except for configuration) get reinstalled.  For e.g. mbr, boot1 and
>such, this has no consequences at all, until you install them into some
>partition using gpart, but changes to loader, loader.efi or zfsloader
>*will* affect the next startup.
>
>Per a suggestion from Kostik, maybe it would be nice to have a separate
>"make installboot" target, which installs just the components in /boot.
>This could then be used before or after "make installkernel".
>
>-Dimitry

The bootcode gets installed to boot, but deployed with gpart, cp, sliced in half and dd, etc. And that's to one or more partitions.
I don't think that a separate install target that just stages boot1 to /boot is valuable.


- Nikolai Lifanov


More information about the svn-src-head mailing list