Date: Sun, 06 Mar 2016 18:44:11 -0500 From: Nikolai Lifanov <lifanov@mail.lifanov.com> To: Dimitry Andric <dim@FreeBSD.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, 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: <D0BC75E8-4B9A-4727-9F8F-365CA3A49667@mail.lifanov.com> In-Reply-To: <0D2DFD32-B29F-48EA-8D60-458960993E97@FreeBSD.org> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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. - Nikolai Lifanov
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?D0BC75E8-4B9A-4727-9F8F-365CA3A49667>