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

[Adrian Chadd]

Oh wow, i didn't know at all that limits broke booting in this way.
Sorry :( This is the first time I've heard about it.



-a


On 6 March 2016 at 16:38, Warner Losh <imp at bsdimp.com> wrote:
>
>
> On Sun, Mar 6, 2016 at 4:44 PM, Nikolai Lifanov <lifanov at mail.lifanov.com>
> wrote:
>>
>> 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.
>
>
> I think it is. First, the boot code you talk about doesn't matter *AT*ALL*
> for this
> change. It needn't be deployed to be safe. We've had a few rare cases where
> you
> do need new boot code as well, but they seem to happen about once a decade
> or so.
>
> Personally, I always install both a kernel and userspace at the same time
> when
> upgrading, though sometimes just the kernel. Usually it just doesn't matter.
> In
> this case, I'll know I need new boot blocks. I'm kinda of the opinion that
> the boot
> loader should be part of installkernel, but I can see how others may
> disagree and
> that's likely too much POLA to do now (it should have been done in the 4.0
> time
> frame when we went to a tertiary boot loader).
>
> With the recent expansion of limits, however, it's become critical that you
> have
> a new kernel on boot so that limits used by the rc system are set correctly
> (the
> new code has no fallback, but fails for limits it doesn't know about, which
> is
> super lame, and should be fixed, but until it is we're stuck with needing a
> new kernel. This also means, btw, that a 10.x kernel has no chance of
> booting
> an 11.x userland, which is somewhat contrary to traditional practice in the
> project).
>
> Warner