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 <i...@bsdimp.com> wrote: > > > On Sun, Mar 6, 2016 at 4:44 PM, Nikolai Lifanov <lifa...@mail.lifanov.com> > wrote: >> >> On March 6, 2016 4:13:34 PM EST, Dimitry Andric <d...@freebsd.org> wrote: >> >On 06 Mar 2016, at 20:57, Nikolai Lifanov <lifa...@mail.lifanov.com> >> >wrote: >> >> >> >> On 2016-03-06 11:17, Dimitry Andric wrote: >> >>> On 06 Mar 2016, at 17:00, Oliver Pinter >> ><oliver.pin...@hardenedbsd.org> wrote: >> >>>> On 3/6/16, Dimitry Andric <d...@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 _______________________________________________ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
