Subject: Re: install/37521: qemu install from NetBSD-current install floppiesfails
To: None <firstname.lastname@example.org>
From: Stephen Borrill <email@example.com>
Date: 12/13/2007 13:41:24
Alan Barrett wrote:
> The following reply was made to PR install/37521; it has been noted by GNATS.
> From: Alan Barrett <firstname.lastname@example.org>
> To: gnats-bugs@NetBSD.org
> Cc: netbsd-bugs@NetBSD.org
> Subject: Re: install/37521: qemu install from NetBSD-current install
> Date: Thu, 13 Dec 2007 14:34:25 +0200
> On Thu, 13 Dec 2007, Stephen Borrill wrote:
> > Patch has been committed and the PR closed.
> The failure in PR 37521 seems to depend on several things:
> A) boot tries to read boot.cfg;
> B) boot.cfg isn't in the ustarfs file system;
> C) ustarfs doesn't notice when seeking backwards to an earlier floppy
> would be a good idea.
> Changing any of A, B, or C, would make the problem go away.
> The change that was committed (for boot to avoid reading boot.cfg if
> ustarfs is in use) is one way of addressing issue A. Another way would
> be to ensure that the boot loader on the floppy was built with -DSMALL.
Yes. The latter would mean building a different copy of boot though,
because as I understand it currently uses the same one (but that is
exactly why I included -DSMALL support in the first place).
> Issue B could be addressed by adding a boot.cfg file (and getting the
> ordering of files right). We might even want a boot.cfg file to make
> "boot without ACPI support" a menu option.
Possibly, though at this point in time giving the option of "boot
without ACPI" would require two kernels to be present in the ustarfs!
This could be revisited when I add support for userconf settings as it
will then be more useful. Or we could just add a small boot.cfg which
gives a welcome banner (or is even empty). Though that does seem to be
increasing image size for little gain and also I like the idea of one
/boot fits all.
> Issue C could presumably be fixed in ustarfs. It could be clever and
> build a table mapping file names to volume numbers, or it could be
> stupid and just ensure that every open attempt searches through every
> volume before reporting failure.
I don't see that the stupid way would solve the problem except that the
user would be prompted to reinsert floppy 1 prior to booting the kernel.
Dr. Stephen Borrill