redesigning the debian installer
I think I said I'd have this design draft done 3 weeks ago. Real life intervened, and the rest of this month is going to be even worse. So I'm going to post this rough draft of the design now, with the caveat that it needs a lot of work. Please help me make it better. Note that all documents are available in debian-installer cvs in the doc directory. (cvs -d:pserver:[EMAIL PROTECTED]:/cvs/debian-boot co debian-installer) I've included the more important ones in this message. I'll start with the simple stuff and build up... Modules --- The new debian installer is highly modular. Modules are loaded at several points in the install process to add capabilities to the installer. Modules are essentially sets of files that get unpacked onto the installation system, plus some metadata. Because there is already so much infrastructure to build and manage debian packages, and because it allows metadata to accompany the files in a module, we have decided to use debian packages as the modules for the installer. Unlike regular debian packages, modules for the installer will not be policy compliant. They will not contain documentation in /usr/share/doc. They need not comply with the FHS. They may be statically linked. They may conflict with essential "real" debian packages, and thus be non-installable on a real debian system, although it is recommended that if possible, this be avoided. [ Detail where the modules will go in the debian archive, and any way they can be distinguised from "real" debs. ] Modules will not be installed by a full-fledged dpkg implementation, so the following features of regular debs will not be supported: [ This is not set in stone, but let's not implement this stuff unless we need it. ] - pre-dependancies - preinst, postrm and prerm - conflicts - versioned dependancies - provides - essential or required packages - suggests - recommends - `|' in dependancies. The following will be supported: - simple dependancies - postinst - debconf Retrievers -- Retrievers are modules that can download or otherwise retrieve files[1], including other modules and Packages files. It is expected that at least the following types will eventually be implemented: - cd retriever Ensures an install cd is mounted, and finds files on it. No real retrieving done. - floppy retriever May or may not need to deal with files split across multiple floppies. In any case, pulls files off floppies. - hard disk retriever Gets a file from a local hard disk (dos, linux, etc). - http retriever Downloads a file from a remote http mirror. - ftp retriever (needed?) Downloads a file from a remote ftp mirror. - nfs retriever Gets a file via nfs. A retriever must be able to do the following: - Set itself up so it can access the cdrom, mirror, or whatever. - Get a list of the modules that are available. This will be done by retrieving a standard Packages file. - Retrieve a file. A separate module will take care of parsing the Packages files, and checking md5sums of downloaded modules, and a separate program (udpkg) will handle actually installing modules. Since retrievers are debian packages, they can have a postinst that is run to set them up. During setup, they may need to prompt the user for information (using debconf). For example, a nfs retriever will probably need to prompt the user for a nfs server name. [ I'm not sure that doing such setup in the postinst is a good idea. ] Retrievers may also need to depend on additional modules. For example the http/ftp/nfs retrievers will need to depend on a module to set up networking, while the cdrom retriever may need to depend on module(s) that include kernel modules for the iso9660 filesystem and cd drivers. Retrievers may also need to interact with the user when they are retrieving a file. For example, the floppy retriever will need to prompt for disks. This interaction will also be accomplished via debconf. Retriever interface --- All retrievers should support the following interface. [ This interface is preliminary and depends on the filesystem layout and ramdisk allocation scheme used by the installer, and so the location may change. ] /usr/lib/debian-installer/retriever/ is a executable. It is run with the following parameters: filename dest-directory Download the specified file to the specified destination directory[2]. The filename is the Filename field of a Packages file. Thus, retrieving the Packages file itself is something like this: program Packages /tmp/ While retrieving a deb is something like this: program retrievers/http-retriever.deb /tmp/ If the destination file already exists, the retriever may want to attempt to continue a download. Note that the destination file may also be a fif
Re: redesigning the debian installer
Hi, > Modules > --- > Retrievers > -- > The Installer UI > > The user's view > --- > > 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. Which UI: Text, fb, X11 or all selectable ? "It might also include language selection" ?? Not might, it is a must. > > Implementation > -- > > - Configure installation media > - Reboot the system We will avoid system reboot. Another important point is an hardware detection database. We might also include samba, beowulf/cluster, mass-install, ... MfG, Hartmut -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: redesigning the debian installer
(Dan, search for 'detect' to see why I cd'd you.) Hartmut Koptein wrote: > > 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. > > Which UI: Text, fb, X11 or all selectable ? Whatever UI is being used. (Not sure I understand the question.) > "It might also include language selection" ?? Not might, it is a must. I meant that it may or may not make sense to do this as part of UI configuration. It may turn out that it makes sense to do it as a seperate step if the code can be shared amoung all UI's. > > - Reboot the system > > We will avoid system reboot. We may provide an _option_ to skip the system reboot. To be used if you don't care if, 4 weeks down the road, after tweaking, installing, and fine-tuning your new debian system, you reboot it and discover that LILO was not properly set up, and it won't boot. And then try to remember where that rescue floppy/install media were filed a month ago.. Caldera skips the reboot. I have had this problem when I was doing installs to get a look at caldera's installer. No thanks. Anyway, the "reboot the system" menu item is just provided by another module. If someone wants to make a "start up debian w/o rebooting" menu item, they just need to make a module that does the work. Either or both modules can then be included on a given install media. > Another important point is an hardware detection database. This is left up to the modules that provide support for the various hardware. We need to pick a good hardware detection library for those modules to use, that's for sure. There are several. libdetect0 is already in Debian (but it's 155k! Urk!). We really need a hardware detection library that is modularized or can be modularized. There is no need to have code in the installer to detect your sound card. And if you're installing from a floppy and the network, you need NIC detection code, but code to detect a CD drive is unnecessary bloat. Also, we have to keep in mind that hardware detection is a two-edged sword. It's great until it probes somewhere it shouldn't and crashes your system. Strictly passive hardware detectors avoid this of course, but they detect less hardware too (no ISA cards, probably). Would some interested people like to get together and do some thurough research of the available hardware detection software, and present a report w/reccomendation to this list? Speak up if you're interested. > We might also include samba, beowulf/cluster, mass-install, ... Yes, there could be a SMB retreiver if someone wants to write it. beofulf/cluster? Arn't those post-install configuration options? This design is geared from the beginning to support mass installs. That's a big part of the reason it uses a debconf clone, so you can install once and get an install script for future installs. -- see shy jo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: redesigning the debian installer
Joey Hess wrote: > > Retrievers > -- > > Retrievers are modules that can download or otherwise retrieve > files[1], including other modules and Packages files. It is expected that at > least the following types will eventually be implemented: > > - cd retriever > Ensures an install cd is mounted, and finds files on it. No real > retrieving done. > - floppy retriever > May or may not need to deal with files split across multiple > floppies. In any case, pulls files off floppies. > - hard disk retriever > Gets a file from a local hard disk (dos, linux, etc). > - http retriever > Downloads a file from a remote http mirror. > - ftp retriever (needed?) > Downloads a file from a remote ftp mirror. > - nfs retriever > Gets a file via nfs. > > A retriever must be able to do the following: > > - Set itself up so it can access the cdrom, mirror, or whatever. > - Get a list of the modules that are available. This will be done by > retrieving a standard Packages file. > - Retrieve a file. > > A separate module will take care of parsing the Packages files, and > checking md5sums of downloaded modules, and a separate program > (udpkg) will handle actually installing modules. > > Since retrievers are debian packages, they can have a postinst that is > run to set them up. During setup, they may need to prompt the user for > information (using debconf). For example, a nfs retriever will probably > need to prompt the user for a nfs server name. [ I'm not sure that doing > such setup in the postinst is a good idea. ] > > Retrievers may also need to depend on additional modules. For example the > http/ftp/nfs retrievers will need to depend on a module to set up networking, > while the cdrom retriever may need to depend on module(s) that include kernel > modules for the iso9660 filesystem and cd drivers. > > Retrievers may also need to interact with the user when they are retrieving > a file. For example, the floppy retriever will need to prompt for disks. > This interaction will also be accomplished via debconf. > > Retriever interface > --- > > All retrievers should support the following interface. > > [ This interface is preliminary and depends on the filesystem layout and > ramdisk allocation scheme used by the installer, and so the location may > change. ] > > /usr/lib/debian-installer/retriever/ is a executable. It > is run with the following parameters: > > filename dest-directory > Download the specified file to the specified destination > directory[2]. The filename is the Filename field of a Packages > file. > > Thus, retrieving the Packages file itself is something like this: > program Packages /tmp/ > > While retrieving a deb is something like this: > program retrievers/http-retriever.deb /tmp/ > > If the destination file already exists, the retriever may want to attempt > to continue a download. Note that the destination file may also be a fifo > or a named pipe. > > Once ran, retrievers are free to prompt the user, or do whatever else is > necessary to retrieve the file. > > Note that this simple interface requires that retrievers know the location > of the base directory of the archive. This will not be a problem for many > -- the cdrom retriever simply uses whatever is available, in a hard-coded > location. Other retrievers may require more configuration. For example, the > http retriever will need to know what version of Debian is being installed, > what site to install from, and probably what version of the debian-installer > is being used as well. The user will likely have to be prompted for some of > this data during retriever setup. > > Footnotes > - > > [1] Conceptually, rather similar to apt's methods, although the interface > is a lot more simplistic and we don't need to support things like > pipelining multiple downloads. > [2] Some retrievers may want to show progress displays while downloading. > Support for this may need to be added to debconf, via a new data type. > It's rather hard to do in the context of debconf -- details to be > determined. > A week or so ago someone uploaded a busyboxed wget command, which is quite small, in the apt source i see occasional reference to wget, so this would probably be a good spot to start for http ftp retriever. btw i havent looked a mini debconf for a number of weeks now, im currently working in tighter integration between busybox ar, tar, gzip. It should enable files to be extracted from a deb one at a time which could give more control for excluding files, maybe im getting a bit carried away with it though Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: redesigning the debian installer
I rather wish I'd seen the beginning of this thread so I could gain some context. I'll see if I can find it at the archive so I can be better educated, but for now I'll try to offer my comments as is. I should introduce myself first. I am the operations team lead for AuctionWatch.com (the .signature is for my side project; I have interests in Debian besides those of my employer's, but they don't necessarily conflict). Currently we're using Red Hat Linux because of its kickstart installation process. I'm not terribly thrilled with Red Hat for many other reasons, but I am quite fond of Debian. However, with Red Hat I can install 100 search servers in under 15 minutes. Currently there is no easy way to accomplish the same feat with Debian; it is my intent to help offer advice and comments that hopefully will lead to an unattended installation process for the next release of Debian. On Tue, Sep 12, 2000 at 05:24:41PM -0700, Joey Hess wrote: > > Which UI: Text, fb, X11 or all selectable ? > > Whatever UI is being used. (Not sure I understand the question.) 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. > > "It might also include language selection" ?? Not might, it is a must. > > I meant that it may or may not make sense to do this as part of UI > configuration. It may turn out that it makes sense to do it as a > seperate step if the code can be shared amoung all UI's. This should be settable in the installation profile for an unattended installation. > > > - Reboot the system > > > > We will avoid system reboot. > > We may provide an _option_ to skip the system reboot. This sounds like a more reasonable option. In an unattended installation it's best to stick in a floppy, watch it read for 90 seconds, eject and go. The system should be capable of being rebooted immediately after installation into production mode (provided, of course, that the installation and configuration profile was correct). > > Another important point is an hardware detection database. > > This is left up to the modules that provide support for the various > hardware. We need to pick a good hardware detection library for those > modules to use, that's for sure. There are several. libdetect0 is > already in Debian (but it's 155k! Urk!). I think that hardware detection should be optional. In our case, we have hundreds of servers, all the same hardware, and we know pretty darned well what's in them and that's not going to change for awhile. In the case of mass installation it's probably better that it just be manually specified and not risk breakage due to a possibly incorrect detection mechanism. -- 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
> Joey Hess wrote: > > Since retrievers are debian packages, they can have a postinst that is > > run to set them up. > > During setup, they may need to prompt the user for > > information (using debconf). For example, a nfs retriever will probably > > need to prompt the user for a nfs server name. [ I'm not sure that doing > > such setup in the postinst is a good idea. ] I think it is vitally important that the postinst will be able to accept some sort of file in lieu of interactive input so that the package will be able to be configured non-interactively. DHCP can assist the installer with determining the location of such information. -- 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
> > We really need a hardware detection library that is modularized or can > be modularized. There is no need to have code in the installer to detect > your sound card. And if you're installing from a floppy and the network, > you need NIC detection code, but code to detect a CD drive is > unnecessary bloat. > > Also, we have to keep in mind that hardware detection is a two-edged > sword. It's great until it probes somewhere it shouldn't and crashes > your system. Strictly passive hardware detectors avoid this of course, > but they detect less hardware too (no ISA cards, probably). > > Would some interested people like to get together and do some thurough > research of the available hardware detection software, and present a > report w/reccomendation to this list? Speak up if you're interested. The good thing about PCI hardware detection is that there is no probing, and the PCI layer/driver handles allocation an IRQ and I/O. So basically the gist is, atleast include PCI detection, which maps PCI device ID's to modules, and can prompt for which ones to load. Ben -- ---===-=-==-=---==-=-- / 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 Tue, Sep 12, 2000 at 05:24:41PM -0700, Joey Hess wrote: > Hartmut Koptein wrote: > > Another important point is an hardware detection database. > > This is left up to the modules that provide support for the various > hardware. We need to pick a good hardware detection library for those > modules to use, that's for sure. There are several. libdetect0 is > already in Debian (but it's 155k! Urk!). > > We really need a hardware detection library that is modularized or can > be modularized. There is no need to have code in the installer to detect > your sound card. And if you're installing from a floppy and the network, > you need NIC detection code, but code to detect a CD drive is > unnecessary bloat. Libdetect is modular in terms of detecting different classes of hardware (CD drive, sound, ethernet, etc) via separate functions, so it can be stripped down for the boot disks quite easily. After just a few of minutes of commenting out detect calls, I was able to compile a libdetect library that's "only" 46k and includes support for detecting cdroms, ethernet, ide, scsi, isa, pci, usb, pcmcia, modems, and serial devices. The lib could be further stripped down if necessary. > Also, we have to keep in mind that hardware detection is a two-edged > sword. It's great until it probes somewhere it shouldn't and crashes > your system. Strictly passive hardware detectors avoid this of course, > but they detect less hardware too (no ISA cards, probably). Definitely. You might consider merely giving an option to use passive detection on ISA cards, and probing all cards by default. > Would some interested people like to get together and do some thurough > research of the available hardware detection software, and present a > report w/reccomendation to this list? Speak up if you're interested. I'm interested in this, as I'm fairly familiar with libdetect, having packaged it. Let me know who I need to talk to. -- Dan Helfman UCLA Linux Users Group: http://www.linux.ucla.edu My GnuPG key: http://torsion.org/witten/public-key.txt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: redesigning the debian installer
Michael S. Fischer wrote: > I rather wish I'd seen the beginning of this thread so I could gain > some context. I'll see if I can find it at the archive so I can be > better educated, but for now I'll try to offer my comments as is. The context you're missing is that we're going to rewrite debian's installer for the next release of debian. My initial manefesto for this can still be found here: http://cvs.debian.org/debian-installer/doc/design.txt?rev=1.1&content-type=text/vnd.viewcvs-markup Although several of the details have changed. > Currently we're using Red Hat Linux because of its kickstart > installation process. I'm not terribly thrilled with Red Hat for many > other reasons, but I am quite fond of Debian. However, with Red Hat I > can install 100 search servers in under 15 minutes. Currently there > is no easy way to accomplish the same feat with Debian; it is my > intent to help offer advice and comments that hopefully will lead to > an unattended installation process for the next release of Debian. Unattended installs are something I am interested in as well. They're an important part of the new design. > > Whatever UI is being used. (Not sure I understand the question.) > > 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. More generally, I expect that the new debian installer will need to support all the features and everything that the current installer supports. Of course the initial prototypes won't, but it will not be suitable as a replacement for the current installer until it does support everything. > I think that hardware detection should be optional. In our case, we > have hundreds of servers, all the same hardware, and we know pretty > darned well what's in them and that's not going to change for awhile. > In the case of mass installation it's probably better that it just be > manually specified and not risk breakage due to a possibly incorrect > detection mechanism. Unless someone knows of a case where PCI hardware detection can fail, I don't see a problem with doing it. But any invasive hardware detection is going to require a way to let the user choose to manually specify the hardware instead of having it detected (read on). > I think it is vitally important that the postinst will be able to > accept some sort of file in lieu of interactive input so that the > package will be able to be configured non-interactively. > > DHCP can assist the installer with determining the location of such > information. The plan for the new installer is the use debconf (or rather, a similar but smaller implementation of the same ptotocol) for all (or almost all) user interaction. The nice thing about debconf is that it reduces all user interaction to a series of questions. It keeps track of the answers to questions, and that data can be fed into a later install in various ways. When that's done, you effectively get a kickstart system for mass installations. Relating this back to hardware detection, for example, you do one install manually. If you elect not to do hardware detection and instead specify hardware, debconf remembers that and remembers each of your answers. Then when you're doing a mess install, those same answers are fed into 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
Ben Collins wrote: > The good thing about PCI hardware detection is that there is no probing, > and the PCI layer/driver handles allocation an IRQ and I/O. So basically > the gist is, atleast include PCI detection, which maps PCI device ID's to > modules, and can prompt for which ones to load. Right. We already do PCI hardware detection, after all, for video card setup with anXious. Maybe that's all the hardware detection we should bother with. Is there really any point in worrying about making life easier for owners of ISA hardware these days? -- 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: > > > Joey Hess wrote: > > > > Since retrievers are debian packages, they can have a postinst that is > > > run to set them up. > > > > During setup, they may need to prompt the user for > > > information (using debconf). For example, a nfs retriever will probably > > > need to prompt the user for a nfs server name. [ I'm not sure that doing > > > such setup in the postinst is a good idea. ] > > I think it is vitally important that the postinst will be able to > accept some sort of file in lieu of interactive input so that the > package will be able to be configured non-interactively. > > DHCP can assist the installer with determining the location of such > information. > Debconf should be able to solve problems for mass and non-interactive installs. debconf has an option for non-interactive installs by using the default value. if dhcp used debconf then network discoveries it makes could be shared with other packages. For mass installs if all machines are the same it should be possible to build a debconf database on one machine and share its values to all the other drone machines. Even though we dont have a small debconf it will have to be compatable with the existing debconf so issues such as setting up debconf scripts for dhcp clients or kernel modules could be done anytime. Sharing debconf databases isnt possible even with the proper debconf so i guess its a fair way off. 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 12:48:36PM +1100, Glenn McGrath wrote: > Debconf should be able to solve problems for mass and non-interactive > installs. > > debconf has an option for non-interactive installs by using the default > value. Could you please define "default value" for me? Is this a default value supplied by the .deb--which in many cases we'll want to override non-interactively? Or are you referring to some other "default value"? -- 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 Tue, Sep 12, 2000 at 06:46:44PM -0700, Joey Hess wrote: > Ben Collins wrote: > > The good thing about PCI hardware detection is that there is no probing, > > and the PCI layer/driver handles allocation an IRQ and I/O. So basically > > the gist is, atleast include PCI detection, which maps PCI device ID's to > > modules, and can prompt for which ones to load. > > Right. We already do PCI hardware detection, after all, for video card > setup with anXious. > > Maybe that's all the hardware detection we should bother with. Is there > really any point in worrying about making life easier for owners of ISA > hardware these days? IMO, we shouldn't. Trying to autodetect ISA is probably more harm than good anyway. -- ---===-=-==-=---==-=-- / 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
"Michael S. Fischer" wrote: > > On Wed, Sep 13, 2000 at 12:48:36PM +1100, Glenn McGrath wrote: > > > Debconf should be able to solve problems for mass and non-interactive > > installs. > > > > debconf has an option for non-interactive installs by using the default > > value. > > Could you please define "default value" for me? Is this a default > value supplied by the .deb--which in many cases we'll want to override > non-interactively? Or are you referring to some other "default value"? > Debconf itself is configured to prompt for questions based on a priority of how important the questions is. (e.g. to reconfigure debconf do "dpkg-reconfigure debconf") if its set to non-interactive debconf wont ever prompt for user input. debconf will first query its database or already answered questions, and if it doesnt find anything there it does use the value defined with the packaging (the vlaue defined in the package is the one will most likely want to override). So in doing mass installs its a matter of sharing already answered questions from your master machine with other target install machines so they dont use the default value that has been provided by the package as its most liely going to need to be changed. The thing is not all debconf values for one machine are applicable to other slave machines, so its only for certain questions that you want to share your answers. Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: redesigning the debian installer
Dan Helfman wrote: > Libdetect is modular in terms of detecting different classes of hardware > (CD drive, sound, ethernet, etc) via separate functions, so it can be > stripped down for the boot disks quite easily. After just a few of > minutes of commenting out detect calls, I was able to compile a > libdetect library that's "only" 46k and includes support for detecting > cdroms, ethernet, ide, scsi, isa, pci, usb, pcmcia, modems, and serial > devices. The lib could be further stripped down if necessary. I was looking at the source and it is modular and seemed quite easy to read (where are the nasty bits hidden? :-). I am concerned that it seems it always tries to detect ISA devices too, and there is no real delination of invasive and noninvasive detection. It is even possible to call a routine like the isa detection routine w/o having already probed the ISA bus? Can you just not call isa_detect() and pass in an empty list to such routines? This kind of thing (in Programming) does not enjender confidence: I recommend to make a sync before all detection operation. Because some criticals parts as isa, modem and mouse detection cand freeze your system. > > Also, we have to keep in mind that hardware detection is a two-edged > > sword. It's great until it probes somewhere it shouldn't and crashes > > your system. Strictly passive hardware detectors avoid this of course, > > but they detect less hardware too (no ISA cards, probably). > > Definitely. You might consider merely giving an option to use passive > detection on ISA cards, and probing all cards by default. Right, the user should be able to control this -- give them a choice of full detection, no detection, or just passive detection. > > Would some interested people like to get together and do some thurough > > research of the available hardware detection software, and present a > > report w/reccomendation to this list? Speak up if you're interested. > > I'm interested in this, as I'm fairly familiar with libdetect, having > packaged it. Let me know who I need to talk to. Are you on the debian-boot mailing list yet? We'll see who else expresses an interest. -- 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: > > Maybe that's all the hardware detection we should bother with. Is there > > really any point in worrying about making life easier for owners of ISA > > hardware these days? > > IMO, we shouldn't. Trying to autodetect ISA is probably more harm than > good anyway. On the other hand, if the library we pick has ISA detection for free, and it doesn't add much code bloat, and it can optionally be done, we can offer it as an option. So I think it's a nice extra, but not required in whatever library we pick, and it _is_ required the library can skip all invasive detection. We should dig up that list someone posted of various hardware detection libraries and look at the rest of them too. -- 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: > > On Tue, Sep 12, 2000 at 06:46:44PM -0700, Joey Hess wrote: > > Ben Collins wrote: > > > The good thing about PCI hardware detection is that there is no probing, > > > and the PCI layer/driver handles allocation an IRQ and I/O. So basically > > > the gist is, atleast include PCI detection, which maps PCI device ID's to > > > modules, and can prompt for which ones to load. > > > > Right. We already do PCI hardware detection, after all, for video card > > setup with anXious. > > > > Maybe that's all the hardware detection we should bother with. Is there > > really any point in worrying about making life easier for owners of ISA > > hardware these days? > > IMO, we shouldn't. Trying to autodetect ISA is probably more harm than > good anyway. > The 2.4 kernel can handle isa-pnp, so there shouldnt be problems with assigning irq and io value for isa-pnp network or sound cards which there are probably a fair few of. So i dont think isa-pnp should be a problem. Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: redesigning the debian installer
Glenn McGrath wrote: > The 2.4 kernel can handle isa-pnp, so there shouldnt be problems with > assigning irq and io value for isa-pnp network or sound cards which > there are probably a fair few of. Two problems there: 1) I have a box that pnpdump locks solid. Ok, I haven't tried the new kernel's detection, but I have my doubts. 2) It's outside the domain of the installer to set up your sound card. The only hardware the installer should care about is the hard drive, whatever hardware is being used to install from (cd, ethernet), and possibly CPU and memory. If we want a sound card detection thing, someone can write it as a normal debian package that's not part of 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 Tue, Sep 12, 2000 at 07:07:44PM -0700, Joey Hess wrote: > Dan Helfman wrote: > > Libdetect is modular in terms of detecting different classes of hardware > > (CD drive, sound, ethernet, etc) via separate functions, so it can be > > stripped down for the boot disks quite easily. After just a few of > > minutes of commenting out detect calls, I was able to compile a > > libdetect library that's "only" 46k and includes support for detecting > > cdroms, ethernet, ide, scsi, isa, pci, usb, pcmcia, modems, and serial > > devices. The lib could be further stripped down if necessary. > > I was looking at the source and it is modular and seemed quite easy to > read (where are the nasty bits hidden? :-). Apparently you haven't yet encountered the code in the SuperProbe directory. :) But that's video hardware anyway, and won't be necessary for the boot floppies unless there's room for that sort of thing. > I am concerned that it seems it always tries to detect ISA devices too, > and there is no real delination of invasive and noninvasive detection. > It is even possible to call a routine like the isa detection routine > w/o having already probed the ISA bus? Can you just not call isa_detect() > and pass in an empty list to such routines? I just tried this, and it appears to work. If I recall correctly, the Mandrake installer pops up a dialog box asking whether you want to really probe ISA devices or not. If you choose no, it goes ahead and does only PCI detection, etc. So it's definitely possible to turn off ISA detection in libdetect, either at compile or runtime. > This kind of thing (in Programming) does not enjender confidence: > > I recommend to make a sync before all detection operation. Because > some criticals parts as isa, modem and mouse detection cand freeze > your system. > Not to mention confidence in x86 hardware.. > > > Also, we have to keep in mind that hardware detection is a two-edged > > > sword. It's great until it probes somewhere it shouldn't and crashes > > > your system. Strictly passive hardware detectors avoid this of course, > > > but they detect less hardware too (no ISA cards, probably). > > > > Definitely. You might consider merely giving an option to use passive > > detection on ISA cards, and probing all cards by default. > > Right, the user should be able to control this -- give them a choice of full > detection, no detection, or just passive detection. > > > > Would some interested people like to get together and do some thurough > > > research of the available hardware detection software, and present a > > > report w/reccomendation to this list? Speak up if you're interested. > > > > I'm interested in this, as I'm fairly familiar with libdetect, having > > packaged it. Let me know who I need to talk to. > > Are you on the debian-boot mailing list yet? Yup. > We'll see who else expresses an interest. > > -- > see shy jo -- Dan Helfman UCLA Linux Users Group: http://www.linux.ucla.edu My GnuPG key: http://torsion.org/witten/public-key.txt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: redesigning the debian installer
Dan Helfman wrote: > Not to mention confidence in x86 hardware.. Well that made me realize the big thing we've missed in this hardware detection discussion so far: what about other architectures? (I'm not a multi-arch kind of guy, so I occasinally need to be reminded to consider them..) Is hardware detection needed much in other architectures? None of them have the same proliferation of crappy hardware as the x86 world. I guess everything we've discussed about PCI hardware applies to alphas too. Anything else on other architectures that needs to be detected? -- see shy jo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: redesigning the debian installer
On Tue, Sep 12, 2000 at 07:57:23PM -0700, Joey Hess wrote: > Dan Helfman wrote: > > Not to mention confidence in x86 hardware.. > > Well that made me realize the big thing we've missed in this hardware > detection discussion so far: what about other architectures? > > (I'm not a multi-arch kind of guy, so I occasinally need to be reminded > to consider them..) > > Is hardware detection needed much in other architectures? None of them > have the same proliferation of crappy hardware as the x86 world. I guess > everything we've discussed about PCI hardware applies to alphas too. > Anything else on other architectures that needs to be detected? Most everything under UltraSPARC is either PCI, or it's built into the kernel (standard hardware). In fact, 90% of UltraSPARC installs do not need to load a single module to get enough functionality for an install. This includes all supported SCSI, ethernet and IDE drivers. As for SPARC, it doesn't have PCI, but again the standard hardware is built into the kernel, so no need for hardware detection here. There are so few needed drivers for SPARC/UltraSPARC (no wacked out "only-one-person-owns-it" type of hardware), that it was possible to compile most of them into the kernel directly and still fit on the rescue disk. -- ---===-=-==-=---==-=-- / 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 Tue, Sep 12, 2000 at 07:18:23PM -0700, Joey Hess wrote: > Glenn McGrath wrote: > > The 2.4 kernel can handle isa-pnp, so there shouldnt be problems with > > assigning irq and io value for isa-pnp network or sound cards which > > there are probably a fair few of. > > Two problems there: > > 1) I have a box that pnpdump locks solid. Ok, I haven't tried the new >kernel's detection, but I have my doubts. > 2) It's outside the domain of the installer to set up your sound card. >The only hardware the installer should care about is the hard drive, >whatever hardware is being used to install from (cd, ethernet), and >possibly CPU and memory. If we want a sound card detection thing, >someone can write it as a normal debian package that's not part of >the installer. The thing is, most of these autodetection libraries just do "detection, suggest module". They don't care whether it is an ethernet card or video frame grabber. There's no need to duplicate this just for sound (or whatever), and IMO it doesn't hurt to do it all at once. Makes the installer look more complete, as opposed to "Hey, it didn't detect my 'foo' card, why not?". There is no overhead in this, since it is just a matter of PCI ID's and module mappings. The PCI_ID->module mapping is already done for all modules. Not using it, doesn't save anything. Ben -- ---===-=-==-=---==-=-- / 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 wrote: > The thing is, most of these autodetection libraries just do "detection, > suggest module". They don't care whether it is an ethernet card or video > frame grabber. That's not how libdetect works. Which library were you thinking of? > There's no need to duplicate this just for sound (or > whatever), and IMO it doesn't hurt to do it all at once. Makes the > installer look more complete, as opposed to "Hey, it didn't detect my > 'foo' card, why not?". If the choice is between one floppy with minimal detection and two floppies with detection of everything, I want one floppy, every day. If we make it clear that here is the hardware that you might want to use to install to/from/with, the user shouldn't be asking that question. > There is no overhead in this, since it is just a matter of PCI ID's > and module mappings. The PCI_ID->module mapping is already done for all > modules. Not using it, doesn't save anything. There's still disk overhead. As Dan showed with libdetect, you can save 50 to 100k by pruning down what it tries to detect. -- see shy jo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: redesigning the debian installer
On Sep 12, Joey Hess wrote: > Dan Helfman wrote: > > Not to mention confidence in x86 hardware.. > > Well that made me realize the big thing we've missed in this hardware > detection discussion so far: what about other architectures? > > (I'm not a multi-arch kind of guy, so I occasinally need to be reminded > to consider them..) > > Is hardware detection needed much in other architectures? None of them > have the same proliferation of crappy hardware as the x86 world. I guess > everything we've discussed about PCI hardware applies to alphas too. > Anything else on other architectures that needs to be detected? PowerPC will probably work with libdetect out of the box (at least the PCI-based ones). I remember something about PPC in the changelog lately. Amigas (PowerPC or m68k) could do some autodetection for AutoConfig devices; the question is, does anyone want to code it? I don't know if we even build any hardware modules in the m68k kernels... (If AutoConfig detection were coded, it could easily fit in libdetect.) Chris (Dan's sponsor) -- Chris Lawrence Titles/affiliations at http://www.lordsutch.com/chris/info.html Office: 662-915-5949 Email: [EMAIL PROTECTED] / [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: redesigning the debian installer
Chris Lawrence wrote: > PowerPC will probably work with libdetect out of the box (at least the > PCI-based ones). I remember something about PPC in the changelog lately. I wonder what other, non-pci hardware there is to content with on PPC? > Amigas (PowerPC or m68k) could do some autodetection for AutoConfig > devices; the question is, does anyone want to code it? I don't know > if we even build any hardware modules in the m68k kernels... (If > AutoConfig detection were coded, it could easily fit in libdetect.) What are autoconfig devices? -- see shy jo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: redesigning the debian installer
On Tue, Sep 12, 2000 at 08:23:16PM -0700, Joey Hess wrote: > If the choice is between one floppy with minimal detection and two floppies > with detection of everything, I want one floppy, every day. I'm with Joey on that. -- 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 Tue, Sep 12, 2000 at 08:34:50PM -0700, Joey Hess wrote: > Chris Lawrence wrote: > > PowerPC will probably work with libdetect out of the box (at least the > > PCI-based ones). I remember something about PPC in the changelog lately. > > I wonder what other, non-pci hardware there is to content with on PPC? Fairly little. There's a few non-pci video cards, but they do not need to be probed for - there's no accelaration support worth speaking of for any of them, so if no PCI video card is found but /dev/fb0 is found, just use fbdev. There's non-pci sound on a lot of macs, but there is a single kernel driver for all of those. Etc. Basically, if it isn't PCI, either it Just Works (tm), or Just Won't Work (tm). 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
"Michael S. Fischer" wrote: > > On Tue, Sep 12, 2000 at 08:23:16PM -0700, Joey Hess wrote: > > > If the choice is between one floppy with minimal detection and two floppies > > with detection of everything, I want one floppy, every day. > > I'm with Joey on that. > We still have to take into consideration that someone somewhere may need that 2nd floppy. I think that it should be easier for the end user to customise there installer based on space limitations and required features, thats the whole point of modularisation isnt it ? Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: redesigning the debian installer
On Sep 12, Joey Hess wrote: > > Amigas (PowerPC or m68k) could do some autodetection for AutoConfig > > devices; the question is, does anyone want to code it? I don't know > > if we even build any hardware modules in the m68k kernels... (If > > AutoConfig detection were coded, it could easily fit in libdetect.) > > What are autoconfig devices? Plug-and-play expansion cards that are automagically recognized by the Amiga hardware; basically, a lot like PCI but without all the backwards-compatibility hacks and several years earlier ;-) Most people call them Zorro cards, but even machines without Zorro busses supported AutoConfig devices on other connectors like the CPU expansion slot. Anyway, we're talking mainly about configuring ~10 possible video cards and ~5 NICs; easily accomplished with a lookup table and the zorroutils package. (Plenty of other hardware, but much of it isn't supported or will be built into the kernel, like SCSI controllers.) Chris -- Chris Lawrence Titles/affiliations at http://www.lordsutch.com/chris/info.html Office: 662-915-5949 Email: [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 03:11:32PM +1100, Glenn McGrath wrote: > We still have to take into consideration that someone somewhere may need > that 2nd floppy. > > I think that it should be easier for the end user to customise there > installer based on space limitations and required features, thats the > whole point of modularisation isnt it ? Perhaps a specialized "express disk" is in order here. (Yes, Glenn, I think maximum flexibility is always a noble goal.) -- 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
Glenn McGrath wrote: > We still have to take into consideration that someone somewhere may need > that 2nd floppy. Well of course. Someone might be installing by just floppies, or they may need something else that won't fit on just one. I'd still like one to be doable in some situations. > I think that it should be easier for the end user to customise there > installer based on space limitations and required features, thats the > whole point of modularisation isnt it ? There are a lot of interesting things we could do to make it easy to create customized install media. Might be possible to make a web site that builds a install floppy with just the stuff you need for your system for example. That's very much a second stage though. -- see shy jo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#71532: Installing Debian GNU/Linux 2.2 for Intel x86
Package: boot-floppies This is a really quick report, I'll dig into more a bit later once I get Debian GNU/Linux installed, but this one seemed to be worthy of note. Nowhere in this document is anything about actually getting Debian GNU/Linux covered. If this is intended to be something that's distributed only with Debian, then it would make sense, but I would place this document as one of the prime locations for new users to Debian. I'd make question 1.5 into "How do I get Debian GNU/Linux?" and have a short section pointing to the rest of the documentation on that topic (which, while easy to find, is not referenced here). Greg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
