> On Sat, 8 Mar 2014, Theo de Raadt wrote:
> > > I follow "-current" for several years but recently a thing puzzles me.
> > >
> > > My "x200" is a dual-boot system ("Seven"/OpenBSD "-current") and since (I
> > > think) the "amd64/i386 installboot" change, each time I upgrade via
> > > "bsd.rd", I have to generate a new "openbsd.pbr" and copy it to "Seven".
> > >
> > > If I miss that, I get an "ERR M" and can't go further.
> > >
> > > First I was thinking about changes but I checked code and last
> > > modification on boot(8) was made 2 weeks ago (I did 2 updates since it).
> > >
> > > I used that setup for several years without any need to do that, what do
> > > I miss here, is it now normal ?
> >
> > The old installboot would reuse the same file, very carefully.
>
> To be clear, the old amd64/i386 installboot never updated /boot - it only
> ever
> patched biosboot and installed it into the PBR. It was entirely up to the
> user (or the install script) to copy /usr/mdec/boot file to /boot - if you
> used cp or cat the old PBR may have continued to work, but there was no
> guarantee.
It was entirely up to something but, but you removed it and replaced it
(incorrectly).
You removed a line like this from various places:
- cat /mnt/usr/mdec/boot >/mnt/boot
and then replaced it with a line which writes a fresh new file, on fresh
disk blocks. It matters, because at that moment primary bootblocks (of
various sorts) point at the old blocks, including ones that installboot
itself is not handling.
It is fundamental to the way that primary and secondary bootblocks
operate on many architectures.
(Those that do not understand multiboot are doomed to break it :)
> > Joel's new installboot does not do that, and chooses to be careful
> > about handling a different problem instead.
> >
> > Can't easily solve both problems. I think he should revert to the
> > old method.
Incorrect. The problem is that the new code does not emulate the
try-to-reuse-the-same-blocks mechanism that was in use before.
