Please add "sysinstall" option on the installer splash screen (next to the Shell and LiveCD), or add bsdinstall as preferred installation method in sysinstall. bsdinstall is not as versatile as sysinstall, it changes habits of users, its buggy and some features are missing - this is a tool for quick fresh installation on a new machine but can do serious damages to existing multisystem machines (i.e. changing the partitioning style to GPT, does not have option to format/noformat partitions, selecting filesystem, etc)...
Responsible Changed From-To: freebsd-bugs->freebsd-sysinstall Over to maintainer(s).
I am actively working on this PR. Note, however, that the prompt to select "sysinstall" as an alternative option to "bsdinstall" cannot be done at the installer splash screen as the OP suggests as both bsdinstall and sysinstall boot into markedly different environments. Whereas bsdinstall boots directly into the ISO-9660 filesystem structure, sysinstall instead expects to boot into an mfsroot structure loaded into memory by loader(8). Therefore, the choice must be presented to the user in the boot-loader menu where the decision can appropriately affect the boot process to boot into the appropriate structure. Here's some pictures showing the option present in the boot loader (see option #8): http://www.twitpic.com/89l2ub/full http://www.twitpic.com/89l4n6/full Note, also, that this is a significant development effort. However, it's also worth noting that this has been planned since before 9.0-RC1 and was discussed at-length on the -sysinstall@ mailing-list in 2010/2011. -- Devin _____________ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you.
Hello Devin and thank you for your response! :-) Having that option would be great, unless its too much work to prepare two separate install methods if you say they need different boot method. I was told bsdinstall replaced sysinstall because it has new features unavailable to sysinstall and its better to maintain. Now I also see more about their difference and that it is not possible to simply put bsdinstall as sysinstall option. I can understand that change and I can understand this makes no bigger sense to develop both of the installers anymore at the same time as they work in a totally different way from system perspective and if the bsdinstall is really better. Right now this is clear for me those are two different programs based on two different mechanisms. I was just suprised bsdinstall was passed and replaced the good installer without implementing existing sysinstall functionalities first (i.e. does not allow to perform fresh install over existing one, set installation options, choose media before commit, etc), and this is very important from user perspective. Now its already in production, so it should develop rapidly and bring the good sysinstall functionalities again soon :-) Btw. are there any comparison documents/articles between functionalities of old boot method used by sysinstall and the new boot method used by bsdinstall to see the advantages of the new method? :-) Best regards! :-) Tomek
On Jan 25, 2012, at 2:02 PM, CeDeROM wrote: > Hello Devin and thank you for your response! :-) >=20 You're welcome ^_^ > Having that option would be great, unless its too much work to prepare > two separate install methods if you say they need different boot > method. It's not hard at all. I have a very elegant solution for separating the nam= espaces. This involves chroot'ing bsdinstall into it's own ISO-9660 namespace, where= it: 1. can bootstrap a traditional /etc/rc 2. have full access to 100+ binaries, and 3. unpacks *.txz files from /usr/freebsd-dist/ opposed to sysinstall which can be separated into it's own namespace, where 1. there is no /etc/rc-style bootstrap and init simply executes /stand/sysi= nstall directly 2. the only binaries available are those in the 1.9MB mfsroot.gz loaded by = loader(8), and 3. it unpacks split-tgz dists from the CD-ROM media it booted from The chroot'ing mentioned is accomplished by using DruidBSD, which is: a. the above-mentioned "1.9MB mfsroot.gz", designed to... b. boot the user into a read-write (albeit limited to ~700K usable space) m= emory filesystem c. Use the ISO09660 geom provider to re-mount /dev/iso9660/druid to /cdrom d. Bootstrap additional executables into PATH based in /cdrom/freebsd/rescue e. Configure shared object support for /cdrom/freebsd/rescue/lib f. Provide the user with a BASH shell I'll simply create a custom build of DruidBSD that swaps that last step for= calling "chroot /cdrom/freebsd/bsdinstallroot /bin/sh /etc/rc" rather than= calling "/cdrom/freebsd/rescue/bash". Then, the boot-loader menu will simply be (on the underside) swapping-out m= fsroot's (sysinstall's instead of the shim-one created to bootstrap the use= r into the bsdinstall root). It may sound complicated, but the shim actually has a very important advant= age (explained below in your quest to understand the pro's-versus-con's bet= ween these two diametrically-apposed boot-procedures. > I was told bsdinstall replaced sysinstall because it has new > features unavailable to sysinstall and its better to maintain. Now I > also see more about their difference and that it is not possible to > simply put bsdinstall as sysinstall option. I can understand that > change and I can understand this makes no bigger sense to develop both > of the installers anymore at the same time as they work in a totally > different way from system perspective and if the bsdinstall is really > better. It's not so much as "better" as it is "different". I'm actually proposing a third-option which marries the two to create somet= hing better than both (creating an-overall easier-to-maintain system). Using the mfsroot to pre-bootstrap the normal-execution-style (mimicking tr= aditional boot) of bsdinstall (which I definitely approve of -- more on tha= t below) actually better-enables bsdinstall to run in a more-natural LiveCD= environment. ASIDE (the "more on that below" part): The fact that bsdinstall boots into a LiveCD environment makes it what I te= rm a "new-style installer" (which is a great thing). In my mind, a fancy gr= aphical installer doesn't itself define a "new-style installer" but instead= by-definition I mean that there has been a merger between "LiveCD" functio= nality and "Installer" functionality. A new-style installer actually bootst= raps a natural environment directly from the CD-ROM and actually appears li= ke an installed system when observing the ISO-9660 directory structure. Thi= s means the user has the ability to (a) run diskless, and/or (b) play befor= e optionally (c) installing -- all without rebooting. From the systems arch= itecture/developer angle, it's even greater that installation is not necess= ary to easily probe hardware, poke drivers, test kernels, etc. There's only one problem with the current method of marrying the LiveCD/Ins= taller environments -- booting a traditional system requires a writable fil= esystem so a simple "make installworld" to the ISO-9660 directory root is o= ut of the question. This is where the shim mfsroot comes in to save the day. Currently-developed is an mfsroot specifically focused on breaking out of t= he mfsroot structure and re-rooting into the ISO-9660 structure using the G= EOM layer. This today can be used to bootstrap into the bsdinstall install environment= and provide an identical experience to what bsdinstall provides today as-p= rovided by 9.0-RELEASE media However, this can be enhanced to make it possible to do that "make installw= orld" to the ISO-9660 structure ... making that LiveCD/Installer look even = more like a true LiveCD (that is, making it look even more like an installe= d system that the user can play in). Currently not-yet developed but _could_ be easily done is to use that pre-b= ootstrap process of the mfsroot to do the following: 1. Mount the ISO-9660 GEOM layer 2. load tmpfs.ko (provided on hypothetical enhanced mfsroot) 3. load unionfs.ko (provided on hypothetical enhanced mfsroot) 4. Create a small (10MB? 100MB?) tmpfs area to write to 5. Layer the tmpfs writable area onto the ISO-9660 layer creating a "writab= le ISO-9660 structure" 6. chroot into ISO-9660 structure where we boot a natural system that forks= -off to bsdinstall (which asks if you want to continue to multi-user mode [= which it doesn't-yet, it just simply offers to start a shell], where the us= er can re-invoke the installer anytime by executing bsdinstall). End ASIDE. > Right now this is clear for me those are two different > programs based on two different mechanisms. I was just suprised > bsdinstall was passed and replaced the good installer without > implementing existing sysinstall functionalities first (i.e. does not > allow to perform fresh install over existing one, set installation > options, choose media before commit, etc), and this is very important > from user perspective. With the way things were going with RC3, a lot of us were under the impress= ion that 9.0-RELEASE would use sysinstall and bsdinstall would be pushed ba= ck to 9.1 for use on media. > Now its already in production, so it should > develop rapidly and bring the good sysinstall functionalities again > soon :-) >=20 Because the changes that I'm proposing are deep, require long-discussions, = and are sweeping... I'm releasing a forked installer and will be looking for feedback. The feedback will hopefully help shape the direction that affect not only t= he installer but release engineering. > Btw. are there any comparison documents/articles between > functionalities of old boot method used by sysinstall and the new boot > method used by bsdinstall to see the advantages of the new method? :-) >=20 See above. > Best regards! :-) > Tomek Thanks! --=20 Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you.
Behold! FreeBSD Druid! http://druidbsd.sourceforge.net/ Install FreeBSD 9.0 with sysinstall (!!) -- Devin _____________ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you.
On Sat, Jan 28, 2012 at 10:19 AM, Devin Teske <devin.teske@fisglobal.com> wrote: > Behold! FreeBSD Druid! > http://druidbsd.sourceforge.net/ > Install FreeBSD 9.0 with sysinstall (!!) > -- > Devin AVE!!! :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
On Sat, Jan 28, 2012 at 10:19 AM, Devin Teske <devin.teske@fisglobal.com> wrote: > Behold! FreeBSD Druid! > http://druidbsd.sourceforge.net/ > Install FreeBSD 9.0 with sysinstall (!!) Uhm, on commit there is an error that "installer is unable to find device node to /dev/ada0s1b in /dev", it happens both on clean install on blank disk and reinstall over existing partitions.. Best regards :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
> -----Original Message----- > From: tomek.cedro@gmail.com [mailto:tomek.cedro@gmail.com] On Behalf Of > CeDeROM > Sent: Friday, February 03, 2012 12:16 PM > To: Devin Teske > Cc: bug-followup@freebsd.org > Subject: Re: bin/164281: bsdinstall(8): please allow sysinstall as instal= ler option >=20 > On Sat, Jan 28, 2012 at 10:19 AM, Devin Teske <devin.teske@fisglobal.com> > wrote: > > Behold! FreeBSD Druid! > > http://druidbsd.sourceforge.net/ > > Install FreeBSD 9.0 with sysinstall (!!) >=20 > Uhm, on commit there is an error that "installer is unable to find > device node to /dev/ada0s1b in /dev", it happens both on clean install > on blank disk and reinstall over existing partitions.. >=20 You've previously attempted to install with "bsdinstall" and you've written= a GPT label to your disk. Since sysinstall knows nothing of GPT *and* since the 9.0 kernel refuses to= create MBR devices in /dev unless your disk is free of GPT labels ... You must destroy the backup GPT label stored in the last sector. This can e= asily be done from the "holographic" shell started by the DRUID just before= prompting you to select your desired release. 1. Once prompted to select your desired release (e.g., 9.0/i386 or 9.0/amd6= 4) Press Alt+F4 to get the "holographic" shell 2. At the "#" prompt, type "rescue" and hit ENTER 3. At the bash prompt, type "sysctl kern.disks" to list your disk device-na= me (e.g. "ad0", "ad1", "da0", "da1", "ada0", etc.) 4. Destroy the GPT backup layout by executing: gpart destroy -F device-name NOTE: device-name is something like "ad0" (as-listed by "sysctl kern.disks") You can then press Alt+F1 and select your desired release without getting t= he error message about disk allocation failing. --=20 Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you.
Thank you Devin! I finally made it with bsdinstall and manual target partition format before install, I can see the advantages of new method right now when I have all programs running from the disk... However new boot method presented with Druid is also great and it is going to be very very nice utility when connected together (also sysinstall having option to setup i386 and both amd64 is very nice, just as the boot time utilities). Once again thank you and good luck with your work! :-) Best regards, Tomek ps/2: Boot menu can have old shortcut keys S(ingle) and V(erbose) while numbers can still toggle boot options that are applied after Enter is pressed :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
> -----Original Message----- > From: tomek.cedro@gmail.com [mailto:tomek.cedro@gmail.com] On Behalf Of > CeDeROM > Sent: Friday, February 03, 2012 2:30 PM > To: Devin Teske > Cc: bug-followup@freebsd.org > Subject: Re: bin/164281: bsdinstall(8): please allow sysinstall as instal= ler option >=20 > Thank you Devin! I finally made it with bsdinstall and manual target > partition format before install, So, in other words, you simply went back to bsdinstall after explicitly req= uesting sysinstall. (shakes head) > I can see the advantages of new > method right now when I have all programs running from the disk... Care to share? > However new boot method presented with Druid is also great and it is > going to be very very nice utility when connected together (also > sysinstall having option to setup i386 and both amd64 is very nice, > just as the boot time utilities). Once again thank you and good luck > with your work! :-) >=20 Thanks. > ps/2: Boot menu can have old shortcut keys S(ingle) and V(erbose) > while numbers can still toggle boot options that are applied after > Enter is pressed :-) >=20 Are you stating your approval or reporting a bug or requesting a feature? I= 'm not sure which. Thanks, Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you.
Any movement on your project, Devin? Many of us that have been using FreeBSD for years ('96 here) would love to see sysinstall return. Whatever sysinstall's failings, bsdinstall is far, far worse.
For bugs matching the following criteria: Status: In Progress Changed: (is less than) 2014-06-01 Reset to default assignee and clear in-progress tags. Mail being skipped
sysinstall was removed entirely in: commit e59e2d8ec7ee4b936b1d9299aed5b879b5dcc26f Author: Nathan Whitehorn <nwhitehorn@FreeBSD.org> Date: Mon Oct 3 15:13:09 2011 +0000 Farewall, sysinstall! You served us well for many years, but 10.0 is one digit beyond your time. Various sysinstall dependencies (e.g. libftpio, libdisk, libodialog, etc.) will be cleaned up in coming days. Some will take longer than others due to a few other consumers (tzsetup and sade). Notes: svn path=/head/; revision=225937
sysinstall has been removed so cannot be made available. If there are open issues in bsdinstall please submit new PRs for them.