Subject: Re: Unsuccessful attempt on 1.2 beta scratch-installation
To: None <port-arm32@NetBSD.ORG>
From: Kjetil Bernhard Thomassen <thomassk@oslo.geco-prakla.slb.com>
List: port-arm32
Date: 08/13/1996 15:36:10
> From: Robert Black <r.black@ic.ac.uk>
> Date: Mon, 12 Aug 1996 12:22:00 +0100
> 
> I am sorry to hear that you are having trouble but I would like to make t=
> he
> following points before I go on to answer your specific problems:
> 
> a) RiscBSD is the binary distribution of NetBSD/arm32. This means that th=
> e
> NetBSD release cycle does not always match up with the RiscBSD cycle. The=
> 
> release versions and alpha/beta/release status are the NetBSD ones and do=
>  not
> necessarily match up with the RiscBSD release cycle. Although we do every=
> thing
> we can to keep them in sync there is quite a bit of porting work to be do=
> ne
> still. This tends to affect people most who do things which have never be=
> en
> tried before (eg running with 256Mb of DRAM). The userbase is small enoug=
> h that
> any given person is likely to have several unique problems.

This sounds reasonable to me, and you are probably right.

But, this again leads back to my main issue.
Since people are likeli to run into problems, it is even more
important that the documentation and installation software is
good.

I will do all I can to help in this matter since it seems to
me that I have fallen into every trap there is.

> b) RiscBSD is non-commercial. This means that it is written by a team of =
> people
> in their spare time. All of the core team (roughly 3 active at any one ti=
> me)
> have full-time jobs and do RiscBSD development in their spare time. Two o=
> f the
> team are also supposed to be writing phd theses (not related to either Ri=
> scBSD
> or their full-time work). This does tend to cramp our style when it comes=
>  to
> documentation and developing the perfect install system. Of course anybod=
> y who
> thinks they can do better is welcome to take the load off our hands (henc=
> e the
> newly formed documentation project with its own mailing list - Neil: is t=
> his in
> the FAQ?). Of course we'd like everything to be perfect, but... The upsid=
> e of
> RiscBSD being non-commercial is that the level of support you get would c=
> ost
> you serious money for a commercial system so fire away with your question=
> s :-)

All valid points, and nice to know.

> On Aug 10, 11:55pm, Kjetil Bernhard Thomassen wrote:
>> Subject: Unsuccessful attempt on 1.2 beta scratch-installation
>> I have tried to install the 1.2-beta release from scratch and has been
>> unsuccessful.
>>
>> I would like to start this report by asking the following question:
>>
>> How can I possibly contribute to making RiscBSD better when I can't get=
>> it installed (in a proper way)?
> 
> By feeding back your problems and suggestions with as much diagnostic
> information as possible so that we can fix them.

Yes, of course.

But, I would like to improve other things than the installation
documentation and software.

>> I really want to contribute, but the lack of documentation and a
>> clean, well thought out system for installing it keeps preventing
>> me from doing that.
> 
> Well, you have just spotted two obvious areas where we could use some hel=
> p....

It seems like it, yes :-)

> If you do manage to get your system up and running (with help from this m=
> ailing
> list) please let us know what the installation documentation should have =
> said.

I will compile my comments into one file and post it to the group.

Then, I would like to improve the installation manual.
(I have joined the documentation project.)

>> I have now wasted two whole days getting nowhere.
>>
>> I understand that the kernel team are busy fixing problems, but
>> I think that they should start in the right end.
> 
> Unfortunately the right end for you is not the right end for other people=
>  so we
> just start with the end we're good at and hope that nice friendly volunte=
> ers
> will turn up to do the other bits :-).

Yes, I can see that. :-)

>> The most important thing is to make sure that all people who wants
>> to use it can install it. Performance issues and the like are a lower
>> priority when there still are people like me having problems
>> installing it.
> 
> Not necessarily. If the performance impovements double the speed of disk =
> access
> and hence increase the speed of compiles they can quickly pay for themsel=
> ves in
> terms of increased core team productivity (eg X currently takes around 8 =
> hours
> to recompile...). Incidentally, most of the performance improvements have=
>  been
> coded outside the core team. They still take core team time because of co=
> de
> management and debugging.

This is a very good point that I have missed.

Thank you for pointing it out.

>> Also, it is very important that equipment can be replaced, added
>> and removed without having to re-install RiscBSD. I just have to
>> refer you to the problems that Kim =D8yhus has had with 1.1 after
>> he removed his SCSI drive. He just can't boot RiscBSD any more.
> 
> I don't know the specifics of the case but this is typically a device
> renumbering problem. This is really a NetBSD-wide issue and I have yet to=
>  see a
> scalable solution to it.

Too bad, but keep looking.

>> My opion is that when a release reaches the beta stage, then
>> there should be no more development on it other than bug-fixes.
>> Also, the documentation should also be at the beta stage, i.e.
>> finished and complete.
> 
> There are no changes being made to the 1.2 release kernel apart from bug =
> fixes.
> The binaries are being fixed to work with it. Note that the latest kernel=
>  on
> the ftp site is NetBSD-current, not 1.2 so any kernel modifications you s=
> ee
> announced have nothing to do with 1.2-beta. Unfortunately there are some =
> quite
> serious bugs in the 1.2-beta kernel which we have been unable to get fixe=
> d and
> are unlikey to get fixed before the release (NetBSD politics) so I expect=
>  Mark
> to wait until he finds a stable kernel which everyone likes and release t=
> hat as
> 1.2-stable.

OK, I see.

