Re: Discussion on the future of floppies in 5.x and 6.x

2004-01-20 Thread David Gilbert
> "Daniel" == Daniel O'Connor <[EMAIL PROTECTED]> writes:

Daniel> True..  Although I believe the loader could do it just as well
Daniel> and it's already imported :)

Daniel> (It uses the BIOS to read the kernel, and groks PXE, although
Daniel> I am hazy on the specifics)

I think the loader understands PXE well and understands certain BIOS
things well.  I mentioned FreeDOS since it would understand some CDROM
nuances well.  AFAIK, the loader understood CDROMs to the extent that
they emulated a floppy of some sort.

Dave.

-- 

|David Gilbert, Independent Contractor.   | Two things can only be |
|Mail:   [EMAIL PROTECTED]|  equal if and only if they |
|http://daveg.ca  |   are precisely opposite.  |
=GLO
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Discussion on the future of floppies in 5.x and 6.x

2004-01-20 Thread Daniel O'Connor
On Wednesday 21 January 2004 00:43, David Gilbert wrote:
> >> I agree.  The boot floppy tries to do w a y too much.  I think we
> >> should think of the boot floppy as way to implement an old-style
> >> console emulator: it "boots" and you tell it where to read the
> >> *real* boot image from.  It should support all of the usual
> >> sources: CDs/DVDs, NFS mounts, FTP, and so on.
>
> Daniel> *How* does it support all of those sources?  CD/DVD drives
> Daniel> need drivers (ATA optimisticly, but quite possibly SCSI),
> Daniel> FTP/NFS need network card support, NFS needs nfsclient.ko
>
> You're missing the solution.  It's right in front of you.
>
> For network drivers, support PXE, RTL and etherboot.  PXE even
> provides the UDP portion of a TCP stack.
>
> For disks, use BIOS.  No seriously.  BIOS support for cdroms and hard
> disks is still maintained as it's required to support windoze
> installs.  AFAIK, too, one cdrom driver works for all the modern
> drives, too.
>
> In fact, FreeDOS might be an excellent bootstrap platform.

True..
Although I believe the loader could do it just as well and it's already 
imported :)

(It uses the BIOS to read the kernel, and groks PXE, although I am hazy on the 
specifics)

-- 
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum
GPG Fingerprint - 9A8C 569F 685A D928 5140  AE4B 319B 41F4 5D17 FDD5

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Discussion on the future of floppies in 5.x and 6.x

2004-01-20 Thread David Gilbert
> "Daniel" == Daniel O'Connor <[EMAIL PROTECTED]> writes:

Daniel> On Friday 09 January 2004 10:04, Greg Shenaut wrote:
>> In nuntio <[EMAIL PROTECTED]>, Michel TALON
>> divulgat: >By the way, what's the reason that it is impossible to
>> have just one >floppy which boots FreeBSD kernel, allows to see an
>> unbootable cdrom >and continue installation from here?
>> 
>> I agree.  The boot floppy tries to do w a y too much.  I think we
>> should think of the boot floppy as way to implement an old-style
>> console emulator: it "boots" and you tell it where to read the
>> *real* boot image from.  It should support all of the usual
>> sources: CDs/DVDs, NFS mounts, FTP, and so on.

Daniel> *How* does it support all of those sources?  CD/DVD drives
Daniel> need drivers (ATA optimisticly, but quite possibly SCSI),
Daniel> FTP/NFS need network card support, NFS needs nfsclient.ko

You're missing the solution.  It's right in front of you.

For network drivers, support PXE, RTL and etherboot.  PXE even
provides the UDP portion of a TCP stack.

For disks, use BIOS.  No seriously.  BIOS support for cdroms and hard
disks is still maintained as it's required to support windoze
installs.  AFAIK, too, one cdrom driver works for all the modern
drives, too.

In fact, FreeDOS might be an excellent bootstrap platform.

Dave.

-- 

|David Gilbert, Independent Contractor.   | Two things can only be |
|Mail:   [EMAIL PROTECTED]|  equal if and only if they |
|http://daveg.ca  |   are precisely opposite.  |
=GLO
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Discussion on the future of floppies in 5.x and 6.x

2004-01-12 Thread M. Warner Losh
In message: <[EMAIL PROTECTED]>
Peter Jeremy <[EMAIL PROTECTED]> writes:
: On Sun, Jan 11, 2004 at 01:12:25PM -0600, William Grim wrote:
: >If it's really such a big deal to get rid of floppy support, how about 
: >we get rid of it and make sure an older version of FreeBSD 4.x/5.x is 
: >always available for download?  This way, floppy users could install an 
: >older version of the OS and cvsup to the latest version they want.
: 
: 1) CVSup isn't an option for someone who wants to install a binary
:distribution and not have to do a buildworld.

Actually, one can distribute binaries with cvsup, but it is a bit of a
pita...

Warner
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Discussion on the future of floppies in 5.x and 6.x

2004-01-12 Thread John Baldwin
On Monday 12 January 2004 01:21 pm, Brooks Davis wrote:
> On Mon, Jan 12, 2004 at 08:26:22AM -0800, Wes Peters wrote:
> > On Monday 12 January 2004 07:22 am, Brooks Davis wrote:
> > > On Sun, Jan 11, 2004 at 09:24:38PM +0100, Nicolas Rachinsky wrote:
> > > > I don't know the release build process, so I don't know how much
> > > > effort is neccessary to create such floppies, but the loader seems to
> > > > have all features needed to use such disks.
> > >
> > > It sounds like this is definatly a viable option.  Now someone needs to
> > > see about hacking something like this into the release makefiles.
> >
> > Note that I didn't say it would be a lot of work. ;^)
> >
> > Do we have a volunteer showing up here?
>
> Definatly not me.  I hate floppies (and they hate me).  I was just
> trying to convince someone to follow what looks like a reasionably
> promising path to keeping floppy support and moving the pain of dealing
> with floppies from RE to the floppy users.
>
> -- Brooks

I'm going to look at using splitfs for GENERIC kernel and mfsroot that we use 
on CD installs.

-- 
John Baldwin <[EMAIL PROTECTED]>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Discussion on the future of floppies in 5.x and 6.x

2004-01-12 Thread Brooks Davis
On Mon, Jan 12, 2004 at 08:26:22AM -0800, Wes Peters wrote:
> On Monday 12 January 2004 07:22 am, Brooks Davis wrote:
> > On Sun, Jan 11, 2004 at 09:24:38PM +0100, Nicolas Rachinsky wrote:
> > >
> > > I don't know the release build process, so I don't know how much
> > > effort is neccessary to create such floppies, but the loader seems to
> > > have all features needed to use such disks.
> >
> > It sounds like this is definatly a viable option.  Now someone needs to
> > see about hacking something like this into the release makefiles.
> 
> Note that I didn't say it would be a lot of work. ;^)
> 
> Do we have a volunteer showing up here?

Definatly not me.  I hate floppies (and they hate me).  I was just
trying to convince someone to follow what looks like a reasionably
promising path to keeping floppy support and moving the pain of dealing
with floppies from RE to the floppy users.

-- Brooks

-- 
Any statement of the form "X is the one, true Y" is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529  9BF0 5D8E 8BE9 F238 1AD4


pgp0.pgp
Description: PGP signature


Re: Discussion on the future of floppies in 5.x and 6.x

2004-01-12 Thread Wes Peters
On Monday 12 January 2004 07:22 am, Brooks Davis wrote:
> On Sun, Jan 11, 2004 at 09:24:38PM +0100, Nicolas Rachinsky wrote:
> >
> > I don't know the release build process, so I don't know how much
> > effort is neccessary to create such floppies, but the loader seems to
> > have all features needed to use such disks.
>
> It sounds like this is definatly a viable option.  Now someone needs to
> see about hacking something like this into the release makefiles.

Note that I didn't say it would be a lot of work. ;^)

Do we have a volunteer showing up here?

-- 

Where am I, and what am I doing in this handbasket?

Wes Peters   [EMAIL PROTECTED]

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Discussion on the future of floppies in 5.x and 6.x

2004-01-12 Thread Brooks Davis
On Sun, Jan 11, 2004 at 09:24:38PM +0100, Nicolas Rachinsky wrote:
> * Brooks Davis <[EMAIL PROTECTED]> [2004-01-11 11:02 -0800]:
> > If you could make this work such that you just stuffed GENERIC and the
> > mfsroot onto however many floppies it takes, I think that would almost
> > certaintly solve re's problems with floppies (i.e. if all they had to do
> > when the kernel/mfsroot got too big was to bump a NUMFLOPPIES
> > variable.)  Sure that would suck for the floppy users, but that would
> > put the pain in the place where it's most likely to cause someone to
> > come up with some better.
> > 
> > Now, who wants to give this a try?
> 
> OK, I tried now the following:
> 
> I made copies of the 4.9 RELEASE Floppies, split the half of the
> kernel and mfsroot to another floppy and added two appropriate
> splitfiles.
> 
> Afterwards booting from these four disks worked fine.
> 
> disk1:
> /boot > /kernel.gz.split
> /kernel.gzaa
> 
> "Message from libstand"
> 
> disk2:
> /kernel.gzab
> 
> "Message from loader.rc"
> 
> disk3:
> /mfsroot.gz.split
> /mfsroot.gzaa
> 
> "Message from libstand"
> 
> disk4:
> /mfsroot.gzab
> 
> 
> I don't know the release build process, so I don't know how much
> effort is neccessary to create such floppies, but the loader seems to
> have all features needed to use such disks.

It sounds like this is definatly a viable option.  Now someone needs to
see about hacking something like this into the release makefiles.

-- Brooks

-- 
Any statement of the form "X is the one, true Y" is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529  9BF0 5D8E 8BE9 F238 1AD4


pgp0.pgp
Description: PGP signature


Re: Discussion on the future of floppies in 5.x and 6.x

2004-01-12 Thread Peter Jeremy
On Sun, Jan 11, 2004 at 01:12:25PM -0600, William Grim wrote:
>If it's really such a big deal to get rid of floppy support, how about 
>we get rid of it and make sure an older version of FreeBSD 4.x/5.x is 
>always available for download?  This way, floppy users could install an 
>older version of the OS and cvsup to the latest version they want.

1) CVSup isn't an option for someone who wants to install a binary
   distribution and not have to do a buildworld.
2) Across major releases, "make world" is only defined for an up to
   date -STABLE to -CURRENT.  Crossing multiple major releases isn't
   supported.
3) It's common for major releases to recommend a reinstall.  5.x is the
   current case-in-point:  a reinstall allows upgrading to UFS2.
4) Bare-metal restores become very painful if you have to do a reversion
   and upgrade - especially if you want to use features that don't exist
   in the "older" version.
5) The "older version would need to be continuously upgraded with
   security fixes.  Would you feel safe with instructions that said (in
   essence) "Install FreeBSD 2.2.8 and then CVSup to 6.x" when 2.2.8
   was missing 5 years of security patches.

Peter
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Discussion on the future of floppies in 5.x and 6.x

2004-01-11 Thread Nicolas Rachinsky
* Avleen Vig <[EMAIL PROTECTED]> [2004-01-11 13:34 -0800]:
> On Sun, Jan 11, 2004 at 09:24:38PM +0100, Nicolas Rachinsky wrote:
> > > Now, who wants to give this a try?
> > 
> > OK, I tried now the following:
> > 
> > I made copies of the 4.9 RELEASE Floppies, split the half of the
> > kernel and mfsroot to another floppy and added two appropriate
> > splitfiles.
> > 
> > Afterwards booting from these four disks worked fine.
> 
> OK, someone help me out here :)
> I was going to try this with a range of floppies (4.8, 4.9, 5.1, 5.2,
> etc), but I can't figure out what to do with splitfs.c

Do nothing, the loader already contains it.

Nicolas
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Discussion on the future of floppies in 5.x and 6.x

2004-01-11 Thread Avleen Vig
On Sun, Jan 11, 2004 at 09:24:38PM +0100, Nicolas Rachinsky wrote:
> > Now, who wants to give this a try?
> 
> OK, I tried now the following:
> 
> I made copies of the 4.9 RELEASE Floppies, split the half of the
> kernel and mfsroot to another floppy and added two appropriate
> splitfiles.
> 
> Afterwards booting from these four disks worked fine.

