On 8/9/07, Izumi Tsutsui <tsutsui@ceres.dti.ne.jp> wrote:
> cyber@NetBSD.org wrote:
>
> > Last I checked attempting to boot off a slave drive using the second
> > stage didn't pass parameters in correctly (it may load the right
> > kernel, but then does the wrong thing with root).
>
> Well, this can be easily fixed.
> The problem is that it doesn't pass anything about boot device.
>
> You could specify -a flag for RB_ASKNAME on boot prompt
> with my recent patch, or we could update bootloader
> and kernel to pass whole bootpath via BTINFO_BOOTPATH.
> (sorry I only implemented functions I needed)
>

I know it can be easily fixed.  I added the ability to boot off the
second device to begin with.  As such, I was a little torqued about
the regression, because I was actually *using* that feature.

One should be able to control ALL the options from the raq's firmware
prompt.  If it wasn't for the fact that the new bootstrap made it into
a release before I found its deficiencies, I would have suggested a
revert.

If you really want to commit PCI drivers to GENERIC, please fix the
2nd stage, and update the netboot instructions first.

-=erik.

> > Net booting using
> > the second stage was completely non-functional.
>
> We already have INSTALL kernel which can be loaded by the firmware.
> If it's not enough, we could still have GENERIC_TINY or something.
>
> kloader(4) could also fix these problems.
> I had partially working kloader support, but I have not
> written code passing bootinfo across reboot yet..
>
> > I'm unhappy that those features were lost with the addition of the
> > second stage boot.  (Despite cdi@ calling it a 1st stage, the firmware
> > really is the first stage.)
>
> Anyway, I don't think both situations are so general
> than using wireless networks on the Cobalt Qubes
> with single disk..
> ---
> Izumi Tsutsui
>


-- 
"Too bad $VOLUNTEERS don't get their act together and provide
$SOLUTION_TO_VERY_DIFFICULT_PROBLEM in a decent fashion"  -- from IRC,
#netbsd, EFNet