I guess there will always be problems with this when an existing
product is to be released in new configurations.

>> ------------ Report from second attempt at RiscBSD -------------
>>
>> This is a report that comments on my second attempt to install RiscBSD.=
> 
>> This time I installed the RiscBSD 1.2-beta from scratch using the
>> files in the 1.2-beta directory on the ftp server.
>>
>> I tried to use my Acorn SCSI card with my HP C3325A SCSI drive.
>> This drive was formatted 400 MB to RISC OS.
>>
>> I am very persistant, and I this refuse to install it to an IDE drive
>> first as I did the first time I installed RiscBSD. As a matter of
>> fact, I do not even have a suitable IDE drive for RiscBSD. The
>> 210 MB I have is my boot disc, and too small for RiscBSD anyway.
>>
>> When I tried to boot RiscBSD the first time, I had unsaved files
>> and StrongED asked me if I wanted to quit. That I did, and RISC OS
>> booted up normally, but RiscBSD did not boot.
>
> Hmm, this is probably because the bootloader plays Russian roulette with =
> the
> RiscOS memory map so very occasionally it comes unstuck. This will get fi=
> xed
> when we get time to rewrite the bootstrap process (maybe this weekend if =
> you're
> really lucky...).

Well, since this does not happen with Draw, this may be a problem
with StrongED as someone pointed out.

Also, the workaround is to save all StrongED files before booting
RiscBSD.

>> When RISC OS had been restarted, I booted RiscBSD with my saved setting=
> =2E
>>
>> I got the following error messages:
>> kbd0 at mainbus0 bas 0xf6000000: Cannot enable keyboard
>> kbd:resend enable keyboard
>>
>> This appeared twice.
> 
> Ouch. Not seen that before, maybe Mark knows...
> 
>> Further down I got the following error message:
>> swap dev 1801 sd0: no disk label
>> -> device not configured for swap
>>
>> This should be quite normal, as this filesystem does not yet exist.
> 
> Yup.
> 
>> Then I got:
>> rd0: allocated 1440K (2880 blocks)
>> panic: Failed to load ramdisc
>>
>> f0110b58 : ???g : e7ffffff : Undefined instruction
>> Stopped at      _Debugger+0x10: ldmdb r11, {r11, r13, r16}
>> db>
>>
>> I then typed continue and the discs were sync'ed and I ended up
>> in the monitor (kshell> prompt). I then typed reboot to return to
>> RISC OS
>>
>> This panic happens every time I try to boot.
> 
> Have you tried different kernels? What kernel number are you using?

This was with bsd-4444 and the bootloader that was present in
the 1.2 directory on the ftp server.

With a 1.1 beta kernel, I did not get that error message.

Is this related to the fact that I have a 16MB/70ns and a 32MB/60ns
installed in my Risc PC?

>> So, then I switched too booting from floppy (/dev/fd0a), and
>> that boots ok.
>>
>> But, now another problem turned out. It seems that the filecore
>> partition has been formatted with 64 sectors/track and
>> 8 tracks/cylinder, but the disc is physically 127/9.
>>
>> Unfortunately, bb_riscbsd is using the logical data that filecore
>> reports, and RiscBSD itself is using the physical.
>>
>> How can I possibly find a number of cylinders that gives the
>> same number of blocks for these two different ways of splitting
>> the cylinders in the area between 400 and 500 MB?
>
> Hmm, this requires knowledge of what filecore is actually up to (ie is it=
> 
> ignoring some of the space?).

I used 1610 as logical and 723 as physical, and that worked fine.

723 is a bit further out in block number than 1610 is.

In other words, I have some blocks lying around after what
is written in the FileCore table, and the superblock of RiscBSD.

>> In my opion there is only one way of fixing this problem.
>> That is to drop the use of filecore and go directly on the
>> disk.
> 
> I need to think about this one. This must be a solved problem because the=
>  i386
> port has exactly the same problem with the BIOS geometry.

As said above, I was wrong. It is just a matter of figuring
out this out and specify a block number larger than the
one given to bb_riscbsd.

>> I tried to boot from floppy and install anyway, but that does
>> not work due to the lack of a writeable filesystem.
>>
>>
>>
>> So, this second attempt was completely unsuccessful as I do not have
>> an IDE drive that I want to use for RiscBSD.
>>
>> During this process, I have seen a lot of things that could be
>> improved upon in the documentation.
>
> [ comments snipped and noted ]
> 
>> Other questions that have sprang to my mind:
>> 1) How can I boot directly from RiscBSD to RiscBSD without going
>> through RiscBSD? Can this be done?
> 
> I take it you mean RiscOS. The answer is no currently. This is not as tri=
> vial
> to sort out as it might seem at first glance. eg you have to reload the k=
> ernel
> and it is quite possible that there is no kernel accessible from the Risc=
> BSD
> side without a filecore partition reader.

I can image that this is a problem, yes.

>> 2) My HP drive is larger than 2GB, how will that work with RiscBSD
>> on a RISC OS 3.6 computer? What about 4GB drives?
>
> This should be no problem. You will not be able to boot a native kernel f=
> rom a
> partition which ends above the 2Gb limit (similar to the 512Mb limit on 3=
> =2E5
> machines).
> 
> I hope this helps. I think Mark will probably have to get in touch with y=
> ou to
> sort out solving your specific booting problems (I haven't a clue when it=
>  comes
> to the foibles of the bootloader). I will try to find out about the disk
> geometry stuff.

I have also found a few bugs in the rcm scripts, and I will fix
them and post them to this list.

As said, I am up and running on 1.2 beta.

Kjetil B.