Re: Wheezy size
Richard Owlett wrote:
OK, it is a hot button issue with me as I'm on dialup. Causes me to
wait until DVD's are available from vendors.
I don't understand how having or not having DVD isos on the Debian ftp
site affects you. You say you are on dialup. You are not going to be
able to download those extra 7 DVDs worth of iso even if they were
available. Therefore having them as an iso on the Debian site can't
help you anyway. Even if they were there you could not use them.
I also know from previous correspondence with you that you have
requirements for specific point release versions of Debian. It is
unlikely that the specific point release version you desire will be
available after the next point release is made.
I've a physically small install of squeeze and I seem to recall
loading something from DVD 8 or 9.
You loaded something. Very likely. But would that not have been
most efficiently downloade over the dialup for just that single
package? Tens of thousands of packages. You need something from the
large set of them. Just download that single something?
I will also suggest apt-cacher-ng as being a good tool to cache
downloaded debs for multiple installs so that they never need to be
transported twice.
I will wait for the full set of DVD's to be available. For my
personal wants/needs/preferences/quirks that is the best solution
and definitely worth the {cost}/{hassle removed}.
Or if you have a location with a faster than dialup internet
connection, a buddy, a library, you could make your own using
jigdo-lite. We have conversed about this before. I wrote up notes in
debian-user for you about it.
http://lists.debian.org/debian-user/2013/03/msg00667.html
http://lists.debian.org/debian-user/2013/03/msg00672.html
The DVD images are available to be created easily for the users who
need them.
Raises the question Will the complete set be available from
vendor/vendors listed at http://www.debian.org/CD/vendors/ ?
I hope that many vendors will make the full set of DVDs available.
But you would need to ask them those specific questions. It might
prompt them to make them available knowing that there are users with
your needs that would purchase them. It might speed them along.
Bob
signature.asc
Description: Digital signature
Bug#700633: Debootstrap is very slow. Please use eatmydata to fix this.
Phillip Susi wrote: After patching debootstrap to add eatmydata to the required list, and activate it during the second stage install, the time to construct the chroot dropped from 10m to 2m. This should also make installing new systems MUCH faster. I have also been suffering with the much slower dpkg on Sid. Today I performed a test of a default debootstrap chroot and had this benchmark data. I am using a local full mirror so that network performance is not significant in the measurement. This is using the stock Sid version of everything up to date as of today operating on an ext3 filesystem. # time debootstrap wheezy testinstall http://localmirror/ftp.us.debian.org/debian ... real2m58.577s user0m49.639s sys 0m8.749s And then using the patched debootstrap script Phillip Susi suggested I get this result: # time debootstrap wheezy testinstall http://localmirror/ftp.us.debian.org/debian ... real1m17.680s user0m49.879s sys 0m7.988s Wall clock time is more than 2x faster for me when avoiding the unnecessary fsync() calls. Ideally I would like to see dpkg handle this issue. But since that doesn't seem to be happening it would be nice if the rest of the ecosystem could work around it. Here is the same test again on an ext4 filesystem on the same system and the stock scripts. # time debootstrap wheezy testinstall http://localmirror/ftp.us.debian.org/debian ... real2m55.402s user0m52.107s sys 0m7.888s And again with the eatmydata patched script: # time debootstrap wheezy testinstall http://localmirror/ftp.us.debian.org/debian ... real1m4.819s user0m48.455s sys 0m6.752s That is 2.7x faster on ext4. Bob -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130216235452.gb10...@hysteria.proulx.com
Bug#700633: Debootstrap is very slow. Please use eatmydata to fix this.
Phillip Susi wrote: Bob Proulx wrote: # time debootstrap wheezy testinstall http://localmirror/ftp.us.debian.org/debian ... real2m58.577s user0m49.639s sys 0m8.749s Wow, that's pretty fast. 2m58s was the slow time. 1m4.819s was the fast time. :-) I was testing on a server with a raid5 array and was seeing nearly 10m original time, down to 1-2m patched. This is on a relatively fast machine. But the benefits will be more dramatic on machines with slower I/O bandwidth for disk storage. And that's with a pre built debootstrap tarball so nothing needed downloaded. With --download-only I assume? Or otherwise is fine. Sounds good. Bob -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130217043129.ga18...@hysteria.proulx.com
Re: Switching to graphical installer by default?
Cyril Brulebois wrote: Also, is there anyone aware of any reasons against switching to graphical installer by default? Can I at least say that I don't like the mouse installer and much prefer the standard keyboard one? I don't have any issues with it. I just don't like it. Bob signature.asc Description: Digital signature
Setting up the clock progress bar jumpy
I see somewhat strange behavior on the display when the installer gets to the part about setting up the clock and contacting the ntp server. The progress bar says 0%, then 3%, then 0%, then 3%, then 0%, then 3%, back and forth several times for the space of many seconds before it eventually proceeds onward. This is obviously very minor. But it caught my eye and just appeared very strange. This is using Installer build: 20121224-00:11 as a PXE booted netinst. I updated the bits today. Bob signature.asc Description: Digital signature
Bug#696571: installation-reports: Linux 3.2 VGA controller regression
Package: installation-reports Severity: important This is really an upgrade report. I am upgrading from Squeeze to Wheezy. I am trying to support a site running Debian with many systems with an ASUS F1A75-M LE motherboard. This hardware runs the Squeeze Linux 2.6.32-5-amd64 kernel without problem. http://www.asus.com/Motherboards/AMD_Socket_FM1/F1A75M_LE/ Unfortunately upgrading to Wheezy or later is a complete fail. The kernel is generally usable and installs and boots okay. But part way through the boot process with text characters being displayed but then the display switches into a ~60% snow ~40% white and becomes unusable. To be clear this is the vt console. This is not the X Window System display. The Linux vt console is unusable. On Squeeze's 2.6.32-5-amd64 kernel all works (mostly) well. When attached to 4:3 aspect ration monitors up through 1600x1200 all works fine all around and no problems were ever logged. It turns out it is using the vesa driver for this function. It worked well. (However changing the monitor to a 16:10 widescreen monitor causes the vesa driver to fail and fallback to the fbdev driver. The fbdev driver tries to drive the 1440x900 monitor in 1280x1024 mode and looks terrible. Therefore I attempted to upgrade to the Wheezy and ran into this problem. This is parenthetical background information only.) Since the vt console works on Squeeze but fails hugely on Wheezy I am calling this a regression. It isn't possible to use Wheezy on a system that used to run Squeeze. Since this is the Linux vt console, not X, there isn't even the proprietary driver to try. I will happily provide additional information. At the moment I don't know what I would add. Any hints? Bob Machine: ASUS F1A75-M LE motherboard 00:01.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Device 9644 (prog-if 00 [VGA controller]) Subsystem: ASUSTeK Computer Inc. Device 84c8 Flags: bus master, fast devsel, latency 0, IRQ 18 Memory at c000 (32-bit, prefetchable) [size=256M] I/O ports at f000 [size=256] Memory at fef0 (32-bit, non-prefetchable) [size=256K] Expansion ROM at unassigned [disabled] Capabilities: [50] Power Management version 3 Capabilities: [58] Express Root Complex Integrated Endpoint, MSI 00 Capabilities: [a0] MSI: Enable- Count=1/1 Maskable- 64bit+ Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010 ? Kernel driver in use: radeon processor : 1 vendor_id : AuthenticAMD cpu family : 18 model : 1 model name : AMD A4-3400 APU with Radeon(tm) HD Graphics stepping: 0 cpu MHz : 2699.755 cache size : 512 KB physical id : 0 siblings: 2 core id : 0 cpu cores : 2 apicid : 0 initial apicid : 0 fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 6 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc nonstop_tsc extd_apicid pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt arat bogomips: 5399.51 clflush size: 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: ts ttp tm stc 100mhzsteps hwpstate -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121223003454.28005.34695.report...@hysteria.proulx.com
Bug#693493: Unable to preseed keyboard for Wheezy
Package: debian-installer Severity: important I am testing Wheezy. Good deal! However I am running into some differences from Squeeze that are causing problems. Here is the first. I can't preseed the keyboard with Wheezy. Works fine with Squeeze. But Wheezy stops and asks the keyboard question. I am specifying console-keymaps-at/keymap=us locale=en_US on the command line but it is being ignored. This is a regression from Squeeze. It prevents an automated installation. I am using kvm and libvirt as the easiest way to reproduce this problem with exactly the following command: virt-install \ --name daze \ --ram 256 \ --vcpus 1 \ --hvm \ --nographics \ --disk path=/home/images/daze.img,size=3 \ --os-type linux \ --os-variant debianwheezy \ --network bridge:br0 \ --location http://ftp.us.debian.org/debian/dists/wheezy/main/installer-amd64/ \ --extra-args console=ttyS,9600n8 initrd=debian-installer/amd64/initrd.gz console-keymaps-at/keymap=us locale=en_US interface=auto hostname=localhost domain=localdomain auto url=http://internal/debian/preseed-kvm.cfg; Using s/wheezy/squeeze/g on the above works okay and preseeds the keyboard. Thanks, Bob signature.asc Description: Digital signature
Bug#693493: Unable to preseed keyboard for Wheezy
Samuel Thibault wrote: Bob Proulx, le Fri 16 Nov 2012 18:43:19 -0700, a écrit : I am specifying console-keymaps-at/keymap=us locale=en_US on the command line but it is being ignored. See the updated preseed documentation: use keymap=us instead. That did work. Therefore I am happy with the result. URL for the updated preseed documentation? The Squeeze released documentation here of course doesn't mention it. http://d-i.alioth.debian.org/manual/en.amd64/apbs04.html#preseed-l10n Bob -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121117020942.gb23...@hysteria.proulx.com
Bug#652275: Guided partitioning should not offer separate /usr, /var, and /tmp partitions; leave that to manual partitioning
Steve Langasek wrote: Michael Biebl wrote: To me it looks like there is broad consensus that a separate /usr partition should be considered deprecated and this option removed from the installer. There isn't. There's just a broad consensus among those who are talking about changing things. Unfortunately the ones that are the most agressive by shouting loudest and repeating the most often are sometimes the most successful. Some of us think this is completely bogus and are really sick of the same already-rebutted arguments being repeated over and over on the list as if that makes them true. Is there a way to collect objective information such that we would be able to know something with data other than with emotions? If the data showed that some wanted it one way and others wanted it the opposite way (which is of course what it would show) then how would having this data help or hinder either side? I will be one of the disenfranchised if /usr is deprecated. Bob signature.asc Description: Digital signature
Bug#650035: os-prober: Please enable quiet operation
Package: os-prober
Version: 1.49
Severity: wishlist
Since os-prober is run by default when grub is updated upon a kernel
upgrade it causes a lot of noise to appear to the syslog. Since
scanning the syslog for errors is good practice it means that there is
more information to scan through and to be discarded. It is more
tedious for me. Not a showstopper. But it would be nice if it were
quieter for normal operation when everything is behaving normally.
For example on one host every run generates 24 lines of debug
information. The debug information is useful to someone developing
and debugging the scripts but on a stable production host isn't
changing.
It would be very nice if the debug information were optional. It
would be very nice to be able to set a quiet variable in order to turn
off the debug information. I am fine with keeping verbose the default
behavior. As a suggestion, perhaps something like this following
(untested) code snippet in /usr/share/os-prober/common.sh file.
VERBOSE=true
if [ -r /etc/default/os-prober ]; then
. /etc/default/os-prober # Available to set VERBOSE=false
fi
debug() {
if $VERBOSE; then
log debug: $@
fi
}
That would preserve the existing behavior yet enable people like
myself to optionally quiet it down on stable production hosts.
Thank you for maintaining Debian!
Bob
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/2025193919.31529.51005.report...@hysteria.proulx.com
Bug#443979: Package: installation-reports
reassign 443979 linux-image-2.6-486 retitle 443979 Linux boot hangs on AMD Geode GX systems thanks I am reassigning this to the kernel package. It isn't an installer problem. Hoping that this will get different exposure and that someone reading it will have some insight into the problem. Bob -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#443979: Package: installation-reports, soft-cpu???
Regarding the failure to load Debian 2.6 kernels on a Geode system... Geert Stappers wrote: Op 09-03-2008 om 21:32 schreef Frans Pop: This is obviously not so much an installer issues, but more a kernel issue. Agreed. But finding this report I decided to add to it. Feel free to reassign this to a more appropriate project. Somewhere along the line the kernel changed in a way that is incompatible with your hardware, either the (upstream) kernel code or the kernel config. Comparing the kernel configs of that FC8 kernel and the Debian 2.6.24 kernel could give us some clues then. The first thing to check, would be the math co-processor emulation support in the kernel. The DSL-N 2.6.12 kernel boots okay and reports the following flags. [EMAIL PROTECTED]:~$ cat /proc/cpuinfo processor : 0 vendor_id : Geode by NSC cpu family : 5 model : 1 model name : Cx486DLC stepping: 0 cpu MHz : 332.052 fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu de pse tsc msr cx8 pge cmov mmx mmxext 3dnowext 3dnow bogomips: 647.16 AFAIK the fpu flag indicates a math co-processor. Bob -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#443979: Package: installation-reports
Steven Tupper wrote: Machine: ETX-LX-800 R10 board on an mini ITX base board Processor: AMD Geode GX MMX 500MHz Memory: 256MB + 8MB graphics Comments/Problems: I run up the system and it boots to the cd which runs the Debian installer app. I get the splash screen with the 'F1 or enter' text. If i just press enter i get a blank screen with a flashing cursor, if i press f1 then install i get: Loading /install.386/vmlinuz... Loading /install.386/initrd.gz... Ready. _ and there is where it sits until i reboot it. I am seeing an almost identical issue using an AMD Geode GX-MMX 333MHz with 256M of ram in an Acrosser AR-B1554A. Testing to determine other datapoints. Woody installer boots linux 2.2.20 and 2.4.18. Sarge installer boots linux 2.4.27 and 2.6.8. But Etch will not boot 2.6.18, Lenny will not boot 2.6.22 and Sid will not boot 2.6.24. Booting DSL-N boots linux 2.6.12 okay. Booting an FC8 live cdrom boots linux 2.6.24 okay. Bob -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#407246: installation-report: printer configuration failed during install
Frans Pop wrote: Bob Proulx wrote: In the middle of the installation the installation failed (red background screen) with a printer configuration failed message. I do not have a printer attached to the machine. I think a lot of machines will be without a printer attached. I think this would have confused many people. To be honest, I do not have the faintest idea what you are referring to. Unfortunately I did not have a camera handy and could not capture the image. An error had apparently occurred during the installation and the message indicated that it was a printer configuration error. The installation displays this information against a red background. What was the package being installed when this happened and could you cite the exact error messages displayed? You may be able to find some indication of this in /var/log/installer/syslog, but you may have to repeat the installation. Unfortunately no because I am using the machine to develop a full preseed file and have reinstalled since then. I cannot tell from your preseed file which tasks you selected for installation. The preseed file I used at that time did not specify any files. The interactive task selection dialog box was presented. I kept the defaults, Desktop and standard system, and installed the default set of packages. I made no customizations and simply pressed enter using the defaults provided. My whole purpose in the preseed file is to reduce the tediousness of the interactive portion when using a custom local depot. I was using an apt-cache depot from a Sarge machine. That should be completely transparent and *should* reflect the current state of the live depot. Since I was installing amd64 bits and had not done so before no files were cached and all needed to be downloaded for the first installation, therefore I believe that to be double true in this particular case. Entering a long deb source entry into d-i at installation time is a little tedious when installing on a large number of machines hence the preseed file. My real purpose is to develop a fully automated installation. My test was simply a development turn-on test. I have installed using the same installation media four times since then and the error has not reappeared. Since this is the business card image and all packages are downloaded from the network I can only imagine that something in the external set of packages changed. Without additional information I don't see how we can follow up on this issue. I was simply following the instructions: http://www.debian.org/devel/debian-installer/ After using the Debian-Installer, please send us an installation report, even if there weren't any problems. And here too: http://d-i.alioth.debian.org/manual/en.i386/ch05s03.html#submit-bug We also encourage installation reports to be sent even if the installation is successful, so that we can get as much information as possible on the largest number of hardware configurations. I assumed the information concerning the hardware with pci ids and such would go into a database that could be referenced to determine if a particular piece of hardware had previously installed successfully or not. Of course I was expecting the printer configuration failure to be repeatable at the time that I reported it. But especially since it has not failed in the subsequent installations I can only assume that something external influenced it. This is a business card image and so is quite possible to be influenced by external events. If a trend emerges then this is perhaps a useful datapoint. If not then this is still just a datapoint. To be clear on this matter, I am not expecting anything. I am an experienced Debian user and admin and am generally quite pleased with the new installer. Things are in general working very well. Thanks to everyone who has worked hard to get it to this point. And thank you for putting in the effort to read and respond to the installation report! Bob -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: slimming down base for a embedded install
Rajkumar S wrote: I am installing debian on a embedded machine with a 96 mb disk on module. The network install is working but there isn't enough space for installation to complete. the /target gets filled up. Since this is for a firewall device we can trim down the size of base install. I am looking for docs about how to do it. Any help will be much appreciated! Here are some references which might help you along. http://lists.debian.org/debian-user/2002/debian-user-200212/msg05265.html http://www.openbrick.org/en/Members/jp/install.stx/view http://www.linuxdevices.com/articles/AT4540125636.html Bob pgp0.pgp Description: PGP signature
Re: Defend Debian
Fabian Fagerholm wrote: Are you sure it isn't a DFE-530TX+, which uses the rtl8139.o module? The rtl8139 is Donald Becker's driver. A fine driver. But not shipped with Linux. You probably meant the 8139too driver, a forking of the code, which is shipped with Linux. Either should work fine if you have it. But you probably have the 8139too driver at install time. The 8139too driver is compiled into the bf24 kernels. But not the optimized kernels like the i686 kernel. Therefore you need to put the module in /etc/modules when or if you upgrade to one of the optimized kernels which has caught many people. Those D-Link names are so confusing sometimes, just a little + can mean it's a completely different piece of hardware... Yep. Bob -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
HPPA: Boot warning 80F5 (was: Boot warning 80F5.)
Max wrote: I have HP 9000/809/k100. Ooo! A K-class. That was big iron in its day. When my box boot from Debian 3.0r1 hppa CD ( Interact with IPL (Y or N)? Y ), i've got message Cannot find ENTRY TEST Status= -4 and WARN 80F5 on LCD panel status. What is that means? What do I do? Where can I find other WARN description ? I would search the archives of debian-hppa for older discussion. If nothing found I would post a note there as that is where the majority of the hppa users will be listening. http://lists.debian.org/debian-hppa/ The LCD panel is a bootrom display and is not Debian specific. I am sure one of the service manuals will list it. Bob msg25444/pgp0.pgp Description: PGP signature
Re: Current EEPRO100 Driver in boot-floppies
Adam DiCarlo [EMAIL PROTECTED] [2003-01-09 09:59:14 -0600]: As for the issue of the shipped EEPro, are you using the bf2.4 to boot with or no? This seems like an issue with the stable kernel-source-* package. It would seem like an issue for upstream more than for a downstream package. Having used the Intel NICs much which use the eepro100 driver I will second that the upstream driver even in 2.4.18 is not perfect. It takes heavy usage to trigger problems. I have never seen casual use be trouble. But under heavy use the driver will sometimes report out of resources or some similar message as that is from my memory. Sometimes it will continue. Sometimes it will just stop doing anything and the network is offline. When that is one of your DNS and NIS servers it is a bad thing. (Of course everyone has at least two of all critical servers, right, and so the redundant servers pick up the load at that point.) If the eepro100 driver stops responding you can log in on the console and restart the networking. Everything is fine. I once put that in a cron to happen regularly just to recover from this problem. Obviously that is an unsatisfying resolution. Installing the previously cited Intel source driver instead of the eepro100 solved the problem completely. It would be great if upstream either adopted that driver or merged a fix into the eepro100 driver. Bob msg25159/pgp0.pgp Description: PGP signature
Re: Failure to boot on dual xeon 2ghz/asus pr-dls
Tollef Fog Heen [EMAIL PROTECTED] [2002-09-09 11:58:02 +0200]: which kernel version do you have installed? can you boot it using linux root=/dev/hda1 initrd= from the cdrom boot prompt? Second that question since I know it is not possible to boot some dual processor machines with the 2.2 kernel. My dual processor boxes require the 2.4 kernel or they hang at boot. But with the 2.4 kernel all goes well. Bob msg22008/pgp0.pgp Description: PGP signature
Re: Graphical installer
[Petter Reinholdtsen] [Bob Proulx] Finally the CD package distribution is not so nice yet. I often see people say that CD #1 is all that 99% of the population needs. But having done a CD installation in the last week I disagree. Currently making my own Debian-based distribution, I agree on this one. But this has improved a lot in the last few months. Did you try to raise your voice on the debian-cd mailing list, where this is being addressed? Well, I have only been using Debian for a few weeks. Possibly for as long as three months now among doing other things. I first subscribed to the list four to six weeks ago. Usually it is polite to make a best attempt to learn how things are done before one comes in suggesting sweeping changes. :-) But I subscribed specifically so I could become more involved with the debian cd process. When was it being addressed? If it was more than a short time ago I missed the discussion. (It is always September on the net these days. Sorry about that.) And note that I am trying not to be overly critical, just pointing out points for improvement. I mean it as constructive criticism. I see much more that I like about Debian than what I don't like. I have Debian running full time on a number of systems, I can't count them all but in the double digits, and plan to have more. Since I am doing a fair number of installations right now I am seeing the issues with the CDs and installs quite often. I would love to help improve that. Since I have been using Debian I have seen the big push to get Woody out the door. Although it is always nice to get absolutely everything perfect before a release it is also true that things are never perfect. Somes it is better and necessary to say enough is enough, for now, and to push things out as they are to a release. That is exactly what woody needed. It needed to be released. A good job to all who helped with that. Further improvements can go in the next release. But I have been using unix/linux systems for many years and consider myself well versed there. I try to contribute where I can. Expect to see me with suggestions. Bob msg20973/pgp0.pgp Description: PGP signature
Re: Install Debian? Maybe
This is the stumbling block that discourages many people from using Debian. There's a lot of development going on in 'improving' Debian but there doesn't seem to be any movement on improving the installation process. I think there is actually a lot of work going on there. But as has been discussed ad-nauseum woody needs to get out so that people can see it. There are huge, good differences between installing potato and installing woody. With each release you expect to see some improvement. Since there has been long gaps in releases there have been long gaps in improvements as well. The current woody install is still far from perfect. Don't think that I believe it to be. But having releases roll out so slowly I believe to be a limiter to the speed of making improvements in the installation process. I had to reinstall 13 times before I got Debian X to work . This is a common problem with transitioning to Debian, or really any system that has fundamental differences from things you know. I have been a from scratch OS builder for years. So for me I never thought about reinstalling the entire OS as a method to fix X. For me the first thought was grab sources from ftp.xfree86.org and recompile. Which has a share of pain involved. Probably many people think reinstallin the OS is easier. But it is all about doing what you know and feel comfortable with. It took me a while to learn things like 'update-alternatives --edit vi' to make sure that vi was vi and not a similar but different vim. (Yes, vim is better than vi but it is not vi and the differences annoy me endlessly.) Until that revelation I had been hand hacking the symlinks in frustration and cussing out debian the entire time. Now that I have learned that part of the system I think it is a pretty cool part of the system. Don't like the ancient 'mawk' as awk? Most don't. 'apt-get install gawk' and transparently the awk links all are updated to the modern flavor. (Gawk should be the standard in the install over mawk, IMNHO.) It took me a while to learn that the dpkg functional group of stuff was really a whole series of related programs dpkg-*. In bash or anything else with completion type in 'dpkg' then TAB-TAB and look at all of the possible programs in the suite. Read the man page for each a few times in turn and suddenly the methodology becomes more apparent. Until that revelation I was lost. There is copius documentation. But not in any coherent way and way too much of it. The installation documentation on the www.debian.org site is particularly confusing. I have read it all several times and cannot recommend it. I hope that once I get to the point that I think I understand Debian more thoroughly that I can help to contribute improvements to that documentation. But I don't feel like I have that expertise yet and neither do I even know where to begin to contribute to those pages. There are places in the installation process is full of surprises where you cannot backtrack to make a correction. If there were some clues as to what steps and options are involved in the installation BEFORE starting it, perhaps there'd be less difficulty with the installation. Hmm... I agree that it is not clear. But in the installations I see a list of steps. I can select any of those. Some of those steps are prior steps that have already been done. Just go back and select them. You will find yourself back at the previous step. Maybe that could be made more clear but I think you can go back although perhaps at particular steps perhaps not. How come Debian based distributions like Libranet are so much easier to install than plain Debian? Could it be sort of an initiation to an exclusive club? I am certain it is not intentional. Since most experts have had systems running for a long time there is less pressure at needing a good installer by experts who are most able to improve it. It has often been said that change comes because of need. People write programs to scratch an itch. If there is no itch by those with the capability to scratch then less progress is made. For example, right now I could really use some documentation. By the time I get to the point that I could write that documentation myself I will no longer need it. Therefore without any compelling reason to write it then it probably won't get written. The cycle continues. No wonder there's so much activity on this list. I'll bet that a large part of the problems are because of errors made in the installation. There are a few very common installation problems that pull people in repeatedly. Probably an installation FAQ or README.1st would be appropriate as an interim to putting improvements in the installation process. Documents can be updated more quickly than installation images. The mouse problems with /dev/psaux versus gpm /dev/gpmdata is one example that tripped me up until other kind souls on the network pointed me to the solution.
Re: Problem with installing the base system
I'm trying to install Debian 3.0 on my system but I cannot install the base system. [...] If your machine has a network connection, you might have better luck with a network install. Agreed. If possible to do so then I highly recommend the network install. http://www.debian.org/CD/netinst/ I have been using the LordSutch.com ISOLINUX mini-ISO image link which currently will take you here. http://www.phy.olemiss.edu/debian-cd/ I have had good luck with the woody-i386-1.iso image. It is 185MB and is self contained to install a small working system with only the minimum of required packages installed. That minimum system is then used to do a network installation from the woody mirrors. You can change the sources.list file to select unstable / sid if desired. The installation process will allow you to use either or both or none of tasksel and dselect. For new users I suggest using tasksel which will get you going with a minimum of trouble and will install a large selection of stuff for you. I recommend avoiding dselect. My preference is neither and I manually install my own list of packages after the system is up. I log in as root and run apt-get install on my package list. These are my personal recommendations and I am sure other people with have different ones. Bob msg20807/pgp0.pgp Description: PGP signature
Re: Graphical installer
[Chris Tillman] You know, the official installer is really not that bad! Petter Reinholdtsen wrote: That depends on your point of view. For new Linux users, it is really, _really_, bad. For more experienced Linux users, it is very flexible and powerful, but not easy, convenient and fast. I want a Debian installer for new Linux users. :-) Since the current installer takes over the terminal and guides the user through the installation, it seems to me that it does the same job as other installers which happen to be graphical. But with one difference. The Debian installer does not use the mouse but instead uses the cursor keys and the enter key. So I have to be specific and ask you is that specifically what you think new Linux users need? An installer that uses the mouse instead of the cursor keys and enter? Are new Linux users really troubled by using the cursor keys instead of the mouse? [insert poignant pause] I should stop here and pause for the answer but I can't. Think of this as a followup to my own posting without even waiting to post it. I would divide what the new user thinks of as the installer up into parts. The installer. The tasksel/dselect package selection step. The debconf and non-debconf configuration step. Let's talk about them individually. The installer is actually pretty nice and I will cautiously say that is probably what most experienced Debian people are refering to when they say the installer is not that bad. But I am betting that is not what the new Linux user is referring to when one talks about the installer. I am betting that they are including the rest of the process with it. The tasksel step for package selection is a good thing. It is much better than not having it. However, it is a pretty big brush right now and paints huge strokes. It needs refinement. This has been a topic on the lists. But dselect step is another thing. IMNHO for the new Linux user it is very intimidating. Many experienced Debian people openly admit that they avoid using it. I believe the dselect experience leaves new Linux users with the same opinion as posted above. I never run dselect and avoid it both during the install and at other times. Packages which do not use debconf have left users with bad experiences as well. I believe this has mostly been fixed up in recent versions of packages. But previously it was very annoying to have unpredictable intervals of time between question and answer customization sessions which would occur during an install. You never knew when you could leave the installer unattended without it stopping waiting for a reaction from you. Again, I believe most of those packages with issues have been addressed in recent versions. Even for packages that use debconf the messages can be very annoying. An example. Do I really need an OK-only dialog box to warn me about ftp globbing attacks? Does the CVS package really need to make a repository even if I only need or want the client apps? Let's not bash on those but they are typical examples. In fairness there used to be many more but much progress has been made in that area. Finally the CD package distribution is not so nice yet. I often see people say that CD #1 is all that 99% of the population needs. But having done a CD installation in the last week I disagree. There are many packages which I consider core which are not in CD #1. I usually do a network installation and never see that difficulty. But if you install from CD you find that you really do need several disks. (I don't know which disk rsync is on but it is not on #1. How about sudo? How about NTP? How about gawk? How about fakeroot? The list continues.) I realize tradeoffs need to be made and not everything can fit but that is different from what people say about most people only needing CD #1. The core installer is pretty good. But the new Linux user thinks all of the surrounding environment is the installer too. It is their first contact with the system. It is all part of the installation experience. I don't think the installer is the problem. But until everything else is improved complaints will continue about it. Bob msg20775/pgp0.pgp Description: PGP signature
