Hmm. Actually I didn't. Through serial console, I had rebooted the
server, just 'to make sure', before booting to bsd.rd, and everything
went through. I rebooted again, immediately, to bsd.rd, and went through
the very normal and standard procedure like umteen times before. One
exception: the bsd.mp was shown as corrupted by its sha256 hash. The
install program, however, continued; so that I could not rectify this.
being on a multi-CPU box, in the end, it automatically copied the
(corrupted) bsd.mp to bsd, which then had a size of 1.3 MB. Therefore,
at the very end, after the device nodes, at the 'reboot now' prompt, I
ftp-ed a correct version from another location into there, and cp-ed it
into bsd. Then, strangely enough, suddenly there appeared a bsd.sp of a
size of 0, which had not been there before.
I found this quite strange, both the installer going through despite of
the wrong hash; and more so the (new?) automatic move of bsd.mp to bsd
on a multicore machine; though the size was wrong. And in the end, a
'0'-sized bsd.sp after moving in a healthy bsd.mp.
I would not totally exclude an interference of this (new?) code that
lead to the described situation. Honestly, nothing at all done in that
session aside from what I wrote, between the 2 boots. I guess, nothing
of what I did should hurt the /boot?
Thanks for the reply. I'll go there next to try what has been proposed.
Before I try, in case the
# /usr/*m*dec/installboot -v boot /*usr/mdec*/biosboot sd0
does NOT work, what else could I do? (I am asking, because it is a
server room quite far away, with little chance for me to communicate,
and difficult to go.) So, is there any alternative, or additional,
solution to fall back to, when I am there, and installboot doesn't cut it?
Uwe
