Re: redesigning the debian installer
On Mon Sep 25, 2000 at 12:26:07PM +0200, Bernhard R. Link wrote: > > > On Sat, 23 Sep 2000, Martin Keegan wrote: > > > Incidentally, what facilities currently exist for non-interactive partitioning? > > Is there a dedicated tool for this, or should one do > > > > /sbin/fdisk < scripted_responses > > > > /sbin/sfdisk > > It seems exacly be written for this. > (But has only limited posibilities. Nothing like make everythin one large > partition as I see it). Last I looked at it, it had some gratuitous endianess issues though. Perhaps it has gotten better... -Erik -- Erik B. Andersen email: [EMAIL PROTECTED] --This message was written using 73% post-consumer electrons-- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: redesigning the debian installer
On Sat, 23 Sep 2000, Martin Keegan wrote: > Incidentally, what facilities currently exist for non-interactive partitioning? > Is there a dedicated tool for this, or should one do > > /sbin/fdisk < scripted_responses > /sbin/sfdisk It seems exacly be written for this. (But has only limited posibilities. Nothing like make everythin one large partition as I see it). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: redesigning the debian installer
Martin Keegan wrote: > > On Sat, 23 Sep 2000, Glenn McGrath wrote: > > > > libfdisk is on the improve as well, and the code looks pretty nice, it > > > could probably be modularised for specific filesystems, only uspports > > > two architectures at the moment though. > > > > > > Glenn > > > > Crap, i meant libparted not libfdisk > > Cheers, I'll have a look at that too; I'm more interested in concentrating > on the logic we're going to have to use to drive any disk-configuring > robot. I'd like to be able to say: > > Which disks do you want to install stuff onto? > Do you want to keep any partitions on these disks? (ok, which ones) > Do you want me to work out where to stick things automaticly? (ooh, goody) We have a kind of automagical partition system in replicator (in the script repli-install). It uses sfdisk internally. You only have to provide lower and upper bound for the partitions (and the list of partitions). It adjusts partitions size to "best fit your choice". > Then internally you've got to work out how much swap to allocate, and fill > in all the other blanks which haven't been specified by the user with > computed values. I think this is acheived with our algorithm provided we use as a parameter the amount of space the user want to allocate to Debian. Sebastien PS: www.ens-lyon.fr/~schaumat/replicator/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: redesigning the debian installer
On Sat, 23 Sep 2000, Glenn McGrath wrote: > > libfdisk is on the improve as well, and the code looks pretty nice, it > > could probably be modularised for specific filesystems, only uspports > > two architectures at the moment though. > > > > Glenn > > Crap, i meant libparted not libfdisk Cheers, I'll have a look at that too; I'm more interested in concentrating on the logic we're going to have to use to drive any disk-configuring robot. I'd like to be able to say: Which disks do you want to install stuff onto? Do you want to keep any partitions on these disks? (ok, which ones) Do you want me to work out where to stick things automaticly? (ooh, goody) Then internally you've got to work out how much swap to allocate, and fill in all the other blanks which haven't been specified by the user with computed values. Mk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: redesigning the debian installer
Glenn McGrath wrote: > > libfdisk is on the improve as well, and the code looks pretty nice, it > could probably be modularised for specific filesystems, only uspports > two architectures at the moment though. > > Glenn Crap, i meant libparted not libfdisk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: redesigning the debian installer
Joey Hess wrote: > > Martin Keegan wrote: > > Incidentally, what facilities currently exist for non-interactive partitioning? > > Is there a dedicated tool for this, or should one do > > > > /sbin/fdisk < scripted_responses > > > > and pray? If we can't do pretty arbitrary partitioning in a scriptable > > fashion, the non-interactive mass install idea goes down the plughole. > > sfdisk should allow this (in util-linux). It has had problems in the > past with other architectures but I think it has been improving. > libfdisk is on the improve as well, and the code looks pretty nice, it could probably be modularised for specific filesystems, only uspports two architectures at the moment though. Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: redesigning the debian installer
On Fri, 22 Sep 2000, Joey Hess wrote: > > Incidentally, what facilities currently exist for non-interactive partitioning? > > Is there a dedicated tool for this, or should one do > > > > /sbin/fdisk < scripted_responses > > > > and pray? If we can't do pretty arbitrary partitioning in a scriptable > > fashion, the non-interactive mass install idea goes down the plughole. > > sfdisk should allow this (in util-linux). It has had problems in the > past with other architectures but I think it has been improving. Gorkl! I've just had a look at sfdisk; it probably wants to be rewritten a little so that its output is safe to feed into a shell script, but I think the HARD part of the drive paving problem is solved by sfdisk. Mk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: redesigning the debian installer
Martin Keegan wrote: > Incidentally, what facilities currently exist for non-interactive partitioning? > Is there a dedicated tool for this, or should one do > > /sbin/fdisk < scripted_responses > > and pray? If we can't do pretty arbitrary partitioning in a scriptable > fashion, the non-interactive mass install idea goes down the plughole. sfdisk should allow this (in util-linux). It has had problems in the past with other architectures but I think it has been improving. -- see shy jo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: redesigning the debian installer
On debian-boot, Joey Hess wrote: > question. This is the main reason I don't think we can use debconf as > the UI for the partitioner, which I think is the most UI-demanding part > of the install. Incidentally, what facilities currently exist for non-interactive partitioning? Is there a dedicated tool for this, or should one do /sbin/fdisk < scripted_responses and pray? If we can't do pretty arbitrary partitioning in a scriptable fashion, the non-interactive mass install idea goes down the plughole. Mk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: redesigning the debian installer
James R. Van Zandt wrote: > >Sure -- Debian has always supported installing from a serial console, > >and I hope it always will. > > Hmm. I beg to differ. I've been working on accessibility of Linux to > blind users for some time. They can't use the video display, > obviously. One installation approach is to use a serial console > connected to a second PC with terminal emulator and a speech device. > However, the Hamm and Slink i386 installation disks did not support > serial console. Ok, I guess we've only supported it for the sun architecture or something. -- see shy jo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: redesigning the debian installer
Bernhard R. Link wrote: > > > On Tue, 19 Sep 2000, Torsten Landschoff wrote: > > > It's on the debconf mailing list. The archives are at > > > http://kitenet.net/auto/pipermail/config/ > > > > Is that an open list? Since it is of interest for the installer I would > > like to subscribe to it. > > me, too Yes it's an open list. http://kitenet.net/cgi-bin/mailman/listinfo/config/ -- see shy jo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: redesigning the debian installer
Adam Di Carlo wrote: > I like this scheme but I was kinda scratching my head wondering how > device autodetection would work. I suppose that would just be a > package, say, libdetect, which when you run the configure step, would > emit information on possible network devices (including hopefully > capability to do null serial install, plip, as well as more > conventional network stuff), possible target devices, possible install > media, even possible "input" devices (normally console or fb or even X > or gecko perhaps, but also could be serial, or some automated system)? > > Is this along the lines of your thinking? More or less. I don't think libdetect can handle all of the network stuff though. > The question would become how is this information emitted and what > protocol is established for other pkgs to use this. One option is just to let things link with libdetect and use its interface to probe for things as needed. This helps limit probing for one thing. Another approach is to write the data to a file somewhere in some parsable format. > Stepping back, is there any other systems (in Debian or in the wider > world) which use this sort of modular schema to drive a user > interface? I'm a little worried that the structure of it might limit > what we can do ergonomically to make the user interface a nice > experience. I guess I read this about 5 days ago, and I've neen pondering it. Some examples: * The web. Some people consider this a user interface, and it's certianly modular. It's also hell from a UI design standpoint, IMHO. There's little consistency between modules (websites). Without resorting to nasty stuff like javascript, there is no way to implement stuff like callbacks that respond to what you're doing when you do it (for example, if you're filling in network info, a callback could autocalculate your netmask from your ip address as you type it) -- nothing happens until you take action to submit a form or go to the next page. * Debconf in Debian proper. If all you've seen is the dialog frontend in potato, you don't know how nice and usable a debconf frontend can be -- check out the slang frontend in woody (which actually still needs a bit of UI work). You move from module to module pretty seamlessly. Like the web though, debconf lacks the ability to use callbacks to make the UI respond to you -- nothing happens until you move on to the next question. This is the main reason I don't think we can use debconf as the UI for the partitioner, which I think is the most UI-demanding part of the install. I don't think modularity is really the problem though. It's that both the web and debconf abstract the UI to a certian degree, and with that abstraction comes a loss of control or even knowledge on the part of the html writer/programmer about what the UI will look like. It's a tradeoff of course. -- see shy jo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: redesigning the debian installer
On Thu, Sep 21, 2000 at 09:58:06AM -0700, Karl M. Hegbloom wrote: > How do you see `debconf' in relation to `linuxconf' or `webmin'? debconf does much less than those. It was never intended to parse the config files of any apps. Instead it is targeted to ask some simple questions and create an initial configuration. Correct me if I am wrong, Joey. > What ever happened to `coas'? No idea. Seems to be still used on Calderas systems. cu Torsten -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: redesigning the debian installer
> "Torsten" == Torsten Landschoff <[EMAIL PROTECTED]> writes: Torsten> [cfengine] >> Isn't `debconf' supposed to take on some of that all? With off-box >> config databases, pre-configuration, etc? Torsten> Forget it :( debconf is for creating the first config files and updating Torsten> them with upgrades if you did not change anything by hand. Most of the Torsten> time the debconf interface of a package does not allow what you want so Torsten> you change the config files. This is what we use cfengine for and this Torsten> is also what can't be done with debconf. >> `debconf's answer to `kickstart' again; set up one box, enter stuff >> for the differing info on the other ones, and set the thing off to >> install them all??? Will such a thing exist someday? Torsten> We are working on it. How do you see `debconf' in relation to `linuxconf' or `webmin'? What ever happened to `coas'? Joey? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: redesigning the debian installer
On Tue, Sep 19, 2000 at 11:33:56AM -0700, Joey Hess wrote: > It depends. We may decide the primary criteria for the debian-installer > debconf is size, and drop a lot of functionality. If so it might make > sense to keep both. Don't you think it would be possible to make that compile time configurable? That way the debconf source package would generate both a udebconf and the full fledged debconf. And we have a single source only. cu Torsten -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: redesigning the debian installer
On Thu, Sep 21, 2000 at 12:54:57AM -0700, Karl M. Hegbloom wrote: > Torsten> You need a decent network for that. That's not always available. > Torsten>It is nice if you have it though. > > Have yous read the "Remote Boot mini-HOWTO"? Have a look. It's in > `doc-linux-html' IIRC. They describe a setup used for school > computer labs where they can boot any OS, and boot from an image kept > on a central server. Maybe someone could package it up? I did something like that in my school back in 1997. But that has nothing to do with the installer. [cfengine] > Isn't `debconf' supposed to take on some of that all? With off-box > config databases, pre-configuration, etc? Forget it :( debconf is for creating the first config files and updating them with upgrades if you did not change anything by hand. Most of the time the debconf interface of a package does not allow what you want so you change the config files. This is what we use cfengine for and this is also what can't be done with debconf. > `debconf's answer to `kickstart' again; set up one box, enter stuff > for the differing info on the other ones, and set the thing off to > install them all??? Will such a thing exist someday? We are working on it. cu Torsten -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: redesigning the debian installer
> "Torsten" == Torsten Landschoff <[EMAIL PROTECTED]> writes: Torsten> On Tue, Sep 19, 2000 at 10:47:20AM +0200, Sebastien Chaumat wrote: >> Let me explain replicator's point of view. We assume that we want to >> install 99% identical contents on all of our computers >> (classrooms, desktops computers in our lab). So we use rsync to >> speed things up and, at the end of the install we do the 1% leaving job. Torsten> You need a decent network for that. That's not always available. It is Torsten> nice if you have it though. Have yous read the "Remote Boot mini-HOWTO"? Have a look. It's in `doc-linux-html' IIRC. They describe a setup used for school computer labs where they can boot any OS, and boot from an image kept on a central server. Maybe someone could package it up? >> We recommend cfengine in post-installation (as a front end to apt if we >> want to deal with packages). Torsten> I have to say that I partly hate and partly love cfengine. We are configuring Torsten> our systems using it but I am looking for an alternative. Some utility that Torsten> is better suited for editing config files... Isn't `debconf' supposed to take on some of that all? With off-box config databases, pre-configuration, etc? >> It's a lot (really) faster than unpacking packages. Torsten> Depends on the network ;) Unpacking is quite fast on our systems here but Torsten> configuring takes a lot of time... `debconf's answer to `kickstart' again; set up one box, enter stuff for the differing info on the other ones, and set the thing off to install them all??? Will such a thing exist someday? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: redesigning the debian installer
Randolph Chung wrote: > assuming a c-debconf is finished, do you still think we'll have a > c-debconf and a perl-debconf? I'd think we'd want to eventually only > have one implementation It depends. We may decide the primary criteria for the debian-installer debconf is size, and drop a lot of functionality. If so it might make sense to keep both. -- see shy jo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: redesigning the debian installer
Hi Sebastien, Sorry, I have to get some work done so I write only a short answer now. On Tue, Sep 19, 2000 at 02:55:30PM +0200, Sebastien Chaumat wrote: > > Nice, another feature I would need. Sadly (or luckily, depends on POV) I > > can't test it here since our systems are working fine for over a year now. > > Perhaps I will accidently wipe the disks so that I can test the installer > > there ;) > > I use VMware for that. It's a unvaluable tool to develop software > like replicator which deals with installing OS. Fine, if you can provide me with a license key... :( cu Torsten -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: redesigning the debian installer
On Tue, 19 Sep 2000, Torsten Landschoff wrote: > On Tue, Sep 19, 2000 at 10:47:20AM +0200, Sebastien Chaumat wrote: > > > Let me explain replicator's point of view. We assume that we want to > > install 99% identical contents on all of our computers > > (classrooms, desktops computers in our lab). So we use rsync to > > speed things up and, at the end of the install we do the 1% leaving job. > > You need a decent network for that. That's not always available. It is > nice if you have it though. Right. There in France it should be the case in all educational sites. Anyway I would say replicator is an easy/fast solution for networked site. > > > Partitionning is auto-scalable to handle different harddisks sizes. > > Very nice feature. I still have to check (and grab :) the code. BTW: iirc > replicator is only available as .deb. Is there a source package somewhere? The code IS the source cause it's only perl scripts :-) > > We recommend cfengine in post-installation (as a front end to apt if we > > want to deal with packages). > > I have to say that I partly hate and partly love cfengine. We are configuring > our systems using it but I am looking for an alternative. Some utility that > is better suited for editing config files... > > > It's a lot (really) faster than unpacking packages. > > Depends on the network ;) Unpacking is quite fast on our systems here but > configuring takes a lot of time... I should have written faster than unpacking/configuring :-) But 10Mbps network is ok. At 100Mbps harddrive speed is the actual limit :-) > > Using grub on our magical bootdisk allow to use a single floppy for all > > the target computers. > > Can you explain what you mean with this? Not that I am against using grub... We suppose the computers we want to install are already in the DNS and in replicators config files. Then we generate a grub menu that allow with only one floppy to select the computer to install (in fact it selects correct boot parameters for the kernel on the floppy). Then the computer boot on a shared NFS root partition and it find its hostname with the dns. Then (when classes are implemented) replicator can know which class the "target" is in. > > > Replicator as been designed for Debian 2.1 and 2.2. We would be pleased > > to include it into Woody. We are moving to sourceforge to open > > devellopement so all good willing are welcome to help improving it. It's > > You aren't a Debian developer? Not yet (though I'm also working on NIS+ for Debian) but I'd love to apply. Anyway the other (and historical) author of Replicator is Loic Prylli who maintained mailx and worked on the alpha port of Linux. > > already used in production environment. We want to implement class based > > install. > > Nice, another feature I would need. Sadly (or luckily, depends on POV) I > can't test it here since our systems are working fine for over a year now. > Perhaps I will accidently wipe the disks so that I can test the installer > there ;) I use VMware for that. It's a unvaluable tool to develop software like replicator which deals with installing OS. Cheers, Sebastien Sebastien CHAUMAT Ecole Normale Superieure Laboratoire de Physique 46, Allée d'Italie +33 4 72 72 84 66 fax: +33 4 72 72 81 81 69364 LYON CEDEX 07 FRANCE E-mail : [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: redesigning the debian installer
On Tue, Sep 19, 2000 at 10:47:20AM +0200, Sebastien Chaumat wrote: > Let me explain replicator's point of view. We assume that we want to > install 99% identical contents on all of our computers > (classrooms, desktops computers in our lab). So we use rsync to > speed things up and, at the end of the install we do the 1% leaving job. You need a decent network for that. That's not always available. It is nice if you have it though. > Partitionning is auto-scalable to handle different harddisks sizes. Very nice feature. I still have to check (and grab :) the code. BTW: iirc replicator is only available as .deb. Is there a source package somewhere? > We recommend cfengine in post-installation (as a front end to apt if we > want to deal with packages). I have to say that I partly hate and partly love cfengine. We are configuring our systems using it but I am looking for an alternative. Some utility that is better suited for editing config files... > It's a lot (really) faster than unpacking packages. Depends on the network ;) Unpacking is quite fast on our systems here but configuring takes a lot of time... > Using grub on our magical bootdisk allow to use a single floppy for all > the target computers. Can you explain what you mean with this? Not that I am against using grub... > Replicator as been designed for Debian 2.1 and 2.2. We would be pleased > to include it into Woody. We are moving to sourceforge to open > devellopement so all good willing are welcome to help improving it. It's You aren't a Debian developer? > already used in production environment. We want to implement class based > install. Nice, another feature I would need. Sadly (or luckily, depends on POV) I can't test it here since our systems are working fine for over a year now. Perhaps I will accidently wipe the disks so that I can test the installer there ;) cu Torsten -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: redesigning the debian installer
On Tue, 19 Sep 2000, Torsten Landschoff wrote: > > It's on the debconf mailing list. The archives are at > > http://kitenet.net/auto/pipermail/config/ > > Is that an open list? Since it is of interest for the installer I would > like to subscribe to it. me, too -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: redesigning the debian installer
Hello, On Sat, Sep 16, 2000 at 11:17:14AM +0800, Niall Young wrote: > Re: automating mass installs there are a number of projects to do exactly > this, most notably FAI. It'd be wise to take a look at these as they all > suggest different solutions to the same problems: > > FAI http://www.informatik.uni-koeln.de/fai/ > NAIS http://www.informatik.uni-koeln.de/nais/ > Mondo http://www.microwerks.net/~hugo/index.html > Replicatorhttp://www.ens-lyon.fr/~schaumat/replicator/ > VA SystemImager http://systemimager.sourceforge.net/ Let me explain replicator's point of view. We assume that we want to install 99% identical contents on all of our computers (classrooms, desktops computers in our lab). So we use rsync to speed things up and, at the end of the install we do the 1% leaving job. Partitionning is auto-scalable to handle different harddisks sizes. We recommend cfengine in post-installation (as a front end to apt if we want to deal with packages). It's a lot (really) faster than unpacking packages. Using grub on our magical bootdisk allow to use a single floppy for all the target computers. Replicator as been designed for Debian 2.1 and 2.2. We would be pleased to include it into Woody. We are moving to sourceforge to open devellopement so all good willing are welcome to help improving it. It's already used in production environment. We want to implement class based install. Sebastien Sebastien CHAUMAT Ecole Normale Superieure Laboratoire de Physique 46, Allée d'Italie +33 4 72 72 84 66 fax: +33 4 72 72 81 81 69364 LYON CEDEX 07 FRANCE E-mail : [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: redesigning the debian installer
On Mon, Sep 18, 2000 at 07:21:42PM -0700, Randolph Chung wrote: > > "Second System Effect"? Can you explain that with source? Thanks > > The tendency for someone who is designing a 2nd generation system to > want to put everything in and overengineer things. > > See _The Mythical Man Month_ by Federick Brooks (ISBN: 0-201-83595-9) Seems like I really have to buy that book. > > Where can I find that proposal? I seem to have missed it :( > > It's on the debconf mailing list. The archives are at > http://kitenet.net/auto/pipermail/config/ Is that an open list? Since it is of interest for the installer I would like to subscribe to it. Thanks Torsten -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: redesigning the debian installer
> "Second System Effect"? Can you explain that with source? Thanks The tendency for someone who is designing a 2nd generation system to want to put everything in and overengineer things. See _The Mythical Man Month_ by Federick Brooks (ISBN: 0-201-83595-9) > Where can I find that proposal? I seem to have missed it :( It's on the debconf mailing list. The archives are at http://kitenet.net/auto/pipermail/config/ randolph -- Debian Developer <[EMAIL PROTECTED]> http://www.TauSq.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: redesigning the debian installer
> Because the data is not quite static. Any config-script and perhaps the > install program may choose it's own sequence of questions. And the > installer may ask variable questions. ( In the menu for example). > > So I think there should be the internal database in mDebConf. An the conf > scripts can say the Frontend that they want to have answered some > question. Therefore the frontend can look in some database, if it wants. Right, but how does it follow that you don't have a single database for both the questions and the answers? (the current debconf does this...) Perhaps I still don't understand what you are getting at. randolph -- Debian Developer <[EMAIL PROTECTED]> http://www.TauSq.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: redesigning the debian installer
In riva.lists.debian.boot, you wrote: >> I think I'm confused -- what's to stop a text-based config database >> from being used for automated installs? I can think of a few good >> reasons to have non-textual databases having to do with searching and >> indexing, but unless the config file is huge (> 100KB) I can't think >> of any legitimate reason to use anything other than text. > >nothing. what i meant to say is there's flexibility in that the sysadmin >can either edit a text file to put a "script" for the automated install >on the install source media (floppy or what not), or they can have a >"configuration database" on their network some place, so that coupled >with, f.i., a dhcp server, they have essentially a centralized install >mechanism. An important element of support for profiles, which would say things like "install extra package foo" "pave my disk like so" "save my Windows partition" is, IMHO, a mechanism by which the system may automaticly determine *which* profile to use, based on host identification information such as "how much RAM/storage/etc does the machine have" "does this host bear MAC/IP address such and such" I started some code for this .. I'll dig it up; can't remember how far I got. Mk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: redesigning the debian installer
> Have you looked at it again, or are you judging by my and others' > comments? I've looked at it again and tinkered with it a little bit. It didn't really "detect" the hardware I have, but I think that's only because their db is not very complete yet. > My time is going to be somewhat limited in the next 2 months. I have a > company move, a personal move, a conference (ALS) and a wisdom teeth > extraction (ugh) scheduled. I would like to help where I can though, > esp. since I understand debconf pretty well.. wisdom teeth extraction ugh > FWIW, I wrote a usable core of debconf in about 3 weeks, and part of that > time was spent working out how it would work. Of course that was in perl. > And of course, a year of enhancing followed.. hopefully we'll be able to build on that so this won't take a year :-) > I'd like to see perl debconf be able to use this as well -- it's a big > missing piece in the debconf puzzle (as you well know). We should probably > discuss that on the debconf mailing list. assuming a c-debconf is finished, do you still think we'll have a c-debconf and a perl-debconf? I'd think we'd want to eventually only have one implementation i'll try to spend some time to come up with some more detailed interface design descriptions in the next week or so for discussion, although i'll actually be travelling for most of that time. randolph -- Debian Developer <[EMAIL PROTECTED]> http://www.TauSq.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: redesigning the debian installer
On Mon, 18 Sep 2000, Randolph Chung wrote: > > I think one has to make a difference between the internal database and an > > database some frontend might use. > > i don't understand this. why do you think these have to be separate? Because the data is not quite static. Any config-script and perhaps the install program may choose it's own sequence of questions. And the installer may ask variable questions. ( In the menu for example). So I think there should be the internal database in mDebConf. An the conf scripts can say the Frontend that they want to have answered some question. Therefore the frontend can look in some database, if it wants. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: redesigning the debian installer
> I think one has to make a difference between the internal database and an > database some frontend might use. i don't understand this. why do you think these have to be separate? randolph -- Debian Developer <[EMAIL PROTECTED]> http://www.TauSq.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: redesigning the debian installer
> I think I'm confused -- what's to stop a text-based config database > from being used for automated installs? I can think of a few good > reasons to have non-textual databases having to do with searching and > indexing, but unless the config file is huge (> 100KB) I can't think > of any legitimate reason to use anything other than text. nothing. what i meant to say is there's flexibility in that the sysadmin can either edit a text file to put a "script" for the automated install on the install source media (floppy or what not), or they can have a "configuration database" on their network some place, so that coupled with, f.i., a dhcp server, they have essentially a centralized install mechanism. randolph -- Debian Developer <[EMAIL PROTECTED]> http://www.TauSq.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: redesigning the debian installer
On Sun, Sep 17, 2000 at 08:56:35PM -0700, Randolph Chung wrote: > Whee, I just made it through the entire thread!! :-) Some comments: Hard, isn't it? > 3) custom-built images (through a CGI or something) > Very interesting idea, but I think this should be a longer-term goal. As > Brooks puts it so eloquently, beware of the "Second System Effect"! "Second System Effect"? Can you explain that with source? Thanks > Let's try to get a complete but *simple* system going first. Agreed. > 4) C-based debconf > Anyone (other than Glenn and myself) interested in working on this? I had > planned on tackling this after i finish udpkg, but my time will be somewhat > limited in the next few weeks. I don't *think* it should be too difficult to > do this Given the modular design of debconf it should be very doable. Question: Can't we make the C debconf replace the perl debconf completely? I think it's not a good idea to have both perl and C of the same program. Sure, it is harder to write C code but it's well worth it if a lot of Debian depends on it. > A month or so ago I had posted a proposal to design a detachable database > system for debconf that is modularized (can use a text or binary, local or > remote) database. i think we can work this in with the automatable installs: > a text-based debconf database is easily editable by a system administrator. > otoh, a network based (ldap or whatnot) system will also allow automated > installs over a lan/wan. Of course, size/complexity is a concern as well. Where can I find that proposal? I seem to have missed it :( Thanks Torsten -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: redesigning the debian installer
On Sat, Sep 16, 2000 at 11:17:14AM +0800, Niall Young wrote: > Re: automating mass installs there are a number of projects to do exactly > this, most notably FAI. It'd be wise to take a look at these as they all > suggest different solutions to the same problems: > > FAI http://www.informatik.uni-koeln.de/fai/ > NAIS http://www.informatik.uni-koeln.de/nais/ > Mondo http://www.microwerks.net/~hugo/index.html > Replicatorhttp://www.ens-lyon.fr/~schaumat/replicator/ > VA SystemImager http://systemimager.sourceforge.net/ As I already said there is also dzinstall http://boogie.cs.unitn.it/dz/debian/dzinstall/ And I missed another installserver ftp://ftp.rfc822.org/pub/local/installserver/ Greetings Torsten -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: redesigning the debian installer
On Sun, 17 Sep 2000, Randolph Chung wrote: > 4) C-based debconf > Anyone (other than Glenn and myself) interested in working on this? I had > planned on tackling this after i finish udpkg, but my time will be somewhat > limited in the next few weeks. I don't *think* it should be too difficult to > do this I started to make some thoughts about it. I put some code (very beginning, only something that could be the front-end-part of it, under www.jugend-wm-netz.de/home/brl/debian/fe.zip It is basely about the idee to have the frontends changing. So that you can have for example an Frontend that asks the user about System name and ip and then exits and lets the work to other frontends. Note that the code is still not able to do it, but it shows some thoughts in this direction. It does not have the main-interface for the configuration or the reading of the templetes and so on. So just some experimenting about the frontend handling. > A month or so ago I had posted a proposal to design a detachable database > system for debconf that is modularized (can use a text or binary, local or > remote) database. i think we can work this in with the automatable installs: > a text-based debconf database is easily editable by a system administrator. > otoh, a network based (ldap or whatnot) system will also allow automated > installs over a lan/wan. Of course, size/complexity is a concern as well. I think one has to make a difference between the internal database and an database some frontend might use. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: redesigning the debian installer
Randolph Chung wrote: > a text-based debconf database is easily editable by a system administrator. > otoh, a network based (ldap or whatnot) system will also allow automated > installs over a lan/wan. Of course, size/complexity is a concern as well. I think I'm confused -- what's to stop a text-based config database from being used for automated installs? I can think of a few good reasons to have non-textual databases having to do with searching and indexing, but unless the config file is huge (> 100KB) I can't think of any legitimate reason to use anything other than text. -- Michael S. Fischer <[EMAIL PROTECTED]>, AKA Otterley Lead Hacketeer, Dynamine Consulting, Silicon Valley, CA Phone: +1 650 533 4684 | AIM: IsThisOtterley | ICQ: 4218323 PGP key fingerprint: 53BD 4179 C3C6 DF0F A8D6 10E6 E1D9 7091 D330 F08D "From the bricks of shame is built the hope"--Alan Wilder -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: redesigning the debian installer
Randolph Chung wrote: > 1) hardware detection > Libraries... libdetect is the big one. When it was first started I had looked > at it and thought (IMHO only) it was a mess, but since then it seems to have > improved significantly. Have you looked at it again, or are you judging by my and others' comments? > I also saw references to vii (DCC based monitor setting retriever). I'll > definitely check it out. Several of us had thought about doing this last > year but it unfortunately never happened. of course, if we standardize on > X4 for woody then this is moot. Then I wouldn't put too much time into it if I were you -- that seems likely. > 3) custom-built images (through a CGI or something) > Very interesting idea, but I think this should be a longer-term goal. As > Brooks puts it so eloquently, beware of the "Second System Effect"! > > Let's try to get a complete but *simple* system going first. Certianly. > 4) C-based debconf > Anyone (other than Glenn and myself) interested in working on this? I had > planned on tackling this after i finish udpkg, but my time will be somewhat > limited in the next few weeks. I don't *think* it should be too difficult to > do this My time is going to be somewhat limited in the next 2 months. I have a company move, a personal move, a conference (ALS) and a wisdom teeth extraction (ugh) scheduled. I would like to help where I can though, esp. since I understand debconf pretty well.. FWIW, I wrote a usable core of debconf in about 3 weeks, and part of that time was spent working out how it would work. Of course that was in perl. And of course, a year of enhancing followed.. > A month or so ago I had posted a proposal to design a detachable database > system for debconf that is modularized (can use a text or binary, local or > remote) database. i think we can work this in with the automatable installs: > a text-based debconf database is easily editable by a system administrator. > otoh, a network based (ldap or whatnot) system will also allow automated > installs over a lan/wan. Of course, size/complexity is a concern as well. I'd like to see perl debconf be able to use this as well -- it's a big missing piece in the debconf puzzle (as you well know). We should probably discuss that on the debconf mailing list. -- see shy jo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: redesigning the debian installer
Whee, I just made it through the entire thread!! :-) Some comments: 1) hardware detection Libraries... libdetect is the big one. When it was first started I had looked at it and thought (IMHO only) it was a mess, but since then it seems to have improved significantly. it is reasonably modular and you can decide not to probe for isa devices if you don't want to, etc. other than libdetect there aren't any big projects out there. however, for modern devices all the "detection" is really done by the kernel already (cf. pci, usb) and really all is needed is a good database of id-to-driver mappings. The rest can be done with a very simple C program and some shell scripts. I also saw references to vii (DCC based monitor setting retriever). I'll definitely check it out. Several of us had thought about doing this last year but it unfortunately never happened. of course, if we standardize on X4 for woody then this is moot. 2) fully automated installs Like others I think this will be one of the most important features we should build into the new installer. I like the idea of "profiles" or "scripts" that have answers to various installer questions. Using debconf for this seems like a natural extension. (see more below). 3) custom-built images (through a CGI or something) Very interesting idea, but I think this should be a longer-term goal. As Brooks puts it so eloquently, beware of the "Second System Effect"! Let's try to get a complete but *simple* system going first. 4) C-based debconf Anyone (other than Glenn and myself) interested in working on this? I had planned on tackling this after i finish udpkg, but my time will be somewhat limited in the next few weeks. I don't *think* it should be too difficult to do this A month or so ago I had posted a proposal to design a detachable database system for debconf that is modularized (can use a text or binary, local or remote) database. i think we can work this in with the automatable installs: a text-based debconf database is easily editable by a system administrator. otoh, a network based (ldap or whatnot) system will also allow automated installs over a lan/wan. Of course, size/complexity is a concern as well. randolph -- Debian Developer <[EMAIL PROTECTED]> http://www.TauSq.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: redesigning the debian installer
Joey Hess <[EMAIL PROTECTED]> writes >Michael S. Fischer wrote: >> Serial console redirection needs to be available. We have hundreds >> of servers (with Intel L440GX+ motherboards with serial BIOS >> support) attached to Portmasters. These are headless boxes. > >Sure -- Debian has always supported installing from a serial console, >and I hope it always will. Hmm. I beg to differ. I've been working on accessibility of Linux to blind users for some time. They can't use the video display, obviously. One installation approach is to use a serial console connected to a second PC with terminal emulator and a speech device. However, the Hamm and Slink i386 installation disks did not support serial console. The main problem was that the standard kernel did not have serial support compiled in. The serial device was in a module, and you had to get pretty far into the installation before it was installed. The last time I checked, the same was true of the potato install disks. I have not checked lately. Massimo Dal Zotto <[EMAIL PROTECTED]> writes: >I am only suggesting that it should be possible to do the debconf >configuration in a separate step from the installation and store the >debconf db for each machine on a floppy for later use. ... >This is more or less what I've done in my hackish slink >auto-installer. It doesn't use debconf and doesn't have a >configuration interface but I can create profiles with a text-editor >and load them for the installation. It has been used by people >knowing only ms-windows to install a lot of machines in production >environments. This touches on the second way a blind person could install Debian - prerecord some configuration info then auto-install. Red Hat's kickstart works this way - no need to go through one installation manually before auto-installations can start. Please keep this scenario in mind while designing the new installer. - Jim Van Zandt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: redesigning the debian installer
I like this scheme but I was kinda scratching my head wondering how device autodetection would work. I suppose that would just be a package, say, libdetect, which when you run the configure step, would emit information on possible network devices (including hopefully capability to do null serial install, plip, as well as more conventional network stuff), possible target devices, possible install media, even possible "input" devices (normally console or fb or even X or gecko perhaps, but also could be serial, or some automated system)? Is this along the lines of your thinking? The question would become how is this information emitted and what protocol is established for other pkgs to use this. Stepping back, is there any other systems (in Debian or in the wider world) which use this sort of modular schema to drive a user interface? I'm a little worried that the structure of it might limit what we can do ergonomically to make the user interface a nice experience. -- .Adam Di [EMAIL PROTECTED]http://www.onShore.com/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: redesigning the debian installer
Mircea Luca wrote: > I was thinking more of archiving the whole system in place, > then use the archive to restore,not reinstalling from scratch I'm working on this. You have private mail. -- _~|__ >@ (vagn( / \`-o-'/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: redesigning the debian installer
Re: automating mass installs there are a number of projects to do exactly this, most notably FAI. It'd be wise to take a look at these as they all suggest different solutions to the same problems: FAI http://www.informatik.uni-koeln.de/fai/ NAIShttp://www.informatik.uni-koeln.de/nais/ Mondo http://www.microwerks.net/~hugo/index.html Replicator http://www.ens-lyon.fr/~schaumat/replicator/ VA SystemImager http://systemimager.sourceforge.net/ Using debconf's persistence would be great, but I'd like to store the db anywhere I like - on a bootfloppy, customised install CD, nfs/ftp server etc. and hence choose whatever method I prefer to perform mass installs. -- [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: redesigning the debian installer
"Bernhard R. Link" wrote: > > > IMHO would be more easier for this specific case to just install the > > desired configuration,then have a small program(set of shellscripts, > > whatever) that will > [...] > > 5.reboot > > > > Does this seems viable and easy to implement or it's just > > "overcomplicated" ? > > Half of discussion here is about to archieve exactly this. > > -- Hmm,not quite. I was thinking more of archiving the whole system in place, then use the archive to restore,not reinstalling from scratch based on a profile. I can't see why I'll want to reinstall again if I need to install several computers with the exact same configuration.From my experience installing debian most of the time is spent in postinstall when configuring the pacakges.It's roughly the same amount of time as the one needed to get and unpack the packages.Skipping this step will obviously reduce the amount of time needed to install. -- The best way to escape from a problem is to solve it. Alan Saporta My waste of cyberspace= http://deepblue.dyndns.org :-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: redesigning the debian installer
Massimo Dal Zotto <[EMAIL PROTECTED]> wrote:
> In my opinion ash lacks many useful features, for example variable expansion.
FUD. Ash has always supported the parameter expansions required by POSIX.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: redesigning the debian installer
Massimo Dal Zotto wrote: > I would suggest zsh. It is much smaller than bash but has 99% of the features. > It is has also readline editing, completion, history, etc. for interactive use. > In my opinion ash lacks many useful features, for example variable expansion. > My debian installer was written in zsh and I found it very good. I'm a big zsh fan, but it's way too big: -rwxr-xr-x2 root root 351k Sep 11 00:42 /usr/bin/zsh* Anyway, we don't need any of its special features in the installer. -- see shy jo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: redesigning the debian installer
On Thu Sep 14, 2000 at 11:31:25PM -0700, Joey Hess wrote: > Michael S. Fischer wrote: > > On Thu, Sep 14, 2000 at 10:57:41PM -0700, Joey Hess wrote: > > > > > Perl is out, far too big. C is fine. Shell is ok if you limit yourself to > > > pure posix shell and are very careful about extra shell commands you use, > > > since each such command adds more size. > > > > tomsrtbt uses ash. What are we using? > > Ash unless something better comes along (busybox has the beginnings of a > shell in it, but it's nowhere near posix yet). As the author of busybox shell -- use ash. busybox shell (lash) is aptly named the Lame Ass SHell. It is designed for only very lightweight lifting (such as an initrd that calls insmod to load up binary kernel modules)... -Erik -- Erik B. Andersen email: [EMAIL PROTECTED] --This message was written using 73% post-consumer electrons-- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: redesigning the debian installer
> Michael S. Fischer wrote: > > On Thu, Sep 14, 2000 at 10:57:41PM -0700, Joey Hess wrote: > > > > > Perl is out, far too big. C is fine. Shell is ok if you limit yourself to > > > pure posix shell and are very careful about extra shell commands you use, > > > since each such command adds more size. > > > > tomsrtbt uses ash. What are we using? > > Ash unless something better comes along (busybox has the beginnings of a > shell in it, but it's nowhere near posix yet). I would suggest zsh. It is much smaller than bash but has 99% of the features. It is has also readline editing, completion, history, etc. for interactive use. In my opinion ash lacks many useful features, for example variable expansion. My debian installer was written in zsh and I found it very good. -- Massimo Dal Zotto +--+ | Massimo Dal Zotto email: [EMAIL PROTECTED] | | Via Marconi, 141phone: ++39-0461534251 | | 38057 Pergine Valsugana (TN) www: http://www.cs.unitn.it/~dz/ | | Italy pgp: see my www home page | +--+ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: redesigning the debian installer
> IMHO would be more easier for this specific case to just install the > desired configuration,then have a small program(set of shellscripts, > whatever) that will [...] > 5.reboot > > Does this seems viable and easy to implement or it's just > "overcomplicated" ? Half of discussion here is about to archieve exactly this. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: redesigning the debian installer
On Thu, 14 Sep 2000, Joey Hess wrote: > So it makes a submenu of those virtual packages. Just like with the main > menu I described above, their menutest scripts are run to see if they > should be the default item in the menu. Their menutest scripts probably call > the hardware detection code, and if it detects the card, they become the > default. But when autodetection is involved here, the default should be a little more clear. If it is only focused, than the user changes the focus and is confused and screw up. Perhaps an "(PROPOSED BY AUTO-DETECTION)"-String after the detected item, so that the user still sees what to do, when he moved the focus. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: redesigning the debian installer
Michael S. Fischer wrote: > > > Each item in the main menu is provided by an installer module. Installer > > > modules indicate that they want to appear on the menu by including the > > > following special flag in their control file: > > > > > > Installer-Menu-Item: nnn > > Correct me if I'm mistaken, but doesn't this require central > coordination of a sort of "magic number registry"? Those numbers are only used to break ties if dependancies don't impose an order, so they're not too important. I don't think it will be any harder to coordinate than the init script priority numbers in Debian proper. > I think I would prefer something like "Installer-Follows: module > [,module, ...]" (e.g. the menus that must precede this one) and have > the installer figure out which order in which they're supposed to be > presented. Declaring a dependency on a module has the same effect as what you're proposing -- if the depended on module appears in the menu, it must appear before whatever depends on it. -- see shy jo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: redesigning the debian installer
Michael S. Fischer wrote: > On Thu, Sep 14, 2000 at 10:57:41PM -0700, Joey Hess wrote: > > > Perl is out, far too big. C is fine. Shell is ok if you limit yourself to > > pure posix shell and are very careful about extra shell commands you use, > > since each such command adds more size. > > tomsrtbt uses ash. What are we using? Ash unless something better comes along (busybox has the beginnings of a shell in it, but it's nowhere near posix yet). -- see shy jo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: redesigning the debian installer
On Thu, Sep 14, 2000 at 10:57:41PM -0700, Joey Hess wrote: > Perl is out, far too big. C is fine. Shell is ok if you limit yourself to > pure posix shell and are very careful about extra shell commands you use, > since each such command adds more size. tomsrtbt uses ash. What are we using? -- Michael S. Fischer <[EMAIL PROTECTED]>, AKA Otterley Lead Hacketeer, Dynamine Consulting, Silicon Valley, CA Phone: +1 650 533 4684 | AIM: IsThisOtterley | ICQ: 4218323 PGP key fingerprint: 53BD 4179 C3C6 DF0F A8D6 10E6 E1D9 7091 D330 F08D "From the bricks of shame is built the hope"--Alan Wilder -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: redesigning the debian installer
On Thu, Sep 14, 2000 at 11:36:03PM -0600, Erik Andersen wrote: > On Thu Sep 14, 2000 at 04:47:09PM -0700, Joey Hess wrote: > > > > Each item in the main menu is provided by an installer module. Installer > > modules indicate that they want to appear on the menu by including the > > following special flag in their control file: > > > > Installer-Menu-Item: nnn > > I think this is brillant. This provides a wonderfully simple way of > breaking things into chunks that can be fully groked by mere > mortals, and easily verified to be obviously correct. It also > ensure that fixing one item doesn't break 10 other things by > accident. Very good idea. Correct me if I'm mistaken, but doesn't this require central coordination of a sort of "magic number registry"? I think I would prefer something like "Installer-Follows: module [,module, ...]" (e.g. the menus that must precede this one) and have the installer figure out which order in which they're supposed to be presented. -- Michael S. Fischer <[EMAIL PROTECTED]>, AKA Otterley Lead Hacketeer, Dynamine Consulting, Silicon Valley, CA Phone: +1 650 533 4684 | AIM: IsThisOtterley | ICQ: 4218323 PGP key fingerprint: 53BD 4179 C3C6 DF0F A8D6 10E6 E1D9 7091 D330 F08D "From the bricks of shame is built the hope"--Alan Wilder -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: redesigning the debian installer
Erik Andersen wrote: > I think this is brillant. Gosh. Well, thanks. :-) FWIW, I have been sort of stuck on how exactly the main menu would work for about 3 months, and like a dam breaking it all finally came clear and expressable (I guess) today. Thank goodness! > This provides a wonderfully simple way of breaking > things into chunks that can be fully groked by mere mortals, and easily > verified to be obviously correct. It also ensure that fixing one item doesn't > break 10 other things by accident. Very good idea. This also means that the > installer floppy only needs the Menu items needed to select an appropriate key > mapping, select a user readable langage, and then set up networking or locate > the cdrom drive. All the other menu items can be downloaded and added > dynamically... You grok. > Any proposed programing language for these modules? C, sh, perl? Perl is out, far too big. C is fine. Shell is ok if you limit yourself to pure posix shell and are very careful about extra shell commands you use, since each such command adds more size. -- see shy jo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: redesigning the debian installer
On Thu Sep 14, 2000 at 04:47:09PM -0700, Joey Hess wrote: > > Each item in the main menu is provided by an installer module. Installer > modules indicate that they want to appear on the menu by including the > following special flag in their control file: > > Installer-Menu-Item: nnn I think this is brillant. This provides a wonderfully simple way of breaking things into chunks that can be fully groked by mere mortals, and easily verified to be obviously correct. It also ensure that fixing one item doesn't break 10 other things by accident. Very good idea. This also means that the installer floppy only needs the Menu items needed to select an appropriate key mapping, select a user readable langage, and then set up networking or locate the cdrom drive. All the other menu items can be downloaded and added dynamically... Any proposed programing language for these modules? C, sh, perl? -Erik -- Erik B. Andersen email: [EMAIL PROTECTED] --This message was written using 73% post-consumer electrons-- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: redesigning the debian installer
I followed this discution from the very beginning and I have one simple problem.In case one would do a mass_install of the same configuration on same hardware,then why go through all the hassle of configuring the databases and profiles and hostnames and IP's, unpack ,configure a.s.o.(in case I messed a step). IMHO would be more easier for this specific case to just install the desired configuration,then have a small program(set of shellscripts, whatever) that will 1.tar the system in place making multiple archives 2.install and configure a dhcp and an ftp server 3.create a)bootflopies if flopies are chosen to be used on the target machines b)the actual install program in case the target machines already have an ext2 filesystem and a script which will modify the runlevel,and run the install script in the defined runlevel,setting up a ramdisk for the installer since we'll gonna format the target hdd.reboot ,the system starts the installer,done.or soething simple can be worked if no reboot is desired. c)same installer archived as a rootfs.gz in case the target machines are running windows/dos and then use loadlin.The needed autoexec.bat and config.sys are standard for all so they have to be copied over the existing ones. 3.The installer should start,get an IP from the dhcp server,format the target partitions,copy (using ftp) the archives,unpack them,run lilo ,modify /etc/network/interfaces to static IP using existing network information. 4.Run whatever other post-configuration is necessary -mail,generate keys for ssh..whatever,depends on the specific configuration. 5.reboot Does this seems viable and easy to implement or it's just "overcomplicated" ? -- The best way to escape from a problem is to solve it. Alan Saporta My waste of cyberspace= http://deepblue.dyndns.org :-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: FWD: mostly UI issues (Re: redesigning the debian installer)
Adam Di Carlo wrote: > Joey Hess <[EMAIL PROTECTED]> writes: > > > > One of the things I really hate about Red Hat's installer, though, is > > > that there's no way to escape to a shell during an installation if > > > you're on the serial console. It does have shell-on-virtual-terminal > > > support, which is all fine and dandy if you're on headed machine, but > > > if you're headless, you're SOL. > > > > How does our installer handle this now? I've not had the opportunity to > > do a serial install of debian, ever. > > dbootstrap has a "run a subshell" option on the menu. Oh yeah, I was thinking about a shell on a seperate VT for some reason. -- see shy jo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: redesigning the debian installer
Before I can answer Adam's message, I need to dump out a huge change I made today to how the main menu works. Before today, Adam would have flummoxed me with his message, but I seem to be keeping ahead of him. :-) So here goes.. Each item in the main menu is provided by an installer module. Installer modules indicate that they want to appear on the menu by including the following special flag in their control file: Installer-Menu-Item: nnn Where nnn is a priority number. The priority number influsences the ordering of items in the menu; higher numbered items are closer to the end of the menu. If this field does not appear, a module will not appear on the main menu. Dependencies also influence the position of a module in the menu. A module will never appear before another module which it (directly or indirectly) depends on. Behaviour of circular dependances is undefined. The short description of the module is used as the text for its menu item. When a menu item is selected, the module that provides it is configured if it is not already configured (ie, if it is just unpacked onto the ramdisk). If it is already configured, it is reconfigured -- its postinst script is run again. However, dependencies are honored before this configuration takes place. So if a module depends on two other modules, and it is selected, both of those modules will first be installed and configured (if they arn't already). Note that if a module depends on a virtual package, and more than one package is available to satisfy that dependancy, and none of them are configured yet, the installer will generate a submenu listing the candidate packages and let the user chose which to use. The submenu is generated and ordered similarly to main menu. (TODO: what do we use for the title and some help for the submenu?) The above rules define what the menu looks like and the order of items on it. There is one other key peice to consider -- the installer has to be able to pick a reasonable default menu item. To accomplish this, we introduce a new, special script, that is part of a module's control archive. It's called the menutest script. Menutest scripts should return a true value (0) if they think it would be a good idea if their menu item was default, and a false value if it seems making their menu item the default would not be a smart decision. Menutest scripts are optional. If a module does not have one, a simpler default test is used: if the module is already configured, then it is not made the default; if it is not configured it is a candidate to be the default. Each time, before the menu is displayed, but after it is ordered, the menutest script of each menu item is run, in turn. The first menutest script to return a true value makes its menu item the default. A Menu Example -- An example -- we have the following packages unpacked onto the installer's ramdisk (leaving out the parts of their control files that don't matter): Package: install-media Installer-Menu-Item: 0 Depends: retriever Description: Configure installation media Package: floppy-retriever Provides: retriever Package: partitions Installer-Menu-Number: 1 Depends: disk-driver Description: Partition disk Package: disk-driver Package: format-partitions Installer-Menu-Number: 0 Depends: partitions, disk-driver Description: Format and mount partitions Package: install-base Installer-Menu-Number: 0 Depends: format-partitions, install-media Description: Install base system Package: install-lilo Installer-Menu-Number: 0 Depends: install-base Description: Install lilo Package: rescue-floppy Installer-Menu-Number: 2 Description: Make a rescue floppy Package: reboot Installer-Menu-Number: 3 Description: Reboot the system (Note that the above package and virtual package names are just examples.) This set of package results in the following menu: - Configure installation media - Partition disk - Format and mount partitions - Install base system - Install lilo - Make a rescue floppy - Reboot the system (Here I explain exactly why things are put into the menu in this order. See doc/ui.txt in cvs if you want to read that.) It's worth noting that if the user starts up the installer, and picks "install the base system" as their first step, the following happens: - install-media-config is configured - partitions is configured - format-partitions is configured - finally, install-base is configured Adam Di Carlo wrote: > So this is all micro-dpkg stuff, using Depends/Provides ? > > Clearly you're going to need to arbitrate a set of virtual package > names for the fundmentals, such as "configured-network". As you can see above, yes. > How does this work with attempting to configure your targetted media, > i.e., IDE, SCSI, NFSRoot, PC
Re: FWD: mostly UI issues (Re: redesigning the debian installer)
Joey Hess <[EMAIL PROTECTED]> writes: > > One of the things I really hate about Red Hat's installer, though, is > > that there's no way to escape to a shell during an installation if > > you're on the serial console. It does have shell-on-virtual-terminal > > support, which is all fine and dandy if you're on headed machine, but > > if you're headless, you're SOL. > > How does our installer handle this now? I've not had the opportunity to > do a serial install of debian, ever. dbootstrap has a "run a subshell" option on the menu. -- .Adam Di [EMAIL PROTECTED]http://www.onShore.com/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: redesigning the debian installer
Joey Hess <[EMAIL PROTECTED]> writes: > I never said this was a complete design yet. You're right, these are > all gaping holes: Yeah -- I wasn't trying to deprecate your work but cast my net a little wider, since there are a lot of blue sky / wishlist stuff floating around. I think the code that works best is the code that keeps it simple. > - A module's maintainer decides it needs one of these things (a configured > network, say). > - They make the module depend on an appropriate virtual package > (configured-network). > - Before the module is used, the system makes sure its dependencies are > met, and that the modules that satisfy those dependencies are > configured (so the network is configured, but first hardware support > for it is set up). > (I need to change how the main menu works a little bit, come to think > of it. More on this soon.) So this is all micro-dpkg stuff, using Depends/Provides ? Clearly you're going to need to arbitrate a set of virtual package names for the fundmentals, such as "configured-network". How does this work with attempting to configure your targetted media, i.e., IDE, SCSI, NFSRoot, PCMCIA IDE device -- "configured-boot-media" and "configured-target-media" virtual pkgs ? And "configured-installation-media" is where we're installing from, provided by "install-from-cdrom", "install-from-http", etc.? So the installer basically proceeds through installation steps, which is a process of installing more and more packages, perhaps leading to an overarching completed installation of "installed-debian" ?? Thus it knows that it's time to install "configured-target-media" so it tries to fullfill that dependancy, presenting the user with all the possible micro-pkgs which fulfill that? This is starting to make my head spin. Are you sure we're not overdesigning/overabstracting a bit? > My point is that these various classes of modules don't need to be > specified in much detail. I don't care how a network configuration > module works, or what programs it installs where, as long as once it > is set up, there is a configured network. Sure. > Of course, that's just in general -- we do need to think about each of > these classes of modules and find the little details that need to be > specified. Well, I wouldn't underestimate it. I mean, "configured-network" does would have to be a standardized virt pkg name, it would have to have a documented/specified list of things it's expected to do, etc. Would "configured-network" only be required for any pkg which wants to install over the network (such as installing from http, or in the later stages, running apt with http/ftp sources) ? > I wish we could share more, it's really silly we all go off and write > our own installers. Um. Er. Well, as much work as it is, it would be more risky and harder to try to mediate one installer used by all distros. > Right that's doable easily (trivial to map debconf db to 822-format) and > will work fine. Or there is this mythical debconf remote database stuff > that maybe one day someone will actually write. Please try to keep it simple. I don't want to have to maintain a woody boot-floppies. :) -- .Adam Di [EMAIL PROTECTED]http://www.onShore.com/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: FWD: mostly UI issues (Re: redesigning the debian installer)
On Thu, 14 Sep 2000, Joey Hess wrote: > The linear mode case bothers me. Trying to think about how the installer > could detect and fix it.. > > It could detect looping items[1]. The fix is always going to be to back the > install process up to some previous item that went wrong, and let the > user correct it. (If this isn't the fix, we're pretty well screwed.) > > The problem is figuring out what step to back up to. We could add a lot > of code to each failure case of each step that figures out why it > failed, and what step to go back to (ran out of disk space, go back to > partitioning, etc). We could just jump all the way back to the very > first step every time something goes wrong. > > Well it looks solvable but I don't like either of the solutions. > > Oh, if we're in linear mode and something goes wrong, we could simply > leave linear mode. "You broke it, you fix it." I think a reasonable solution is to devote some time to doing a sanity check on the debconf DB, instead of blindly doing what is indicated and trying to catch an error after it has occurred. e.g., If every package (normal or installation module) has an Installed-Size, the DB builder can check to make sure everything will fit in the allocated space. Devices that specify IO ports, IRQs, etc. can be checked for resource conflicts. etc. This will not eliminate all the problems, or obviate the need for a robust installer, but it should catch the really silly errors before they become a problem. IMO... A non-integral part of the installation process should be where the user defines what the system will consist of. The DB generated should be checked for consistency and the md5sum of the file containing the DB should be stored someplace, when the installer fires up it should check the md5sum and re-verify its consistency of the DB if they don't match. If it is not possible to re-verify the DB (can't load the module that does the checking or some required external info is unavailable) the user should be warned of that fact and either the installation proceed as normal (unless the DB contains a flag that specifies the installation should not proceed without a verified-for-consistency-DB) or the user be given a chance to redefine what is in the DB. Since it may be possible to have the DB spread out over many files in different locations, the consistency check would need to be performed by debconf on the results of concatenating and/or overlaying all the pieces. This scheme is not bulletproof, but I think it is a step in the right direction. later, Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: debconf (Re: redesigning the debian installer)
On Thu, Sep 14, 2000 at 10:55:18PM +0200, Massimo Dal Zotto wrote: > I was thinking something different. The stored profile should include not > only the package questions but also the installer questions (keyboard, swap > root partition, source location, etc.) and it should be possible to create > one or more profile without actually installing any machine. Ideally this > should be possible from the bootdisk or on an already installed system. > The config browser should be able to load and save profile files like > any normal application does. Seconded. -- Michael S. Fischer <[EMAIL PROTECTED]>, AKA Otterley Lead Hacketeer, Dynamine Consulting, Silicon Valley, CA Phone: +1 650 533 4684 | AIM: IsThisOtterley | ICQ: 4218323 PGP key fingerprint: 53BD 4179 C3C6 DF0F A8D6 10E6 E1D9 7091 D330 F08D "From the bricks of shame is built the hope"--Alan Wilder -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: debconf (Re: redesigning the debian installer)
Massimo Dal Zotto wrote: > I was thinking something different. The stored profile should include not > only the package questions but also the installer questions (keyboard, swap > root partition, source location, etc.) and it should be possible to create > one or more profile without actually installing any machine. We seem to be talking past each other. If debconf is used for installation, the debconf database includes *all* questions, it doesn't matter if they were for the installer or a package. In the message you replied to, I talked about debconf databases can be created w/o installing a machine. And the way I discussed is the *only* way that a debconf database can be created w/o actually running through an install. -- see shy jo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: debconf (Re: redesigning the debian installer)
On Thu, 14 Sep 2000, Joey Hess wrote: > > debconf here, but about the installation system which uses debconf. Can we > > save and load different pre-stored profiles? <...> > Loading: Move the data from the already installed system to each new > install somehow, hopefully by the network, and with an option of >just dropping a debconf db file onto the boot floppy. ...or a separate floppy, or non-linux partition someplace, ... later, Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: redesigning the debian installer
On Thu, Sep 14, 2000 at 11:05:17PM +0200, Massimo Dal Zotto wrote: > > > But if you want for example to install many similar machine from a cdrom > > > how can you specify which machine (hostname, ip, etc.) you are installing > > > without any prompting? > > > > DHCP > > This works if you have a network and a DHCP server. What if you have > only the cdrom? Home users usually don't have a server machine. > DHCP is ok but we must support all possibilities. I guess a 'config floppy' could also be used. I can't imagine anyone doing a mass install this way though; the cost per installation would be too high compared to setting up DHCP and FTP/NFS servers if you're going to do multiple cloned installations. -- Michael S. Fischer <[EMAIL PROTECTED]>, AKA Otterley Lead Hacketeer, Dynamine Consulting, Silicon Valley, CA Phone: +1 650 533 4684 | AIM: IsThisOtterley | ICQ: 4218323 PGP key fingerprint: 53BD 4179 C3C6 DF0F A8D6 10E6 E1D9 7091 D330 F08D "From the bricks of shame is built the hope"--Alan Wilder -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: redesigning the debian installer
Massimo Dal Zotto <[EMAIL PROTECTED]> writes: > > Massimo Dal Zotto wrote: > > > But if you want for example to install many similar machine from a cdrom > > > how can you specify which machine (hostname, ip, etc.) you are installing > > > without any prompting? > > > > DHCP > > This works if you have a network and a DHCP server. What if you have > only the cdrom? Home users usually don't have a server machine. Home users usually don't want to install many similar machines from a CD-ROM. -- "MONO - Monochrome Emulation This field is used to store your favorite bit." --FreeVGA Attribute Controller Reference -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: redesigning the debian installer
> Massimo Dal Zotto wrote: > > But if you want for example to install many similar machine from a cdrom > > how can you specify which machine (hostname, ip, etc.) you are installing > > without any prompting? > > DHCP This works if you have a network and a DHCP server. What if you have only the cdrom? Home users usually don't have a server machine. DHCP is ok but we must support all possibilities. > (Buit I have no problem with allowing an automatic installation to be > started manually. Another thing to keep in mind is that it would be > possible to make the debconf db provided for an automatica installation > include answers to every question _except_ the hostname. Then the > install is automatic except you get to walk around and enter the > hostname or whatever.) This is exactly what I had in mind and what did my old installer. Any important variable not stored in the db is asked interactively. The next step is to store also these questions in machine specific profiles and have a fully automatic installation. This approach could be used also to implement a `newbie' installation that asks only the essential things and installs a standard system. -- Massimo Dal Zotto +--+ | Massimo Dal Zotto email: [EMAIL PROTECTED] | | Via Marconi, 141phone: ++39-0461534251 | | 38057 Pergine Valsugana (TN) www: http://www.cs.unitn.it/~dz/ | | Italy pgp: see my www home page | +--+ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: debconf (Re: redesigning the debian installer)
> > Ok. It's theoretically possible to generate a debconf db by just pulling > in every debconf question the installer can possibly ask, and then use > some sort of a database browser/editor program to fill in answers. > You're not really using debconf to do this mind you. Then you feed the > doctored db to an install. Yes, but I would like to do it with debconf and then save the db instead or before using it for the installation. > Good enough? Note that the db browser isn't written, but can be. It > would run on a full linux system. > > > I also suggest that we can merge more debconf databases during the > > installation step, for example a default profile with very general > > configurations, a class profile (home, workstation, server, firewall) > > and a host specific profile (hostname, ipaddr, keyboard, mouse, monitor). > > There's a whole unimplemented part of the debconf specification that > deals with exactly this. It allows merging and overlaying databases. > Someone should implement it. The same should be true for any config file. For example install a common /etc/export on all machines and a different version on a server. What I did in my installer is simply copying different file trees for different profiles and machines on the target root after the base system files are installed. > > Yes, but can we do this with the new bootfloppies? I'm not speaking about > > debconf here, but about the installation system which uses debconf. Can we > > save and load different pre-stored profiles? > > Given the respone on this list, I think it's a must. (And I was planning > on supporting it anyway.) > > Saving: after the debian-installer installs the base system, it simply > writes its debconf database to some place inside the newly installed > system. Probably it writes it directly to the new system's debconf > database. > > Loading: Move the data from the already installed system to each new > install somehow, hopefully by the network, and with an option of >just dropping a debconf db file onto the boot floppy. I was thinking something different. The stored profile should include not only the package questions but also the installer questions (keyboard, swap root partition, source location, etc.) and it should be possible to create one or more profile without actually installing any machine. Ideally this should be possible from the bootdisk or on an already installed system. The config browser should be able to load and save profile files like any normal application does. -- Massimo Dal Zotto +--+ | Massimo Dal Zotto email: [EMAIL PROTECTED] | | Via Marconi, 141phone: ++39-0461534251 | | 38057 Pergine Valsugana (TN) www: http://www.cs.unitn.it/~dz/ | | Italy pgp: see my www home page | +--+ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: FWD: mostly UI issues (Re: redesigning the debian installer)
Michael S. Fischer wrote: > Agreed. It would be *especially* cool if the installer didn't abort > entirely if, for example, a piece of required information was missing > (for example, if someone forgot to put in the machine's DNS domain > name). Instead, it would be nice if the installer paused to collect > the information, and then resumed with the unattended installation. > > I'd say that's second priority to getting an unattended installation > working, however. We should get it for free with debconf, as I mentioned in another message. -- see shy jo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: FWD: mostly UI issues (Re: redesigning the debian installer)
On Thu, Sep 14, 2000 at 01:24:55PM -0700, Joey Hess wrote: > > Ok, I was wondering about this. Maybe an automatic install mode can deal > > with _some_ error conditions, but it does seem sometimes you just have > > to throw up your hands and scream for help. Or give up and say the > > install failed. And the latter seems a much better call. > > Er, former, not latter. Agreed. It would be *especially* cool if the installer didn't abort entirely if, for example, a piece of required information was missing (for example, if someone forgot to put in the machine's DNS domain name). Instead, it would be nice if the installer paused to collect the information, and then resumed with the unattended installation. I'd say that's second priority to getting an unattended installation working, however. -- Michael S. Fischer <[EMAIL PROTECTED]>, AKA Otterley Lead Hacketeer, Dynamine Consulting, Silicon Valley, CA Phone: +1 650 533 4684 | AIM: IsThisOtterley | ICQ: 4218323 PGP key fingerprint: 53BD 4179 C3C6 DF0F A8D6 10E6 E1D9 7091 D330 F08D "From the bricks of shame is built the hope"--Alan Wilder -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: FWD: mostly UI issues (Re: redesigning the debian installer)
Joey Hess wrote: > Ok, I was wondering about this. Maybe an automatic install mode can deal > with _some_ error conditions, but it does seem sometimes you just have > to throw up your hands and scream for help. Or give up and say the > install failed. And the latter seems a much better call. Er, former, not latter. -- see shy jo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: FWD: mostly UI issues (Re: redesigning the debian installer)
[ People keep replying to me privately. I hope you don't mind that I'm replying to the list. ] Michael S. Fischer wrote: > On Thu, Sep 14, 2000 at 01:02:22PM -0700, Joey Hess wrote: > > > Oh, if we're in linear mode and something goes wrong, we could simply > > leave linear mode. "You broke it, you fix it." > > This is what Red Hat's kickstart procedure does--returns control to > the user if an error occurs during the unattended installation. I > think it's fine, provided good diagnostic information is available. Ok, I was wondering about this. Maybe an automatic install mode can deal with _some_ error conditions, but it does seem sometimes you just have to throw up your hands and scream for help. Or give up and say the install failed. And the latter seems a much better call. > One of the things I really hate about Red Hat's installer, though, is > that there's no way to escape to a shell during an installation if > you're on the serial console. It does have shell-on-virtual-terminal > support, which is all fine and dandy if you're on headed machine, but > if you're headless, you're SOL. How does our installer handle this now? I've not had the opportunity to do a serial install of debian, ever. -- see shy jo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: redesigning the debian installer
Massimo Dal Zotto wrote: > But if you want for example to install many similar machine from a cdrom > how can you specify which machine (hostname, ip, etc.) you are installing > without any prompting? DHCP (Buit I have no problem with allowing an automatic installation to be started manually. Another thing to keep in mind is that it would be possible to make the debconf db provided for an automatica installation include answers to every question _except_ the hostname. Then the install is automatic except you get to walk around and enter the hostname or whatever.) -- see shy jo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: redesigning the debian installer
On Thu, 14 Sep 2000, Ben Collins wrote: > > Sparcs and powerpc also have PCI support for the most part -- maybe > > the focus should be just on PCI support. Then we could look at SBUS > > on older sparcs as a sideline? > > Concentratin on PCI is the goal, IMO. SBUS device detection is overkill. It seems academic to me - make guesstimates as to the percentage of boxes out there that have PCI, ISA, SBUS, whatever... then concentrate on them from most to least popular. Make allowances for _all_ of them, even if you doubt that some will ever be supported (probably trivial, considering how the new installer will work, but worthy of special consideration). I don't think saying, `that's old hardware, let's not support it' is a good idea - it sounds too much like `upgrade to my standards or get lost'. later, Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
debconf (Re: redesigning the debian installer)
Massimo Dal Zotto wrote: > > You're essentially suggesting that we don't use debconf. > > > > Ok, I'm open to that suggestion. What does this method give us that > > using a debconfish scheme does not? > > No, using debconf is ok. I don't see any other way to do it. > > I am only suggesting that it should be possible to do the debconf > configuration in a separate step from the installation and store the > debconf db for each machine on a floppy for later use. Ok. It's theoretically possible to generate a debconf db by just pulling in every debconf question the installer can possibly ask, and then use some sort of a database browser/editor program to fill in answers. You're not really using debconf to do this mind you. Then you feed the doctored db to an install. Good enough? Note that the db browser isn't written, but can be. It would run on a full linux system. > I also suggest that we can merge more debconf databases during the > installation step, for example a default profile with very general > configurations, a class profile (home, workstation, server, firewall) > and a host specific profile (hostname, ipaddr, keyboard, mouse, monitor). There's a whole unimplemented part of the debconf specification that deals with exactly this. It allows merging and overlaying databases. Someone should implement it. > > > I would like also to have the possibility to store installation > > > profiles as debconf databases on a floppy or another locations, > > > and to be able to provide a set of configuration files created in > > > advance for each machine, for example hosts, groups, exports, etc. > > > and not to be prompted when the required information can be found > > > in those files. > > > > That's what debconf is all about, really. > > Yes, but can we do this with the new bootfloppies? I'm not speaking about > debconf here, but about the installation system which uses debconf. Can we > save and load different pre-stored profiles? Given the respone on this list, I think it's a must. (And I was planning on supporting it anyway.) Saving: after the debian-installer installs the base system, it simply writes its debconf database to some place inside the newly installed system. Probably it writes it directly to the new system's debconf database. Loading: Move the data from the already installed system to each new install somehow, hopefully by the network, and with an option of just dropping a debconf db file onto the boot floppy. > This is more or less what I've done in my hackish slink auto-installer. > It doesn't use debconf and doesn't have a configuration interface but I > can create profiles with a text-editor and load them for the installation. > It has been used by people knowing only ms-windows to install a lot of > machines in production environments. It is not perfect but this the way > people needs it. I'm really glad you're involved with this redesign since you have practical experience with automated debian installs. -- see shy jo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: FWD: mostly UI issues (Re: redesigning the debian installer)
I wrote: > Also, remember the little aside I wrote about making the menu be > skippable so the install happens in a linear mode, with whatever would > be the default menu item being picked each time. This will be hard. We > will have to avoid loops that they can't break out of. I'm not sure yet > if it will really be possible to do it robustly. > > I've been thinking about this some more, and I have came up with some > places where my design breaks down. For example, suppose the menu > includes: > > - partition a hard disk > - format and mount partitions > - install base system > > But it is not being displayed, the user is just being taken from step to > step in linear mode. > > - The user partitions a hard disk, and makes some really dumb choices. > - Partitions are formatted and mounted. > - The base system fails to unpack, because they have a 1 mb /usr and a > 5 gb /usr/local. > > Now we're in a situation where the first two steps think they have been > completed satisfactoraly, and the third step knows its failing. We > really need to back the user up. How can we do this? > > (I'd like to know how boot-floppies deal with this now, and I'll > probably do some tests tomorrow to see, if nobody knows off the top of > their head.) Just tried this. It is indeed possible to make dbootstrap have "install os kernel and modules" as the next step in the menu, and nothing helpful as previous and alternate steps, and each time you pick the default it loops[1]. There's also no error message, so you have to guess that your partitioning is screwed up. I don't think this is a big problem in dinstall, though it could handle it better. If the new installer has the same problem, the effects will be: - In a normal install like dbootstrap's menu now, no different than with dbootstrap. - In an install in "linear mode", where there is no menu, an infinite loop, as the step keeps being run and failing. Yuck. - In a noninteractive install, the same thing as in linear mode. Although it would take some real effort to get through a normal install successfully, feed the recorded debconf data back into a new install, and have the new one fail. It could happen though. The linear mode case bothers me. Trying to think about how the installer could detect and fix it.. It could detect looping items[1]. The fix is always going to be to back the install process up to some previous item that went wrong, and let the user correct it. (If this isn't the fix, we're pretty well screwed.) The problem is figuring out what step to back up to. We could add a lot of code to each failure case of each step that figures out why it failed, and what step to go back to (ran out of disk space, go back to partitioning, etc). We could just jump all the way back to the very first step every time something goes wrong. Well it looks solvable but I don't like either of the solutions. Oh, if we're in linear mode and something goes wrong, we could simply leave linear mode. "You broke it, you fix it." -- see shy jo [1] I can do it by really messing up the disk partitions. I can also do it by configuring the network, unplugging my ethernet cable, and telling it to do a network install. [2] Would probably have to detect cycles of more than one item as well. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
FWD: mostly UI issues (Re: redesigning the debian installer)
I just realized this didn't go to debian-boot. Whoops. - Forwarded message from Joey Hess <[EMAIL PROTECTED]> - From: Joey Hess <[EMAIL PROTECTED]> Date: Wed, 13 Sep 2000 19:20:22 -0700 To: "Bernhard R. Link" <[EMAIL PROTECTED]> Subject: mostly UI issues (Re: redesigning the debian installer) Bernhard R. Link wrote: > > The install begins with a bootloader. It is unlikely that this will change > > significantly from what is used now. > > It would be very much convenient, if there would be a possibility to > install if from an client over the network without the need of an > boot-disk. > I think it would be on of the most bottom parts of the todo-list, and it > propably will not affect on the way the installation is done, but it would > be nice to have it on the todo-list and have a short look on it to ensure, > that it realy would work with the whole system. I said it would start with a bootloader, didn't specify what type of boot loader. :-) If we eventually want to add support for systems that can load by tftp or whatever, I don't really see how it's going to impact the design. After all, I haven't messed with the normal kernel boot process at all. > > After the kernel boots up, the first thing the user will see is whatever UI > > is being used, configuring itself. This is equivalent to the current > > installer asking if the screen supports color, and keyboard configuration. > > It might also include language selection, mouse setup, etc. All up the > > individual UI. > > How is determined which ui to use? > Could it be (additionaly to other ways) be choosen with an Env-Var on the > boot-up prompt. > Or would there be only one ui in the system, and the person making > the install-floppy/zip/cdrom choses which one to install? I can think of a few possibilities. As a degenerate case, if there is one UI, it will be used. If there are multiple UI's, they could prioritize themselves somehow, and each could be asked in turn to set itself up. If setup failed, fall back to the next UI. FWIW, perl debconf uses a similar method to pick between the UI's it can use, and it works quite well. I've added some stuff related to this to TODO in cvs. > I like this way ver much, too, and personally would not like to use > anything else. But I have seen people beeing disturbed and/or confused by > that many freedom. It should either be well tested, that you come to an > running system finally, when you wildly choose randomly. Or some question > before, if you want an more direct way. (With std-answer no and an > priority low enough. I don't think we can guarentee that one can feed random input into the installer and get a working install. That's a little ridiculous. On the other hand, there should be enough sanity checking that the install is not allowed to _complete_ until the random input happens to work. (Of course, they may just decide to reboot half way through.) And we can work as hard as we can to ensure that everything has a default answer that is as good as possible. The current debian installer really exemplifies this and shows it can be done, IMHO. Also, remember the little aside I wrote about making the menu be skippable so the install happens in a linear mode, with whatever would be the default menu item being picked each time. This will be hard. We will have to avoid loops that they can't break out of. I'm not sure yet if it will really be possible to do it robustly. I've been thinking about this some more, and I have came up with some places where my design breaks down. For example, suppose the menu includes: - partition a hard disk - format and mount partitions - install base system But it is not being displayed, the user is just being taken from step to step in linear mode. - The user partitions a hard disk, and makes some really dumb choices. - Partitions are formatted and mounted. - The base system fails to unpack, because they have a 1 mb /usr and a 5 gb /usr/local. Now we're in a situation where the first two steps think they have been completed satisfactoraly, and the third step knows its failing. We really need to back the user up. How can we do this? (I'd like to know how boot-floppies deal with this now, and I'll probably do some tests tomorrow to see, if nobody knows off the top of their head.) > I think the user will get an debconf-frontend there, too, to ask the > questions. I think it would be nice, if the kind of ui in the > base-install could be committed to the full-install some kind. Yes, we will have a mechanism to pass stuff between the two debconf's. Probably just pass in the entire database we generated in the installer. This is already done to a very limited degree in the current boot-floppies, BTW. > > Each item in the
Re: redesigning the debian installer
On Thu, Sep 14, 2000 at 10:08:07AM -0400, Adam Di Carlo wrote: > Ben Collins <[EMAIL PROTECTED]> writes: > > > On Wed, Sep 13, 2000 at 08:15:51PM -0700, Joey Hess wrote: > > > Adam Di Carlo wrote: > > > > That's true, but a more generalized point is that more and more > > > > hardware (sparc, ultrasparc, powerpc, dunno about the rest) support > > > > openfirmware or openboot, and it's possible to traverse the > > > > openfirmware device tree with pretty damn good results. > > > > > > I don't think libdetect knows anything about openfirmware. Do you know > > > of any hw detection code that does? > > > > Nope, but it would be nice to see such code. On the downside, most > > non-standard hardware supported by UltraSPARC Linux, doesn't have, nor > > need OpenPROM. If only Sun didn't require license/money/other crap for > > vendors to support their PROM :/ > > Sure, although any bootable device by definition will support it. > > Sparcs and powerpc also have PCI support for the most part -- maybe > the focus should be just on PCI support. Then we could look at SBUS > on older sparcs as a sideline? Concentratin on PCI is the goal, IMO. SBUS device detection is overkill. -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: redesigning the debian installer
Ben Collins <[EMAIL PROTECTED]> writes: > On Wed, Sep 13, 2000 at 08:15:51PM -0700, Joey Hess wrote: > > Adam Di Carlo wrote: > > > That's true, but a more generalized point is that more and more > > > hardware (sparc, ultrasparc, powerpc, dunno about the rest) support > > > openfirmware or openboot, and it's possible to traverse the > > > openfirmware device tree with pretty damn good results. > > > > I don't think libdetect knows anything about openfirmware. Do you know > > of any hw detection code that does? > > Nope, but it would be nice to see such code. On the downside, most > non-standard hardware supported by UltraSPARC Linux, doesn't have, nor > need OpenPROM. If only Sun didn't require license/money/other crap for > vendors to support their PROM :/ Sure, although any bootable device by definition will support it. Sparcs and powerpc also have PCI support for the most part -- maybe the focus should be just on PCI support. Then we could look at SBUS on older sparcs as a sideline? -- .Adam Di [EMAIL PROTECTED]http://www.onShore.com/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: redesigning the debian installer
> > > On Thu, 14 Sep 2000, Massimo Dal Zotto wrote: > > > Ideally the auto-installation should be completely non-interactive but it > > may ask the installation profile name and some vital information not > > supplied in the profile. > > Completely non-interactive is an point. > > > 2) on each target machine: > > > > boot the installer > > select the auto-installation option > > But please: Also some possibility, that you do not have to enter something > there at all. (I do not have something against an option there, that you > can switch von non-automated to automated, but please do not forget an > fully automated) > > I want to be a able to sit on my server, ssh to an client, say: > bootp (or whatver) this image of the base-installer you get from server A > (perhaps even install.debian.org :-) using the database on server B, > whithout needing to leave my seat and walk to the client! > > > A second option would be starting it from the boot prompt: > > boot: auto-install PROFILE=workstation HOSTNAME=debian01 > > > > and in this case the initial menu should be skipped. > > Yes, like this way. But without the need of an bootprompt > (But I think the env-variables could also be entered > with some remote-booting tool, perhaps an remote-loadlin would be cool) > I have not explained clearly. I have nothing against the fully automatic approach you are suggesting. I like it. What I'm saying is only that the auto-installation should also be one of the choices of the initial menu. But any other way of starting it is ok. The boot-prompt option given as example could be easily made the default boot in a syslinux config, so you have only to insert the disk and start the boot. But if you want for example to install many similar machine from a cdrom how can you specify which machine (hostname, ip, etc.) you are installing without any prompting? Either you create N different bootfloppies or you must be prompted for a profile or machine name before starting the auto- installation. In my opinion this the one of the most common usage of the auto-intallation feature. The network boot you are suggesting is ok but not always applicable, so we must have also a manual startup of the auto- installation. -- Massimo Dal Zotto +--+ | Massimo Dal Zotto email: [EMAIL PROTECTED] | | Via Marconi, 141phone: ++39-0461534251 | | 38057 Pergine Valsugana (TN) www: http://www.cs.unitn.it/~dz/ | | Italy pgp: see my www home page | +--+ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: redesigning the debian installer
On Thu, 14 Sep 2000, Massimo Dal Zotto wrote: > Ideally the auto-installation should be completely non-interactive but it > may ask the installation profile name and some vital information not > supplied in the profile. Completely non-interactive is an point. > 2) on each target machine: > > boot the installer > select the auto-installation option But please: Also some possibility, that you do not have to enter something there at all. (I do not have something against an option there, that you can switch von non-automated to automated, but please do not forget an fully automated) I want to be a able to sit on my server, ssh to an client, say: bootp (or whatver) this image of the base-installer you get from server A (perhaps even install.debian.org :-) using the database on server B, whithout needing to leave my seat and walk to the client! > A second option would be starting it from the boot prompt: > boot: auto-install PROFILE=workstation HOSTNAME=debian01 > > and in this case the initial menu should be skipped. Yes, like this way. But without the need of an bootprompt (But I think the env-variables could also be entered with some remote-booting tool, perhaps an remote-loadlin would be cool) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: redesigning the debian installer
> Massimo Dal Zotto wrote: > > In my slink automatic installer I used snarf to do network installation > > from http and ftp. It is quite small and works very well. > > I also wrote a cp-like command which can copy files and directories from > > a real filesystem path or a remote url. Very handy for install scripts > > since you don't have to know from what type of media you are installing. > > I recommend this approach. > > I think it's more or less identical to the retreiver approach. > > > I would also suggest that all installer features could be called also as > > unix commands, i.e. no internal commands which can be use only from the C > > code. > > The only things I think we might want to use libraries for are installer > UI's and hardware detection code. This ok, provided that the internal primitives can be used also from the unix prompt. -- Massimo Dal Zotto +--+ | Massimo Dal Zotto email: [EMAIL PROTECTED] | | Via Marconi, 141phone: ++39-0461534251 | | 38057 Pergine Valsugana (TN) www: http://www.cs.unitn.it/~dz/ | | Italy pgp: see my www home page | +--+ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: redesigning the debian installer
> Massimo Dal Zotto wrote: > > I suggest that the installer configuration and installation are done > > in separate and independent steps so that one can configure one or > > more installation profiles, store them on a floppy or remote server > > and then run automatic installations without any further prompting. > > I would like to have an initial menu with three options: > > > > 1. configuration > > 2. installation > > 3. auto-installation > > You're essentially suggesting that we don't use debconf. > > Ok, I'm open to that suggestion. What does this method give us that > using a debconfish scheme does not? No, using debconf is ok. I don't see any other way to do it. I am only suggesting that it should be possible to do the debconf configuration in a separate step from the installation and store the debconf db for each machine on a floppy for later use. I also suggest that we can merge more debconf databases during the installation step, for example a default profile with very general configurations, a class profile (home, workstation, server, firewall) and a host specific profile (hostname, ipaddr, keyboard, mouse, monitor). In a typical mass installation scenario the administrator creates all these profiles on his previously installed workstation, copies them on a floppy and then installs each machine loading its profile from the floppy. Therefore the configurator should be installable and usable also on an installed debian system. This has the advantage that one can for example create many similar profiles semi-automatically from a template and, more importantly, reinstall a machine by simply recalling its original profile. One important thing is also the possibility to store in the profile a list of tasks and packages to install. This is essential in case we want to install systems of different classes and with different hardware or package selections. > (By way of comparison, if you use debconf, you don't really have a menu > of choices like this. Either debconf has been pre-seeded with the > answers to questions, or it prompts you for answers. Either way, it > remembers the answers, which can be used to pre-seed a later automated > install.) No, debconf is flexible enough to be forced to ask the question or skip it completely if some boot option has been supplied instead. It is the installer which must store the proper answer into the debconf db if the unattended installation has been selected at the boot prompt. Then debconf will find a user-selected autoinstall option in the db and start the installation skipping the initial menu. > > I would like also to have the possibility to store installation > > profiles as debconf databases on a floppy or another locations, > > and to be able to provide a set of configuration files created in > > advance for each machine, for example hosts, groups, exports, etc. > > and not to be prompted when the required information can be found > > in those files. > > That's what debconf is all about, really. Yes, but can we do this with the new bootfloppies? I'm not speaking about debconf here, but about the installation system which uses debconf. Can we save and load different pre-stored profiles? This is more or less what I've done in my hackish slink auto-installer. It doesn't use debconf and doesn't have a configuration interface but I can create profiles with a text-editor and load them for the installation. It has been used by people knowing only ms-windows to install a lot of machines in production environments. It is not perfect but this the way people needs it. -- Massimo Dal Zotto +--+ | Massimo Dal Zotto email: [EMAIL PROTECTED] | | Via Marconi, 141phone: ++39-0461534251 | | 38057 Pergine Valsugana (TN) www: http://www.cs.unitn.it/~dz/ | | Italy pgp: see my www home page | +--+ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: redesigning the debian installer
On Thu, Sep 14, 2000 at 09:33:10AM +0200, Massimo Dal Zotto wrote: > The auto-installation could be started automatically with the proper boot > option but from the user point of view I prefer that he has the possibility > to start it from the initial menu. This is also much safer than running it > automatically from the boot disk and possibly erasing by mistake a previous > installation. You won't get any arguments from me re: flexibility. I just want to make sure that complete non-interactivity is an option, not necessarily at the expense of other options. -- Michael S. Fischer <[EMAIL PROTECTED]>, AKA Otterley Lead Hacketeer, Dynamine Consulting, Silicon Valley, CA Phone: +1 650 533 4684 | AIM: IsThisOtterley | ICQ: 4218323 PGP key fingerprint: 53BD 4179 C3C6 DF0F A8D6 10E6 E1D9 7091 D330 F08D "From the bricks of shame is built the hope"--Alan Wilder -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: redesigning the debian installer
> On Wed, Sep 13, 2000 at 09:07:09PM +0200, Massimo Dal Zotto wrote: > > > I would like to have an initial menu with three options: > > > > 1. configuration > > 2. installation > > 3. auto-installation > > I suggest for an unattended installation that (3) not necessarily be > menu-driven, because we need to have complete non-interactivity from > power-on to production mode. It makes little sense to have one > required keypress when you can get away with having none. Ideally the auto-installation should be completely non-interactive but it may ask the installation profile name and some vital information not supplied in the profile. The auto-installation could be started automatically with the proper boot option but from the user point of view I prefer that he has the possibility to start it from the initial menu. This is also much safer than running it automatically from the boot disk and possibly erasing by mistake a previous installation. In my opinion a typical usage could be: 1) configure the profiles for various machines, possibly on an installed system 2) on each target machine: boot the installer select the auto-installation option choose a stored profile and start the installation A second option would be starting it from the boot prompt: boot: auto-install PROFILE=workstation HOSTNAME=debian01 and in this case the initial menu should be skipped. Having both options is certainly better than having only one. -- Massimo Dal Zotto +--+ | Massimo Dal Zotto email: [EMAIL PROTECTED] | | Via Marconi, 141phone: ++39-0461534251 | | 38057 Pergine Valsugana (TN) www: http://www.cs.unitn.it/~dz/ | | Italy pgp: see my www home page | +--+ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: kernel modules (Re: redesigning the debian installer)
Glenn McGrath wrote: > I will have to and lookup what PITA means, but i assume it means > difficult. (apt-get install dict-vera; Pain In the Ass) > hmm, it could get complex, installer modules depending on the used > kernel, i think this makes it more important that the end user has some > tools to customise there installer. You just have a lot of modules that correspone to one debian-installer + kernel build, and the installer only uses the modules from that directory. Not a whole lot different from the way the multiple driver disks, pcmcia modules, etc are handled in the boot floppies today, from an organizational standpoint. -- see shy jo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: kernel modules (Re: redesigning the debian installer)
Joey Hess wrote: > > Note that I'm not opposed to websites or whatever that autobuild install > media in the least. > > Glenn McGrath wrote: > > Also the user building there own customised installer would logically > > only include modules that apply to them, eg. they wouldnt include an NFS > > modules if they dont intend to install from or too NFS, same with > > detecting different types of hardware e.g. ISA, CDROM etc. > > My ideas on this are rather different, but are not refined yet. What I'm > thinking about doing is making each debian-installer module include the > kernel modules it needs (or depend on some other module that has them, > of course). > > This means that if you are not doing a NFS install, you can just drop > off the nfs debian-installer module from your install media. Same for a > *lot* of other modules. > This makes sense > > I think enabling heavy end-user customisation is the best chance we have > > of buildign a 1 disk installer. I think it would be very challenging to > > build a 1 disk installer for the masses if your kernel is 1MB leaving > > 400KB left to work with, 400KB would get most of busybox in, but not > > much else. > > But see, your kernel will be more like 300kb. It will include no drivers > except enough to get the debian installer up and to get up on the > network. > > All other kernel drivers and installer modules will be downloaded (hard > disk drivers, filesystems, etc), and from that point, space metters much > less. > > This is why I'm holding out some hope for a single floppy install, > without excessive user customization aside from specifying that they > want to use the single floppy to install from the network. > > The main issues this raises is that it makes kernel compilations for the > installer a PITA (because you have to shove the kernel modules into a > buch of different installer modules), and that it means we need an initrd > to boot up the debian system once it is installed (because the kernel > may not even have a disk driver or ext2 filesystem in it). > I will have to and lookup what PITA means, but i assume it means difficult. hmm, it could get complex, installer modules depending on the used kernel, i think this makes it more important that the end user has some tools to customise there installer. I think this tool will have to a) specify what modules will be included with the installer (others can be fetched) b) build the installer modules that will be on the disk (from a module base and kernel dependencies?) c) Allow the user to pre-define default values for any modules. Maybe the installer modules themselves could be virtual packages, and the kernel modules they require could be extracted from a deb. This would require lots of work on the kernel though. Im a bit out of my depth on the best way to do this. Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: redesigning the debian installer
On Wed, Sep 13, 2000 at 08:15:51PM -0700, Joey Hess wrote: > Adam Di Carlo wrote: > > That's true, but a more generalized point is that more and more > > hardware (sparc, ultrasparc, powerpc, dunno about the rest) support > > openfirmware or openboot, and it's possible to traverse the > > openfirmware device tree with pretty damn good results. > > I don't think libdetect knows anything about openfirmware. Do you know > of any hw detection code that does? Nope, but it would be nice to see such code. On the downside, most non-standard hardware supported by UltraSPARC Linux, doesn't have, nor need OpenPROM. If only Sun didn't require license/money/other crap for vendors to support their PROM :/ -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: redesigning the debian installer
On Wed, Sep 13, 2000 at 08:15:51PM -0700, Joey Hess wrote: > Adam Di Carlo wrote: > > That's true, but a more generalized point is that more and more > > hardware (sparc, ultrasparc, powerpc, dunno about the rest) support > > openfirmware or openboot, and it's possible to traverse the > > openfirmware device tree with pretty damn good results. > > I don't think libdetect knows anything about openfirmware. Do you know > of any hw detection code that does? To the best of my knowledge, there isn't any except what is in the kernel. However, the kernel's is pretty sufficient... I'm all for using devfs for a lot of this, assuming 2.4 stabilizes in time, which I would hope it would. Of course, that doesn't help for figuring out which modules to load. Dan /\ /\ | Daniel Jacobowitz|__|SCS Class of 2002 | | Debian GNU/Linux Developer__Carnegie Mellon University | | [EMAIL PROTECTED] | | [EMAIL PROTECTED] | \/ \/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: redesigning the debian installer
Massimo Dal Zotto wrote: > In my slink automatic installer I used snarf to do network installation > from http and ftp. It is quite small and works very well. > I also wrote a cp-like command which can copy files and directories from > a real filesystem path or a remote url. Very handy for install scripts > since you don't have to know from what type of media you are installing. > I recommend this approach. I think it's more or less identical to the retreiver approach. > I would also suggest that all installer features could be called also as > unix commands, i.e. no internal commands which can be use only from the C > code. The only things I think we might want to use libraries for are installer UI's and hardware detection code. -- see shy jo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: redesigning the debian installer
Massimo Dal Zotto wrote: > I suggest that the installer configuration and installation are done > in separate and independent steps so that one can configure one or > more installation profiles, store them on a floppy or remote server > and then run automatic installations without any further prompting. > I would like to have an initial menu with three options: > > 1. configuration > 2. installation > 3. auto-installation You're essentially suggesting that we don't use debconf. Ok, I'm open to that suggestion. What does this method give us that using a debconfish scheme does not? (By way of comparison, if you use debconf, you don't really have a menu of choices like this. Either debconf has been pre-seeded with the answers to questions, or it prompts you for answers. Either way, it remembers the answers, which can be used to pre-seed a later automated install.) > I would like also to have the possibility to store installation > profiles as debconf databases on a floppy or another locations, > and to be able to provide a set of configuration files created in > advance for each machine, for example hosts, groups, exports, etc. > and not to be prompted when the required information can be found > in those files. That's what debconf is all about, really. -- see shy jo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: redesigning the debian installer
Adam Di Carlo wrote: > That's true, but a more generalized point is that more and more > hardware (sparc, ultrasparc, powerpc, dunno about the rest) support > openfirmware or openboot, and it's possible to traverse the > openfirmware device tree with pretty damn good results. I don't think libdetect knows anything about openfirmware. Do you know of any hw detection code that does? > This is relevant to a number of what I consider pretty major > weaknesses in the Potato installation system, such as detection of > whether we want an SMP kernel, proper configuration of mouse devices > on powerpc/sparc, proper detection of CD-ROM for the purposes of > generating the /dev/cdrom link, etc. -- see shy jo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: redesigning the debian installer
Bernhard R. Link wrote (about debconf): > As I see, there is no need for compatibility with the other protocolls, > as they seem to be perlish-call-an-method protocolls. Those arn't protocols. Debconf is object oriented perl code, and you're seeing objects use other objects. But all such stuff is entirely specific to my implementation of debconf and can easily be ignored by clones. > (Which would also be > something for some in-the-long-run replacement for debconf: When database, > ui and so on could be perl,c,shell-script or what ever one wants to have). Randolph Chung has actually written a debconf "passthrough" frontend that allows other programs to serve as debconf frontends and communicate with it via a pipe. And yes, the database does need to be split out somehow. -- see shy jo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: redesigning the debian installer
Massimo Dal Zotto wrote: > I would like also to remember a small utility, read-edid, which can be > used by the X configurator to retrieve the monitor model and frequencies > from the monitor itself. It can be found at http://www.altern.org/vii/ > If we know the pci id of the card, the monitor frequencies and leave the > mouse configuration to gpm we can configure X almost automatically. You should mention this to Randolph Chung for anXious. -- see shy jo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
kernel modules (Re: redesigning the debian installer)
Note that I'm not opposed to websites or whatever that autobuild install media in the least. Glenn McGrath wrote: > Also the user building there own customised installer would logically > only include modules that apply to them, eg. they wouldnt include an NFS > modules if they dont intend to install from or too NFS, same with > detecting different types of hardware e.g. ISA, CDROM etc. My ideas on this are rather different, but are not refined yet. What I'm thinking about doing is making each debian-installer module include the kernel modules it needs (or depend on some other module that has them, of course). This means that if you are not doing a NFS install, you can just drop off the nfs debian-installer module from your install media. Same for a *lot* of other modules. > I think enabling heavy end-user customisation is the best chance we have > of buildign a 1 disk installer. I think it would be very challenging to > build a 1 disk installer for the masses if your kernel is 1MB leaving > 400KB left to work with, 400KB would get most of busybox in, but not > much else. But see, your kernel will be more like 300kb. It will include no drivers except enough to get the debian installer up and to get up on the network. All other kernel drivers and installer modules will be downloaded (hard disk drivers, filesystems, etc), and from that point, space metters much less. This is why I'm holding out some hope for a single floppy install, without excessive user customization aside from specifying that they want to use the single floppy to install from the network. The main issues this raises is that it makes kernel compilations for the installer a PITA (because you have to shove the kernel modules into a buch of different installer modules), and that it means we need an initrd to boot up the debian system once it is installed (because the kernel may not even have a disk driver or ext2 filesystem in it). -- see shy jo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: redesigning the debian installer
Adam Di Carlo wrote: > Some generalized comments and musings. > > Modularization is specified for retrievers but I fail to see how that > is going to address, say, installation over the network for i386 boxes > (providing perhaps modules for NIC cards) or installation via pcmcia > on arches that support that (which should be i386, alpha, and sparc, I > think, dunno really about sparc/powerpc). I never said this was a complete design yet. You're right, these are all gaping holes: > I believe there must be a module subsystem defined for not just > retrieval issues, but also: > > - network/hardware support (discussed above) > > - network configuration (dhcp/bootp) > > - target media support (what we're installing to -- this means >PCMCIA/IDE devices, NFSRoot, RAID boot/root, etc.) (And in my TODO list now.) The reason I specced out retreivers first is that they are a pretty simple, and yet essential part of the design, and they are one of the few classes of modules that need to present a standard command-line interface. The way network hardware support, network configuration, and target media support all work, in general, is: - A module's maintainer decides it needs one of these things (a configured network, say). - They make the module depend on an appropriate virtual package (configured-network). - Before the module is used, the system makes sure its dependencies are met, and that the modules that satisfy those dependencies are configured (so the network is configured, but first hardware support for it is set up). (I need to change how the main menu works a little bit, come to think of it. More on this soon.) My point is that these various classes of modules don't need to be specified in much detail. I don't care how a network configuration module works, or what programs it installs where, as long as once it is set up, there is a configured network. Of course, that's just in general -- we do need to think about each of these classes of modules and find the little details that need to be specified. > I think you need to specify a TFTP retriever, but not really sure. > The network retrievers should be centered around the "best of breed" > tiny net clients, such as snarf or busybox's wget. Implementation details IMHO. > Hardware detection should be *designed* for modern hardware, perhaps > having also support for older stuff. I'm saying you should be > targetting PCI busses or OpenFirmware where supported. You'll get > better milage that way. I'm not saying rule out ISA or other legacy > support necessarily, however -- just that it should be a sideline. I agree. > Also, I reiterate that we need to liase with the larger linux/GNU > community regarding either the adoption or enlargement of current > hardware detection subsystems (i.e., libdetect if that's what we use). Clearly. Interestingly, libdetect is used by mandrake, and also includes code from redhat (not sure if redhat uses it directly). I still want to look at other similar libraries, but I think that having several distributions use the same hardware detection code is a good thing. I wish we could share more, it's really silly we all go off and write our own installers. Um. Er. > I think more needs to be specified regarding automated installation, > which is a big issue as discussion here has shown. I guess that would > be in the context of the debconf-tiny ? I suggest the retrievers > could be purposed to retrieve also configuration files, perhaps > specified in RFC 822 or XML format. Right that's doable easily (trivial to map debconf db to 822-format) and will work fine. Or there is this mythical debconf remote database stuff that maybe one day someone will actually write. -- see shy jo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: redesigning the debian installer
Ben Collins wrote: > Still, though. After the main install is done, and the reboot complete, > setting up the rest of the autodetection should be done in base-config, > even if it simply calls dpkg-reconfigure or something. Let's plan for this > from the installer, even if it isn't done till after install. Detecting > hardware (all kinds, if possible) is part of the install process after > all. I have no problem with this. If you want to do it, all that is needed is a regular debian package that uses debconf and does whatever hardware detection is appropriate. Then we just arrange for it to be dpkg-reconfigure'd on initial boot. (I hope to split base-config up and more or less do away with it, so pam is responsible for setting up shadow and md5, pam or base-password or something is responsible for making sure root has a password, etc.) -- see shy jo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: redesigning the debian installer
"Michael S. Fischer" wrote: > > On Wed, Sep 13, 2000 at 04:09:09PM -0400, Adam Di Carlo wrote: > > > I believe there must be a module subsystem defined for not just > > retrieval issues, but also: > > > > - network/hardware support (discussed above) > > > > - network configuration (dhcp/bootp) > > > > - target media support (what we're installing to -- this means > >PCMCIA/IDE devices, NFSRoot, RAID boot/root, etc.) > > I think someone recently brought up the idea on debian-boot of having > an "installer builder," which seems like a wonderful idea. My idea > would be to have a Web-based builder script on the Debian Web site > (transportable, of course, to a local system if necessary) that would > provide maximum flexibility. With such a scheme, one could create and > download a boot disk (or set) that could contain the "kitchen sink", > or, alternatively, a very slim 1.44MB boot disk or PXE boot set that > could be used to perform a non-interactive installation with a known > set of (perhaps customized) packages on a known set of hardware. > > I'm drooling already, > I think the biggest reason to have an "installer builder" is to allow end users to simply use they own kernel rather than a generalised one, a customised kernel can be ~500KB, whereas a generalised kernel trying to make everyone happy will be aproaching 1M. If the user has there own kernel-.deb built with make-kpkg then it could be possible to do this painlessly. Also the user building there own customised installer would logically only include modules that apply to them, eg. they wouldnt include an NFS modules if they dont intend to install from or too NFS, same with detecting different types of hardware e.g. ISA, CDROM etc. I think enabling heavy end-user customisation is the best chance we have of buildign a 1 disk installer. I think it would be very challenging to build a 1 disk installer for the masses if your kernel is 1MB leaving 400KB left to work with, 400KB would get most of busybox in, but not much else. Perhaps customising the installer could be a solution for a "hands-free" or "non-interactive" install as well. 1. Build Customise Installer [OPTIONAL] a. allow user to define what kernel and kenrel modules to use. b. allow user to define what installer modules they require (at least one) from each of the modules sub-layers fetch method, hardware detection, target mdeia. c. pre-configure the install method verbosness and defualt UI (i.e. dpkg-reconfigure debconf). d. set the default value for any question 2. Run installer. Step 1 has been done by someone else, this closely resembles a regular install method. If someone wants a non-interactive install they can start at step 1 and preconfigure it to default values (or methods) that are correct for their situation, and then set it to non-interactive at this stage. Step 1 is akin to building different flavours for an architecture, i.e. i386 has udma, scsi, ide, compact flavours, the install team could just prepare one version for each architecture and give the user greater ability to build there own flavour. But then we can also setup methods that autobuild customised installers through web pages or other programs. Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: redesigning the debian installer
On Wed, Sep 13, 2000 at 04:09:09PM -0400, Adam Di Carlo wrote: > > Some generalized comments and musings. > > Modularization is specified for retrievers but I fail to see how that > is going to address, say, installation over the network for i386 boxes > (providing perhaps modules for NIC cards) or installation via pcmcia > on arches that support that (which should be i386, alpha, and sparc, I > think, dunno really about sparc/powerpc). PowerPC's one of them. In fact, PowerPC PCMCIA install works right now, I think... Dan /\ /\ | Daniel Jacobowitz|__|SCS Class of 2002 | | Debian GNU/Linux Developer__Carnegie Mellon University | | [EMAIL PROTECTED] | | [EMAIL PROTECTED] | \/ \/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: redesigning the debian installer
On Wed, Sep 13, 2000 at 04:09:09PM -0400, Adam Di Carlo wrote: > I believe there must be a module subsystem defined for not just > retrieval issues, but also: > > - network/hardware support (discussed above) > > - network configuration (dhcp/bootp) > > - target media support (what we're installing to -- this means >PCMCIA/IDE devices, NFSRoot, RAID boot/root, etc.) I think someone recently brought up the idea on debian-boot of having an "installer builder," which seems like a wonderful idea. My idea would be to have a Web-based builder script on the Debian Web site (transportable, of course, to a local system if necessary) that would provide maximum flexibility. With such a scheme, one could create and download a boot disk (or set) that could contain the "kitchen sink", or, alternatively, a very slim 1.44MB boot disk or PXE boot set that could be used to perform a non-interactive installation with a known set of (perhaps customized) packages on a known set of hardware. I'm drooling already, -- Michael S. Fischer <[EMAIL PROTECTED]>, AKA Otterley Lead Hacketeer, Dynamine Consulting, Silicon Valley, CA Phone: +1 650 533 4684 | AIM: IsThisOtterley | ICQ: 4218323 PGP key fingerprint: 53BD 4179 C3C6 DF0F A8D6 10E6 E1D9 7091 D330 F08D "From the bricks of shame is built the hope"--Alan Wilder -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: redesigning the debian installer
On Wed, Sep 13, 2000 at 09:07:09PM +0200, Massimo Dal Zotto wrote: > I would like to have an initial menu with three options: > > 1. configuration > 2. installation > 3. auto-installation I suggest for an unattended installation that (3) not necessarily be menu-driven, because we need to have complete non-interactivity from power-on to production mode. It makes little sense to have one required keypress when you can get away with having none. -- Michael S. Fischer <[EMAIL PROTECTED]>, AKA Otterley Lead Hacketeer, Dynamine Consulting, Silicon Valley, CA Phone: +1 650 533 4684 | AIM: IsThisOtterley | ICQ: 4218323 PGP key fingerprint: 53BD 4179 C3C6 DF0F A8D6 10E6 E1D9 7091 D330 F08D "From the bricks of shame is built the hope"--Alan Wilder -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
