Re: FreeBSD Installer Roadmap
On 2/22/2011 2:57 PM, Peter Jeremy wrote: When that does come, it will probably be driven by BIOS and hardware vendors dropping support for MBR. MBR is not a BIOS concept. MBR is an OS thing. The BIOS does not care or know what kind of partitioning you use, or if you partition at all. A GPT disk with FreeBSD should boot fine on a quarter-century-old IBM PC/AT, until FreeBSD's don't support 80286 message. There may be SSDs that know about MBR - I don't know - but otherwise hardware does not care either. We've yet to see a must have technology that would require us to shun sysinstall (as explained earlier, we have no desire whatsoever to boot from ZFS, gmirror, geli, GPT, or anything else missing from sysinstall). Two vendors have released 3 TB disks and there will be more large disks released before 9.0-RELEASE. sysinstall needs to behave well with them. As stated, it's common to boot from ZFS, mirrors, or GPT disks. These aren't blocker issues now. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: FreeBSD Installer Roadmap
On Wednesday, February 23, 2011 11:15:09 am James R. Van Artsdalen wrote: On 2/22/2011 2:57 PM, Peter Jeremy wrote: When that does come, it will probably be driven by BIOS and hardware vendors dropping support for MBR. MBR is not a BIOS concept. MBR is an OS thing. The BIOS does not care or know what kind of partitioning you use, or if you partition at all. That is mostly true. There are some SCSI BIOSes that would examine the MBR and infer what C/H/S geometry the OS was expecting from the MBR. The original dedicated disk dummy MBR triggered a divide by zero in one of these BIOS ROMs. A GPT disk with FreeBSD should boot fine on a quarter-century-old IBM PC/AT, until FreeBSD's don't support 80286 message. Even a GPT has a legacy MBR (the PMBR) at the front of the disk (it marks the entire disk as in use by a special 0xee partition or some such). -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: FreeBSD Installer Roadmap
On Wed, 2011-02-23 at 11:33 -0500, John Baldwin wrote: That is mostly true. There are some SCSI BIOSes that would examine the MBR and infer what C/H/S geometry the OS was expecting from the MBR. The original dedicated disk dummy MBR triggered a divide by zero in one of these BIOS ROMs. I guess RAID BIOS's read through the MBR too: my Gigabyte board has an Intel AHCI BIOS (1.20E seems to be the problematic revision) with fakeraid that hangs (requiring a CMOS reset) if you install FreeBSD physically after Windows 7 x64 for example - and some IBM laptops have a bug related to repair partitions and FreeBSD too (http://wiki.pcbsd.org/index.php/Laptops), so they must read the MBR too. -- Bruce Cran ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: FreeBSD Installer Roadmap
On Tue, 2011-02-22 at 01:03 -0600, Josh Paetzel wrote: I suppose my last question is along the lines of, If adding geom_mirror support to sysinstall was easy, why has it been 6+ years since gmirror made it's appearance in FreeBSD and you still can't create or install to a gmirror with sysinstall? It's not been added because everyone thinks sysinstall code is horrible and won't touch it. -- Bruce Cran ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: FreeBSD Installer Roadmap
On Feb 21, 2011, at 11:03 PM, Josh Paetzel wrote:
On Monday, February 21, 2011 08:38:03 pm Devin Teske wrote:
Really, the crux of the issue is that our organization is **just now**
migrating off of FreeBSD-4 (yes, it's true... there are over 1,000
FreeBSD-4.11 machines running in production at this very moment spanning
the entire United States, parts of India, and parts of the Indo-pacific
rim). Worse? We just added yet-another 200+ to those ranks in the past 2
months.
My hat is off to you sir... as I envy your position that you can be so
free-moving. We are encumbered by entrenched methods and do not have the
luxury of trying new things for the sake of change (case in-point, since
bsdinstall brings nothing new to the table that we rely upon, it truly
would be change for the sake of change in our organization).
Fin de dialectics.
--
Cheers,
Devin Teske
Maintaining sysinstall for 4.x is indeed a NOOP, since features aren't being
added to it, and the featureset that sysinstall supports is pretty much in
line with the featureset in 4...no ZFS, no geom_*, etc etc etc.
On the other hand, maintaining sysinstall for the next N years of new FreeBSD
releases seems hard
Actually, it's trivial to anyone that has mastered release engineering (see
release(7) and the handbook).
, when it's already missing features compared to what
FreeBSD supports,
That's the operative word here (supports). Lord help us when that changes to
requires (that is to say, if/when the FreeBSD kernel becomes legacy-free with
respect to supporting fdisk/disklabel partitioned disks).
and that's likely to continue to grow.
We've yet to see a must have technology that would require us to shun
sysinstall (as explained earlier, we have no desire whatsoever to boot from
ZFS, gmirror, geli, GPT, or anything else missing from sysinstall).
One such possible motivation would be if we needed to create a boot partition
that exceeds 4TB (the limits of MBR partitioning versus GPT). I just don't see
that happening (workstations, servers, pedestals... why would we ever need 8GB
for the operating system? all production data is being stored on enterprise
class devices such as the NEC-D210, and being backed up with tapes such as LTO;
In our organization every machine is expendable and we have disaster recovery
procedures for any/all failures).
I totally agree that for internal use, migrating thousands of lines of code
makes no sense whatsoever, especially if sysinstall meets your needs and you
don't care about the functionality it doesn't have. Exporting that to the
community seems to be a questionable use of resources.
I'm no stranger to large deployments. With my ${WORK} hat on we can install
a
thousand FreeBSD systems in a week. In my 16+ years of involvement with
FreeBSD I've written three automated installers...quite frankly, ditching
sysinstall for that happened really fast.
Good work.
However, it's a shame that you found the need to ditch sysinstall. We found no
such need and have created an automated network installation process literally
on the assembly line in a factory the size of a football stadium -- responsible
for churning out thousands of machines per year with FreeBSD-4.11 pre-installed
before they arrive on-site (all using sysinstall). The hardware gets assembled
to-spec, slides down an assembly-line, a technician jacks power, network, video
and keyboard to the box, netboots it by pressing F12, waits 5 minutes for the
screen to finish installation, powers it off, and slides it down the line.
I do admit to being a tad curious where you find systems that can run FreeBSD
4 at this point.
We're installing FreeBSD-4.11 onto modern systems, including:
Intel Server Chassis SC5299
Intel Server Chassis SR2500
just to name a couple.
Albeit, we've back-ported many drivers, such as mfi(3) from RELENG_6 to support
the LSI MegaSAS controller.
We're no stranger to putting even the Operating System on Life Support for as
long as it takes for our customers to bolster their budgets for an integrated
upgrade strategy.
We have a very small yet largely talented group of individuals (including
myself) within our organization that quickly and efficiently remediate lost
functionality required to maintain hardware compatibility simply because our
customers cannot stomach upgrading the OS every 18-months (or whatever the
life-cycle may be). We can't be forcing our customers to upgrade their entire
organization everytime the OS can't boot from some new controller -- not when
adding the lost functionality into the OS is only a matter of a couple weeks
work (at most).
So in earnest, I should have clarified that despite running FreeBSD-4.11 on
thousands of machines... it's actually a highly customized kernel _and_ install
process that allows us to run on modern hardware.
A single socket intel shows up as 8 or 12 CPUs these days,
Re: FreeBSD Installer Roadmap
On Saturday, February 19, 2011 4:34:11 am grarpamp wrote: Sysinstall is fine, as I'm sure any replacement will be. So I'll just note a few things I'd like to see in any such replacement... 1 - I used install.cfg's on floppies to clone systems, a lot. Hands on the box were needed with that. Operators skills were in question, so having them use the dialog menus properly was a pain and often resulted in non-zeroed disk or half built systems. And though all else was cloned, it needed a separate host.cfg for each box due to: fqdn, gateway, ip/mask interface - sometimes changed root disk - sometimes changed Would have killed for a simple console shell script to ask those questions of the operator, per machine. Actually, you can do that if you are a bit creative (add a few more tools to the mfsroot, and use the 'system' command in install.cfg to invoke a shell script that then generates a foo.cfg you later include via loadConfig, but I've covered that at multiple conferences by now). That said, I'm hopeful that the new installer will be more flexible in less hackish ways while letting you do things like PXE boot to a shell where you can use mfiutil to create a RAID-5 volume and then invoke the installer on that, etc. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: FreeBSD Installer Roadmap
On 02/22/11 06:45, John Baldwin wrote: On Saturday, February 19, 2011 4:34:11 am grarpamp wrote: Sysinstall is fine, as I'm sure any replacement will be. So I'll just note a few things I'd like to see in any such replacement... 1 - I used install.cfg's on floppies to clone systems, a lot. Hands on the box were needed with that. Operators skills were in question, so having them use the dialog menus properly was a pain and often resulted in non-zeroed disk or half built systems. And though all else was cloned, it needed a separatehost.cfg for each box due to: fqdn, gateway, ip/mask interface - sometimes changed root disk - sometimes changed Would have killed for a simple console shell script to ask those questions of the operator, per machine. Actually, you can do that if you are a bit creative (add a few more tools to the mfsroot, and use the 'system' command in install.cfg to invoke a shell script that then generates a foo.cfg you later include via loadConfig, but I've covered that at multiple conferences by now). That said, I'm hopeful that the new installer will be more flexible in less hackish ways while letting you do things like PXE boot to a shell where you can use mfiutil to create a RAID-5 volume and then invoke the installer on that, etc. This is something that I very explicitly built in to the design of bsdinstall. When the installer starts (as well as at several other points), you are offered an option to bring up a shell specifically to do things like this. Scripted installs are just shell scripts instead of a configuration file, so it is trivial to interleave complicated things like this. -Nathan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: FreeBSD Installer Roadmap
On Tuesday, February 22, 2011 11:26:33 am Nathan Whitehorn wrote: On 02/22/11 06:45, John Baldwin wrote: On Saturday, February 19, 2011 4:34:11 am grarpamp wrote: Sysinstall is fine, as I'm sure any replacement will be. So I'll just note a few things I'd like to see in any such replacement... 1 - I used install.cfg's on floppies to clone systems, a lot. Hands on the box were needed with that. Operators skills were in question, so having them use the dialog menus properly was a pain and often resulted in non-zeroed disk or half built systems. And though all else was cloned, it needed a separatehost.cfg for each box due to: fqdn, gateway, ip/mask interface - sometimes changed root disk - sometimes changed Would have killed for a simple console shell script to ask those questions of the operator, per machine. Actually, you can do that if you are a bit creative (add a few more tools to the mfsroot, and use the 'system' command in install.cfg to invoke a shell script that then generates a foo.cfg you later include via loadConfig, but I've covered that at multiple conferences by now). That said, I'm hopeful that the new installer will be more flexible in less hackish ways while letting you do things like PXE boot to a shell where you can use mfiutil to create a RAID-5 volume and then invoke the installer on that, etc. This is something that I very explicitly built in to the design of bsdinstall. When the installer starts (as well as at several other points), you are offered an option to bring up a shell specifically to do things like this. Scripted installs are just shell scripts instead of a configuration file, so it is trivial to interleave complicated things like this. Yes, I should have worded it a bit differently in that I do actually think that is true from what little I have seen and the hopeful bit more refers to my being able to adopt it locally. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: FreeBSD Installer Roadmap
On 02/22/11 11:14, John Baldwin wrote: On Tuesday, February 22, 2011 11:26:33 am Nathan Whitehorn wrote: On 02/22/11 06:45, John Baldwin wrote: On Saturday, February 19, 2011 4:34:11 am grarpamp wrote: Sysinstall is fine, as I'm sure any replacement will be. So I'll just note a few things I'd like to see in any such replacement... 1 - I used install.cfg's on floppies to clone systems, a lot. Hands on the box were needed with that. Operators skills were in question, so having them use the dialog menus properly was a pain and often resulted in non-zeroed disk or half built systems. And though all else was cloned, it needed a separatehost.cfg for each box due to: fqdn, gateway, ip/mask interface - sometimes changed root disk - sometimes changed Would have killed for a simple console shell script to ask those questions of the operator, per machine. Actually, you can do that if you are a bit creative (add a few more tools to the mfsroot, and use the 'system' command in install.cfg to invoke a shell script that then generates a foo.cfg you later include via loadConfig, but I've covered that at multiple conferences by now). That said, I'm hopeful that the new installer will be more flexible in less hackish ways while letting you do things like PXE boot to a shell where you can use mfiutil to create a RAID-5 volume and then invoke the installer on that, etc. This is something that I very explicitly built in to the design of bsdinstall. When the installer starts (as well as at several other points), you are offered an option to bring up a shell specifically to do things like this. Scripted installs are just shell scripts instead of a configuration file, so it is trivial to interleave complicated things like this. Yes, I should have worded it a bit differently in that I do actually think that is true from what little I have seen and the hopeful bit more refers to my being able to adopt it locally. Ah, understood. Speaking of which, there is a new amd64 snapshot ISO with bsdinstall on it (an i386 ISO should follow in the next day or so): http://people.freebsd.org/~nwhitehorn/bsdinstall-amd64-20110222.iso.bz2 This is more or less the planned final form of the installer and layout of the install media, so I would very much appreciate testing at this point. Pending a small patch to the distributeworld target currently under review, this will be followed by patches to the release Makefile to change the default installer to bsdinstall in -CURRENT. Barring any objections, I hope to have that second patch in the tree by mid-March. -Nathan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: FreeBSD Installer Roadmap
On 2011-Feb-22 02:50:54 -0800, Devin Teske dte...@vicor.com wrote: That's the operative word here (supports). Lord help us when that changes to requires (that is to say, if/when the FreeBSD kernel becomes legacy-free with respect to supporting fdisk/disklabel partitioned disks). When that does come, it will probably be driven by BIOS and hardware vendors dropping support for MBR. Current disks are at the upper limit of what MBR can be support (and that's after several revamps of MBR). Since GPT already provides a superior feature set without MBR's limits, the next step will be to just drop MBR support. And when it does come, FreeBSD needs to be ready with an installer that can cope with non-MBR disks. We've yet to see a must have technology that would require us to shun sysinstall (as explained earlier, we have no desire whatsoever to boot from ZFS, gmirror, geli, GPT, or anything else missing from sysinstall). Whilst _you_ might not be interested, lots of other people _are_ interested in using these features - I personally use a mixture of gmirror, GPT and ZFS root on different systems. Why should other people be forced to avoid these features just because you don't use them? FreeBSD's installer should support the same features as FreeBSD itself for consistency. pedestals... why would we ever need 8GB for the operating system? all production data is being stored on enterprise class devices such as the NEC-D210, and being backed up with tapes such as LTO; Not everyone uses FreeBSD in the same environment as you. We're no stranger to putting even the Operating System on Life Support for as long as it takes for our customers to bolster their budgets for an integrated upgrade strategy. Given that you've already said you are staying with FreeBSD 4.11, why are you at all worried about FreeBSD using a new installed in FreeBSD 9 to support features that don't exist in FreeBSD 4? FreeBSD is primarily a volunteer project. Whilst you may be an expert on the innards of sysinstall, this seems to be a rare skill and no-one (including yourself) has stepped up and offered to add the missing functionality to sysinstall. It's worth noting that the original author of sysinstall considered it to be a temporary stop-gap until something better was developed. The increasing disparity between FreeBSD's features, together with the opaqueness of sysinstall have led to a replacement being developed. No-one is forcing you to replace sysinstall on your legacy systems but if you want sysinstall to remain the default installer, you are going to need to add the missing functionality to it. -- Peter Jeremy pgpHyWlStxF6J.pgp Description: PGP signature
Re: FreeBSD Installer Roadmap
On Feb 22, 2011, at 12:57 PM, Peter Jeremy wrote: On 2011-Feb-22 02:50:54 -0800, Devin Teske dte...@vicor.com wrote: That's the operative word here (supports). Lord help us when that changes to requires (that is to say, if/when the FreeBSD kernel becomes legacy-free with respect to supporting fdisk/disklabel partitioned disks). When that does come, it will probably be driven by BIOS and hardware vendors dropping support for MBR. Current disks are at the upper limit of what MBR can be support (and that's after several revamps of MBR). Since GPT already provides a superior feature set without MBR's limits, the next step will be to just drop MBR support. And when it does come, FreeBSD needs to be ready with an installer that can cope with non-MBR disks. All very true. Though admittedly we're [as a technological society] still a long long ways off from dropping support for MBR in even the most modern BIOS'. We've yet to see a must have technology that would require us to shun sysinstall (as explained earlier, we have no desire whatsoever to boot from ZFS, gmirror, geli, GPT, or anything else missing from sysinstall). Whilst _you_ might not be interested, lots of other people _are_ interested in using these features - I personally use a mixture of gmirror, GPT and ZFS root on different systems. Excellent. And the likes of us (enterprise) will be watching the likes of you (non-enterprise) for many years to come to see how you fare in your travels. From time to time we'll be checking in on the list and perusing list archives to see how well you fare. I don't know if you remember, but I can remember 10+ years ago when ReiserFS (the *killer* filesystem -- sorry, I couldn't resist) hit the Linux scene. There were wild reports of comprehensive data loss even in the 3rd year of its production cycle. It was stories like that which kept down the rate of adoption because many enterprises adopt the same wait and see attitude. We call it the great shake out and all new technologies must have one before being adopted by the largest enterprises. Why should other people be forced to avoid these features just because you don't use them? They shouldn't. We encourage others to dive head-long into the soupy mix and be our guinea pigs for us. Innovation is no place for the enterprises that run the market place (or even the World). (in a very serious tone) Would you rather your bank call you up and explain that because they tried some new technology that caused a crash in the data center, you won't have access to your bank account for the next few hours whilst they reboot the master server? Just as I suspect your answer would be no, it should be self-evident that when a critical system goes down, there is not always the luxury of being able to drop to gdb/kdb and diagnose the root-cause (rather, disaster recovery procedures often demand focusing your efforts on getting said service -- if not the original machine, a replacement machine -- back online as fast as humanly possible). Whereas others may have the luxury of providing backtraces, core dumps, and swapfiles to the authors of some new kernel device driver to eventually have some critical bug fixed, the downtime required to cull those resources would decimate any profit-driven business model which relies on service uptime. It's very easy to forget that -- while playing with new technologies is both fun _and_ exciting -- businesses that make the world go-'round demand more than just the promise of stability, they demand the numbers to prove it (and even then, may still require their own engineers to perform an in-house bake-out of their own which involves the added complexity of working with their own code). Rolling in any replacement anytime anywhere requires burn-in metrics to show that the technology can reproduce an acceptable fault-to-performance ratio. Of course, it goes without saying that said stringent testing requires both resources and man-hours. FreeBSD's installer should support the same features as FreeBSD itself for consistency. I don't disagree. That's a laudable goal for all Operating Systems. Though with due respect, I don't think any one installer for any operating system allows you to achieve all permutations of which the OS itself supports. pedestals... why would we ever need 8GB for the operating system? all production data is being stored on enterprise class devices such as the NEC-D210, and being backed up with tapes such as LTO; Not everyone uses FreeBSD in the same environment as you. Oh how society would stagnate if we _did_. Thank goodness we _don't_ operate in the same environments (for your sake and mine). We're no stranger to putting even the Operating System on Life Support for as long as it takes for our customers to bolster their budgets for an integrated upgrade strategy. Given that you've already said you are staying with FreeBSD
Re: FreeBSD Installer Roadmap
On Tue, Feb 22, 2011 at 7:23 PM, Devin Teske dte...@vicor.com wrote: On Feb 22, 2011, at 12:57 PM, Peter Jeremy wrote: On 2011-Feb-22 02:50:54 -0800, Devin Teske dte...@vicor.com wrote: That's the operative word here (supports). Lord help us when that changes to requires (that is to say, if/when the FreeBSD kernel becomes legacy-free with respect to supporting fdisk/disklabel partitioned disks). When that does come, it will probably be driven by BIOS and hardware vendors dropping support for MBR. Current disks are at the upper limit of what MBR can be support (and that's after several revamps of MBR). Since GPT already provides a superior feature set without MBR's limits, the next step will be to just drop MBR support. And when it does come, FreeBSD needs to be ready with an installer that can cope with non-MBR disks. While I love a good discussion (and there have been a number of good points for either side on here), should we agree to switch the default over to bsdinstall, leave sysinstall in (lumps or no lumps), then over the period of the next 2~3 major (that amounts to 4~6 years) releases, and retire sysinstall to the happy hunting grounds? sysinstall didn't take up that much space on the release media I thought, and it might be doable to map both sets of media so that sysinstall can work in harmony on bsdinstall's release media? Preparing custom releases to use the sysinstall init_path isn't that bad, so it would at least give the legacy folks time to transition over while us guinea pigs burn in the new wax :)... Sound good? Thanks! -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: FreeBSD Installer Roadmap
On Feb 22, 2011, at 7:41 PM, Garrett Cooper wrote: On Tue, Feb 22, 2011 at 7:23 PM, Devin Teske dte...@vicor.com wrote: On Feb 22, 2011, at 12:57 PM, Peter Jeremy wrote: On 2011-Feb-22 02:50:54 -0800, Devin Teske dte...@vicor.com wrote: That's the operative word here (supports). Lord help us when that changes to requires (that is to say, if/when the FreeBSD kernel becomes legacy-free with respect to supporting fdisk/disklabel partitioned disks). When that does come, it will probably be driven by BIOS and hardware vendors dropping support for MBR. Current disks are at the upper limit of what MBR can be support (and that's after several revamps of MBR). Since GPT already provides a superior feature set without MBR's limits, the next step will be to just drop MBR support. And when it does come, FreeBSD needs to be ready with an installer that can cope with non-MBR disks. While I love a good discussion (and there have been a number of good points for either side on here), should we agree to switch the default over to bsdinstall, leave sysinstall in (lumps or no lumps), then over the period of the next 2~3 major (that amounts to 4~6 years) releases, and retire sysinstall to the happy hunting grounds? sysinstall didn't take up that much space on the release media I thought, and it might be doable to map both sets of media so that sysinstall can work in harmony on bsdinstall's release media? Preparing custom releases to use the sysinstall init_path isn't that bad, so it would at least give the legacy folks time to transition over while us guinea pigs burn in the new wax :)... Sound good? Love it. Absolutely love it. You are a uniter, sir (tips hat)! Thanks! -Garrett -- Cheers, Devin Teske - CONTACT INFORMATION - Business Solutions Consultant II FIS - fisglobal.com 510-735-5650 Mobile 510-621-2038 Office 510-621-2020 Office Fax 909-477-4578 Home/Fax devin.te...@fisglobal.com - LEGAL DISCLAIMER - This message contains confidential and proprietary information of the sender, and is intended only for the person(s) to whom it is addressed. Any use, distribution, copying or disclosure by any other person is strictly prohibited. If you have received this message in error, please notify the e-mail sender immediately, and delete the original message without making a copy. - END TRANSMISSION - ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: FreeBSD Installer Roadmap
On Tue, Feb 22, 2011 at 9:26 PM, Devin Teske dte...@vicor.com wrote: On Feb 22, 2011, at 7:41 PM, Garrett Cooper wrote: On Tue, Feb 22, 2011 at 7:23 PM, Devin Teske dte...@vicor.com wrote: On Feb 22, 2011, at 12:57 PM, Peter Jeremy wrote: On 2011-Feb-22 02:50:54 -0800, Devin Teske dte...@vicor.com wrote: That's the operative word here (supports). Lord help us when that changes to requires (that is to say, if/when the FreeBSD kernel becomes legacy-free with respect to supporting fdisk/disklabel partitioned disks). When that does come, it will probably be driven by BIOS and hardware vendors dropping support for MBR. Current disks are at the upper limit of what MBR can be support (and that's after several revamps of MBR). Since GPT already provides a superior feature set without MBR's limits, the next step will be to just drop MBR support. And when it does come, FreeBSD needs to be ready with an installer that can cope with non-MBR disks. While I love a good discussion (and there have been a number of good points for either side on here), should we agree to switch the default over to bsdinstall, leave sysinstall in (lumps or no lumps), then over the period of the next 2~3 major (that amounts to 4~6 years) releases, and retire sysinstall to the happy hunting grounds? sysinstall didn't take up that much space on the release media I thought, and it might be doable to map both sets of media so that sysinstall can work in harmony on bsdinstall's release media? Preparing custom releases to use the sysinstall init_path isn't that bad, so it would at least give the legacy folks time to transition over while us guinea pigs burn in the new wax :)... Sound good? Love it. Absolutely love it. You are a uniter, sir (tips hat)! Well, it's just a proposal. It needs to be presented to a) re@, b) they need to tentatively accept, and someone needs to a) do the work of integrating both pieces together and b) ensure it works in both cases, c) test, test test, d) commit. All of this needs to be done before 9.0-RELEASE. So I wouldn't say success! just yet, but we're on the right path. Switching stuff overnight is impossible for something like sysinstall. I'm having to deal with similar issues transitioning acquisition MIBs over to the acquiree company's style and requirements. Providing an ample transition plan is one of the great things I've noticed about BSD anyhow in areas like these :)... it shows real planning and architecture. Thanks, -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: FreeBSD Installer Roadmap
On Tue, Feb 22, 2011 at 10:41 PM, Garrett Cooper gcoo...@freebsd.orgwrote: On Tue, Feb 22, 2011 at 7:23 PM, Devin Teske dte...@vicor.com wrote: On Feb 22, 2011, at 12:57 PM, Peter Jeremy wrote: On 2011-Feb-22 02:50:54 -0800, Devin Teske dte...@vicor.com wrote: That's the operative word here (supports). Lord help us when that changes to requires (that is to say, if/when the FreeBSD kernel becomes legacy-free with respect to supporting fdisk/disklabel partitioned disks). When that does come, it will probably be driven by BIOS and hardware vendors dropping support for MBR. Current disks are at the upper limit of what MBR can be support (and that's after several revamps of MBR). Since GPT already provides a superior feature set without MBR's limits, the next step will be to just drop MBR support. And when it does come, FreeBSD needs to be ready with an installer that can cope with non-MBR disks. While I love a good discussion (and there have been a number of good points for either side on here), should we agree to switch the default over to bsdinstall, leave sysinstall in (lumps or no lumps), then over the period of the next 2~3 major (that amounts to 4~6 years) releases, and retire sysinstall to the happy hunting grounds? sysinstall didn't take up that much space on the release media I thought, and it might be doable to map both sets of media so that sysinstall can work in harmony on bsdinstall's release media? Preparing custom releases to use the sysinstall init_path isn't that bad, so it would at least give the legacy folks time to transition over while us guinea pigs burn in the new wax :)... Sound good? Thanks! -Garrett Yes , very much . My suggestion is to include the item sysinstall in BSD-Install by Nathan Whitehorn as an option in installation start up menu . In that way , existing installation works will be upward compatible with bsdinstall . My another suggestion is to move installation startup menu part into /boot/install/ directory for each architecture and allow platform specific installers by using common parts from common directories . For example , in PC-based installations ( amd64 , i386 , ... ) PC-BSD pc-sysinstall will be usable from bsdinstall as an option at present . In that form , the initial installation menu will be seen in PC environment as follows : bsdinstall ( by Nathan Whitehorn ) pc-sysinstall ( by Kris Moore ) sysinstall ( by John Hubbard ) Thank you very much . Mehmet Erol Sanliturk ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: FreeBSD Installer Roadmap
On Saturday, February 19, 2011 02:44:42 am Bruce Cran wrote: On Saturday 19 February 2011 03:04:39 Devin Teske wrote: There are many reasons for this, and none of them are selfish (although it remains possible to drum-up some selfish reason, all of the reasons behind our motivation are in-fact unselfish). Truth-be-told, I welcome the replacement of sysinstall but am very wary that ANY replacement will be able to exactly replicate the hardware compatibility that sysinstall currently enjoys. I do indeed envision a great celebration as FreeBSD-9 bucks sysinstall but also at the same time have nightmares of receiving waves of calls from people having trouble (for example) installing FreeBSD-9 on their AMD K6 based system, circa long-long-ago in a universe far-far-away. (yes, we do have data centers running that very equipment with uptime in the 1,000's of days). I think bsdinstall as it currently is is simple enough that there shouldn't be any compatibility issues: it uses gpart for partitioning, runs tools like tzsetup to configure settings etc. so there's far less to go wrong than sysinstall's custom code which for example could crash on the probing devices screen. pc-sysinstall has been used as the PC-BSD installer for quite a while now, and has done a lot of installs on a lot of different hardware platforms. I'll wager that the compatibility of the shell command gpart is a better bet than the stick your thumbs in you ears and yell nananana while you scribble 1's and 0's to a disk and voila, there's a disklabel approach that sysinstall uses. That being said, sysinstall holds FreeBSD back in a lot of ways, using GPT labeling, installing to ZFS, or gmirror, using geli, all require you to boot to a shell and do an install by hand. I'm sure more people can chime in to limitations in sysinstall than I can think of off the top of my head. So my question is: Given that everyone involved is very conscious of locking out FreeBSD from hardware platforms due to installer compatibility, wouldn't a better use of your time be investing in the future and ensuring that it works on legacy platforms as opposed to putting sysinstall on life support when it already has some fairly serious missing functionality, that is only likely to become more of an issue in the future? -- Thanks, Josh Paetzel signature.asc Description: This is a digitally signed message part.
Re: FreeBSD Installer Roadmap
On Mon, 2011-02-21 at 16:12 -0600, Josh Paetzel wrote: pc-sysinstall has been used as the PC-BSD installer for quite a while now, and has done a lot of installs on a lot of different hardware platforms. I'll wager that the compatibility of the shell command gpart is a better bet than the stick your thumbs in you ears and yell nananana while you scribble 1's and 0's to a disk and voila, there's a disklabel approach that sysinstall uses. I wish that was true: unfortunately I tried and failed to create a ZFS installation with pc-sysinstall, and I get a few worrying error messages even with UFS while it repartitions the disk - people have been reporting it creating unbootable systems. gpart might be more compatible, but I don't think parsing the output of tools like as fdisk, diskinfo and dmesg is. The concerns about GPT, ZFS, gmirror etc. in sysinstall could all be resolved in a couple of days by ripping out the existing partitioning code and replacing it with ae@'s new version of sade from /user/ae/usr.sbin/sade . However since the future is pc-sysinstall I've now shifted my work to improving the Qt front-end. -- Bruce Cran ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: FreeBSD Installer Roadmap
On Mon, 2011-02-21 at 16:12 -0600, Josh Paetzel wrote: pc-sysinstall has been used as the PC-BSD installer for quite a while now, and has done a lot of installs on a lot of different hardware platforms. I'll wager that the compatibility of the shell command gpart is a better bet than the stick your thumbs in you ears and yell nananana while you scribble 1's and 0's to a disk and voila, there's a disklabel approach that sysinstall uses. I wish that was true: unfortunately I tried and failed to create a ZFS installation with pc-sysinstall, and I get a few worrying error messages even with UFS while it repartitions the disk - people have been reporting it creating unbootable systems. gpart might be more compatible, but I don't think parsing the output of tools like as fdisk, diskinfo and dmesg is. The concerns about GPT, ZFS, gmirror etc. in sysinstall could all be resolved in a couple of days by ripping out the existing partitioning code and replacing it with ae@'s new version of sade from /user/ae/usr.sbin/sade . However since the future is pc-sysinstall I've now shifted my work to improving the Qt front-end. -- Bruce Cran ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: FreeBSD Installer Roadmap
On Feb 21, 2011, at 2:12 PM, Josh Paetzel wrote: On Saturday, February 19, 2011 02:44:42 am Bruce Cran wrote: On Saturday 19 February 2011 03:04:39 Devin Teske wrote: There are many reasons for this, and none of them are selfish (although it remains possible to drum-up some selfish reason, all of the reasons behind our motivation are in-fact unselfish). Truth-be-told, I welcome the replacement of sysinstall but am very wary that ANY replacement will be able to exactly replicate the hardware compatibility that sysinstall currently enjoys. I do indeed envision a great celebration as FreeBSD-9 bucks sysinstall but also at the same time have nightmares of receiving waves of calls from people having trouble (for example) installing FreeBSD-9 on their AMD K6 based system, circa long-long-ago in a universe far-far-away. (yes, we do have data centers running that very equipment with uptime in the 1,000's of days). I think bsdinstall as it currently is is simple enough that there shouldn't be any compatibility issues: it uses gpart for partitioning, runs tools like tzsetup to configure settings etc. so there's far less to go wrong than sysinstall's custom code which for example could crash on the probing devices screen. pc-sysinstall has been used as the PC-BSD installer for quite a while now, and has done a lot of installs on a lot of different hardware platforms. I'll wager that the compatibility of the shell command gpart is a better bet than the stick your thumbs in you ears and yell nananana while you scribble 1's and 0's to a disk and voila, there's a disklabel approach that sysinstall uses. This is a common affront that can be assuaged simply by perusing sysinstall's code. Unfortunately, I may be truly-alone in my opinion that sysinstall is elegantly simple (but then again, I also have an innate understanding of why each/every line of code exists; bourne in-truth from a decadal melange of knowledge when it comes to ancient architectures -- that and I routinely read the 15+ years of commit logs for fun). In reality, the _only_ thing, in my honest opinion, that sysinstall fails-at is its embracement of new technologies such as GPT, ZFS, and geli (just to name a few; all of which you mention below). However, this is not the position that I am (or we are, as a business collective) coming from. From the position at which we stand, sysinstall is not [yet] deficient and despite your claims, neither does it resort to black-magic scribbl[ing] 1's and 0's to a disk and voila, there's a disklabel (by comparison standards, might one be able to say -- if taking the same naive tone -- that gpart scribble[s] 1's and 0's and voila, there's a [partition table]; the only distinction being perhaps your own bias of MBR versus GPT which if you conversely understood the limitations of MBR then you might not have such qualms against disklabels). Just as it was stated by another in this thread that a system with 1,000+ days uptime may not be a good candidate for upgrade (entirely on the basis that such a system in its current state has proved its meddle), we make an argument along the same lines for the install process -- because sysinstall has served us *so exquisitely well* over the years (its meddle being proven) we are reluctant to blindly accept the new kid on the block without rigorous recension (note: in comparison by age, any technology is young when compared to sysinstall). That being said, sysinstall holds FreeBSD back in a lot of ways, using GPT labeling, installing to ZFS, or gmirror, using geli, all require you to boot to a shell and do an install by hand. I'm sure more people can chime in to limitations in sysinstall than I can think of off the top of my head. You are absolutely correct in highlighting the most prominent short-comings of sysinstall, but alas if you don't need those features then completely swapping out your installer for a new one begins to make less sense than sticking with what has served (and will continue to serve) you well. The long and the short of this is, we don't use GPT, we don't (and wouldn't) use ZFS as a root partition scheme, and have no use for geli on the root disk (though may venture into using geli as a PCI solution -- pcisecuritystandards.org -- on secondary media mounted at boot-time). Philosophically, innovation is bourne of necessity -- and we don't need any of the things that bsdinstall brings us ... so the only thing that bsdinstall represents is more work for me in migrating thousands upon thousands of lines of code to the new installer, vetting every aspect of the new installer in the process (note that we utilize sysinstall in ways that others could only dream of -- something you'll be able to see for yourself when I get back from Hong Kong to The States and start publishing our/my work). That being said, if we _did_ need the features that are provided by bsdinstall versus what is
Re: FreeBSD Installer Roadmap
On Monday, February 21, 2011 08:38:03 pm Devin Teske wrote:
Really, the crux of the issue is that our organization is **just now**
migrating off of FreeBSD-4 (yes, it's true... there are over 1,000
FreeBSD-4.11 machines running in production at this very moment spanning
the entire United States, parts of India, and parts of the Indo-pacific
rim). Worse? We just added yet-another 200+ to those ranks in the past 2
months.
My hat is off to you sir... as I envy your position that you can be so
free-moving. We are encumbered by entrenched methods and do not have the
luxury of trying new things for the sake of change (case in-point, since
bsdinstall brings nothing new to the table that we rely upon, it truly
would be change for the sake of change in our organization).
Fin de dialectics.
--
Cheers,
Devin Teske
Maintaining sysinstall for 4.x is indeed a NOOP, since features aren't being
added to it, and the featureset that sysinstall supports is pretty much in
line with the featureset in 4...no ZFS, no geom_*, etc etc etc.
On the other hand, maintaining sysinstall for the next N years of new FreeBSD
releases seems hard, when it's already missing features compared to what
FreeBSD supports, and that's likely to continue to grow.
I totally agree that for internal use, migrating thousands of lines of code
makes no sense whatsoever, especially if sysinstall meets your needs and you
don't care about the functionality it doesn't have. Exporting that to the
community seems to be a questionable use of resources.
I'm no stranger to large deployments. With my ${WORK} hat on we can install a
thousand FreeBSD systems in a week. In my 16+ years of involvement with
FreeBSD I've written three automated installers...quite frankly, ditching
sysinstall for that happened really fast.
I do admit to being a tad curious where you find systems that can run FreeBSD
4 at this point. A single socket intel shows up as 8 or 12 CPUs these days,
more than enough to tie 4.x into knots. Add in disk controllers, NICs, ACPI
(modern systems use that for nearly everything it seems) and suddenly an
installer seems the least of the concerns.
I suppose my last question is along the lines of, If adding geom_mirror
support to sysinstall was easy, why has it been 6+ years since gmirror made
it's appearance in FreeBSD and you still can't create or install to a gmirror
with sysinstall?
--
Thanks,
Josh Paetzel
signature.asc
Description: This is a digitally signed message part.
Re: FreeBSD Installer Roadmap
On Saturday 19 February 2011 03:04:39 Devin Teske wrote: There are many reasons for this, and none of them are selfish (although it remains possible to drum-up some selfish reason, all of the reasons behind our motivation are in-fact unselfish). Truth-be-told, I welcome the replacement of sysinstall but am very wary that ANY replacement will be able to exactly replicate the hardware compatibility that sysinstall currently enjoys. I do indeed envision a great celebration as FreeBSD-9 bucks sysinstall but also at the same time have nightmares of receiving waves of calls from people having trouble (for example) installing FreeBSD-9 on their AMD K6 based system, circa long-long-ago in a universe far-far-away. (yes, we do have data centers running that very equipment with uptime in the 1,000's of days). I think bsdinstall as it currently is is simple enough that there shouldn't be any compatibility issues: it uses gpart for partitioning, runs tools like tzsetup to configure settings etc. so there's far less to go wrong than sysinstall's custom code which for example could crash on the probing devices screen. -- Bruce Cran ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: FreeBSD Installer Roadmap
On 19/02/2011, at 20:04, grarpamp wrote: 1 - I used install.cfg's on floppies to clone systems, a lot. Hands on the box were needed with that. Operators skills were in question, so having them use the dialog menus properly was a pain and often resulted in non-zeroed disk or half built systems. And though all else was cloned, it needed a separate host.cfg for each box due to: fqdn, gateway, ip/mask interface - sometimes changed root disk - sometimes changed Would have killed for a simple console shell script to ask those questions of the operator, per machine. Not to get into the whole wishlist for sysinstall Mk II (aka second system syndrome in full effect).. You can do this with sysinstall already (although it isn't very clean). Also, you don't need floppies, you can do the whole install off a FAT32 USB stick with the aforementioned install.cfg file and a script run from that. I do this at work to do a partition minimal install, then untar a pre-populated FS generated from a chroot. It also asks various questions afterward for final tuning. -- 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 - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: FreeBSD Installer Roadmap
On 01/18/11 11:38, Nathan Whitehorn wrote: This plan ensures that we have a minimum of three months of testing of the new installer on snapshot media before the 9.0 release, which should ensure a minimum of bugs. I would also like to point out that there are no roads in this map that end up with us having sysinstall as the default installer past the 18th of February. After 15 years of sysinstall being greatly in need of death, it will finally be time to retire it. Today is the 18th of February. Josh Paetzel and I (mostly him) have done a significant amount of infrastructural work required to do the bsdinstall/pc-sysinstall merge, but it is not quite done yet, so I have imported bsdinstall into HEAD with its own backend. As per the original roadmap, we will now continue work on merging (first retaining the bsdinstall partition editor backend combined with the rest of pc-sysinstall) while simultaneously working on release integration and bug fixes for bsdinstall. Many thanks to everyone who provided test results and feedback. Recent test ISOs can be found at the BSDInstall wiki page at http://wiki.freebsd.org/BSDInstall for amd64, i386, powerpc, powerpc64, and sparc64. -Nathan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: FreeBSD Installer Roadmap
On Feb 18, 2011, at 7:46 AM, Nathan Whitehorn wrote: On 01/18/11 11:38, Nathan Whitehorn wrote: This plan ensures that we have a minimum of three months of testing of the new installer on snapshot media before the 9.0 release, which should ensure a minimum of bugs. I would also like to point out that there are no roads in this map that end up with us having sysinstall as the default installer past the 18th of February. After 15 years of sysinstall being greatly in need of death, it will finally be time to retire it. Today is the 18th of February. Josh Paetzel and I (mostly him) have done a significant amount of infrastructural work required to do the bsdinstall/pc-sysinstall merge, but it is not quite done yet, so I have imported bsdinstall into HEAD with its own backend. As per the original roadmap, we will now continue work on merging (first retaining the bsdinstall partition editor backend combined with the rest of pc-sysinstall) while simultaneously working on release integration and bug fixes for bsdinstall. Many thanks to everyone who provided test results and feedback. Recent test ISOs can be found at the BSDInstall wiki page at http://wiki.freebsd.org/BSDInstall for amd64, i386, powerpc, powerpc64, and sparc64. -Nathan I've been following this (and related) threads for months (regarding alternatives to sysinstall), and yet I am still hesitant to write this e-mail (perhaps unnecessarily-so)(that is to say, that I've been biting our collective tongue until now). However, the fact remains that this is perhaps going to raise some ire (or perhaps the opposite ... maybe people will like what I have to say), and for that I apologize in advance. Okay, here we go. I -- having a _deep_ love and respect for sysinstall and further having spent many years of my life in the deep annals of its twisted home-grown code base -- plan to create/manage/maintain a 3rd-party distribution installer that continues to use sysinstall to install the later (assumed bsdinstall-based) versions of FreeBSD. There are many reasons for this, and none of them are selfish (although it remains possible to drum-up some selfish reason, all of the reasons behind our motivation are in-fact unselfish). Truth-be-told, I welcome the replacement of sysinstall but am very wary that ANY replacement will be able to exactly replicate the hardware compatibility that sysinstall currently enjoys. I do indeed envision a great celebration as FreeBSD-9 bucks sysinstall but also at the same time have nightmares of receiving waves of calls from people having trouble (for example) installing FreeBSD-9 on their AMD K6 based system, circa long-long-ago in a universe far-far-away. (yes, we do have data centers running that very equipment with uptime in the 1,000's of days). This project is simply to give people an alternative as bugs are ironed-out in the new installer. A quick note however... this project will _NOT_ be continued in perpetuity. That is to say that I will only offer a sysinstall-based alternative to the newest releases using bsdinstall for a limited time. How limited? Until I can get our universal installler migrated over to the new install platform AND prove that said new installer can work on *every* machine that we employ in production. That being said, we may be looking at years of offerings (no less than one, but beit far-fetched for me to consider maintaining this longer than 3-4 years; *self-check* I just _know_ I'm going to eat those words some day). The code to keep this running has already been developed in-house and will be published in the next 6 months on http://druidbsd.sourceforge.net/ The long and the short of this is... with a large distribution of over 1,000 FreeBSD systems running in production (that's an ultra-conservative estimate by the way), we will be damned-sad to see sysinstall bite the dust yet eagerly await the day we can perform real-world tests with the newer installer -- however until then we are fully intending on extending the life of sysinstall to service our customer's production-level requirements (sysinstall has served us well, so we intend to return the favor by extending its life -- and we hope that there are people out there that have the same sentiments about this aged-but-rock-solid code). -- Cheers, Devin P.S. Call us luddites, call us slow-movers, but don't call us haters ^_^ (I for one welcome our new bsdinstall overlords -- we just need more time for the transition but don't want to be pigeon-holed into running FreeBSD-8.x as our last production OS simply because the FreeBSD-9 installer is different). P.P.S. I've got _no_ idea what kind of response I'm going to get from this. But (holds up a snifter of sherry), here's to hoping that someone out there will be sounding the trumpets in favor of someone willing to carry on the legacy! (hey, I'm all for advancement, but there's something to be said for paying
Re: FreeBSD Installer Roadmap
There are many reasons for this, and none of them are selfish (although it remains possible to drum-up some selfish reason, all of the reasons behind our motivation are in-fact unselfish). Truth-be-told, I welcome the replacement of sysinstall but am very wary that ANY replacement will be able to exactly replicate the hardware compatibility that sysinstall currently enjoys. I do indeed envision a great celebration as FreeBSD-9 bucks sysinstall but also at the same time have nightmares of receiving waves of calls from people having trouble (for example) installing FreeBSD-9 on their AMD K6 based system, circa long-long-ago in a universe far-far-away. (yes, we do have data centers running that very equipment with uptime in the 1,000's of days). I'm sure I'm not fully aware of the situation at your data center, but would systems that have 1,000+ day uptimes be candidates for upgrade to FreeBSD 9? It seems that if a system has that kind of uptime, it's a high priority server and uptime needs to be maintained. Maybe it would be possible to have both sysinstall and bsdinstall on the same install medium? Thanks, Shawn Webb ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: FreeBSD Installer Roadmap
On 02/18/11 22:11, Shawn Webb wrote: There are many reasons for this, and none of them are selfish (although it remains possible to drum-up some selfish reason, all of the reasons behind our motivation are in-fact unselfish). Truth-be-told, I welcome the replacement of sysinstall but am very wary that ANY replacement will be able to exactly replicate the hardware compatibility that sysinstall currently enjoys. I do indeed envision a great celebration as FreeBSD-9 bucks sysinstall but also at the same time have nightmares of receiving waves of calls from people having trouble (for example) installing FreeBSD-9 on their AMD K6 based system, circa long-long-ago in a universe far-far-away. (yes, we do have data centers running that very equipment with uptime in the 1,000's of days). I'm sure I'm not fully aware of the situation at your data center, but would systems that have 1,000+ day uptimes be candidates for upgrade to FreeBSD 9? It seems that if a system has that kind of uptime, it's a high priority server and uptime needs to be maintained. Maybe it would be possible to have both sysinstall and bsdinstall on the same install medium? It may. If it is possible without enormous difficulty, this is something that should certainly be in place for 9.0. If it isn't possible, it may be a good idea to provide a second set of media with sysinstall for those who want it. I think that in any case, it is extremely unlikely that sysinstall will be entirely disconnected from the build before the release. As regards the original posting, I totally share Devin's concern about wide hardware compatibility, including with very old hardware, and wish him the best of luck with sysinstall life support! As for bsdinstall, I have taken a substantial amount of effort to ensure that bsdinstall work on older hardware (I have tested it on a VT220 at 9600 baud connected to a 13-year-old Sun Ultra 5) and would regard it failing in any way on any hardware on which FreeBSD will boot as a serious bug. -Nathan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
