[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: installboot is broken
On 2013-03-24 20:08, Mark Pizzolato - Info Comm wrote:
On Sunday, March 24, 2013 at 11:17 AM, Martin Husemann wrote:
You made your point perfectly clear, however, I do not know the differences
between the various boot details, so I don't know if the scheme used by
installboot is wrong.
What it does:
1) In block 0 create a struct vax_boot_block and fill in the magic needed.
This includes pointing at block 1 as start of the loader:
bb.bb_load = htole32(VAX_BOOT_LOAD);
bb.bb_entry = htole32(VAX_BOOT_ENTRY);
2) it writes all of xxboot (including the first sector, as created from
start.S) to the sectors starting at 1.
If the bb_load/bb_entry version does not work on all vaxes, and instead the
full first sector (with patched in disklabel) is needed, this has to be an
oversight during the conversion to single bootblock - easy to happen, as it will
only cause problems with brand new/zeroed disks, otherwise the old block 0
will be preserved.
I'd be happy to fix it, if we have consensus here on what to do (and do
testing on simh).
This issue CAN and SHOULD be fixed. However, there is a fundamental chicken
and egg problem here in that every available NetBSD vax ISO image going back to
the earliest available (NetBSD 1.6.2) are all missing this boot block on that
media. Clearly no one has attempted to install any version of NetBSD on a
legacy VAX (one which boots without the aid of a ROM based VMB).
Definitely can and should be fixed. You can already solve the problem
today, but it involves a few manual steps. Fixing installboot to do the
right thing will be the proper solution.
This issue came to light due to efforts to use NetBSD with the latest simh's
new VAX simulators (VAX 11/730, VAX 11/750 and VAX 8600/8650). All of these
systems use VMB to initiate the bootstrap process and since the disk being
booted doesn't contain a Digitial ODS2 disk structure, they boot using they
achieve a boot using the bootstrap code provide in sector 0 of the device being
booted. The systems with ROM based VMB have built in code in the ROM VMB to
use the pointers describing the bootstrap location in sector 0 to directly load
the rest of the bootstrap (usually from sectors 1 thru 13) and dispatch to that.
The VAX 11/780 simulator has been available in simh for a long time and no one
had ever tried to install any version of NetBSD on it, or they would have
encountered this issue there as well...
Definitely, since the 11/780 use the same VMB.EXE as the 86x0.
I confirmed that a disk I had installed NetBSD 5.1 vax on a simh VAX 3900
simulator (ROM based VMB) booted fine on the original 3900 simulator, but would
not boot with any of the newer simulators which boot using VMB. I dug around
and ultimately found this difference in behavior for the ROM vs non ROM base
To avoid future strange questions from folks who may try to install any version
of NetBSD or OpenBSD which all have this issue, I'm going to package the new
simh simulators with a patched version of VMB.EXE that handles boot block
booting the same way as the ROM based VMB systems. This will mask this issue,
for those using the simh simulators. If after experiencing the smooth behavior
using a simulator one of these users tries to translate that experience back to
real hardware, they will have the issues I encountered.
Yes. So while a workaround for simh is nice, it is no excuse for NetBSD
to continue being broken.
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt%softjar.se@localhost || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
Main Index |
Thread Index |