OK, someone help me out here :)
I was going to try this with a range of floppies (4.8, 4.9, 5.1, 5.2,
etc), but I can't figure out what to do with splitfs.c
gcc -o splitfs /usr/src/lib/libstand/splitfs.c
/usr/lib/crt1.o: In function `_start':
/usr/lib/crt1.o(.text+0x85): undefined reference to `main'
/tmp/cc1Xbt2V.o: In function `splitfs_open':
/tmp/cc1Xbt2V.o(.text+0x239): undefined reference to `fgetstr'
/tmp/cc1Xbt2V.o: In function `splitfs_seek':
/tmp/cc1Xbt2V.o(.text+0x695): undefined reference to `panic'
/tmp/cc1Xbt2V.o(.text+0x801): undefined reference to `panic'
/tmp/cc1Xbt2V.o(.data+0x10): undefined reference to `null_write'
/tmp/cc1Xbt2V.o(.data+0x1c): undefined reference to `null_readdir'


I'm guessing that's not the right thing to do.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Discussion on the future of floppies in 5.x and 6.x

2004-01-11 Thread Nicolas Rachinsky
* Brooks Davis <[EMAIL PROTECTED]> [2004-01-11 11:02 -0800]:
> If you could make this work such that you just stuffed GENERIC and the
> mfsroot onto however many floppies it takes, I think that would almost
> certaintly solve re's problems with floppies (i.e. if all they had to do
> when the kernel/mfsroot got too big was to bump a NUMFLOPPIES
> variable.)  Sure that would suck for the floppy users, but that would
> put the pain in the place where it's most likely to cause someone to
> come up with some better.
> 
> Now, who wants to give this a try?

OK, I tried now the following:

I made copies of the 4.9 RELEASE Floppies, split the half of the
kernel and mfsroot to another floppy and added two appropriate
splitfiles.

Afterwards booting from these four disks worked fine.

disk1:
/boot
/kernel.gz.split
/kernel.gzaa

"Message from libstand"

disk2:
/kernel.gzab

"Message from loader.rc"

disk3:
/mfsroot.gz.split
/mfsroot.gzaa

"Message from libstand"

disk4:
/mfsroot.gzab


I don't know the release build process, so I don't know how much
effort is neccessary to create such floppies, but the loader seems to
have all features needed to use such disks.

Nicolas

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Discussion on the future of floppies in 5.x and 6.x

2004-01-11 Thread William Grim
Marco van de Voort wrote:

I also don't think it's the issue that needs to be dealt with - 
distribution is much, much, MUCH bigger an issue than "shall we get rid 
of floppies"? I sent this to the list before, but it got ignored, so 
I'll send it again, where Jordan points out we have bigger issues to 
deal with when discussing the "floppy disk problem" whilst discussing 
libh:- (http://rtp1.slowblink.com/~libh/sysinstall2/improvements.html):

"As I mentioned in Section 2.3, one of the more annoying problems with
FreeBSD's current distribution format is the dividing line between
distributions and packages. There should really only be one type of
"distribution format" and, of course, it should be the package (There Can
Be Only One). Achieving this means we're first going to have to grapple
with several problems, however:
First, eliminating the distribution format means either teaching the
package tools how to deal with a split archive format (they currently do
not) or divorcing ourselves forever from floppies as a distribution
medium. This is an issue which would seem an easy one to decide but
invariably becomes Highly Religious(tm) every time it's brought up. In
some dark corner of the world, there always seems to be somebody still
installing FreeBSD via floppies and even some of the fortune 500 folks can
cite FreeBSD success stories where they resurrected some old 386 box (with
only a floppy drive and no networking/CD/...) and turned it into the star
of the office/saved the company/etc etc. That's not to say we can't still
bite that particular bullet, just that it's not a decision which will go
down easily with everyone and should be well thought-out."
And I have to say, I agree. If abondoning floppies is part of some
well-thought-out and well-planned package management strategy, I'm all for
it. Otherwise, let sleeping dogs lie?
   

It isn't as far as I can understand from that link. JKH is talking about
doing floppy only install
(some old 386 box (with only a floppy drive and no networking/CD/...) and
turned it into the star of the office/saved the company/etc etc...)
not loading an installation kernel and /stand from floppy and then transfer to
network/cd later.
This because when then base/packages need to fit on floppy. This isn't necessary
for the current two-flop, then CD install which is discussed now. 

P.s. for the record, I prefer Slackware's approach to floppy booting.
Multiple cut down bootsets (SCSI, NET etc) with the ability to simply
extract extra kernel modules from CD to a floppy (on a separate machine) and
load them from floppy while still in the initial system ramdisk (before
mounting CD). The loading/mounting etc must be done by hand, no extra
new functionality required.
Maybe the basic idea should be to forget the equivalence of floppy and cd
boot, and deliver a set of kernel modules on CD, and a few basic boot/root
floppies, and for the rest let users create their own custom driver discs,
and do some extra work to keep their floppy boot running.
That ends the one boot/root for all idea, but is maybe more flexible, ( didn't
have to make something with custom kernel to install my Proliant 1500, but
only select the right kernel disc and copy some extra kernel moduless to an empty
flop) and at the same time decrease release engineering on the floppies.
I think this is a good compromise:  Keep floppy option open, but shift some
burden to the users.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
 

This idea dawned on me a few moments ago:

If it's really such a big deal to get rid of floppy support, how about 
we get rid of it and make sure an older version of FreeBSD 4.x/5.x is 
always available for download?  This way, floppy users could install an 
older version of the OS and cvsup to the latest version they want.

I see the above as a decent compromise.  This way, we no longer have to 
support newer floppy editions, but we leave people with floppy drives an 
option to perform the installation.

What do you think?

--
William Michael Grim
Student, Southern Illinois University at Edwardsville
Unix Network Administrator, SIUE, Computer Science dept.
Phone: (217) 341-6552
Email: [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Discussion on the future of floppies in 5.x and 6.x

2004-01-11 Thread Brooks Davis
On Sun, Jan 11, 2004 at 10:27:46AM +0100, Nicolas Rachinsky wrote:
> * Dag-Erling Smørgrav <[EMAIL PROTECTED]> [2004-01-11 10:19 +0100]:
> > Paul Robinson <[EMAIL PROTECTED]> writes:
> > > Understood. I just think saying "let's get rid of floppies" is
> > > shooting a dog that happens to be near to hand because you don't like
> > > that dog, to stretch the analogy.
> > 
> > I don't think you have any idea how difficult it is (and has been for
> > a couple of years now) just to keep the install floppies alive.  The
> > kernel keeps growing, and the amount of "must-have" features (such as
> > acpi) keeps growing, and every time the boot floppies overflow we have
> > to toss out yet another driver that about a dozen people vehemently
> > tell us they can't live without.
> 
> Why not split the kernel onto 2 disks? The code to do this is already
> there and seems to work. And the people who think they absolutly need
> disks would have to deal with 4 disks, but that would be better than
> no disks.
> 
> Look at the commit history of /usr/src/lib/libstand/splitfs.c. Is
> there a reason not to use it?

If you could make this work such that you just stuffed GENERIC and the
mfsroot onto however many floppies it takes, I think that would almost
certaintly solve re's problems with floppies (i.e. if all they had to do
when the kernel/mfsroot got too big was to bump a NUMFLOPPIES
variable.)  Sure that would suck for the floppy users, but that would
put the pain in the place where it's most likely to cause someone to
come up with some better.

Now, who wants to give this a try?

-- Brooks

-- 
Any statement of the form "X is the one, true Y" is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529  9BF0 5D8E 8BE9 F238 1AD4


pgp0.pgp
Description: PGP signature


Re: Discussion on the future of floppies in 5.x and 6.x

2004-01-11 Thread Nik Clayton
On 8 Jan 2004, at 14:39, Leo Bicknell wrote:
Then, to replace the current floppy process, a new floppy installer
is created.  It may or may not be based on FreeBSD, but what it
needs to be able to do is boot, load a network driver, configure
the network, and ftp the above mentioned iso into ram, and then
jump into the kernel from the iso as if it had been loaded from a
CD.
Or mount the ISO image from a FAT, NTFS, UFS, or EXT2FS filesystem on a 
disk that's already in the machine...

N


PGP.sig
Description: This is a digitally signed message part


Re: Discussion on the future of floppies in 5.x and 6.x

2004-01-11 Thread Marco van de Voort
> I also don't think it's the issue that needs to be dealt with - 
> distribution is much, much, MUCH bigger an issue than "shall we get rid 
> of floppies"? I sent this to the list before, but it got ignored, so 
> I'll send it again, where Jordan points out we have bigger issues to 
> deal with when discussing the "floppy disk problem" whilst discussing 
> libh:- (http://rtp1.slowblink.com/~libh/sysinstall2/improvements.html):
> 
> "As I mentioned in Section 2.3, one of the more annoying problems with
> FreeBSD's current distribution format is the dividing line between
> distributions and packages. There should really only be one type of
> "distribution format" and, of course, it should be the package (There Can
> Be Only One). Achieving this means we're first going to have to grapple
> with several problems, however:
> 
> First, eliminating the distribution format means either teaching the
> package tools how to deal with a split archive format (they currently do
> not) or divorcing ourselves forever from floppies as a distribution
> medium. This is an issue which would seem an easy one to decide but
> invariably becomes Highly Religious(tm) every time it's brought up. In
> some dark corner of the world, there always seems to be somebody still
> installing FreeBSD via floppies and even some of the fortune 500 folks can
> cite FreeBSD success stories where they resurrected some old 386 box (with
> only a floppy drive and no networking/CD/...) and turned it into the star
> of the office/saved the company/etc etc. That's not to say we can't still
> bite that particular bullet, just that it's not a decision which will go
> down easily with everyone and should be well thought-out."
> 
> And I have to say, I agree. If abondoning floppies is part of some
> well-thought-out and well-planned package management strategy, I'm all for
> it. Otherwise, let sleeping dogs lie?

It isn't as far as I can understand from that link. JKH is talking about
doing floppy only install

(some old 386 box (with only a floppy drive and no networking/CD/...) and
turned it into the star of the office/saved the company/etc etc...)

not loading an installation kernel and /stand from floppy and then transfer to
network/cd later.

This because when then base/packages need to fit on floppy. This isn't necessary
for the current two-flop, then CD install which is discussed now. 

P.s. for the record, I prefer Slackware's approach to floppy booting.
Multiple cut down bootsets (SCSI, NET etc) with the ability to simply
extract extra kernel modules from CD to a floppy (on a separate machine) and
load them from floppy while still in the initial system ramdisk (before
mounting CD). The loading/mounting etc must be done by hand, no extra
new functionality required.

Maybe the basic idea should be to forget the equivalence of floppy and cd
boot, and deliver a set of kernel modules on CD, and a few basic boot/root
floppies, and for the rest let users create their own custom driver discs,
and do some extra work to keep their floppy boot running.

That ends the one boot/root for all idea, but is maybe more flexible, ( didn't
have to make something with custom kernel to install my Proliant 1500, but
only select the right kernel disc and copy some extra kernel moduless to an empty
flop) and at the same time decrease release engineering on the floppies.

I think this is a good compromise:  Keep floppy option open, but shift some
burden to the users.

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Discussion on the future of floppies in 5.x and 6.x

2004-01-11 Thread Nicolas Rachinsky
* Dag-Erling Smørgrav <[EMAIL PROTECTED]> [2004-01-11 10:19 +0100]:
> Paul Robinson <[EMAIL PROTECTED]> writes:
> > Understood. I just think saying "let's get rid of floppies" is
> > shooting a dog that happens to be near to hand because you don't like
> > that dog, to stretch the analogy.
> 
> I don't think you have any idea how difficult it is (and has been for
> a couple of years now) just to keep the install floppies alive.  The
> kernel keeps growing, and the amount of "must-have" features (such as
> acpi) keeps growing, and every time the boot floppies overflow we have
> to toss out yet another driver that about a dozen people vehemently
> tell us they can't live without.

Why not split the kernel onto 2 disks? The code to do this is already
there and seems to work. And the people who think they absolutly need
disks would have to deal with 4 disks, but that would be better than
no disks.

Look at the commit history of /usr/src/lib/libstand/splitfs.c. Is
there a reason not to use it?

Nicolas
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Discussion on the future of floppies in 5.x and 6.x

2004-01-11 Thread Dag-Erling Smørgrav
Paul Robinson <[EMAIL PROTECTED]> writes:
> Understood. I just think saying "let's get rid of floppies" is
> shooting a dog that happens to be near to hand because you don't like
> that dog, to stretch the analogy.

I don't think you have any idea how difficult it is (and has been for
a couple of years now) just to keep the install floppies alive.  The
kernel keeps growing, and the amount of "must-have" features (such as
acpi) keeps growing, and every time the boot floppies overflow we have
to toss out yet another driver that about a dozen people vehemently
tell us they can't live without.

To rephrase this in terms of your analogy, the dog was hit by a bus
two years ago and has been on artificial life support ever since, and
it's starting to dawn on us that we can no longer afford the hospital
bill.

DES
-- 
Dag-Erling Smørgrav - [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Discussion on the future of floppies in 5.x and 6.x

2004-01-11 Thread Paul Robinson
Wes Peters wrote:

So you'll be signing up to do the floppy release engineering, and to 
modify the kernel so it can load the boot-device modules dynamically.  
That's great news!

If the kernel changes don't support the established distribution format, 
the kernel changes are broken, not the distribution format. If the 
kernel changes must happen at some point and the distribution format 
must therefore become "the package", then that's fine, but that change 
(including being able to split packages over several physical 
distribution "units") has to happen first, surely? I'm happy to get 
involved in any team looking at that as it falls under something I've 
been looking at for the last year or so in my spare time - package 
management and installers.

The dog isn't sleeping, it's dead.  Like everything else in FreeBSD, it 
takes time.  If someone wants to donate that time, it'll continue getting 
done, otherwise it'll fall by the wayside.

Understood. I just think saying "let's get rid of floppies" is shooting 
a dog that happens to be near to hand because you don't like that dog, 
to stretch the analogy. Personally, I think getting the package 
management issues sorted so that distribution becomes independent of 
physical medium (so floppies, CDs, etc. can be used or abondoned at 
will, along with future formats) is an admirable goal, but one that 
should be on the 6- roadmap. In other words, getting rid of floppies is 
not the discussion we should be having, if that makes sense?

--
Paul Robinson
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Discussion on the future of floppies in 5.x and 6.x

2004-01-11 Thread Wes Peters
On Sunday 11 January 2004 12:27 am, Paul Robinson wrote:
>
> Perhaps I'm missing something, and I can see why abondoning the current
> method in 5-6 years would be reasonable, but I don't see the immediate
> advantage of making the change right now.

So you'll be signing up to do the floppy release engineering, and to 
modify the kernel so it can load the boot-device modules dynamically.  
That's great news!

> And I have to say, I agree. If abondoning floppies is part of some
> well-thought-out and well-planned package management strategy, I'm all
> for it. Otherwise, let sleeping dogs lie?

The dog isn't sleeping, it's dead.  Like everything else in FreeBSD, it 
takes time.  If someone wants to donate that time, it'll continue getting 
done, otherwise it'll fall by the wayside.

-- 

Where am I, and what am I doing in this handbasket?

Wes Peters   [EMAIL PROTECTED]

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Discussion on the future of floppies in 5.x and 6.x

2004-01-11 Thread Paul Robinson
Wes Peters wrote:

Faster than loading a single ISO image with only the boot information and 
sysinstall and booting from that, rather than 3 (or 4 or 5) floppies?  A 
CD-R is cheaper, faster, more reliable, and you don't have to keep 
feeding them into the machine.

I think you're missing the point, which I'll come onto, but first, the 
points you raise.

It's not cheaper than a floppy - I have stacks of old floppies here that 
are re-usable, unlike CD-Rs where I have to shell out for a new one 
every time. It isn't faster than a floppy, because I'm still doing an 
FTP install (because I've taken your advice and only downloaded a 3Mb 
file to "save time"). If you assume that burning the CD takes no longer 
than doing a dd (finding the machine would take me longer), it takes the 
same amount of time. Oh, you mean the extra 30 seconds to read the disk? 
Yeah, my life would be *much* improved if I could save that. (I'm trying 
to be ironic... :-) ).

It isn't "more reliable", as I do a diff on /dev/fd0 and the img file to 
make sure everything is OK after the dd, and therefore it's just as 
reliable. In fact, with cheap CD-Rs, I get a coaster-to-usable ratio of 
about 1:2 which is nowhere near as good as 3.5" floppy. As for "Keep 
feeding them into the machine"? It's two disks. Let me write that again. 
2. Two. One + one. This "constant feeding" is hardly likely to give me 
serious RSI. :-)

Perhaps I'm missing something, and I can see why abondoning the current 
method in 5-6 years would be reasonable, but I don't see the immediate 
advantage of making the change right now.

I also don't think it's the issue that needs to be dealt with - 
distribution is much, much, MUCH bigger an issue than "shall we get rid 
of floppies"? I sent this to the list before, but it got ignored, so 
I'll send it again, where Jordan points out we have bigger issues to 
deal with when discussing the "floppy disk problem" whilst discussing 
libh:- (http://rtp1.slowblink.com/~libh/sysinstall2/improvements.html):

"As I mentioned in Section 2.3, one of the more annoying problems with FreeBSD's current distribution format is the dividing line between distributions and packages. There should really only be one type of "distribution format" and, of course, it should be the package (There Can Be Only One). Achieving this means we're first going to have to grapple with 
several problems, however:

First, eliminating the distribution format means either teaching the package tools how to deal with a split archive format (they currently do not) or divorcing ourselves forever from floppies as a distribution medium. This is an issue which would seem an easy one to decide but invariably becomes Highly Religious(tm) every time it's brought up. In some dark corner of the world, there always seems to be somebody still installing FreeBSD via floppies and even some of the fortune 500 folks can cite FreeBSD success stories where they resurrected some old 386 box (with only a floppy drive and no networking/CD/...) and turned it into the star of the office/saved the company/etc etc. That's not to say we can't still bite that particular bullet, just that it's not a decision which will go down easily with everyone and should be well thought-out."

And I have to say, I agree. If abondoning floppies is part of some well-thought-out and well-planned package management strategy, I'm all for it. Otherwise, let sleeping dogs lie?

--
Paul Robinson
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Discussion on the future of floppies in 5.x and 6.x

2004-01-10 Thread William Grim
Wes Peters wrote:

On Friday 09 January 2004 09:34 pm, Marc G. Fournier wrote:
 

On Thu, 8 Jan 2004, Michel TALON wrote:
   

Sincerely FreeBSD developers have more important tasks than spending
hours to fit an installable system on floppies. When FreeBSD used
one floppy, it was tolerable to do floppy installs. With 2 or 3
floppies it is awfully slow, i have done once and will never do it
again.
 

I still use floppies to do my installs, and find getting the base
system up over FTP to generally take <30minutes *shrug*  Faster, IMHO,
then downloading the ISO and burning it to a CD ..
   

Faster than loading a single ISO image with only the boot information and 
sysinstall and booting from that, rather than 3 (or 4 or 5) floppies?  A 
CD-R is cheaper, faster, more reliable, and you don't have to keep 
feeding them into the machine.

 

Yes, and what about my P3-500 server that has no CD drive in it?  I 
hardly think I'm going to purchase a CD drive just for that server.

If there ever comes a time when I have to decide between purchasing a CD 
drive to reinstall a broken installation of FBSD that I have deemed 
unrecoverable or using linux (where I can use floppies all day and 
night), I'll be installing linux.

However, on this note, I would like to say I'd like to help out with a 
floppy project, but I would not want to be "floppy maintainer."  At 
least, not until I knew a lot more about how things worked, and even 
then, I'm not sure, because of time and lack of several test systems.

Later!

--
William Michael Grim
Student, Southern Illinois University at Edwardsville
Unix Network Administrator, SIUE, Computer Science dept.
Phone: (217) 341-6552
Email: [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Discussion on the future of floppies in 5.x and 6.x

2004-01-10 Thread Wes Peters
On Friday 09 January 2004 09:34 pm, Marc G. Fournier wrote:
> On Thu, 8 Jan 2004, Michel TALON wrote:
> >
> > Sincerely FreeBSD developers have more important tasks than spending
> > hours to fit an installable system on floppies. When FreeBSD used
> > one floppy, it was tolerable to do floppy installs. With 2 or 3
> > floppies it is awfully slow, i have done once and will never do it
> > again.
>
> I still use floppies to do my installs, and find getting the base
> system up over FTP to generally take <30minutes *shrug*  Faster, IMHO,
> then downloading the ISO and burning it to a CD ..

Faster than loading a single ISO image with only the boot information and 
sysinstall and booting from that, rather than 3 (or 4 or 5) floppies?  A 
CD-R is cheaper, faster, more reliable, and you don't have to keep 
feeding them into the machine.

-- 

Where am I, and what am I doing in this handbasket?

Wes Peters   [EMAIL PROTECTED]

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Discussion on the future of floppies in 5.x and 6.x

2004-01-10 Thread Nicolas Rachinsky
* Richard Coleman <[EMAIL PROTECTED]> [2004-01-09 20:59 -0500]:
> Richard Coleman wrote:
> >I apologize if this is a dumb question.  But rather than using two 
> >floppies during the install process, why not three or four?
> >
> >Richard Coleman
> >[EMAIL PROTECTED]
> 
> Sorry, I just got caught up on the list, and see that this has already 
> been discussed.  Ignore the question.

I'm not sure that the question is dumb. I think
/usr/src/lib/libstand/splitfs.c should work for this. From the commit
message of it:
|Add splitfs vfs layer into libstand, which allows loading big kernels
|and
|modules split across several physical medias. Following is how it
|works:
|
|The splitfs code, when asked to open "foo" looks for a file
|"foo.split"
|which is a text file containing a list of filenames and media names,
|e.g.
|
|foo.aa "Kernel floppy 1"
|foo.ab "Kernel floppy 2"
|foo.ac "Kernel and modules floppy"
|
|For each file segment, the process is:
|
|- try to open the file
|- prompt "Insert the disk labelled  and press any key..."
|- try to open the file
|- return error if file could not be located

I just took the 4.9-RELEASE install disks and splited mfsroot.gz into
two files put them onto two disks. They booted without any problem to
sysinstall.

So it seems the code to use more disks is already there.

Nicolas

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Discussion on the future of floppies in 5.x and 6.x

2004-01-10 Thread Peter Jeremy
On Fri, Jan 09, 2004 at 10:57:56PM +0100, Martin Nilsson wrote:
>This discussion is just like when the i386 support was removed from the 
>GENERIC kernel, a lot of noise about old systems that wouldn't be able 
>to run (or benefit) from FreeBSD 5 anyway.

There's a big jump between i386 systems and Pentium I/II systems.  I
agree that any "standard" i386 syystem would be very unlikely to be
able to run a generic FreeBSD kernel - the ones that are left are in
embedded systems where they need customised install environments
already.

An old P-I or P-II system is still perfectly adequate to run FreeBSD -
and will be for some time yet.  They make ideal firewalls, print
servers, terminal servers, low-end fileservers etc.  (My home firewall
is a 486).  I agree that you wouldn't want to run OpenOffice or
Mozilla on one but that doesn't make them unusable.

>I fail to see the difference in required labour between creating two 
>floppies or a CD-R/RW disc. Most new machines ship with CD-RW drives 
>today, the only boxes that can't boot from a CD are early Pentium1 class 
>and frankly why run 5.x or 6.x on those?

In a corporate environment, machines are very likely to not include a
CD-RW (and might not even include a CD-ROM).  As for why run 5.x, how
about:
1) because you want some of the features in 5.x - a fileserver could
   benefit enormously from ACLs, UFS2 and snapshots (to name a few)
   even if it's only an old P-I.
2) for support.  4.x will probably be officially de-supported sometime
   in 2005.  At that point, I either need to accept the overhead of
   handling (eg) security fixes myself or migrate to 5.x
   
Peter
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Discussion on the future of floppies in 5.x and 6.x

2004-01-10 Thread Scott Long
Peter Jeremy wrote:
On Fri, Jan 09, 2004 at 04:26:54PM -0600, Matthew D. Fuller wrote:

On Fri, Jan 09, 2004 at 02:23:58PM -0700 I heard the voice of
Scott Long, and lo! it spake thus:
Dag-Erling Sm?rgrav wrote:

yes, we need something like

struct pci_device_info {
  uint32_tpciid;
  charbrand[64];
  charmodel[64];
} my_supported_devices[] = {
  { 0x12345678, "Acme", "Nutcracker 2000" }
};
which is placed in a separate ELF section so we can extract it from
the module.
except it needs to be flexible enough to support other buses than PCI
(SBUS, USB...)
DES
Yeah, this is a good suggestion, the only problem being in making it 
flexible enough to not be a burden on the drivers.  Many drivers
keep one or more flag elements in their tables to flag hardware than
needs special attention.  I'm sure that there are also countless other
pieces of state that drivers would want to associate with a table like
this.
I was poking around a bit (in my completely kernel-fu-lacking way) at
this last night.  For one thing, we could avoid the struct definition,
and instead just mandate a few fields in the structure with given names
as above.  Then, write a little helper .c file with a main() that goes
through the array (with the name given as a preprocessor -D or something)
and spits the info out into a text file.  Compile it up and run it for
each module as we compile it, and assemble the results in a big reference
file.  Then, a userland program (like sysinstall, in this case) can
easily poke through that text file to find and describe the drivers for
devices found.


This is more what I was thinking in terms of.  As well as the PCI ID
and brand/model, we probably would need:
- a priority field, so a generic driver can grab a device if a more
  specific driver isn't found
- the option to use card ID instead of chip ID
- wild-carding (maybe a bitmask)
And this still isn't enough to identify things like the Realtek 8139C+
chips that would prefer re(4) instead of rl(4) (though rl(4) is good
enough to install FreeBSD).
Peter

Right, since there are at least 5 identifying fields in the PCI config
space that might need to be looked at.
Lets not repeat the mistakes of vendors like RedHat that require that a
duplicate table be maintained (with only 2 of the five fields!).
Whether our tables are generated through script magic or through a
stuctured API doesn't matter so long at it adds minimal burden to the
driver maintainership and is guaranteed to always be in sync.
Scott

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Discussion on the future of floppies in 5.x and 6.x

2004-01-09 Thread Peter Jeremy
On Fri, Jan 09, 2004 at 04:26:54PM -0600, Matthew D. Fuller wrote:
>On Fri, Jan 09, 2004 at 02:23:58PM -0700 I heard the voice of
>Scott Long, and lo! it spake thus:
>> Dag-Erling Sm?rgrav wrote:
>> >
>> >yes, we need something like
>> >
>> >struct pci_device_info {
>> >uint32_tpciid;
>> >charbrand[64];
>> >charmodel[64];
>> >} my_supported_devices[] = {
>> >{ 0x12345678, "Acme", "Nutcracker 2000" }
>> >};
>> >
>> >which is placed in a separate ELF section so we can extract it from
>> >the module.
>> >
>> >except it needs to be flexible enough to support other buses than PCI
>> >(SBUS, USB...)
>> >
>> >DES
>> 
>> Yeah, this is a good suggestion, the only problem being in making it 
>> flexible enough to not be a burden on the drivers.  Many drivers
>> keep one or more flag elements in their tables to flag hardware than
>> needs special attention.  I'm sure that there are also countless other
>> pieces of state that drivers would want to associate with a table like
>> this.
>
>I was poking around a bit (in my completely kernel-fu-lacking way) at
>this last night.  For one thing, we could avoid the struct definition,
>and instead just mandate a few fields in the structure with given names
>as above.  Then, write a little helper .c file with a main() that goes
>through the array (with the name given as a preprocessor -D or something)
>and spits the info out into a text file.  Compile it up and run it for
>each module as we compile it, and assemble the results in a big reference
>file.  Then, a userland program (like sysinstall, in this case) can
>easily poke through that text file to find and describe the drivers for
>devices found.

This is more what I was thinking in terms of.  As well as the PCI ID
and brand/model, we probably would need:
- a priority field, so a generic driver can grab a device if a more
  specific driver isn't found
- the option to use card ID instead of chip ID
- wild-carding (maybe a bitmask)

And this still isn't enough to identify things like the Realtek 8139C+
chips that would prefer re(4) instead of rl(4) (though rl(4) is good
enough to install FreeBSD).

Peter
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Discussion on the future of floppies in 5.x and 6.x

2004-01-09 Thread Marc G. Fournier
On Thu, 8 Jan 2004, Michel TALON wrote:

> > And, further, some of us don't have (and don't want) CD burners, and even
> > if we had 'em, don't want to burn (no pun intended ;) a CD blank just to
> > install an OS, when we can just (re-)use 2 floppies and do it across the
> > LAN from a local FTP mirror, which is as fast as a CD drive anyway.
>
> Sincerely FreeBSD developers have more important tasks than spending
> hours to fit an installable system on floppies. When FreeBSD used
> one floppy, it was tolerable to do floppy installs. With 2 or 3 floppies
> it is awfully slow, i have done once and will never do it again.

I still use floppies to do my installs, and find getting the base system
up over FTP to generally take <30minutes *shrug*  Faster, IMHO, then
downloading the ISO and burning it to a CD ..


Marc G. Fournier   Hub.Org Networking Services (http://www.hub.org)
Email: [EMAIL PROTECTED]   Yahoo!: yscrappy  ICQ: 7615664
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Discussion on the future of floppies in 5.x and 6.x

2004-01-09 Thread Avleen Vig
On Fri, Jan 09, 2004 at 02:08:08PM -0800, Julian Elischer wrote:
> > PXE boot against an automated backup/restore service would be much more 
> > useful for this.
> 
> Assuming they have PXE and a supported card..

One point that hasn't been made here against PXE (well, not against it,
but not in favour it):
  What if you dont' have another server to PXE boot from? What if it's
  the only PC in your house? PXE booting might be fine for a
  multi-server network, but when it's the only machine you have at home
  and you don't have a CD burner, you'd be screwed :)

If the etherboot code can be made to use FTP, that would be good.
Otherwise, can we have the mirror servers allow tftp? That would fix
this quite easily.
I might be willing to find hosting for a "boot image" provided it is
small, as scott suggested it might be (3mb?)
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Discussion on the future of floppies in 5.x and 6.x

2004-01-09 Thread Bill Vermillion
Somewhere around Fri, Jan 09, 2004 at 17:11 , the world stopped
and listened as [EMAIL PROTECTED] graced us with
this profound tidbit of wisdom that would fulfill the enjoyment of
future generations:

> --

> Message: 16
> Date: Fri, 09 Jan 2004 22:57:56 +0100
> From: Martin Nilsson <[EMAIL PROTECTED]>
> Subject: Re: Discussion on the future of floppies in 5.x and 6.x
> Cc: [EMAIL PROTECTED]
> Message-ID: <[EMAIL PROTECTED]>
> Content-Type: text/plain; charset=us-ascii; format=flowed

> This is getting stupid!

> This discussion is just like when the i386 support was removed
> from the GENERIC kernel, a lot of noise about old systems that
> wouldn't be able to run (or benefit) from FreeBSD 5 anyway.

There is a difference between old systems and new systems that
don't have CDs.

> >>And, further, some of us don't have (and don't want) CD
> >>burners, and even if we had 'em, don't want to burn (no pun
> >>intended ;) a CD blank just to install an OS, when we can just
> >>(re-)use 2 floppies and do it across the LAN from a local FTP
> >>mirror, which is as fast as a CD drive anyway.

> I fail to see the difference in required labour between creating
> two floppies or a CD-R/RW disc. Most new machines ship with
> CD-RW drives today, the only boxes that can't boot from a CD are
> early Pentium1 class and frankly why run 5.x or 6.x on those?

I have several PIII's that can't boot from a CD because there is no
room for a CD.  These are 1RU units in a colo.  A floppy, two HDs,
on the back two NICs, a serial connector, and a keyboard connector.
The iNTEL 1RU units don't even have graphics cards and the BIOS
boot messgages are routed out the serial port which changes to true
serial after POST.

All are in a colo facility - and I suspect many other have the same
problem.

The only 1RU units I've personally seen with CD units in them are
the little Sun pizza box Netras - SPARC platform - that a colo
client had has front ends for their G4s [running Web Objects] and
the large Sun running an Oracle back end for a data base. And
those CD players were custom made - and exceptionally thin - and
instead of a drawer that came out, the spindle mechanism came out
that you put the CD onto and then it slid back in.

Space is a big consideration in those small units.  All my 2RU
machine have CDs in them.  I'd hate to have to think of taking the
devices out of the racks and then the building to install a new OS.
It's no fun with a floppy and minimal work space in the racks but
I've only had to access them via floppy about twice, as I can
rebuild and reinstall remotely.  As long as I don't have to remake
a file system I'm in good shape.  But CD's just aren't always in
'industrial' type machines - as the only time they'd be used is
during install.  Luckily at least a couple will support PXE.  Not
all will be that lucky.


> End of freebsd-hackers Digest, Vol 42, Issue 10
> ***

Bill

-- 
Bill Vermillion - bv @ wjv . com
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Discussion on the future of floppies in 5.x and 6.x

2004-01-09 Thread Richard Coleman
Richard Coleman wrote:

Scott Long wrote:

All,

Every FreeBSD release cycle in the past year has hit bumps due to install
floppy problems.  This is becoming more and more of a burden on the
Release Engineering Team, as we simply do not have the resources to
constantly battle the floppies.
FreeBSD/i386 is the only port left that generates install floppies.
Their primary purpose is to fascilitate installing FreeBSD on systems
where a CDROM is either not available or is incompatible with the
'Non-Emulated El Torito' boot method that we use on our CDs.  Systems 
that
cannot boot these CDs are typically those that are also not certified for
WinNT4, Win2K, or WinXP.  Thus, nearly all machines produced after 1997
can boot our CDs.

It is certainly possible to run FreeBSD 5.x on machines of this and prior
vintage, and I certainly do not want to dispute or question any motives
here.  However, the number of machines in this category is steadily
declining as time goes on, while the effort put into supporting install
floppies seems to be on the rise.  I certainly do not want to orphan 
these
machines, so we need to find a compromise.

One solution is to find a dedicated 'floppy maintainer' that will
frequently assess the floppies during the normal developement periods and
work closely with the Release Engineering team to ensure that there are
few surprises when it's time to cut a release.  I would expect this 
person
to develop and execute a test plan that covers all of the common aspects
of installing via floppy: basic sanity checks, loading drivers, 
installing
via the various mechanisms, etc.  This person should also be comfortable
with modifying makefiles and the sysinstall source.

The other solution is to replace install floppies with an 'Emulated El
Torito' CD image.  I'm not going to go into the differences between
'non-emulated' and 'emulated' except to say that 'emulated' is the method
used on FreeBSD 4.x (and prior), Win95, and Win98.  Virtually every 
system
in existance that supports a CDROM supports this method.  This image 
would
contain the loader, kernel, and MFS root, just like the current
'bootonly.iso' image, but would be configured for emulated booting.  
Users
could download this image, burn it, boot it, and then install FreeBSD 
just
like they normally would.  Of course this adds the requirement of needing
a CD burner, but these devices are becoming common enough that it could
be a reasonable expectation.

Switching to this method doesn't entirely remove the headache of release
floppies, but it does make it signficantly easier to deal with them.  The
'emulated' method actually uses a 2.88MB floppy image that combines the
first two 1.44MB floppies that we traditionally produce.  By combining
them, we have a bit more flexibility since the driver modules that are on
the second floppy can go back into the kernel image and benefit from the
compression that happens there.
So, this is something to consider before 5.3.  After that, we are
stuck with the consequences of whatever we choose (or don't choose) for
the entire 5.x lifespan.  I do not cherish the thought of fighting
floppies for another 2-3 years.  I'm happy to work with someone who steps
forward and is committed to maintaining the floppies as they are today.
Otherwise, we need to seriously consider the alternative.
Thanks,

Scott


I apologize if this is a dumb question.  But rather than using two 
floppies during the install process, why not three or four?

Richard Coleman
[EMAIL PROTECTED]
Sorry, I just got caught up on the list, and see that this has already 
been discussed.  Ignore the question.

Richard Coleman
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Discussion on the future of floppies in 5.x and 6.x

2004-01-09 Thread Richard Coleman
Scott Long wrote:
All,

Every FreeBSD release cycle in the past year has hit bumps due to install
floppy problems.  This is becoming more and more of a burden on the
Release Engineering Team, as we simply do not have the resources to
constantly battle the floppies.
FreeBSD/i386 is the only port left that generates install floppies.
Their primary purpose is to fascilitate installing FreeBSD on systems
where a CDROM is either not available or is incompatible with the
'Non-Emulated El Torito' boot method that we use on our CDs.  Systems that
cannot boot these CDs are typically those that are also not certified for
WinNT4, Win2K, or WinXP.  Thus, nearly all machines produced after 1997
can boot our CDs.
It is certainly possible to run FreeBSD 5.x on machines of this and prior
vintage, and I certainly do not want to dispute or question any motives
here.  However, the number of machines in this category is steadily
declining as time goes on, while the effort put into supporting install
floppies seems to be on the rise.  I certainly do not want to orphan these
machines, so we need to find a compromise.
One solution is to find a dedicated 'floppy maintainer' that will
frequently assess the floppies during the normal developement periods and
work closely with the Release Engineering team to ensure that there are
few surprises when it's time to cut a release.  I would expect this person
to develop and execute a test plan that covers all of the common aspects
of installing via floppy: basic sanity checks, loading drivers, installing
via the various mechanisms, etc.  This person should also be comfortable
with modifying makefiles and the sysinstall source.
The other solution is to replace install floppies with an 'Emulated El
Torito' CD image.  I'm not going to go into the differences between
'non-emulated' and 'emulated' except to say that 'emulated' is the method
used on FreeBSD 4.x (and prior), Win95, and Win98.  Virtually every system
in existance that supports a CDROM supports this method.  This image would
contain the loader, kernel, and MFS root, just like the current
'bootonly.iso' image, but would be configured for emulated booting.  Users
could download this image, burn it, boot it, and then install FreeBSD just
like they normally would.  Of course this adds the requirement of needing
a CD burner, but these devices are becoming common enough that it could
be a reasonable expectation.
Switching to this method doesn't entirely remove the headache of release
floppies, but it does make it signficantly easier to deal with them.  The
'emulated' method actually uses a 2.88MB floppy image that combines the
first two 1.44MB floppies that we traditionally produce.  By combining
them, we have a bit more flexibility since the driver modules that are on
the second floppy can go back into the kernel image and benefit from the
compression that happens there.
So, this is something to consider before 5.3.  After that, we are
stuck with the consequences of whatever we choose (or don't choose) for
the entire 5.x lifespan.  I do not cherish the thought of fighting
floppies for another 2-3 years.  I'm happy to work with someone who steps
forward and is committed to maintaining the floppies as they are today.
Otherwise, we need to seriously consider the alternative.
Thanks,

Scott
I apologize if this is a dumb question.  But rather than using two 
floppies during the install process, why not three or four?

Richard Coleman
[EMAIL PROTECTED]


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Discussion on the future of floppies in 5.x and 6.x

2004-01-09 Thread Matthew D. Fuller
On Fri, Jan 09, 2004 at 02:23:58PM -0700 I heard the voice of
Scott Long, and lo! it spake thus:
> Dag-Erling Sm?rgrav wrote:
> >
> >yes, we need something like
> >
> >struct pci_device_info {
> >uint32_tpciid;
> >charbrand[64];
> >charmodel[64];
> >} my_supported_devices[] = {
> >{ 0x12345678, "Acme", "Nutcracker 2000" }
> >};
> >
> >which is placed in a separate ELF section so we can extract it from
> >the module.
> >
> >except it needs to be flexible enough to support other buses than PCI
> >(SBUS, USB...)
> >
> >DES
> 
> Yeah, this is a good suggestion, the only problem being in making it 
> flexible enough to not be a burden on the drivers.  Many drivers
> keep one or more flag elements in their tables to flag hardware than
> needs special attention.  I'm sure that there are also countless other
> pieces of state that drivers would want to associate with a table like
> this.

I was poking around a bit (in my completely kernel-fu-lacking way) at
this last night.  For one thing, we could avoid the struct definition,
and instead just mandate a few fields in the structure with given names
as above.  Then, write a little helper .c file with a main() that goes
through the array (with the name given as a preprocessor -D or something)
and spits the info out into a text file.  Compile it up and run it for
each module as we compile it, and assemble the results in a big reference
file.  Then, a userland program (like sysinstall, in this case) can
easily poke through that text file to find and describe the drivers for
devices found.

I also was thinking that perhaps we should just stick the vendor/model
ID's (and maybe submodel and bus, too) into a string and export it via
sysctl; that was we don't have to use another tool or manually grub
around /dev/pci and whatever other buses there might be, to identify
devices pining away for a driver to mate with.


-- 
Matthew Fuller (MF4839)   |  [EMAIL PROTECTED]
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/

"The only reason I'm burning my candle at both ends, is because I
  haven't figured out how to light the middle yet"
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Discussion on the future of floppies in 5.x and 6.x

2004-01-09 Thread Avleen Vig
On Fri, Jan 09, 2004 at 10:57:56PM +0100, Martin Nilsson wrote:
> This discussion is just like when the i386 support was removed from the 
> GENERIC kernel, a lot of noise about old systems that wouldn't be able 
> to run (or benefit) from FreeBSD 5 anyway.

No, this is nothing like that.

> >>And, further, some of us don't have (and don't want) CD burners, and even
> >>if we had 'em, don't want to burn (no pun intended ;) a CD blank just to
> >>install an OS, when we can just (re-)use 2 floppies and do it across the
> >>LAN from a local FTP mirror, which is as fast as a CD drive anyway.
> 
> I fail to see the difference in required labour between creating two 
> floppies or a CD-R/RW disc. Most new machines ship with CD-RW drives 
> today, the only boxes that can't boot from a CD are early Pentium1 class 
> and frankly why run 5.x or 6.x on those?

Incorrect. I and others have already given several examples of how
modern machines cannot boot from CD for all the various reasons given.
If the freebsd hosting mirrors don't mind us NFS mounting their servers
to get the boot image, etherboot would be by far the simplest solution
to maintain in the long run - then we can go with Scott's approach of
getting rid of the current floppies, and adding in the other suggested
approach of downloading the boot img from a remote server and "running"
it. (I believe etherboot can be used like this, please someone correct
me if i'm wrong).
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Discussion on the future of floppies in 5.x and 6.x

2004-01-09 Thread Julian Elischer


On Fri, 9 Jan 2004, Martin Nilsson wrote:

> This is getting stupid!
> 
> 
> > Here at Vicor, we have over a thousand machines spread over about 
> > 20 sites. About 10 of those machines have cdrom drives. Our plans call
> > for moving from 4.x to 5.x, probably at the end of 2004, maybe early
> > 2005. Most of the machien swill not have been replaced by then so 
> > we'll still have very few cdroms. 
> 
> That is why I want to get boot from an USB CDROM to work, this way you 
> just plug in the portable drive in the machine that you want to boot 
> just like you do with a floppy, the difference is that you don't have to 
> wait to change floppies. You can also save some money by not having to 
> buy CD/floppy drives for your servers. Slim drives (for server use) are 
> not cheap. Besides floppydrives tend to collect dust and never work 
> anyway when you want to use them.
> 

Many of the older machines don't have the USB connectors brough out of
the boxes The motherboards mostly have them but even then I wouldn't
guarantee that all of them do. Certainly I know that many of the
machines from 4 or so years ago have no externally accessible USB
connectors. (custom cases etc.). These boxes are doign fixed jobs and as
long as they can "keep up" they will not be replaced. That's the "real
world".



> > Luckily this would probably not be an issue for the upgrade, but
> > the Custommer Engineers (CEs) need to be able to rebuild machine quickly
> > in the case of disk failures or other problems. They use floppies at the
> > moment for this.
> 
> PXE boot against an automated backup/restore service would be much more 
> useful for this.

Assuming they have PXE and a supported card..

> 
>   /Martin
> ___
> [EMAIL PROTECTED] mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "[EMAIL PROTECTED]"
> 

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Discussion on the future of floppies in 5.x and 6.x

2004-01-09 Thread Julian Elischer


On Fri, 9 Jan 2004, Scott Long wrote:

> Julian Elischer wrote:
> > 
> > 
> > 
> > 
> > Here at Vicor, we have over a thousand machines spread over about 
> > 20 sites. About 10 of those machines have cdrom drives. Our plans call
> > for moving from 4.x to 5.x, probably at the end of 2004, maybe early
> > 2005. Most of the machien swill not have been replaced by then so 
> > we'll still have very few cdroms. 
> > Luckily this would probably not be an issue for the upgrade, but
> > the Custommer Engineers (CEs) need to be able to rebuild machine quickly
> > in the case of disk failures or other problems. They use floppies at the
> > moment for this.
> > 
> > I could immagine that a floppy that did a net-boot might 
> > be a possibility, but retraining them to do things differently is
> > always a problem.
> > 
> > 
> 
> Can these machines netboot/PXEboot?  In any case, there looks to be some
> prospects for someone stepping forward to help with floppies.  If Vicor
> wants to help out too, that would be wonderful.

I have grave doubts as to all 1000  machines being able to net/PXE 
boot.. They have come from varying sources at different times..

Of course we may be able to produce our own boot floppies with unneeded
options removed.. A net-booting floppy may be enough, and I'll add it to
my list of things that I'll keep my eye on.. If we get close and no-one
has worked on it I'll see what I need to do to get it to work for us :-)

(At that point I'd get payed to do whatever it took  :-)


> 
> Scott
> 
> 

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Discussion on the future of floppies in 5.x and 6.x

2004-01-09 Thread Martin Nilsson
This is getting stupid!

This discussion is just like when the i386 support was removed from the 
GENERIC kernel, a lot of noise about old systems that wouldn't be able 
to run (or benefit) from FreeBSD 5 anyway.

And, further, some of us don't have (and don't want) CD burners, and even
if we had 'em, don't want to burn (no pun intended ;) a CD blank just to
install an OS, when we can just (re-)use 2 floppies and do it across the
LAN from a local FTP mirror, which is as fast as a CD drive anyway.
I fail to see the difference in required labour between creating two 
floppies or a CD-R/RW disc. Most new machines ship with CD-RW drives 
today, the only boxes that can't boot from a CD are early Pentium1 class 
and frankly why run 5.x or 6.x on those?


Here at Vicor, we have over a thousand machines spread over about 
20 sites. About 10 of those machines have cdrom drives. Our plans call
for moving from 4.x to 5.x, probably at the end of 2004, maybe early
2005. Most of the machien swill not have been replaced by then so 
we'll still have very few cdroms. 
That is why I want to get boot from an USB CDROM to work, this way you 
just plug in the portable drive in the machine that you want to boot 
just like you do with a floppy, the difference is that you don't have to 
wait to change floppies. You can also save some money by not having to 
buy CD/floppy drives for your servers. Slim drives (for server use) are 
not cheap. Besides floppydrives tend to collect dust and never work 
anyway when you want to use them.

Luckily this would probably not be an issue for the upgrade, but
the Custommer Engineers (CEs) need to be able to rebuild machine quickly
in the case of disk failures or other problems. They use floppies at the
moment for this.
PXE boot against an automated backup/restore service would be much more 
useful for this.

/Martin
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Discussion on the future of floppies in 5.x and 6.x

2004-01-09 Thread Scott Long
Julian Elischer wrote:


On Thu, 8 Jan 2004, Matthew D. Fuller wrote:


On Wed, Jan 07, 2004 at 11:50:59PM -0800 I heard the voice of
Avleen Vig, and lo! it spake thus:
While it is indeed true that most machines since 1997 will support this
CD format, please take in to account:
And, further, some of us don't have (and don't want) CD burners, and even
if we had 'em, don't want to burn (no pun intended ;) a CD blank just to
install an OS, when we can just (re-)use 2 floppies and do it across the
LAN from a local FTP mirror, which is as fast as a CD drive anyway.
It seems to me that we could split more out into modules, and/or add more
disks of modules (maybe categorize a "storage device" modules disk, a
"network drivers" modules disk, etc, keeping just the more common devices
in the main kernel).  Last I saw, the current system only created a
single modules disk, which was a godsend to a kernel overflowing one
disk, but as we add more and more stuff becomes another, albeit larger,
noose.


Here at Vicor, we have over a thousand machines spread over about 
20 sites. About 10 of those machines have cdrom drives. Our plans call
for moving from 4.x to 5.x, probably at the end of 2004, maybe early
2005. Most of the machien swill not have been replaced by then so 
we'll still have very few cdroms. 
Luckily this would probably not be an issue for the upgrade, but
the Custommer Engineers (CEs) need to be able to rebuild machine quickly
in the case of disk failures or other problems. They use floppies at the
moment for this.

I could immagine that a floppy that did a net-boot might 
be a possibility, but retraining them to do things differently is
always a problem.


Can these machines netboot/PXEboot?  In any case, there looks to be some
prospects for someone stepping forward to help with floppies.  If Vicor
wants to help out too, that would be wonderful.
Scott

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Discussion on the future of floppies in 5.x and 6.x

2004-01-09 Thread Scott Long
Dag-Erling Smørgrav wrote:
Peter Jeremy <[EMAIL PROTECTED]> writes:

The (conceptually) simplest approach would be for all drivers to
advertise the PCI IDs that they can support (together with a priority)
in a manner that would allow such a list to be generated automatically.


yes, we need something like

struct pci_device_info {
uint32_tpciid;
charbrand[64];
charmodel[64];
} my_supported_devices[] = {
{ 0x12345678, "Acme", "Nutcracker 2000" }
};
which is placed in a separate ELF section so we can extract it from
the module.
except it needs to be flexible enough to support other buses than PCI
(SBUS, USB...)
DES
Yeah, this is a good suggestion, the only problem being in making it 
flexible enough to not be a burden on the drivers.  Many drivers
keep one or more flag elements in their tables to flag hardware than
needs special attention.  I'm sure that there are also countless other
pieces of state that drivers would want to associate with a table like
this.

Scott

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Discussion on the future of floppies in 5.x and 6.x

2004-01-09 Thread Dag-Erling Smørgrav
Peter Jeremy <[EMAIL PROTECTED]> writes:
> Keep in mind that older systems probably won't boot over the network
> without a netboot ROM or similar.  The netboot ROM images are (or
> were) in the distribution but aren't much use without an EPROM
> burner.

I believe that in most cases you can dd the ROM image to a floppy and
boot from it.

DES
-- 
Dag-Erling Smørgrav - [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Discussion on the future of floppies in 5.x and 6.x

2004-01-09 Thread Peter Jeremy
On Thu, Jan 08, 2004 at 10:52:08AM +0100, Daniel Lang wrote:
>Matthew D. Fuller wrote on Thu, Jan 08, 2004 at 01:58:11AM -0600:
>[..]
>> And, further, some of us don't have (and don't want) CD burners, and even
>> if we had 'em, don't want to burn (no pun intended ;) a CD blank just to
>> install an OS, when we can just (re-)use 2 floppies and do it across the
>> LAN from a local FTP mirror, which is as fast as a CD drive anyway.
>
>That's no point, as you can use a CD-RW, so no media is wasted.

Not all CD readers will read CD-RW's (I have one that won't).  And
this doesn't solve the problem of not having a CD burner or installing
onto a system that either doesn't have a CD drive or won't boot off
one (I have systems in both categories).

>On the other hand, I guess such systems are able to boot over
>the network. I'd love to see a integrated boot and installation
>procedure that utilizes PXE (or any other network boot method)
>and advocates it. (In this regard I just love Suns).

Keep in mind that older systems probably won't boot over the network
without a netboot ROM or similar.  The netboot ROM images are (or
were) in the distribution but aren't much use without an EPROM burner.

Peter
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Discussion on the future of floppies in 5.x and 6.x

2004-01-09 Thread Peter Jeremy
On Thu, Jan 08, 2004 at 08:30:17PM -0800, Avleen Vig wrote:
>A simple website which lets you choose what drivers you want (anyone
>seen the .muttrc config page? :)
>That should be really easy to do with a little perl CGI.
>I might take a crack at this in the next week or so.

FWIW, Plan-9 ( http://plan9.bell-labs.com/plan9dist/index.html ) does
this: You describe your hardware via a WEB form and the site spits out
a boot floppy customised to your hardware.  In order for this to be
practical, we'd need to avoid having to fully compile a custom kernel
- we'd probably need to develop and use the a 'binary distribution'
approach (as for all the commercial Unices).

Peter
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Discussion on the future of floppies in 5.x and 6.x

2004-01-09 Thread Dag-Erling Smørgrav
Peter Jeremy <[EMAIL PROTECTED]> writes:
> The (conceptually) simplest approach would be for all drivers to
> advertise the PCI IDs that they can support (together with a priority)
> in a manner that would allow such a list to be generated automatically.

yes, we need something like

struct pci_device_info {
uint32_tpciid;
charbrand[64];
charmodel[64];
} my_supported_devices[] = {
{ 0x12345678, "Acme", "Nutcracker 2000" }
};

which is placed in a separate ELF section so we can extract it from
the module.

except it needs to be flexible enough to support other buses than PCI
(SBUS, USB...)

DES
-- 
Dag-Erling Smørgrav - [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Discussion on the future of floppies in 5.x and 6.x

2004-01-09 Thread Peter Jeremy
On Fri, Jan 09, 2004 at 04:38:11PM +0100, Dag-Erling Smørgrav wrote:
>"M. Warner Losh" <[EMAIL PROTECTED]> writes:
>> [EMAIL PROTECTED] (Dag-Erling Smørgrav) writes:
>> : 2) use pciconf -l (or direct access to /dev/pci) to retrieve the PCI
>> :IDs of unclaimed devices, look them up in a list of supported PCI
>> :devices, and load the appropriate module.
>> There's some ongoing work to make this easier to do.  There are some
>> issues with doing this, but nothing that can't be overcome.  Every PCI
>> driver in the tree will likely need to change in some form to make
>> this happen, however.
>
>Not necessarily; one could, as a temporary measure, create and
>maintain the list of supported PCI IDs manually.

These sort of 'temporary measures' have a nasty habit of becoming
permanent - witness sysinstall itself.  Having to keep two lists
of PCI IDs in sync manually is a maintenance nightmare.

The (conceptually) simplest approach would be for all drivers to
advertise the PCI IDs that they can support (together with a priority)
in a manner that would allow such a list to be generated automatically.
This would be fairly trivial for the PCI drivers that already scan
a table of PCI IDs, but would be a nuisance for the drivers that have
the PCI IDs wired into the probe code.

Peter
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Discussion on the future of floppies in 5.x and 6.x

2004-01-09 Thread Julian Elischer




On Thu, 8 Jan 2004, Matthew D. Fuller wrote:

> On Wed, Jan 07, 2004 at 11:50:59PM -0800 I heard the voice of
> Avleen Vig, and lo! it spake thus:
> > 
> > While it is indeed true that most machines since 1997 will support this
> > CD format, please take in to account:
> 
> And, further, some of us don't have (and don't want) CD burners, and even
> if we had 'em, don't want to burn (no pun intended ;) a CD blank just to
> install an OS, when we can just (re-)use 2 floppies and do it across the
> LAN from a local FTP mirror, which is as fast as a CD drive anyway.
> 
> It seems to me that we could split more out into modules, and/or add more
> disks of modules (maybe categorize a "storage device" modules disk, a
> "network drivers" modules disk, etc, keeping just the more common devices
> in the main kernel).  Last I saw, the current system only created a
> single modules disk, which was a godsend to a kernel overflowing one
> disk, but as we add more and more stuff becomes another, albeit larger,
> noose.

Here at Vicor, we have over a thousand machines spread over about 
20 sites. About 10 of those machines have cdrom drives. Our plans call
for moving from 4.x to 5.x, probably at the end of 2004, maybe early
2005. Most of the machien swill not have been replaced by then so 
we'll still have very few cdroms. 
Luckily this would probably not be an issue for the upgrade, but
the Custommer Engineers (CEs) need to be able to rebuild machine quickly
in the case of disk failures or other problems. They use floppies at the
moment for this.

I could immagine that a floppy that did a net-boot might 
be a possibility, but retraining them to do things differently is
always a problem.

> 
> 
> -- 
> Matthew Fuller (MF4839)   |  [EMAIL PROTECTED]
> Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
> 
> "The only reason I'm burning my candle at both ends, is because I
>   haven't figured out how to light the middle yet"
> ___
> [EMAIL PROTECTED] mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "[EMAIL PROTECTED]"
> 

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Discussion on the future of floppies in 5.x and 6.x

2004-01-09 Thread Jason Slagle
On Thu, 8 Jan 2004, Diomidis Spinellis wrote:

> I presume the above means a PXE *client*.  This would be cool, but by no
> means trivial.  I looked at this in the past when I wanted to network
> boot FreeBSD on a couple of machines that did not support a boot ROM and
> reached a dead end; I ended up using PicoBSD and NFS-mounting most of
> the stuff.

What about etherboot?  Doesn't it do exactly this?

Jason

-- 
Jason Slagle - CCNP - CCDP
/"\ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
\ /   ASCII Ribbon Campaign  .
 X  - NO HTML/RTF in e-mail  .
/ \ - NO Word docs in e-mail .



___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Discussion on the future of floppies in 5.x and 6.x

2004-01-09 Thread Josh Paetzel
> > There are several documents linked off of http://www.freebsd.org/releng
> > that describe how to build a release.  It's not nearly as arcane of a
> > process as it used to be 5 years ago.  The biggest barrier to entry is
> > probably disk space.  You'll need a good 5GB free to hold the CVS repo,
> > chroot environment, and resulting bits.
> 
> Well, I've got the CVS repo, though boy, has *THAT* ever grown since I
> built this system; I had to trim it down to only src and ports, and even
> so:
> /dev/da1s1e 2032623 1769089 10092595%/usr/cvs
> 
> Of course, I left out the ports and docs parts of the release last time I
> tried (which was in fact about 5 years ago ;), though I had all kinda of
> troubles with parts of THAT, too.  But still, I don't have even a tenth
> that much hard drive space around.
> 
> 
> > Yes, to build the floppies you need to build most of the release, but
> > once you've built the release, you can back-step and rebuild the
> > floppies at will.
> 
> And building the whole release is quite an ordeal on a Pentium Pro  :)
> 
> 
> Still, I'm willing to donate some time and brain to the problem, since
> apparently I kinda care about it.  It seems to me that the probing
> problem above is the biggest problem from a real coding POV; the rest is
> mostly just a whole heck of a lot of implementation, and "inconvenience"
> from the usability standpoint.  That's a breaking point.
> 
> 

I'll donate the disk space and CPU time if you want to run with this.  I 
have an interest in keeping floppies around, but not much ability to help out.
  
Josh Paetzel


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Discussion on the future of floppies in 5.x and 6.x

2004-01-09 Thread Dag-Erling Smørgrav
"M. Warner Losh" <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] (Dag-Erling Smørgrav) writes:
> : 2) use pciconf -l (or direct access to /dev/pci) to retrieve the PCI
> :IDs of unclaimed devices, look them up in a list of supported PCI
> :devices, and load the appropriate module.
> There's some ongoing work to make this easier to do.  There are some
> issues with doing this, but nothing that can't be overcome.  Every PCI
> driver in the tree will likely need to change in some form to make
> this happen, however.

Not necessarily; one could, as a temporary measure, create and
maintain the list of supported PCI IDs manually.

I had a prototype once (though my purpose at the time was to generate
kernel configs, not load modules).  I dropped it because someone else
was working on the same thing and had it seemed they'd gotten further
than I had.  I still have the sources though...

(rev 1.32 of sys/dev/pci/pcireg.h was a side effect of that work)

DES
-- 
Dag-Erling Smørgrav - [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Discussion on the future of floppies in 5.x and 6.x

2004-01-09 Thread M. Warner Losh
In message: <[EMAIL PROTECTED]>
[EMAIL PROTECTED] (Dag-Erling Smørgrav) writes:
: 2) use pciconf -l (or direct access to /dev/pci) to retrieve the PCI
:IDs of unclaimed devices, look them up in a list of supported PCI
:devices, and load the appropriate module.

There's some ongoing work to make this easier to do.  There are some
issues with doing this, but nothing that can't be overcome.  Every PCI
driver in the tree will likely need to change in some form to make
this happen, however.

Warner

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Discussion on the future of floppies in 5.x and 6.x

2004-01-09 Thread Sergey Babkin
Leo Bicknell wrote:
> 
> I'm going to propose a different solution that was brought up about
> two years ago (although I can't find it now).
> 
> You start with something like the CD boot image mentioned, that is
> a 3-5 Meg iso image that basically contains what is now on the
> floppies (perhaps with a few more drivers/modules) and nothing more.
> Downloading and burning to CD would be the primary method of install.
> 
> Then, to replace the current floppy process, a new floppy installer
> is created.  It may or may not be based on FreeBSD, but what it

I guess a simple variation would be to split the CD boot filesystem
into multiple floppies. Then remove the current contents from
the MFSROOT floppy and put there a small program (plus possibly
the first part of the split CD filesystem image) that would load
the boot filesystem from the bunch of floppies into memory,
load the extra kernel modules, and then start the installer
from memory just as it would go when booted from CD. That should 
really be a no-brainer as long as the base kernel still fits onto one
floppy. The only inconvenience is that we get something like 6
install floppies instead of 2, but it's not _such_ a big deal.

-SB
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Discussion on the future of floppies in 5.x and 6.x

2004-01-09 Thread Paul Robinson
On Fri, Jan 09, 2004 at 02:00:40PM +1030, Daniel O'Connor wrote:

> You still need the right drivers, ie which SCSI controller/network/... cards 
> you have to get a minimal install is _more_ when you are doing FTP (you need 
> a network).

Out of around 300+ installs of FreeBSD I've done over the last few years, 
about 12 of them were by CD. The rest were FTP kick-started off floppy. 
Normally, because I happened to have the two floppies I needed in my shirt 
pocket.

Since 4.x I have never had a problem with drivers, depsite installing on a 
range of hardware from non-branded Taiwanese notebooks through to £30k 
enterprise servers.

I don't see the problem with floppy install.

However, as Jordan said when discussing libh 
(http://rtp1.slowblink.com/~libh/sysinstall2/improvements.html):

"As I mentioned in Section 2.3, one of the more annoying problems with 
FreeBSD's current distribution format is the dividing line between 
distributions and packages. There should really only be one type of 
"distribution format" and, of course, it should be the package (There Can Be 
Only One). Achieving this means we're first going to have to grapple with 
several problems, however:

First, eliminating the distribution format means either teaching the 
package tools how to deal with a split archive format (they currently do 
not) or divorcing ourselves forever from floppies as a distribution medium. 
This is an issue which would seem an easy one to decide but invariably 
becomes Highly Religious(tm) every time it's brought up. In some dark corner 
of the world, there always seems to be somebody still installing FreeBSD via 
floppies and even some of the fortune 500 folks can cite FreeBSD success 
stories where they resurrected some old 386 box (with only a floppy drive 
and no networking/CD/...) and turned it into the star of the office/saved 
the company/etc etc. That's not to say we can't still bite that particular 
bullet, just that it's not a decision which will go down easily with 
everyone and should be well thought-out."

I should point out, this appears to have been written some time ago, late 
2002 I'm guessing.
 
-- 
Paul Robinson
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Discussion on the future of floppies in 5.x and 6.x

2004-01-09 Thread Daniel O'Connor
On Friday 09 January 2004 19:37, Dag-Erling Smørgrav wrote:
> 2) use pciconf -l (or direct access to /dev/pci) to retrieve the PCI
>IDs of unclaimed devices, look them up in a list of supported PCI
>devices, and load the appropriate module.

You know, when I wrote the code in sysinstall to load KLD's I thought about 
this..
Unfortunatly there IS no such list :(

I am not sure how hard it would be to generate, but I think it's non-trivial 
(although probably not too difficult to maintain once it exists)

-- 
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum
GPG Fingerprint - 9A8C 569F 685A D928 5140  AE4B 319B 41F4 5D17 FDD5

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Discussion on the future of floppies in 5.x and 6.x

2004-01-09 Thread Matthew D. Fuller
On Fri, Jan 09, 2004 at 12:48:55AM -0700 I heard the voice of
Scott Long, and lo! it spake thus:
> Daniel O'Connor wrote:
> >BTW Does camcontrol rescan cause the devices to be detected? Perhaps 
> >sysinstall could be "enhanced" to perform this duty as part of it's 
> >reprobe  machinations.
> 
> See my comment about blowing out the mfsroot.gz file.  If you're not
> careful with this one then you'll wind up pulling in libcam, which will
> certainly create a size problem.

# $FreeBSD: src/release/i386/boot_crunch.conf,v 1.56 2003/01/23 08:30:47 ru Exp $
[...]
progs [...] camcontrol
[...]
libs [...] -lcam [...]


-- 
Matthew Fuller (MF4839)   |  [EMAIL PROTECTED]
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/

"The only reason I'm burning my candle at both ends, is because I
  haven't figured out how to light the middle yet"

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Discussion on the future of floppies in 5.x and 6.x

2004-01-09 Thread Dag-Erling Smørgrav
Scott Long <[EMAIL PROTECTED]> writes:
> Incorrect.  Scanning SCSI buses is something that does not happen
> automatically.  There is magic in the boot process that makes it happen
> near the end, right before the kernel looks for the root device.
> However, that is the exception to the rule.  If you load a SCSI driver
> after the kernel has booted, the SCSI channel behind it will _not_ be
> probed automatically.

'camcontrol rescan all'

> Take something like the if_dc(4) driver.  It covers literally _dozens_
> of cards and chips, all under different brands and manufacturers.  There
> is no way that a single line description file will tell you if your
> hardware is supported by the if_dc driver.  But this is a minor nit.

1) keep drivers for ISA devices in the kernel

2) use pciconf -l (or direct access to /dev/pci) to retrieve the PCI
   IDs of unclaimed devices, look them up in a list of supported PCI
   devices, and load the appropriate module.

DES
-- 
Dag-Erling Smørgrav - [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Discussion on the future of floppies in 5.x and 6.x

2004-01-09 Thread Scott Long
Daniel O'Connor wrote:
On Friday 09 January 2004 17:32, Scott Long wrote:


Scott also said stuff like SCSI cards won't get probed if a module is
loaded but I can't see why that is true.. The module will load, the
device get detected, and then sysinstall is told to reprobe the hardware,
so it should pick it up.
Incorrect.  Scanning SCSI buses is something that does not happen
automatically.  There is magic in the boot process that makes it happen
near the end, right before the kernel looks for the root device.
However, that is the exception to the rule.  If you load a SCSI driver
after the kernel has booted, the SCSI channel behind it will _not_ be
probed automatically.  Trust me on this one.  Fixing this particular
problem is well beyond the scope of fixing floppies in general.  Until
it gets fixed, floppies will just have to deal with it.


Yech sucky :(


I see the 'which kld goes with what device' problem as separate to this
issue. The KLD load stuff DOES show a small description for each KLD so
it isn't a total black box, and heck, you can just pick everything and
cross your fingers :)
Take something like the if_dc(4) driver.  It covers literally _dozens_
of cards and chips, all under different brands and manufacturers.  There
is no way that a single line description file will tell you if your
hardware is supported by the if_dc driver.  But this is a minor nit.


Yes..


As I've stated before, loading kernel modules after the kernel has
booted is the wrong time to do it.  The loader needs to be enhanced to
be able to take care of this.  Once that happens, we can trivially
modify the release scripts to allow an arbitrary number of driver
floppies to be created, and the maintenance nightmare goes away for
the most part.


I don't necessarily agree here - I think sysinstall is a better place because 
it's much much easier to write stuff for it than the loader. In the example 
you mention the only reason to use the loader is because the SCSI subsystem 
won't reprobe when a new SCSI bus comes online which sounds like a bug.

One thing that FreeBSD _sorely_ lacks is the ability to easily use 
vendor-supplied driver disks.  It is not unusual for a vendor to want
to replace a buggy/incomplete driver that is in the base system with one
that is better.  This is incredibly difficult to do in FreeBSD; some
drivers cannot be unloaded after being loaded, some drivers are compiled
into the kernel for space considerations.  If we design a mice interface
for handling module loading/unload, multiple floppies, etc, in the
boot-loader, then we solve this problem.  Btw, I speak of this
first-hand; not having a vendor-friendly method for updating drivers
makes FreeBSD very, very hard to support, which means that FreeBSD is
less likely to receive support.

BTW Does camcontrol rescan cause the devices to be detected? Perhaps 
sysinstall could be "enhanced" to perform this duty as part of it's reprobe  
machinations.

See my comment about blowing out the mfsroot.gz file.  If you're not
careful with this one then you'll wind up pulling in libcam, which will
certainly create a size problem.  Don't forget that some driver modules
live on the same floppy as mfsroot.gz.  Any increase in here means that
another driver doesn't fit there and has to go somewhere else.

Well, except when mfsroot.gz becomes too large to fit on a single
floppy.  Right now it is about 90k away from that.  What happens when
mount_nfsv4 gets put on there?  John Baldwin and I already spat ent a
day over the holiday break making the mfsroot.gz image fit given the
new requirements created by having a dynamic root.  What happens the
next time that it overflows?  It's not like the driver floppies where
you can dike more stuff to another disk; this is a single image.  Do
we come up with a method for having multiple, segmented images?  Who
writes the code to do that?
If we are going to keep floppies, then we need people who are willing to
tackle these issues and keep them under control.


I agree with that! :)

However, given your example above, I would just put mount_nfsv4 on another 
floppy, although if sysinstall (or it's replacement) is too large, there will 
need to be the ability to load N floppy images into memory.
Sysinstall is based on the concept that the root filesystem is populated 
with all of the tools that it needs.  It has no concept of looking at 
other media/filesystems for tools.  So, who is going to teach it how to
do this?  I personally think that this would be a hack anyways.  If we 
need to support an mfsroot.gz that is too big for a single floppy, then
we need to invent a way to span it across multiple floppies, not 
randomly put the tools individually onto whatever floppy isn't full this 
week.

If we are going to do the work to keep floppies, then we need to put in
a little effort to do it right and not turn it into a collection of
miserable hacks (not more than it already is).
Anyways, I've debated this as much as I can.  I'm looking for

Re: Discussion on the future of floppies in 5.x and 6.x

2004-01-09 Thread Matthew D. Fuller
On Fri, Jan 09, 2004 at 05:50:59PM +1030 I heard the voice of
Daniel O'Connor, and lo! it spake thus:
> 
> I don't necessarily agree here - I think sysinstall is a better place because 
> it's much much easier to write stuff for it than the loader. In the example 
> you mention the only reason to use the loader is because the SCSI subsystem 
> won't reprobe when a new SCSI bus comes online which sounds like a bug.

Indeed.  I think it's actually (specifically and as a class) the sort of
bug/feature that very much impacts on the floppy situation, since it
prevents us from using an otherwise open road to move stuff around.  Even
if we have to write some code in sysinstall or its successors to trigger
the rescan from userland (ie, the 'camcontrol rescan' point), I think
that's a reasonable road (and likely the easier way).  But that's a bit
out of my depth.


> > Well, except when mfsroot.gz becomes too large to fit on a single
> > floppy.  Right now it is about 90k away from that.  What happens when
> > mount_nfsv4 gets put on there?  John Baldwin and I already spat ent a
> > day over the holiday break making the mfsroot.gz image fit given the
> > new requirements created by having a dynamic root.
> 
> However, given your example above, I would just put mount_nfsv4 on another 
> floppy, although if sysinstall (or it's replacement) is too large, there will 
> need to be the ability to load N floppy images into memory.

This is that situation where the "fetch installer program thingy from
install media on the fly" solution comes into play.


-- 
Matthew Fuller (MF4839)   |  [EMAIL PROTECTED]
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/

"The only reason I'm burning my candle at both ends, is because I
  haven't figured out how to light the middle yet"
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Discussion on the future of floppies in 5.x and 6.x

2004-01-09 Thread Nicolas Rachinsky
* Scott Long <[EMAIL PROTECTED]> [2004-01-09 00:02 -0700]:
> Well, except when mfsroot.gz becomes too large to fit on a single
> floppy.  Right now it is about 90k away from that.  What happens when
> mount_nfsv4 gets put on there?  John Baldwin and I already spent a
> day over the holiday break making the mfsroot.gz image fit given the
> new requirements created by having a dynamic root.  What happens the
> next time that it overflows?  It's not like the driver floppies where
> you can dike more stuff to another disk; this is a single image.  Do
> we come up with a method for having multiple, segmented images?  Who
> writes the code to do that?

Shouldn't lib/libstand/splitfs.c do this?

Nicolas
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Discussion on the future of floppies in 5.x and 6.x

2004-01-09 Thread Daniel O'Connor
On Friday 09 January 2004 17:32, Scott Long wrote:

> > Scott also said stuff like SCSI cards won't get probed if a module is
> > loaded but I can't see why that is true.. The module will load, the
> > device get detected, and then sysinstall is told to reprobe the hardware,
> > so it should pick it up.
>
> Incorrect.  Scanning SCSI buses is something that does not happen
> automatically.  There is magic in the boot process that makes it happen
> near the end, right before the kernel looks for the root device.
> However, that is the exception to the rule.  If you load a SCSI driver
> after the kernel has booted, the SCSI channel behind it will _not_ be
> probed automatically.  Trust me on this one.  Fixing this particular
> problem is well beyond the scope of fixing floppies in general.  Until
> it gets fixed, floppies will just have to deal with it.

Yech sucky :(

> > I see the 'which kld goes with what device' problem as separate to this
> > issue. The KLD load stuff DOES show a small description for each KLD so
> > it isn't a total black box, and heck, you can just pick everything and
> > cross your fingers :)
>
> Take something like the if_dc(4) driver.  It covers literally _dozens_
> of cards and chips, all under different brands and manufacturers.  There
> is no way that a single line description file will tell you if your
> hardware is supported by the if_dc driver.  But this is a minor nit.

Yes..

> As I've stated before, loading kernel modules after the kernel has
> booted is the wrong time to do it.  The loader needs to be enhanced to
> be able to take care of this.  Once that happens, we can trivially
> modify the release scripts to allow an arbitrary number of driver
> floppies to be created, and the maintenance nightmare goes away for
> the most part.

I don't necessarily agree here - I think sysinstall is a better place because 
it's much much easier to write stuff for it than the loader. In the example 
you mention the only reason to use the loader is because the SCSI subsystem 
won't reprobe when a new SCSI bus comes online which sounds like a bug.

BTW Does camcontrol rescan cause the devices to be detected? Perhaps 
sysinstall could be "enhanced" to perform this duty as part of it's reprobe  
machinations.

> Well, except when mfsroot.gz becomes too large to fit on a single
> floppy.  Right now it is about 90k away from that.  What happens when
> mount_nfsv4 gets put on there?  John Baldwin and I already spat ent a
> day over the holiday break making the mfsroot.gz image fit given the
> new requirements created by having a dynamic root.  What happens the
> next time that it overflows?  It's not like the driver floppies where
> you can dike more stuff to another disk; this is a single image.  Do
> we come up with a method for having multiple, segmented images?  Who
> writes the code to do that?
>
> If we are going to keep floppies, then we need people who are willing to
> tackle these issues and keep them under control.

I agree with that! :)

However, given your example above, I would just put mount_nfsv4 on another 
floppy, although if sysinstall (or it's replacement) is too large, there will 
need to be the ability to load N floppy images into memory.

However they're issues for floppy users ;)

-- 
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum
GPG Fingerprint - 9A8C 569F 685A D928 5140  AE4B 319B 41F4 5D17 FDD5

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Discussion on the future of floppies in 5.x and 6.x

2004-01-09 Thread Scott Long
Daniel O'Connor wrote:
On Thursday 08 January 2004 18:20, Avleen Vig wrote:

I understand it is difficult to maintain the floppies. I wish I
understood them better :-) Is it not possible to have "ftp install"
floppies, which do nothing more than simple FTP installations?


It wouldn't make it any easier.

You still need the right drivers, ie which SCSI controller/network/... cards 
you have to get a minimal install is _more_ when you are doing FTP (you need 
a network).

I think one possibility that wasn't mentioned is to have a floppy maintainer 
that generates several sets of floppies that are used for non-CD 
booting/no-CD installs which are available via download, and some are chucked 
on the CD. ie make it a separate part of the release, so it is not directly 
the install team's job.

This would mean that the default 'make release' produces no floppy images. 
Instead they are built separately and bundled with 'official' releases. It 
would even be (fairly trivially) possible to setup a web site where you 
select what cards you want support for and it makes a floppy image for you. 
Even just having a page which tells you want card needs what KLD and where to 
get the KLD's would help, as you could download them on your  and 
put them on floppy yourself.

Scott also said stuff like SCSI cards won't get probed if a module is loaded 
but I can't see why that is true.. The module will load, the device get 
detected, and then sysinstall is told to reprobe the hardware, so it should 
pick it up.

Incorrect.  Scanning SCSI buses is something that does not happen
automatically.  There is magic in the boot process that makes it happen
near the end, right before the kernel looks for the root device.
However, that is the exception to the rule.  If you load a SCSI driver
after the kernel has booted, the SCSI channel behind it will _not_ be
probed automatically.  Trust me on this one.  Fixing this particular
problem is well beyond the scope of fixing floppies in general.  Until
it gets fixed, floppies will just have to deal with it.
I see the 'which kld goes with what device' problem as separate to this issue. 
The KLD load stuff DOES show a small description for each KLD so it isn't a 
total black box, and heck, you can just pick everything and cross your 
fingers :)

Take something like the if_dc(4) driver.  It covers literally _dozens_
of cards and chips, all under different brands and manufacturers.  There
is no way that a single line description file will tell you if your
hardware is supported by the if_dc driver.  But this is a minor nit.
As I've stated before, loading kernel modules after the kernel has
booted is the wrong time to do it.  The loader needs to be enhanced to
be able to take care of this.  Once that happens, we can trivially
modify the release scripts to allow an arbitrary number of driver
floppies to be created, and the maintenance nightmare goes away for
the most part.
Well, except when mfsroot.gz becomes too large to fit on a single
floppy.  Right now it is about 90k away from that.  What happens when
mount_nfsv4 gets put on there?  John Baldwin and I already spent a
day over the holiday break making the mfsroot.gz image fit given the
new requirements created by having a dynamic root.  What happens the
next time that it overflows?  It's not like the driver floppies where
you can dike more stuff to another disk; this is a single image.  Do
we come up with a method for having multiple, segmented images?  Who
writes the code to do that?
If we are going to keep floppies, then we need people who are willing to
tackle these issues and keep them under control.
Scott

Scott

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Discussion on the future of floppies in 5.x and 6.x

2004-01-08 Thread Daniel O'Connor
On Friday 09 January 2004 15:48, Avleen Vig wrote:
> > Yep,
> > I suspect mtools is the easiest way to do this..
>
> Something that was suggested in #FreeBSDHelp on EFnet just now:
> sysinstall already has the ability to dynamically load modules.
> If this is the case, I don't see where the "problem" is.
> Make the kernel on the floppy disk have few/no drivers built in, and
> have then all loaded from a third disk.
> Have the third disk generated dynamically from say, a website?

Yeah, that was similar to what I was thinking.

You could just get it to make a zip for you to put on a floppy after you 
select your hardware from a list.

-- 
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum
GPG Fingerprint - 9A8C 569F 685A D928 5140  AE4B 319B 41F4 5D17 FDD5

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Discussion on the future of floppies in 5.x and 6.x

2004-01-08 Thread Avleen Vig
On Fri, Jan 09, 2004 at 03:28:11PM +1030, Daniel O'Connor wrote:
> On Friday 09 January 2004 15:00, Avleen Vig wrote:
> > > onto floppy disks easily so users can grab what they need and use it
> > > instead of having to second guess what sort of hardware they are likely
> > > to be using. IMHO of course 8-)
> >
> > Now you've got me thinking.
> > A simple website which lets you choose what drivers you want (anyone
> > seen the .muttrc config page? :)
> > That should be really easy to do with a little perl CGI.
> > I might take a crack at this in the next week or so.
> 
> Yep, 
> I suspect mtools is the easiest way to do this..

Something that was suggested in #FreeBSDHelp on EFnet just now:
sysinstall already has the ability to dynamically load modules.
If this is the case, I don't see where the "problem" is.
Make the kernel on the floppy disk have few/no drivers built in, and
have then all loaded from a third disk.
Have the third disk generated dynamically from say, a website?
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Discussion on the future of floppies in 5.x and 6.x

2004-01-08 Thread Daniel O'Connor
On Friday 09 January 2004 15:00, Avleen Vig wrote:
> > onto floppy disks easily so users can grab what they need and use it
> > instead of having to second guess what sort of hardware they are likely
> > to be using. IMHO of course 8-)
>
> Now you've got me thinking.
> A simple website which lets you choose what drivers you want (anyone
> seen the .muttrc config page? :)
> That should be really easy to do with a little perl CGI.
> I might take a crack at this in the next week or so.

Yep, 
I suspect mtools is the easiest way to do this..

-- 
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum
GPG Fingerprint - 9A8C 569F 685A D928 5140  AE4B 319B 41F4 5D17 FDD5

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Discussion on the future of floppies in 5.x and 6.x

2004-01-08 Thread Avleen Vig
On Fri, Jan 09, 2004 at 02:04:34PM +1030, Daniel O'Connor wrote:
> *How* does it support all of those sources?
> CD/DVD drives need drivers (ATA optimisticly, but quite possibly SCSI), 
> FTP/NFS need network card support, NFS needs nfsclient.ko
> ie this is the exact problem it has now :)
> You could save a little space with your idea because you wouldn't need 
> sysinstall which is admittedly quite large, but it wouldn't address the 
> fundamental issue.
> If you want floppy installs you need a way of putting arbitary drivers onto 
> floppy disks easily so users can grab what they need and use it instead of 
> having to second guess what sort of hardware they are likely to be using.
> IMHO of course 8-)

Now you've got me thinking.
A simple website which lets you choose what drivers you want (anyone
seen the .muttrc config page? :)
That should be really easy to do with a little perl CGI.
I might take a crack at this in the next week or so.

-- 
Avleen Vig
Systems Administrator
Personal: www.silverwraith.com
EFnet:irc.mindspring.com (Earthlink user access only)
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Discussion on the future of floppies in 5.x and 6.x

2004-01-08 Thread Daniel O'Connor
On Friday 09 January 2004 10:04, Greg Shenaut wrote:
> In nuntio <[EMAIL PROTECTED]>, Michel TALON divulgat:
> >By the way, what's the reason that it is impossible to have just one
> >floppy which boots FreeBSD kernel, allows to see an unbootable cdrom
> >and continue installation from here?
>
> I agree.  The boot floppy tries to do w a y too much.  I think we
> should think of the boot floppy as way to implement an old-style
> console emulator: it "boots" and you tell it where to read the
> *real* boot image from.  It should support all of the usual sources:
> CDs/DVDs, NFS mounts, FTP, and so on.

*How* does it support all of those sources?
CD/DVD drives need drivers (ATA optimisticly, but quite possibly SCSI), 
FTP/NFS need network card support, NFS needs nfsclient.ko

ie this is the exact problem it has now :)

You could save a little space with your idea because you wouldn't need 
sysinstall which is admittedly quite large, but it wouldn't address the 
fundamental issue.

If you want floppy installs you need a way of putting arbitary drivers onto 
floppy disks easily so users can grab what they need and use it instead of 
having to second guess what sort of hardware they are likely to be using.

IMHO of course 8-)

-- 
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum
GPG Fingerprint - 9A8C 569F 685A D928 5140  AE4B 319B 41F4 5D17 FDD5

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Discussion on the future of floppies in 5.x and 6.x

2004-01-08 Thread Daniel O'Connor
On Thursday 08 January 2004 18:20, Avleen Vig wrote:
> I understand it is difficult to maintain the floppies. I wish I
> understood them better :-) Is it not possible to have "ftp install"
> floppies, which do nothing more than simple FTP installations?

It wouldn't make it any easier.

You still need the right drivers, ie which SCSI controller/network/... cards 
you have to get a minimal install is _more_ when you are doing FTP (you need 
a network).

I think one possibility that wasn't mentioned is to have a floppy maintainer 
that generates several sets of floppies that are used for non-CD 
booting/no-CD installs which are available via download, and some are chucked 
on the CD. ie make it a separate part of the release, so it is not directly 
the install team's job.

This would mean that the default 'make release' produces no floppy images. 
Instead they are built separately and bundled with 'official' releases. It 
would even be (fairly trivially) possible to setup a web site where you 
select what cards you want support for and it makes a floppy image for you. 
Even just having a page which tells you want card needs what KLD and where to 
get the KLD's would help, as you could download them on your  and 
put them on floppy yourself.

Scott also said stuff like SCSI cards won't get probed if a module is loaded 
but I can't see why that is true.. The module will load, the device get 
detected, and then sysinstall is told to reprobe the hardware, so it should 
pick it up.

I see the 'which kld goes with what device' problem as separate to this issue. 
The KLD load stuff DOES show a small description for each KLD so it isn't a 
total black box, and heck, you can just pick everything and cross your 
fingers :)

-- 
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum
GPG Fingerprint - 9A8C 569F 685A D928 5140  AE4B 319B 41F4 5D17 FDD5

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Discussion on the future of floppies in 5.x and 6.x

2004-01-08 Thread Matthew D. Fuller
On Thu, Jan 08, 2004 at 03:36:42PM -0700 I heard the voice of
Scott Long, and lo! it spake thus:
> 
> Unfortunately, there are two problems with this.

Now,

> The first is that it runs after the kernel has already booted, so SCSI
> devices that are handled by drivers on this floppy won't get probed.

This I hadn't known.  Why is that?  I thought when you loaded a module it
pulled up the driver and probed the hardware, which included scanning any
busses on it.


> The second is that forcing the user to know which driver is appropriate
> for their hardware is not very good form.

This is one of those things I list under the category of "letting floppy
installs be a bit ugly, or 'experienced-users only'-labelled".


> There are several documents linked off of http://www.freebsd.org/releng
> that describe how to build a release.  It's not nearly as arcane of a
> process as it used to be 5 years ago.  The biggest barrier to entry is
> probably disk space.  You'll need a good 5GB free to hold the CVS repo,
> chroot environment, and resulting bits.

Well, I've got the CVS repo, though boy, has *THAT* ever grown since I
built this system; I had to trim it down to only src and ports, and even
so:
/dev/da1s1e 2032623 1769089 10092595%/usr/cvs

Of course, I left out the ports and docs parts of the release last time I
tried (which was in fact about 5 years ago ;), though I had all kinda of
troubles with parts of THAT, too.  But still, I don't have even a tenth
that much hard drive space around.


> Yes, to build the floppies you need to build most of the release, but
> once you've built the release, you can back-step and rebuild the
> floppies at will.

And building the whole release is quite an ordeal on a Pentium Pro  :)


Still, I'm willing to donate some time and brain to the problem, since
apparently I kinda care about it.  It seems to me that the probing
problem above is the biggest problem from a real coding POV; the rest is
mostly just a whole heck of a lot of implementation, and "inconvenience"
from the usability standpoint.  That's a breaking point.


-- 
Matthew Fuller (MF4839)   |  [EMAIL PROTECTED]
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/

"The only reason I'm burning my candle at both ends, is because I
  haven't figured out how to light the middle yet"
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Discussion on the future of floppies in 5.x and 6.x

2004-01-08 Thread Greg Shenaut
In nuntio <[EMAIL PROTECTED]>, Michel TALON divulgat:
>By the way, what's the reason that it is impossible to have just one
>floppy which boots FreeBSD kernel, allows to see an unbootable cdrom
>and continue installation from here?

I agree.  The boot floppy tries to do w a y too much.  I think we
should think of the boot floppy as way to implement an old-style
console emulator: it "boots" and you tell it where to read the
*real* boot image from.  It should support all of the usual sources:
CDs/DVDs, NFS mounts, FTP, and so on.

The real boot image would know how to format drives, install
distributions & packages, and so on.

This "boot console" floppy would only need to change to support new
hardware, and there could even be boot-source-specific versions
of it.  Once you had one that worked on a specific type of PC,
you could keep using it indefinitely.

Greg Shenaut
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Discussion on the future of floppies in 5.x and 6.x

2004-01-08 Thread BSD
On Thu, Jan 08, 2004 at 04:10:38PM -0600, Matthew D. Fuller wrote:
> On Thu, Jan 08, 2004 at 07:36:10AM -0800 I heard the voice of
> Avleen Vig, and lo! it spake thus:
> > 
> > If I understand you right..
> > A floppy boot, which loads the absolutely basic stuff (network drivers,
> > and some easy way to config the network) and then goes and grabs the
> > installer would otherwise be on the current floppies and "boots" it?
> 
> Many (most?) Linux dists do this for floppy installs.  I've come around
> to thinking it a better and better idea lately.  It makes it easy to have
> much more bloa... er, "featureful" installers, particularly more
> graphical ones, since you're no longer limited by the size of a floppy.
> And even cheap DSL is faster than a floppy drive for loading it, to boot
> (no pun ;).  And you can even provide for loading it off a local CD, if
> you have a CD drive you can't boot from.
> 
> The downside is that writing such a beast is a lot more work...

Take what I'm babbling about with a huge grain of salt, since I probably
have no idea what I'm talking about...

How hard would it be to take something like etherboot and building a
single install floppy from that? And have a FreeBSD kernel/installer
hosted on a public nfs/tftp server?

Ie., the user pops in the etherboot floppy, it asks for network setup
info, we tell it to use ftp.freebsd.org, and it goes out and either nfs
mounts or tftp the kernel and installer and drivers. Then proceed from
there to installing FreeBSD onto the system.

I suppose that's what you just said.. But was just thinking that it'd be
easier modifying an existing system (ie., etherboot) than writing one
from scratch..


Note: I just mentioned etherboot because that was the first thing that
came to mind. I'm sure there are other systems better suited or licensed
for what's needed.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Discussion on the future of floppies in 5.x and 6.x

2004-01-08 Thread Scott Long
Matthew D. Fuller wrote:

On Thu, Jan 08, 2004 at 03:43:55AM -0700 I heard the voice of
Scott Long, and lo! it spake thus:
Well, regardless of how you label it, these floppies still require lots
of care and feeding in order to work.  We currently have no way to
support multiple floppies in a convenient way.


My hope is that, with this piece taken care of, the amount of care and
feeding necessary to maintain it will be minimized.  When adding new
drivers, you'd have to stick their names in a list somewhere to be split
out, but that's pretty minimal.  It should help avoid all the juggling we
keep having to do to manage the size.
We already have this.  It's at src/release/i386/drivers.conf.  It can
trivially be expanded to take care of more than just three floppies.
However, the piece that is missing is the ability for 3rd, 4th, 5th,
etc, floppies to be conveniently loaded and work seamlessly.  Right now,
the boot loader that comes on floppy on has some magic to ask the user
for the second floppy, then load the mfsroot and .ko files off it
automatically before the kernel boots.  Unfortunatley, this magic is
split between an interactive step in boot/loader.rc and a
non-interactive step in the loader code.  There is no easy way to expand
this to handle multiple floppies; the non-interactive second step cannot
recurse back to the interactive first step.
The 3rd floppy is handled right now in a menu that is run when
sysinstall starts.  It's a nice menu; it gives you a list of the drivers
on the floppy and asks which one you want to load.  Unfortunately, there
are two problems with this.  The first is that it runs after the kernel
has already booted, so SCSI devices that are handled by drivers on this
floppy won't get probed.  The second is that forcing the user to know
which driver is appropriate for their hardware is not very good form.
My preference would be to deprecate the sysinstall method and expand the
boot loader to fully handle an arbitrary number of floppies.  It would
also be nice to build a method for manually excluding drivers that the
user doesn't want to load.  This would greatly help to support 3rd party
vendor driver disks, something that SuSE and Redhat derive significant
benefit from right now.


This can be fixed in a variety of ways that range from fragile hacks to
wonderful designs, but it still requires someone to put forth the
effort.  My offer for a 'floppy maintainer' is quite sincere; I hope
that someone takes an interest and steps up to the challenge.


I have some interest in this, to be sure.  However, every time I've
ventured into src/release/ in the past, I've come away with an intense
desire for absinthe.  I've never successfully built a release, and it's
been my impression that you can't just build the floppies, you have to
build the full release to have everything in place to build them.  That
takes a huge chunk of disk space (to say nothing of _TIME_!  Just
building the kernel and modules takes the better part of a half hour),
which are two things in chronically short supply.

There are several documents linked off of http://www.freebsd.org/releng
that describe how to build a release.  It's not nearly as arcane of a
process as it used to be 5 years ago.  The biggest barrier to entry is
probably disk space.  You'll need a good 5GB free to hold the CVS repo,
chroot environment, and resulting bits.  Yes, to build the floppies you
need to build most of the release, but once you've built the release,
you can back-step and rebuild the floppies at will.
Scott

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Discussion on the future of floppies in 5.x and 6.x

2004-01-08 Thread Diomidis Spinellis
Brooks Davis wrote:
> No, I mean a server.  The hard part about using PXE to install a box is
> setting up the other box to boot the box your are installing on.  It's
> not all the difficult, but it require a bit of knowledge, some grunt
> work, and a reasionable UNIX-like machine to start from.  What I propose
> is adding enough stuff to disk 1 that you can do pxe installs like this:
Nice idea!  My mind was fixated on older machines that do not support 
PXE; as I always have a couple of FreeBSD servers around at work/home I 
failed to realise that setting up a PXE server could ever be a problem.

Diomidis

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Discussion on the future of floppies in 5.x and 6.x

2004-01-08 Thread Michel TALON
> And, further, some of us don't have (and don't want) CD burners, and even
> if we had 'em, don't want to burn (no pun intended ;) a CD blank just to
> install an OS, when we can just (re-)use 2 floppies and do it across the
> LAN from a local FTP mirror, which is as fast as a CD drive anyway.

Sincerely FreeBSD developers have more important tasks than spending
hours to fit an installable system on floppies. When FreeBSD used
one floppy, it was tolerable to do floppy installs. With 2 or 3 floppies
it is awfully slow, i have done once and will never do it again.
There are so many workarounds for people who don't have a CD burner,
including asking a friend to burn the CD, buying a cheap CD somewhere.
For people who don't have a CD reader able to boot, the simplest
solution by far is to remove the hard drive and install it on another
machine, much faster than reading the 2 damned floppies :-)
The technically dedicated people can also arrange a PXE boot
which boots a live system, and then brutally install on hard disk
bypassing the installer which is far from nice anyways. There are
tons of ways of proceeding, including dd copying a series of identical
disks for people who have to do large installs.
By the way, what's the reason that it is impossible to have just one
floppy which boots FreeBSD kernel, allows to see an unbootable cdrom
and continue installation from here? During the holidays i have
installed the Linux Knoppix distro this way on an old machine which
doesn't allow to boot from CD. There is a 1.44M floppy image on the CD
which allows to do just that. I am quite stunned that the same thing
cannot be done for FreeBSD.



-- 

Michel TALON

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Discussion on the future of floppies in 5.x and 6.x

2004-01-08 Thread Matthew D. Fuller
On Thu, Jan 08, 2004 at 07:36:10AM -0800 I heard the voice of
Avleen Vig, and lo! it spake thus:
> 
> If I understand you right..
> A floppy boot, which loads the absolutely basic stuff (network drivers,
> and some easy way to config the network) and then goes and grabs the
> installer would otherwise be on the current floppies and "boots" it?

Many (most?) Linux dists do this for floppy installs.  I've come around
to thinking it a better and better idea lately.  It makes it easy to have
much more bloa... er, "featureful" installers, particularly more
graphical ones, since you're no longer limited by the size of a floppy.
And even cheap DSL is faster than a floppy drive for loading it, to boot
(no pun ;).  And you can even provide for loading it off a local CD, if
you have a CD drive you can't boot from.

The downside is that writing such a beast is a lot more work...


-- 
Matthew Fuller (MF4839)   |  [EMAIL PROTECTED]
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/

"The only reason I'm burning my candle at both ends, is because I
  haven't figured out how to light the middle yet"
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Discussion on the future of floppies in 5.x and 6.x

2004-01-08 Thread Matthew D. Fuller
On Thu, Jan 08, 2004 at 03:43:55AM -0700 I heard the voice of
Scott Long, and lo! it spake thus:
> 
> Well, regardless of how you label it, these floppies still require lots
> of care and feeding in order to work.  We currently have no way to
> support multiple floppies in a convenient way.

My hope is that, with this piece taken care of, the amount of care and
feeding necessary to maintain it will be minimized.  When adding new
drivers, you'd have to stick their names in a list somewhere to be split
out, but that's pretty minimal.  It should help avoid all the juggling we
keep having to do to manage the size.


> This can be fixed in a variety of ways that range from fragile hacks to
> wonderful designs, but it still requires someone to put forth the
> effort.  My offer for a 'floppy maintainer' is quite sincere; I hope
> that someone takes an interest and steps up to the challenge.

I have some interest in this, to be sure.  However, every time I've
ventured into src/release/ in the past, I've come away with an intense
desire for absinthe.  I've never successfully built a release, and it's
been my impression that you can't just build the floppies, you have to
build the full release to have everything in place to build them.  That
takes a huge chunk of disk space (to say nothing of _TIME_!  Just
building the kernel and modules takes the better part of a half hour),
which are two things in chronically short supply.


-- 
Matthew Fuller (MF4839)   |  [EMAIL PROTECTED]
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/

"The only reason I'm burning my candle at both ends, is because I
  haven't figured out how to light the middle yet"
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Discussion on the future of floppies in 5.x and 6.x

2004-01-08 Thread Brooks Davis
On Thu, Jan 08, 2004 at 10:48:24PM +0200, Diomidis Spinellis wrote:
> Brooks Davis wrote:
> >I think it would be really cool if someone would add a feature to
> >disk 1 to become a PXE install server.  It should be fairly straight
> >forward other then dealing with sysinstall.
> 
> I presume the above means a PXE *client*.  This would be cool, but by no 
> means trivial.  I looked at this in the past when I wanted to network 
> boot FreeBSD on a couple of machines that did not support a boot ROM and 
> reached a dead end; I ended up using PicoBSD and NFS-mounting most of 
> the stuff.

No, I mean a server.  The hard part about using PXE to install a box is
setting up the other box to boot the box your are installing on.  It's
not all the difficult, but it require a bit of knowledge, some grunt
work, and a reasionable UNIX-like machine to start from.  What I propose
is adding enough stuff to disk 1 that you can do pxe installs like this:

 - find a random box with a cdrom drive and a supported nic
 - boot the install cd
 - select the "make me an install server" option from the menu
 - select an interface and configure it (or take a nice 10-net default)
 - pxe boot the boxes you want to install on and install over the network
 - shutdown the server, returning it to its previous function

-- Brooks

-- 
Any statement of the form "X is the one, true Y" is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529  9BF0 5D8E 8BE9 F238 1AD4


pgp0.pgp
Description: PGP signature


Re: Discussion on the future of floppies in 5.x and 6.x

2004-01-08 Thread John Baldwin
On Thursday 08 January 2004 11:36 am, Ceri Davies wrote:
> On Thu, Jan 08, 2004 at 12:35:01AM -0700, Scott Long wrote:
> > All,
> >
> > Every FreeBSD release cycle in the past year has hit bumps due to install
> > floppy problems.  This is becoming more and more of a burden on the
> > Release Engineering Team, as we simply do not have the resources to
> > constantly battle the floppies.
>
> Floppies can go as far as I'm concerned, with the one proviso that we
> start shipping a /boot.config containing '-P'.  Without floppies, the
> only ways to do a headless install are PXE and cutting your own release
> with that /boot.config in place, and not all machines can do PXE.

-P breaks machines with USB keyboards because it doesn't use a very smary 
keyboard probe check.  That's why it was turned off in the first place.

-- 
John Baldwin <[EMAIL PROTECTED]>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Discussion on the future of floppies in 5.x and 6.x

2004-01-08 Thread Diomidis Spinellis
Brooks Davis wrote:
I think it would be really cool if someone would add a feature to
disk 1 to become a PXE install server.  It should be fairly straight
forward other then dealing with sysinstall.
I presume the above means a PXE *client*.  This would be cool, but by no 
means trivial.  I looked at this in the past when I wanted to network 
boot FreeBSD on a couple of machines that did not support a boot ROM and 
reached a dead end; I ended up using PicoBSD and NFS-mounting most of 
the stuff.

Following Brook's suggestion, I looked around to see how difficult a PXE 
client project would be.  Here are some bullets and pointers:

- What we would need is a PXE emulator.  PXE stands for Portable 
Execution *Environment*, and it really does supply a (primitive) but not 
trivial environment used to bootstrap the code.

- Microsoft supplies with its Remote Installation Server (RIS) a program 
(rbfg.exe) that creates such an emulation floppy.  This PXE emulator 
only supports PCI cards.  See http://support.microsoft.com/?kbid=242920

- Apparently the same product, but with additional functionality, is 
sold by Argon Technologies.   See 
http://www.argontechnology.com/rbfg/index.shtml

- An open-source project called pxe-toolkit aimed at providing examples 
of PXE client and server code.  The project seems to have dissappeared 
from the face of the earth.  Its homepage on freshmeat and a download 
page on savannah are dead; a page with links on 
http://savannah.nongnu.org/projects/pxe-toolkit does not contain any 
useful pointers.

- The PXE specification (2.1) is freely available from Intel in PDF 
format (500K, 103 pages).  See 
ftp://download.intel.com/labs/manage/wfm/download/pxespec.pdf

- Implementing a PXE client from scratch is obviously doable, but not 
trivial.  One problem is that the API is 16-bit, so we would have to use 
16-bit development tools, libraries, and an execution environment.  The 
client should support a DHCP client, preboot functionality, and an API. 
 The API consists of 37 relatively high-level functions providing TFTP, 
UDP, and UNDI (Universal Network Driver Interface) functionality.  Here 
is a list to give you a rough idea of the functionality that has to be 
provided:

UNLOAD_STACK, GET_CACHED_INFO, RESTART_TFTP, START_UNDI, STOP_UNDI,
START_BASE, STOP_BASE, TFTP_OPEN, TFTP_CLOSE, TFTP_READ, TFTP_READ_FILE,
TFTP_GET_FSIZE, UDP_OPEN, UDP_CLOSE, UDP_WRITE, UDP_READ, UNDI_STARTUP,
UNDI_CLEANUP, UNDI_INITIALIZE, UNDI_RESET_ADAPTER, UNDI_SHUTDOWN,
UNDI_OPEN, UNDI_CLOSE, UNDI_TRANSMIT, UNDI_SET_MCAST_ADDRESS,
UNDI_SET_STATION_ADDRESS, UNDI_SET_PACKET_FILTER, UNDI_GET_INFORMATION,
UNDI_GET_STATISTICS, UNDI_CLEAR_STATISTICS, UNDI_INITIATE_DIAGS,
UNDI_FORCE_INTERRUPT, UNDI_GET_MCAST_ADDRESS, UNDI_GET_NIC_TYPE,
UNDI_GET_IFACE_INFO, UNDI_GET_STATE, UNDI_ISR.
I hope this information helps if anyone wants to take it up from here.

Diomidis
--
Diomidis Spinellis  Assistant Professor
Department of Management Science and Technology  (DMST)
Athens University of Economics and Business  (AUEB)
http://www.dmst.aueb.gr/dds/ mailto:[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Discussion on the future of floppies in 5.x and 6.x

2004-01-08 Thread Matt Emmerton
> On Thu, 8 Jan 2004, Matthew D. Fuller wrote:
> > On Thu, Jan 08, 2004 at 02:05:14AM -0700 I heard the voice of
> > Scott Long, and lo! it spake thus:
> > >
> > > For 5.x we already have a 3rd floppy that is dedicated to modules.
> > > Unfortunately, it doesn't work nearly as well as it should because
there
> > > is no way to activate it during the boot sequence; it can only be used
> > > once sysinstall is running.  Also, it too is nearly overflowing.
> >
> > Well, that's why I suggest more.  Have a "network cards" floppy, and a
> > "mass storage devices" floppy, etc.  We should be able to fit the
> > half-dozen most common network cards, the ata drivers, and a half dozen
> > of the more common SCSI drivers on the boot kernel.  That'll get us far
> > enough to be able to load the drivers off the other disks, as well as
> > install with just that on many systems.
> >
> > It won't necessarily be the prettiest process, but I'm in favor of
> > letting the floppies be a bit ugly, or even explicitly moving them to
> > "experienced users only" status.  I just find them far too convenient,
as
> > well as ubiquitous, to see them sent into the Great Bitbucket In The Sky
> > yet.

This is exactly what Debian does.  I was a bit ticked when I found I had to
make 7 floppy images to get a machine installed, but the important part is
that it worked.

> Well, regardless of how you label it, these floppies still require lots of
> care and feeding in order to work.  We currently have no way to support
> multiple floppies in a convenient way.  This can be fixed in a variety
> of ways that range from fragile hacks to wonderful designs, but it still
> requires someone to put forth the effort.  My offer for a 'floppy
> maintainer' is quite sincere; I hope that someone takes an interest and
> steps up to the challenge.

I myself have 4 machines (out of the 6 in front of me) that are Pentium- or
Pentium II-class machines that cannot boot from CD-ROM or PXE, thus floppies
are my only choice.

Thus, I am genuinely interested in the effort to maintain working floppy
images and can help out -- but not to the point of being "maintainer" yet.
However, I have no experience building releases at all, so someone from re@
will have to help me along.

--
Matt Emmerton


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Discussion on the future of floppies in 5.x and 6.x

2004-01-08 Thread M. Warner Losh
In message: <[EMAIL PROTECTED]>
Scott Long <[EMAIL PROTECTED]> writes:
: My offer for a 'floppy
: maintainer' is quite sincere; I hope that someone takes an interest and
: steps up to the challenge.

I think people misunderstand Scott's call here.  He's not saying that
the project doesn't want to support floppies because they are
floppies.  It isn't a dislike of the technology.  Scott is saying that
they have become a burdon to the release engineering team.  He's
saying that he's looking for someone to volunteer to actively help
care and feed for the floppies used in the installation process.  This
is a call for people who care about them to step forward and put some
action behind their caring.

The only way something stays working in FreeBSD is if enough
developers care about it to monitor it constantly.  There are many
examples of formerly well supported items being less supported now
because they impact fewer developers directly.  This is one of them.

We can all come up with better ideas on how to support these things.
Ideas aren't the issue.  Elbow grease and sweat are.

Warner

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Discussion on the future of floppies in 5.x and 6.x

2004-01-08 Thread Narvi

On Thu, 8 Jan 2004, Steven Hartland wrote:

> Need necessitates effort?
>

Precicely. Or even more precicely - the RE team provided an alternative
path to eliminating floppy support which they could cope with. It follows
that people who want floppy support should work towards that because the
other option:

 you tell RE team that they had better shut up and make it work

is not workable becuase they have no compulsion to listen to your and
could just walk away any minute they bloody well want anyways. It thus
follows that some persons out of the "we want floppy support to stay
around" had better start volunteering to be floppy maintainers.

> - Original Message -
> From: "Avleen Vig" <[EMAIL PROTECTED]>
>
> > How you made the jump from "I don't want to buy a CD burner to install
> > FreeBSD" to "I will be a floppy maintainer" I'm not sure. :-)
>
> 
> This e.mail is private and confidential between Multiplay (UK) Ltd. and the person 
> or entity to whom it is addressed. In the event of misdirection, the recipient is 
> prohibited from using, copying, printing or otherwise disseminating it or any 
> information contained in it.
>
> In the event of misdirection, illegible or incomplete transmission please telephone 
> (023) 8024 3137
> or return the E.mail to [EMAIL PROTECTED]
>
>

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Discussion on the future of floppies in 5.x and 6.x

2004-01-08 Thread Steven Hartland
Need necessitates effort?

- Original Message - 
From: "Avleen Vig" <[EMAIL PROTECTED]>

> How you made the jump from "I don't want to buy a CD burner to install
> FreeBSD" to "I will be a floppy maintainer" I'm not sure. :-)


This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or 
entity to whom it is addressed. In the event of misdirection, the recipient is 
prohibited from using, copying, printing or otherwise disseminating it or any 
information contained in it. 

In the event of misdirection, illegible or incomplete transmission please telephone 
(023) 8024 3137
or return the E.mail to [EMAIL PROTECTED]


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Discussion on the future of floppies in 5.x and 6.x

2004-01-08 Thread Avleen Vig
On Thu, Jan 08, 2004 at 05:56:22PM +0200, Narvi wrote:
> > And, further, some of us don't have (and don't want) CD burners, and even
> > if we had 'em, don't want to burn (no pun intended ;) a CD blank just to
> > install an OS, when we can just (re-)use 2 floppies and do it across the
> > LAN from a local FTP mirror, which is as fast as a CD drive anyway.
> 
> Which would obviously mean that there would be lots of volunteers for the
> position of floppy maintainer?

How you made the jump from "I don't want to buy a CD burner to install
FreeBSD" to "I will be a floppy maintainer" I'm not sure. :-)
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Discussion on the future of floppies in 5.x and 6.x

2004-01-08 Thread Paul Schenkeveld
Hi All,

On Thu, Jan 08, 2004 at 12:35:01AM -0700, Scott Long wrote:
> All,
> 
> Every FreeBSD release cycle in the past year has hit bumps due to install
> floppy problems.  This is becoming more and more of a burden on the
> Release Engineering Team, as we simply do not have the resources to
> constantly battle the floppies.
> 
> ...

What if the loader would be able to load a, potentially large, kernel
split over two or more floppies?

That would allow for the same kernel that goes on the CD-Rom to be
used for floppy install, greatly simplifying the release process.

Or are my thoughts to simplistic?

> Thanks,
> 
> Scott

Regards,

Paul Schenkeveld, Consultant
PSconsult ICT Services BV
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Discussion on the future of floppies in 5.x and 6.x

2004-01-08 Thread Brooks Davis
On Thu, Jan 08, 2004 at 10:52:08AM +0100, Daniel Lang wrote:
> Hi,
> 
> Matthew D. Fuller wrote on Thu, Jan 08, 2004 at 01:58:11AM -0600:
> [..]
> > And, further, some of us don't have (and don't want) CD burners, and even
> > if we had 'em, don't want to burn (no pun intended ;) a CD blank just to
> > install an OS, when we can just (re-)use 2 floppies and do it across the
> > LAN from a local FTP mirror, which is as fast as a CD drive anyway.
> 
> That's no point, as you can use a CD-RW, so no media is wasted.
> Install over LAN is done anyway, as Scott mentioned only the
> basic boot/install-strap is put into the emulated image.
> 
> However, I second the point, that there is recent hardware around
> which cannot have a CD-Drive attached, but a floppy drive, because
> of space constraints.
> 
> On the other hand, I guess such systems are able to boot over
> the network. I'd love to see a integrated boot and installation
> procedure that utilizes PXE (or any other network boot method)
> and advocates it. (In this regard I just love Suns).

PXE installs are fun and easy.  I use them for the no removable media
boxes on our cluster when I need a local install for testing.

The process is roughly (See Alfred's PXE article for details. Just
ignore the kernel mods.):

mount an install cd (assuming /cdrom as mountpoint)
export /cdrom via nfs
point a tftpd server at /cdrom
configure a dhcpd with the necessicary lines to boot from /boot/pxeboot
boot and install (I think you may need to choose to do an nfs install in
  sysinstall, but I'm not 100% sure of that.)

I think it would be really cool if someone would add a feature to
disk 1 to become a PXE install server.  It should be fairly straight
forward other then dealing with sysinstall.

-- Brooks

-- 
Any statement of the form "X is the one, true Y" is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529  9BF0 5D8E 8BE9 F238 1AD4


pgp0.pgp
Description: PGP signature


Re: Discussion on the future of floppies in 5.x and 6.x

2004-01-08 Thread Ceri Davies
On Thu, Jan 08, 2004 at 04:36:47PM +, Ceri Davies wrote:
> On Thu, Jan 08, 2004 at 12:35:01AM -0700, Scott Long wrote:
> > All,
> > 
> > Every FreeBSD release cycle in the past year has hit bumps due to install
> > floppy problems.  This is becoming more and more of a burden on the
> > Release Engineering Team, as we simply do not have the resources to
> > constantly battle the floppies.
> 
> Floppies can go as far as I'm concerned, with the one proviso that we
> start shipping a /boot.config containing '-P'.  Without floppies, the
> only ways to do a headless install are PXE and cutting your own release
> with that /boot.config in place, and not all machines can do PXE.

Actually, I'd like to go one further and suggest that we do this anyway.

Ceri

-- 


pgp0.pgp
Description: PGP signature


Re: Discussion on the future of floppies in 5.x and 6.x

2004-01-08 Thread Ceri Davies
On Thu, Jan 08, 2004 at 12:35:01AM -0700, Scott Long wrote:
> All,
> 
> Every FreeBSD release cycle in the past year has hit bumps due to install
> floppy problems.  This is becoming more and more of a burden on the
> Release Engineering Team, as we simply do not have the resources to
> constantly battle the floppies.

Floppies can go as far as I'm concerned, with the one proviso that we
start shipping a /boot.config containing '-P'.  Without floppies, the
only ways to do a headless install are PXE and cutting your own release
with that /boot.config in place, and not all machines can do PXE.

Ceri

-- 


pgp0.pgp
Description: PGP signature


Re: Discussion on the future of floppies in 5.x and 6.x

2004-01-08 Thread Narvi


On Thu, 8 Jan 2004, Matthew D. Fuller wrote:

> On Wed, Jan 07, 2004 at 11:50:59PM -0800 I heard the voice of
> Avleen Vig, and lo! it spake thus:
> >
> > While it is indeed true that most machines since 1997 will support this
> > CD format, please take in to account:
>
> And, further, some of us don't have (and don't want) CD burners, and even
> if we had 'em, don't want to burn (no pun intended ;) a CD blank just to
> install an OS, when we can just (re-)use 2 floppies and do it across the
> LAN from a local FTP mirror, which is as fast as a CD drive anyway.

Which would obviously mean that there would be lots of volunteers for the
position of floppy maintainer?

>
> --
> Matthew Fuller (MF4839)   |  [EMAIL PROTECTED]
> Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
>
> "The only reason I'm burning my candle at both ends, is because I
>   haven't figured out how to light the middle yet"
>

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Discussion on the future of floppies in 5.x and 6.x

2004-01-08 Thread Avleen Vig
On Thu, Jan 08, 2004 at 01:22:38PM +0100, Martin Nilsson wrote:
> Are you aware that the FreeBSD CD:s (both 4.9 & 5.2) are not bootable on 
> a CD-ROM connected via USB? Both try to boot but hangs somewhere in the 
> loader. This is on our P4 Supermicro serverboards. As usual Win2K, 2K3 & 
> RedHat just works. An external USB2.0 connected Asus CD-RW drive 
> (52x/24x/52x) with power supply costs about $70 so this is really 
> nothing expensive or fancy today.

Please do not assume that because it costs $70 it is universally
availible.
There are a lot of people who cannot afford this:
 the unemployed
 school children
 retired persons (sometimes)
 people with families to support :)

Unfortuantely I feel this does need to be taken in to account here.
While I totally empathise with Scott's problem and the lack of time to
do things the way we have been, we need to appreciate that telling
everyone to burn a CD to install FreeBSD (thus incur costs if you don't
have a CD burner, and wouldn't need one if not to install FreeBSD) is
not far from the "You must pay us to buy this on CD" approach (openbsd)
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Discussion on the future of floppies in 5.x and 6.x

2004-01-08 Thread Avleen Vig
On Thu, Jan 08, 2004 at 09:39:34AM -0500, Leo Bicknell wrote:
> It would require a whole new floppy booter setup, but I can see
> other OS projects using something like this as well, so perhaps
> some cross work with NetBSD or OpenBSD, or even the Linux camp could
> make an open source "load an image" floppy, that since it just
> loaded an ISO could load about anything.

If I understand you right..
A floppy boot, which loads the absolutely basic stuff (network drivers,
and some easy way to config the network) and then goes and grabs the
installer would otherwise be on the current floppies and "boots" it?

This sounds like a good solution - they we wouldn't have to worry about:
  If people have cd burners or not
  The size of the installer (for most practical purposes as long as the
installer itself doesn't hit 600Mb :P)
  Compatibility with CD drives
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Discussion on the future of floppies in 5.x and 6.x

2004-01-08 Thread Martin Nilsson
Scott Long wrote:
FreeBSD/i386 is the only port left that generates install floppies.
Their primary purpose is to fascilitate installing FreeBSD on systems
where a CDROM is either not available or is incompatible with the
'Non-Emulated El Torito' boot method that we use on our CDs.  Systems that
cannot boot these CDs are typically those that are also not certified for
WinNT4, Win2K, or WinXP.  Thus, nearly all machines produced after 1997
can boot our CDs.
Are you aware that the FreeBSD CD:s (both 4.9 & 5.2) are not bootable on 
a CD-ROM connected via USB? Both try to boot but hangs somewhere in the 
loader. This is on our P4 Supermicro serverboards. As usual Win2K, 2K3 & 
RedHat just works. An external USB2.0 connected Asus CD-RW drive 
(52x/24x/52x) with power supply costs about $70 so this is really 
nothing expensive or fancy today.

If anybody can give me directions on how to debug this I'm willing to help.
/Martin
--
Martin Nilsson, CTO & Founder, Mullet Scandinavia AB, Malmö, SWEDEN
E-mail: [EMAIL PROTECTED], Phone: +46-(0)708-606170, http://www.mullet.se
Our business is well engineered servers optimized for FreeBSD and Linux.

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Discussion on the future of floppies in 5.x and 6.x

2004-01-08 Thread Kris Kennaway
On Thu, Jan 08, 2004 at 04:14:51AM -0600, Matthew D. Fuller wrote:
> On Thu, Jan 08, 2004 at 02:05:14AM -0700 I heard the voice of
> Scott Long, and lo! it spake thus:
> > 
> > For 5.x we already have a 3rd floppy that is dedicated to modules.
> > Unfortunately, it doesn't work nearly as well as it should because there
> > is no way to activate it during the boot sequence; it can only be used
> > once sysinstall is running.  Also, it too is nearly overflowing.
> 
> Well, that's why I suggest more.  Have a "network cards" floppy, and a
> "mass storage devices" floppy, etc.  We should be able to fit the
> half-dozen most common network cards, the ata drivers, and a half dozen
> of the more common SCSI drivers on the boot kernel.  That'll get us far
> enough to be able to load the drivers off the other disks, as well as
> install with just that on many systems.

Ideas are cheap, but someone's going to have to write the sysinstall
code to do that (or any other modified scheme people might be able to
come up with).

Kris


pgp0.pgp
Description: PGP signature


Re: Discussion on the future of floppies in 5.x and 6.x

2004-01-08 Thread Leo Bicknell

I'm going to propose a different solution that was brought up about
two years ago (although I can't find it now).

You start with something like the CD boot image mentioned, that is
a 3-5 Meg iso image that basically contains what is now on the
floppies (perhaps with a few more drivers/modules) and nothing more.
Downloading and burning to CD would be the primary method of install.

Then, to replace the current floppy process, a new floppy installer
is created.  It may or may not be based on FreeBSD, but what it
needs to be able to do is boot, load a network driver, configure
the network, and ftp the above mentioned iso into ram, and then
jump into the kernel from the iso as if it had been loaded from a
CD.

Yes, I'm grossly oversimplifing the process, but it removes all of
sysinstall from the floppy, all the need for crunchgen and all that,
as it should be fairly easy (again, perhaps not with a full kernel)
to support a number of network drivers and a basic FTP client on a
single floppy.  The only real direct freebsd issue is to make the
kernel able to boot itself from memory, and then treat that memory
as a ram disc on boot.

It would require a whole new floppy booter setup, but I can see
other OS projects using something like this as well, so perhaps
some cross work with NetBSD or OpenBSD, or even the Linux camp could
make an open source "load an image" floppy, that since it just
loaded an ISO could load about anything.

-- 
   Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - [EMAIL PROTECTED], www.tmbg.org


pgp0.pgp
Description: PGP signature


Re: Discussion on the future of floppies in 5.x and 6.x

2004-01-08 Thread Avleen Vig
On Thu, Jan 08, 2004 at 03:43:55AM -0700, Scott Long wrote:
> Well, regardless of how you label it, these floppies still require lots of
> care and feeding in order to work.  We currently have no way to support
> multiple floppies in a convenient way.  This can be fixed in a variety
> of ways that range from fragile hacks to wonderful designs, but it still
> requires someone to put forth the effort.  My offer for a 'floppy
> maintainer' is quite sincere; I hope that someone takes an interest and
> steps up to the challenge.

The other big "problem" with removing floppies, is that not everyone has
a cd burner. I wouldn't even say the majority of FreeBSD users have CD
burners. I think someone mentioned this.

I would love to be the 'floppy maintainer', but I know very little about
the actual process and sadly don't have the time either :(

-- 
Avleen Vig
Systems Administrator
Personal: www.silverwraith.com
EFnet:irc.mindspring.com (Earthlink user access only)
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Discussion on the future of floppies in 5.x and 6.x

2004-01-08 Thread Scott Long
On Thu, 8 Jan 2004, Matthew D. Fuller wrote:
> On Thu, Jan 08, 2004 at 02:05:14AM -0700 I heard the voice of
> Scott Long, and lo! it spake thus:
> >
> > For 5.x we already have a 3rd floppy that is dedicated to modules.
> > Unfortunately, it doesn't work nearly as well as it should because there
> > is no way to activate it during the boot sequence; it can only be used
> > once sysinstall is running.  Also, it too is nearly overflowing.
>
> Well, that's why I suggest more.  Have a "network cards" floppy, and a
> "mass storage devices" floppy, etc.  We should be able to fit the
> half-dozen most common network cards, the ata drivers, and a half dozen
> of the more common SCSI drivers on the boot kernel.  That'll get us far
> enough to be able to load the drivers off the other disks, as well as
> install with just that on many systems.
>
> It won't necessarily be the prettiest process, but I'm in favor of
> letting the floppies be a bit ugly, or even explicitly moving them to
> "experienced users only" status.  I just find them far too convenient, as
> well as ubiquitous, to see them sent into the Great Bitbucket In The Sky
> yet.
>
> If somebody wants "pretty" and "not have to fudge around to find the
> driver to load for my RAID controller", THEN let 'em download the CD  :)
>

Well, regardless of how you label it, these floppies still require lots of
care and feeding in order to work.  We currently have no way to support
multiple floppies in a convenient way.  This can be fixed in a variety
of ways that range from fragile hacks to wonderful designs, but it still
requires someone to put forth the effort.  My offer for a 'floppy
maintainer' is quite sincere; I hope that someone takes an interest and
steps up to the challenge.

Scott
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Discussion on the future of floppies in 5.x and 6.x

2004-01-08 Thread Matthew D. Fuller
On Thu, Jan 08, 2004 at 02:05:14AM -0700 I heard the voice of
Scott Long, and lo! it spake thus:
> 
> For 5.x we already have a 3rd floppy that is dedicated to modules.
> Unfortunately, it doesn't work nearly as well as it should because there
> is no way to activate it during the boot sequence; it can only be used
> once sysinstall is running.  Also, it too is nearly overflowing.

Well, that's why I suggest more.  Have a "network cards" floppy, and a
"mass storage devices" floppy, etc.  We should be able to fit the
half-dozen most common network cards, the ata drivers, and a half dozen
of the more common SCSI drivers on the boot kernel.  That'll get us far
enough to be able to load the drivers off the other disks, as well as
install with just that on many systems.

It won't necessarily be the prettiest process, but I'm in favor of
letting the floppies be a bit ugly, or even explicitly moving them to
"experienced users only" status.  I just find them far too convenient, as
well as ubiquitous, to see them sent into the Great Bitbucket In The Sky
yet.

If somebody wants "pretty" and "not have to fudge around to find the
driver to load for my RAID controller", THEN let 'em download the CD  :)


-- 
Matthew Fuller (MF4839)   |  [EMAIL PROTECTED]
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/

"The only reason I'm burning my candle at both ends, is because I
  haven't figured out how to light the middle yet"
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Discussion on the future of floppies in 5.x and 6.x

2004-01-08 Thread Per Engelbrecht
Hi Matthew and others

I think that we all can find reasons to (or not to) use floppies,
but I don'tthink that was the issue in Scott's mail.

The generational change from 4.x to 5.x where the majority of the
code hasbeen rewritten (in my opinion an extremly healthy sign for any kind of
serious development)  has taken it's toll on the develepors and
commiterstime and energy, which is why they need to fix some kind of order of
priorityin their future work.

Evolution has caught up beasts as mammuth's, Cherry Coke and floppies.
I for one, won't miss them and would rather have the developer team
spenttheir time on security, SMP, GEOM and other vital  and important
issues.
Best regards

/per
[EMAIL PROTECTED]



> On Wed, Jan 07, 2004 at 11:50:59PM -0800 I heard the voice of
> Avleen Vig, and lo! it spake thus:
>>
>> While it is indeed true that most machines since 1997 will
>> support this CD format, please take in to account:
>
> And, further, some of us don't have (and don't want) CD burners,
> and even if we had 'em, don't want to burn (no pun intended ;) a
> CD blank just to install an OS, when we can just (re-)use 2
> floppies and do it across the LAN from a local FTP mirror, which
> is as fast as a CD drive anyway.
>
> It seems to me that we could split more out into modules, and/or
> add more disks of modules (maybe categorize a "storage device"
> modules disk, a "network drivers" modules disk, etc, keeping just
> the more common devices in the main kernel).  Last I saw, the
> current system only created a single modules disk, which was a
> godsend to a kernel overflowing one disk, but as we add more and
> more stuff becomes another, albeit larger, noose.
>
>
> --
> Matthew Fuller (MF4839)   |  [EMAIL PROTECTED]
> Systems/Network Administrator |
> http://www.over-yonder.net/~fullermd/
>
> "The only reason I'm burning my candle at both ends, is because I
>  haven't figured out how to light the middle yet"
> ___
> [EMAIL PROTECTED] mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to
> "[EMAIL PROTECTED]"


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Discussion on the future of floppies in 5.x and 6.x

2004-01-08 Thread Daniel Lang
Hi,

Matthew D. Fuller wrote on Thu, Jan 08, 2004 at 01:58:11AM -0600:
[..]
> And, further, some of us don't have (and don't want) CD burners, and even
> if we had 'em, don't want to burn (no pun intended ;) a CD blank just to
> install an OS, when we can just (re-)use 2 floppies and do it across the
> LAN from a local FTP mirror, which is as fast as a CD drive anyway.

That's no point, as you can use a CD-RW, so no media is wasted.
Install over LAN is done anyway, as Scott mentioned only the
basic boot/install-strap is put into the emulated image.

However, I second the point, that there is recent hardware around
which cannot have a CD-Drive attached, but a floppy drive, because
of space constraints.

On the other hand, I guess such systems are able to boot over
the network. I'd love to see a integrated boot and installation
procedure that utilizes PXE (or any other network boot method)
and advocates it. (In this regard I just love Suns).

my 0.02¤,
 Daniel
-- 
IRCnet: Mr-Spock - Work is for people, who don't surf -  
 Daniel Lang * [EMAIL PROTECTED] * +49 89 289 18532 * http://www.leo.org/~dl/


smime.p7s
Description: S/MIME cryptographic signature


Re: Discussion on the future of floppies in 5.x and 6.x

2004-01-08 Thread Scott Long
On Thu, 8 Jan 2004, Matthew D. Fuller wrote:
> On Wed, Jan 07, 2004 at 11:50:59PM -0800 I heard the voice of
> Avleen Vig, and lo! it spake thus:
> >
> > While it is indeed true that most machines since 1997 will support this
> > CD format, please take in to account:
>
> And, further, some of us don't have (and don't want) CD burners, and even
> if we had 'em, don't want to burn (no pun intended ;) a CD blank just to
> install an OS, when we can just (re-)use 2 floppies and do it across the
> LAN from a local FTP mirror, which is as fast as a CD drive anyway.

Well, using the emulated boot cd would only be about 3MB and would only
contain the sysinstall environment, so you'd still be installing over the
LAN or whatever.  As someone else pointed out, it is apparently possible
to use Compact Flash as the media instead of a CD, so that is something to
consider also.

>
> It seems to me that we could split more out into modules, and/or add more
> disks of modules (maybe categorize a "storage device" modules disk, a
> "network drivers" modules disk, etc, keeping just the more common devices
> in the main kernel).  Last I saw, the current system only created a
> single modules disk, which was a godsend to a kernel overflowing one
> disk, but as we add more and more stuff becomes another, albeit larger,
> noose.
>

For 5.x we already have a 3rd floppy that is dedicated to modules.
Unfortunately, it doesn't work nearly as well as it should because there
is no way to activate it during the boot sequence; it can only be used
once sysinstall is running.  Also, it too is nearly overflowing.

Scott
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Discussion on the future of floppies in 5.x and 6.x

2004-01-08 Thread Bernd Walter
On Thu, Jan 08, 2004 at 01:58:11AM -0600, Matthew D. Fuller wrote:
> On Wed, Jan 07, 2004 at 11:50:59PM -0800 I heard the voice of
> Avleen Vig, and lo! it spake thus:
> > 
> > While it is indeed true that most machines since 1997 will support this
> > CD format, please take in to account:
> 
> And, further, some of us don't have (and don't want) CD burners, and even
> if we had 'em, don't want to burn (no pun intended ;) a CD blank just to
> install an OS, when we can just (re-)use 2 floppies and do it across the
> LAN from a local FTP mirror, which is as fast as a CD drive anyway.

My personal descision was to use Compactflash Media in IDE mode.
They are easy to modify with your notebook.

-- 
B.Walter   BWCThttp://www.bwct.de
[EMAIL PROTECTED]  [EMAIL PROTECTED]

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Discussion on the future of floppies in 5.x and 6.x

2004-01-08 Thread Matthew D. Fuller
On Wed, Jan 07, 2004 at 11:50:59PM -0800 I heard the voice of
Avleen Vig, and lo! it spake thus:
> 
> While it is indeed true that most machines since 1997 will support this
> CD format, please take in to account:

And, further, some of us don't have (and don't want) CD burners, and even
if we had 'em, don't want to burn (no pun intended ;) a CD blank just to
install an OS, when we can just (re-)use 2 floppies and do it across the
LAN from a local FTP mirror, which is as fast as a CD drive anyway.

It seems to me that we could split more out into modules, and/or add more
disks of modules (maybe categorize a "storage device" modules disk, a
"network drivers" modules disk, etc, keeping just the more common devices
in the main kernel).  Last I saw, the current system only created a
single modules disk, which was a godsend to a kernel overflowing one
disk, but as we add more and more stuff becomes another, albeit larger,
noose.


-- 
Matthew Fuller (MF4839)   |  [EMAIL PROTECTED]
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/

"The only reason I'm burning my candle at both ends, is because I
  haven't figured out how to light the middle yet"
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Discussion on the future of floppies in 5.x and 6.x

2004-01-08 Thread Avleen Vig
On Thu, Jan 08, 2004 at 12:35:01AM -0700, Scott Long wrote:
> So, this is something to consider before 5.3.  After that, we are
> stuck with the consequences of whatever we choose (or don't choose) for
> the entire 5.x lifespan.  I do not cherish the thought of fighting
> floppies for another 2-3 years.  I'm happy to work with someone who steps
> forward and is committed to maintaining the floppies as they are today.
> Otherwise, we need to seriously consider the alternative.

Scott,

While it is indeed true that most machines since 1997 will support this
CD format, please take in to account:
  There are lots of machines with no CD drives:
"Slimline" machines a la dell/compaq/hp/gateway
Many corporate workstations
Laptops
Machines older than 1997 (this is mostly anything early PII chips
  and older, of which there are still a lot). Freebsd does work
  great on old hardware :)
I'm sure there are others I can't think of at almost midnight.. :)

I understand it is difficult to maintain the floppies. I wish I
understood them better :-) Is it not possible to have "ftp install"
floppies, which do nothing more than simple FTP installations?

-- 
Avleen Vig
Systems Administrator
Personal: www.silverwraith.com
EFnet:irc.mindspring.com (Earthlink user access only)
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


  1   2   >