Port-sparc archive

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

Re: SPARC build failing with boot.fs overflow



On 13 March 2012 09:56, Martin Husemann <martin%duskware.de@localhost> wrote:
On Tue, Mar 13, 2012 at 11:43:06AM +0200, Andreas Gustafsson wrote:
> Looks like this was triggered by joerg's "P1003_1B_SEMAPHORE is no
> longer optional" commits on March 10:
>
>   http://releng.NetBSD.org/b5reports/sparc/commits-2012.03.html#2012.03.10.21.51.48

Doesn't realy matter in this case what triggered it, the install kernel is
already seriously cripled (i.e. does not even have INET6) - we need to fix
this properly.

I would suggest to create a special "small" install kernel (for
machines with very few memory) and also use ustarfs for multiple
floppies (but with the memory constraints, there still is not much
room). Then uncripple the install kernel used one on CDs so we can
download sets via IPv6, or straight go the GENERIC with / on cd0a route
for CDs.

Yet another option is to drop install floppies completely. I haven't seen
a working drive in years (besides a strange USB connected floppy drive last
year).
(Duck...)

It would be nice to have all floppy install providing ports use ustar, so the issue is available RAM on the machine not install media size.

Actually if we really care about floppy installs on low RAM machines we should generate install media use modules so it can unload unused drivers & have the final disk as a straight FFS image which the kernel mounts directly (*), but as you say, how many people are going to use floppies to install NetBSD & so how much effort is it worth expending...

(*) this means the hypothetical user needs to provide the data to install via another medium, second floppy drive, network, tape, etc... but how long has it been since we provided the sets split into floppy sized chunks? :)


Home | Main Index | Thread Index | Old Index