Date: Sun, 6 Mar 2016 16:56:21 -0800 From: Adrian Chadd <adrian.chadd@gmail.com> To: Warner Losh <imp@bsdimp.com> Cc: Nikolai Lifanov <lifanov@mail.lifanov.com>, Dimitry Andric <dim@freebsd.org>, "svn-src-head@freebsd.org" <svn-src-head@freebsd.org>, "svn-src-all@freebsd.org" <svn-src-all@freebsd.org>, src-committers <src-committers@freebsd.org>, owner-svn-src-head@freebsd.org, Oliver Pinter <oliver.pinter@hardenedbsd.org> Subject: Re: svn commit: r296428 - head/sys/boot/common Message-ID: <CAJ-Vmokp5XDhRo7KTJXnird045OYLuFaXiuG5TZO8irqeAP--Q@mail.gmail.com> In-Reply-To: <CANCZdfqDHb5JjjADU4n6r88mMGZ0HcRnP3T3anjgnxiFgPReUg@mail.gmail.com> References: <201603061557.u26FvhMi033982@repo.freebsd.org> <CAPQ4ffut5jLNp5X4cV_DCsPGfv4Fw%2BPVm0ANNftuj2PLFZrjtQ@mail.gmail.com> <0FC43773-1BF0-43FF-BB97-35B482ABBE12@FreeBSD.org> <5ba9554b9066227c883140c7c12e4703@mail.lifanov.com> <0D2DFD32-B29F-48EA-8D60-458960993E97@FreeBSD.org> <D0BC75E8-4B9A-4727-9F8F-365CA3A49667@mail.lifanov.com> <CANCZdfqDHb5JjjADU4n6r88mMGZ0HcRnP3T3anjgnxiFgPReUg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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@bsdimp.com> wrote: > > > On Sun, Mar 6, 2016 at 4:44 PM, Nikolai Lifanov <lifanov@mail.lifanov.com> > wrote: >> >> On March 6, 2016 4:13:34 PM EST, Dimitry Andric <dim@FreeBSD.org> wrote: >> >On 06 Mar 2016, at 20:57, Nikolai Lifanov <lifanov@mail.lifanov.com> >> >wrote: >> >> >> >> On 2016-03-06 11:17, Dimitry Andric wrote: >> >>> On 06 Mar 2016, at 17:00, Oliver Pinter >> ><oliver.pinter@hardenedbsd.org> wrote: >> >>>> On 3/6/16, Dimitry Andric <dim@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-Vmokp5XDhRo7KTJXnird045OYLuFaXiuG5TZO8irqeAP--Q>