Re: installboot is broken

[Johnny Billquist <bqt%softjar.se@localhost>]

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
> > ages.
> 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

--
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