Re: Discussion on the future of floppies in 5.x and 6.x
> "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
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
> "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
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
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
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
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
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
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
* 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
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
* 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
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
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
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
> 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
* 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
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
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
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
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
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
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
* 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
> > 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
"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
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
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
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
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
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
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
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
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
* 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
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
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
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
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
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
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
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
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
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
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
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
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
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
> 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
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
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
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
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
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
> 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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]"