Port-vax archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: installboot is broken

On 2013-03-24 22:03, Anders Magnusson wrote:
On 03/24/2013 08:52 PM, Johnny Billquist wrote:
On 2013-03-24 19:25, Anders Magnusson wrote:
On 03/24/2013 05:48 PM, Martin Husemann wrote:
On Sun, Mar 24, 2013 at 04:39:45PM +0100, Anders Magnusson wrote:
Vax only have one bootblock which is installed in the first 16 sectors
on the disk.
The boot block is the same for all different disk types. Which is
nice :-)
Yes, indeed - but Jonny claims the conversion to this sheme broke
preparation of completely zeroed/new disks for 11/750 and others (but
not for micro vaxen, which is the only hardware I have).
You mean the installboot usage, or something else?  Vax has had a
unified boot block on NetBSD ~forever.  It was installed by newfs
earlier but now it needs installboot.

I thought I remembered disklabel doing the installation of the boot
block, but I might be misremembering.
You could do it with disklabel as well.  disklabel -B -b xxboot would do
the trick :-)

Right. And as far as I remember, that did the right thing. However, that functionality is gone from disklabel now.

All machines that have PROM-VMB + 11/750 and VAX8200 (with ROM routines)
works correctly.

I wonder. Does the 11/750 really work now? I have a feeling it will not.

If the boot block gets installed correctly it will.

Right. But my point is that it isn't. That's what this whole thread is about. :-)

Hm, it sounds odd that a boot block problem hasn't been noticed for
quite some time since the new installboot were introduced.

Yes, but maybe not that surprising if you think about it.
How many installations from scratch have been done on any large VAXen lately? This is a problem that is apparent if you do an installation of NetBSD to a disk which does not already have a good NetBSD boot block on it.

Here is a simple experiment: Save the disklabel of a disk. Overwrite block zero with nulls, restore the disk label, and then use installboot, and see what happens when you try to boot the disk.

You still have a couple of 11/750 don't you?

For other machines the boot program is installed on the frontend media
(RX11, RL02 or something) so the boot blocks are never used.

Ragge, that was ages ago. :-)
We have not used out own boot program on the FE media since 2.0 or
something. I still have a copy around on my FE RL02 just in case
something really bad happens, and I need it, but I have not used it in
Actually this is still the supported way :-)

What do you mean "supported"? :-)
I doubt anyone but me is running an 86x0 with NetBSD anymore. And I suspect the number of 11/78x machines running NetBSD is one less than the 86x0 machines. :-)

So the only one who have tried any variant, tested and verified it even works would be me. And I've not used the boot program on the console for over 10 years. There was a time when the boot was changing quite a lot, when we switched the format of the NetBSD executable, and did various tweaks to /boot. I stopped using the boot on the console before this. It was such a headache to keep up to date, as well as getting it working when we switched from a.out that I'm telling you I'm not sure if we even have a working way of getting a standalone boot on the console that we can start.

I think I added some stuff to the boot blocks to let VMB recognize and
load the blocks needed when I wrote the VAX8800 support, because I had
difficulties to access the PC350 console media.  It may be that it just
worked on all other machines with console media also.

It's same procedure as done by Ultrix. VMB reads in block 0, and jumps in there. It might be that you originally did it for the 8800, but any VMB based boot works the same.

The 11/750 initially needed to load the boot code from the TU58 (as
4.2BSD needed), but that was fixed before the 1.0 release IIRC.

Yes. But it depends on that the stuff in xxboot actually gets onto the disk at block 0. Which isn't done. If anyone were to actually look at the code, they should realize the silliness. start.S even have a large hole in it, which is pointed out in the comments in the source, that it is there so that the disk label can sit in that hole. If we're only copying this block into block 1 of the disk, there is no disk label to sit in that hole...


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

Home | Main Index | Thread Index | Old Index