Uwe Dippel wrote:
Tobias Ulmer wrote:
As explained above, no, you likely moved around/corrupted /boot in a way
that doesn't work for biosboot.
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.
actually, the hash wasn't reported as "wrong", just different from what
was stored in bsd.rd. there are a lot of reasons why that might be
that are legit, so that's why the installer continues.
It is up to you to determine "I know why the hashes didn't match, so
continue" or "huh. wonder why it did that?" and abort/fix the process.
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?
well, something did damage /boot. I doubt it was anything you did
intentionally, but something also caused a bad bsd.sp to be copied over.
Possibly related. May indicate system problems of some type.
The upgrade process will install a new boot loader for you, but
obviously something went wrong.
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
well, I'd certainly copy over a new, verified sane /boot before running
it, and I'm not sure what all the asterisks are doing in there...and you
better make sure you are in the right directory if you are planning on
running it as you show.
Might even want to wait a bit before hitting "reboot", in case something
really odd, like a caching RAID controller that dumps unwritten data as
part of a reboot (I really hope I'm wrong on that one...).
Nick.
