Bug#724627: cracklib-runtime: cracklib-check should deny key-runs with dvorak keyboard variants
It's not that qwerty layout runs per se are denied, it's that too many consecutive character pairs are denied. Certain qwerty layout runs simply happen to contain many consecutive character pairs. As the prior message observes, the bug is annoying: augmenting an otherwise acceptable password by appending consecutive characters renders it no longer acceptable! The bug is real, but has nothing to do with qwerty-vs-dvorak. The Fedora project addresses it by simply disregarding consecutive character pairs as adding any "length strength". -/* Change by Ben Karsin from ITS at University of Hawaii at Manoa. Static MAXSTEP -would generate many false positives for long passwords. */ -maxrepeat = 3+(0.09*strlen(password)); -if (i > maxrepeat) +/* We were still generating false positives for long passwords. +Just count systematic double as a single character. */ +if (len - i < MINLEN) Regards, Alex
Bug#819742: man firehol.conf results in undesired behavior
Package: firehol Version: 3.0.1+ds-1 The package firehol contains /usr/share/man/man5/firehol.conf.5.gz which references the non-existent "man5/firehol-conf.5" (which doesn't exist in this package; it is part of firehol-doc, but that package might not be installed). The command "man firehol.conf" results in: man: can't open /usr/share/man/man5/firehol-conf.5: No such file or directory Manual page firehol.conf(5) line ?/? (END) (press h for help or q to quit) It would be better if the firehol.conf.5.gz were moved to firehol-doc, and it would be even better if firehol.conf.5 were a stub that said to install firehol-doc for access to the documentation, and that stub were to be substituted with the real thing if firehol-doc were in fact installed. Note: The same issues exist with fireqos and fireqos-doc, but I'm not filing a separate bug report.
Bug#410878: d-i uses mirror/http/proxy setting when it (probably) shouldn't
The bug Roland reported is real, and occurs in 2013 with Debian 6 installer. There should indeed be a distinction between an APT proxy and a general-purpose HTTP proxy. Our APT proxy knows how to serve up files related to Debian mirrors, but can't do general-purpose HTTP retrievals such as preseed/run files from our PXE server. Currently mirror/http/proxy affects http_proxy globally, for all subsequent calls to wget. Might be better to not do that; instead, on each APT-related call to wget, if mirror/http/proxy has a value, then temporarily store it in http_proxy, call wget, and then restore http_proxy to its prior value. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#701656: initramfs rescue shell doesn't recognize USB keyboard
On 2/25/2013 4:54 PM, Ben Hutchings wrote: [...] But my keyboard was present at time of install, so one would expect it to work. Yes, I understand this. Unfortunately this is still going to randomly go wrong if you upgrade the kernel (or any other package that contributes to the initramfs) without a keyboard plugged in. (I don't know what kind of computer you are installing on, but this would be entirely normal for a server.) Agreed, that situation can occur, although the server might at least be connected to a KVM and perhaps newer USB-based KVMs present a keyboard presence even when the KVM focus isn't currently pointing at that particular server. The topic isn't perhaps so much about keyboards specifically as it is about whether a targeted build should support hot pluggable hardware (of any kind) present at time of build? For example, I might permanently attach a flash drive to a USB port to boot the system or for other purposes. In fact, some servers have an *internal* USB port for just that purpose. So even though in principle the USB device might not be present at the time I happen to randomly upgrade the kernel or an initramfs-related package, in fact I would always have it present, and would want it to work. The existence of hot pluggable hardware certainly presents a conundrum: do you include all possible drivers? Of course not, it's a targeted build that is supposed to be as small as possible. Do you instead include none of the drivers? That too won't work. It seems the correct compromise is to include precisely those drivers for the hardware (hot pluggable or not) that is present at time of build. If someone subsequently shoots themselves in the foot because they disconnected something temporarily during the time they did a kernel upgrade, well, they'll eventually learn that a targeted build can't handle that situation. Perhaps we should also rename 'targetted' to 'what-could-possibly-go-wrong'... :) Alex -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#701223: post-install boot failure with ext2 + TTY-only (desktop tasksel skipped) installation
Hi, On 02/23/2013 02:14 AM, Holger Wansing wrote: 1) I used the 6.0.6 netboot installer (tried both 32-bit and 64-bit) Could you try to reproduce this bug with the latest debian-installer being prepared for 7.0 ? Take the mini.iso from http://ftp.nl.debian.org/debian/dists/testing/main/installer-i386/current/images/netboot/gtk/ Unfortunately same outcome. At the final be-sure-to-eject-CD-before-reboot message, I dropped into a shell, and both /dev/disk/by-uuid and /target/dev/disk/by-uuid contain the same BOGUS uuid, whereas the 'search' line in /target/boot/grub/grub.cfg contains the CORRECT uuid. Alex -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#701656: initramfs rescue shell doesn't recognize USB keyboard
Package: initramfs-tools Version: 0.109 The initramfs rescue shell doesn't recognize the USB keyboard if I do an expert install of Debian 7.0 and in response to Drivers to include in the initrd choose targeted instead of generic. Same behavior with Debian 6.0 and yaird choice, in which case the initramfs-tools version is 0.98.2. In either case, the USB keyboard driver seems to not be included. I'm landing in the initramfs rescue shell early in the boot process due to an incorrect kernel root= parameter in the GRUB configuration (due to an unrelated installer bug, which has been reported separately). I get: ALERT! /dev/sde1 does not exist. Dropping to a shell! BusyBox v1.17.1 (Debian 1:1.17.1-8) built-in shell (ash) Enter 'help' for a list of built-in commands. /bin/sh: can't access tty; job control turned off (initramfs) At this point there is a blinking cursor. On systems with a PS/2 keyboard, I can type commands. With both a PS/2 keyboard and a USB keyboard, only the PS/2 keyboard works. But some of our machines don't have PS/2 ports! On those machines, I'm not totally stuck. Whereas the preceding BIOS and GRUB components did respond to the USB keyboard, the rescue shell at this point does not. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#701656: initramfs rescue shell doesn't recognize USB keyboard
On 02/25/2013 02:39 PM, Ben Hutchings wrote: There isn't just one USB keyboard driver; there are many. I see. Since my keyboard works in BIOS and GRUB, I suppose this means the driver is present in those places, or they are using some legacy user input approach that wouldn't be appropriate for the rescue shell? Now maybe we should include the right driver for whatever you had plugged in during installation. That seems reasonable. But what if you don't have a keyboard plugged in? What if you plug a different model of keyboard in, that needs a specialised driver? A valid concern, but in analogy to plugging in a different model keyboard, one could install say an add-on video card to use in place of built-in video. Either way, that's changing the hardware, so a targeted build may legitimately fail. But my keyboard was present at time of install, so one would expect it to work. This is why 'generic' is usually the right answer. Good to know. That was the default, but the associated debconf explanatory text warned that a generic build might be too large to boot, which tempted the experiment with changing the value. If keyboard support can't be improved in time for the Debian 7.0 release, could at least the debconf explanatory text include (Note: initramfs includes a rescue shell for boot failures. The targeted build doesn't include any USB keyboard drivers.) ? Thanks! Alex -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#701223: post-install boot failure with ext2 + TTY-only (desktop tasksel skipped) installation
Package: debian-installer Version: 6.0.6 I'm trying to build a text-only (no graphical desktop) Debian system with ext2 instead of the default ext3, but the resulting install is unbootable due to a bad grub configuration. To reproduce: 1) I used the 6.0.6 netboot installer (tried both 32-bit and 64-bit) 2) Went with default responses, with two deviations: 2A) Instead of guided partitioning, manually set a / partition and a swap partition, with / formatted as ext2 2B) When tasksel came up with the defaults of graphical desktop and standard system utilities, I unchecked graphical desktop 3) Upon reboot, the grub menu comes up, then grub loads the kernel and initrd, then the usual Loading, please wait..., but a little while later we get Gave up waiting for root device and it drops into the rescue shell. The culprit is line 6 of the GRUB configuration: 1: insmod part_msdos 2: insmod ext2 3: set root='(hd0,msdos1)' 4: search --no-floppy --fs-uuid --set 5: echo 'Loading Linux 2.6.32-5-amd64 ...' 6: linux /boot/vmlinuz-2.6.32-5-amd64 root=/dev/sde1 ro 7: echo 'Loading initial ramdisk ...' 8: initrd /boot/initrd.img-02.6.32-5-amd64 The target hard drive was indeed /dev/sde when the installer was running (due to USB card reader devices taking up earlier slots), yet it seems that at boot time the hard drive is now /dev/sda. If I use the built-in GRUB editor to on-the-fly change that line to have root=/dev/sda1, then the system boots fine. Once booted, if I then run update-grub, the new GRUB configuration has root=UUID= instead of root=/dev/sde1, and everything works fine. If I start over and reinstall with ext3 instead of ext2, then the GRUB configuration already has root=UUID=, whence everything works fine. It also works fine with ext4. Thus there seems to be a bug in the Debian Installer when it comes to writing the GRUB configuration, specifically in the case of using ext2. In fact, if I drop into a shell at the end of installation but before the reboot, I observe that grub-probe returns the correct UUID of the partition, but the /target/dev/disk/by-uuid/ directory contains a BOGUS value! Hence the grub-mkconfig script doesn't trust the UUID and doesn't write it into the GRUB config. However, after reboot (via on-the-fly GRUB editing), the /dev/disk/by/uuid/ directory contains the correct value, explaining why update-grub at this point does the right thing. I also stumbled on a mysterious different way to avoid triggering the bug: if I start over and reinstall, again with ext2, but this time allowing the graphical desktop in tasksel, then the GRUB configuration ends up with the desired root=UUID=! I'm at a complete loss to explain this. Can the installation of the graphical desktop task somehow cause /target/dev/disk/by/uuid/ to get corrected? I'm guessing that task subsequently invokes update-grub after installing the background graphics for the GRUB menu, but how are the udev links getting corrected by the graphical desktop task? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#701223: follow-up thoughts
It occurs to me that the BOGUS value in /target/dev/disk/by-uuid might be a spurious filesystem signature left over from a previous install? I've noticed that the partman ext2 formatting goes really fast compared to the ext3 and ext4 formatting, so presumably less data is being written, perhaps allowing old superblocks to survive. One might furthermore presume that the installer code doing population of /target/dev/disk/by-uuid/ is different from the code doing the population upon reboot, and one could then theorize that the installer version incorrectly pays attention to leftover superblocks that aren't really part of the ext2 partition. However, this theory doesn't explain how the graphical desktop task ends up fixing everything prior to reboot. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#642159: debian-installer preseed broken with apt-cacher-ng mirror
This debian-installer bug is perhaps more serious than might seem from the original bug report. It affects preseed/run and preseed/include. Not clear how to adapt the work-around from the original bug report. The bug also affects fetching in preseed/late_command, as well as subsequent attempts to re-fetch the original preseed file (which comes up if you have priority=low or some other installer error to bring up the installer menu, and as you proceed through the steps it will direct you to the preseed fetch menu option). Particularly confusing is that Ctrl-Alt-F4 shows a wget 403 error yet tcpdump on port 80 on the preseed server shows no activity, and furthermore if you go into BusyBox in the installer and do a manual wget there is no error. I can't determine a work-around, which might for example be to tell apt-cacher-ng to serve up (and not cache) local files, but no luck so far. I considered replacing apt-cacher-ng with two copies of approx (one for debian, one for ubuntu), but approx seems to be a more apt specific cache that won't serve up arbitrary local files. Consequently I avoid fetching additional preseed files entirely, with a growing one-liner script in preseed/late_command. It seems that much of the additional power of preseeding is unavailable right now, in the context of an apt proxy cache, until this debian-installer bug can be addressed. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#351993: ssmtp doesn't failover to multiple mailhubs in IPv4
There has been no comment and no movement on this bug. (It has been 3.5 years!) A patch was included. The bug is easily understood, and the patch is only a minor code rearrangement, simple to verify for correctness. Do you need more information? More clarification? Why can't this get fixed? Can you at least comment on what the holdup is? For us the situation is a pain: everytime you modify ssmtp to fix some other bug, we have to take your new version and manually apply our patch, build a custom .deb, and install this on our machines. To explain the bug again: Say for failover purposes you have two identical outgoing mail submission hosts. For example, mailhost.mydomain.com in DNS could expand to two different IP addresses. If one of them is down (unreachable), clients should then try the next IP address. Most mail clients handle this correctly. But ssmtp does not. (Actually, ssmtp even handles this correctly for IPv6 addresses, but does not handle it correctly for IPv4 addresses.) Our previously submitted patch fixes this bug. Thanks. Alexander Perlis, Department of Mathematics, The University of Arizona -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#504665: /etc/init.d/fwknop-server has a typo
Package: fwknop-server Version: 1.9.8-1 /etc/init.d/fwknop-server calls log_failure, which doesn't exist. Should probably be log_failure_msg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#504666: Request /etc/default/fwknop-server option to set daemon options
Package: fwknop-server Version: 1.9.8-1 A feature request: if would be nice if /etc/default/fwknop-server defined a variable such as FWKNOP_OPTS= and then one could for example put FWKNOP_OPTS=--debug among other things. Just an idea. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#504670: Please don't depend on mailx
Package: fwknop-server Version: 1.9.8-1 The *-mailx variants are for the command-line mail program, which is a userland program for end-users, not for use by scripted systems. In particular, depending on user configuration, mail might want to deposit copies of messages to an IMAP folder, requiring prompting for a password. This is hardly something to be used by scripts. AFAIK, scripts should depend on mail-transport-agent and call sendmail directly. The code has to be modified slightly. Whereas with mail you can do mail -s my subject [EMAIL PROTECTED] EOF This is the body of the message EOF with sendmail you have to do sendmail [EMAIL PROTECTED] EOF From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: my subject This is the body of the message EOF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#407085: Poweroff/restart problems due to miscommunication between /etc/init.d/halt and /etc/init.d/ups-monitor
We have the same problem and present below some possible solutions. ASSUMPTION: Your computer's BIOS is set to Last State After Power Loss, i.e., it will turn back on iff it lost power after system halt. On some computers, if your BIOS is set to Always On After Power Loss, this bug report may *also* apply, because on some computers, if you do a clean shutdown and poweroff, if you then pull the plug and then plug back in, the computer will remain off. If /etc/default/halt has HALT=poweroff, then: 0) Power goes out. UPS starts beeping. apcupsd kicks into gear! 1) /etc/init.d/halt will set INIT_HALT to POWEROFF 2) /etc/init.d/halt will indeed call /etc/init.d/ups-monitor 3) /etc/init.d/ups-monitor will tell the UPS to cut power within ~90 seconds 4) /etc/init.d/halt will tell the computer to poweroff completely 5) When power is restored, the computer does *not* turn back on, because BIOS saw the clean poweroff and thus does *not* view this as a Power Loss situation. 6) Power is restored but computer remains off. PROBLEM! If /etc/default/halt has HALT=halt, then: 0) Power goes out. UPS starts beeping. apcupsd kicks into gear! 1) /etc/init.d/halt will set INIT_HALT to HALT 2) /etc/init.d/halt will *not* call /etc/init.d/ups-monitor 3) /etc/init.d/halt will tell the computer to go into system halt (not poweroff) 4) Computer remains on, and UPS continues to drain. 5) If the UPS eventually runs out of juice and dies, so that computer loses power, then when power is later restored, the computer will turn back on. 6) However, if power is restored before UPS drains out, then the computer remains in system halt state forever. PROBLEM! SUMMARY THUS FAR: No matter what you put in /etc/default/halt, you will have a PROBLEM! Possible solutions: 1) The /etc/init.d/halt script could be changed (note that it is part of 'initscripts', not part of 'apcupsd', and fortunately is marked as a conffile, so a sysadmin can modify it and won't quietly lose those changes during an upgrade) to set INIT_HALT to HALT after calling ups-monitor: if [ $INIT_HALT = POWEROFF ] [ -x /etc/init.d/ups-monitor ] then /etc/init.d/ups-monitor poweroff INIT_HALT=HALT THIS LINE WAS ADDED fi 2) An alternate change is to have it *always* call ups-monitor, i.e., remove the test for INIT_HALT being POWEROFF, but then make sure /etc/default/halt has HALT=halt: Old: if [ $INIT_HALT = POWEROFF ] [ -x /etc/init.d/ups-monitor ] New: if [ -x /etc/init.d/ups-monitor ] 3) Ultimately, though, the /etc/init.d/halt script should have a way to communicate with /etc/init.d/ups-monitor to find out the situation. In other words, ups-monitor should return a value indicating whether the UPS will cut power, whether power was already restored, etc., and perhaps indicating what should happen next: merely halt the system, also do a poweroff, or in fact do a restart? See Debian bugs #55123 and #293401 for related discussions in regards to other UPS packages with similar issues. It seems the initscripts maintainers don't want to make changes unless *all* UPS package developers join in the discussion. The goal seems to be to find a common solution in initscripts that will work with all UPS packages. Alexander Perlis, Department of Mathematics, The University of Arizona -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#377129: rkhunter should not depend on mailx
Package: rkhunter Version: 1.2.7 rkhunter's dependence on mailx prevents us from installing it. At our site, we have replacement command-line MUAs that conflict with the mailx package, and thus we cannot install anything that depends on mailx. There is a long complicated history to the command-line programs that go under the names mail, Mail, mailx, and they do not all behave the same; in particular, modern versions (e.g., nail) may even ask for a password when sending a message (so that a copy of the message can be placed in the sent-mail folder on a remote IMAP server), and this interaction breaks scripts that invoke these MUAs to send an outgoing message. Programs should invoke an MTA (or MSA), not an MUA. For example, rkhunter could depend on mail-transport-agent instead of depending on mailx, and then call sendmail (which might actually be provided by postfix or exim or a nullmailer) to send the message. To do this, the scripting difference is essentially this: /usr/bin/mail -s This is a subject [EMAIL PROTECTED] EOT And this is the body. EOT /usr/sbin/sendmail [EMAIL PROTECTED] EOT Subject: This is a subject And this is the body. EOT __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#377131: Dependence on mailx prevents installation
Package: mysql-server Version: 4.0.24-10 The dependence on mailx prevents us from installing it. At our site, we have replacement command-line MUAs that conflict with the mailx package, and thus we cannot install anything that depends on mailx. There is a long complicated history to the command-line programs that go under the names mail, Mail, mailx, and they do not all behave the same; in particular, modern versions (e.g., nail) may even ask for a password when sending a message (so that a copy of the message can be placed in the sent-mail folder on a remote IMAP server), and this interaction breaks scripts/programs that invoke these MUAs to send an outgoing message. Programs should invoke an MTA (or MSA), not an MUA. For example, you could depend on mail-transport-agent instead of depending on mailx, and then call sendmail (which might actually be provided by postfix or exim or a nullmailer) to send the message. To do this, the scripting difference is essentially this: /usr/bin/mail -s This is a subject [EMAIL PROTECTED] EOT And this is the body. EOT /usr/sbin/sendmail [EMAIL PROTECTED] EOT Subject: This is a subject And this is the body. EOT __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#377132: Dependence on mailx prevents installation
Package: mysql-server-4.1 Version: 4.1.11a-4 The dependence on mailx prevents us from installing it. At our site, we have replacement command-line MUAs that conflict with the mailx package, and thus we cannot install anything that depends on mailx. There is a long complicated history to the command-line programs that go under the names mail, Mail, mailx, and they do not all behave the same; in particular, modern versions (e.g., nail) may even ask for a password when sending a message (so that a copy of the message can be placed in the sent-mail folder on a remote IMAP server), and this interaction breaks scripts/programs that invoke these MUAs to send an outgoing message. Programs should invoke an MTA (or MSA), not an MUA. For example, you could depend on mail-transport-agent instead of depending on mailx, and then call sendmail (which might actually be provided by postfix or exim or a nullmailer) to send the message. To do this, the scripting difference is essentially this: /usr/bin/mail -s This is a subject [EMAIL PROTECTED] EOT And this is the body. EOT /usr/sbin/sendmail [EMAIL PROTECTED] EOT Subject: This is a subject And this is the body. EOT __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#312556: debian-installer partition bugs
Package: debian-installer Severity: grave This concerns a bug in the partition portion of the debian-installer for Debian GNU/Linux 3.1r0. At the bottom of this report are also two feature requests. 1) I start with a single 80 GB hard disk. 2) Clear the partition table. 3) Create a couple 20 GB partitions marked as RAID volumes. 4) Run Configure software RAID to tie the partitions into a RAID device (I happened to pick RAID 0 but I don't think it matters). 5) Now select the master hda hard disk and hit return to clear out the partition table. 6) The RAID0 device still exists, even though its underlying partitions are gone. 7) In particular, one can now partition hda in a usual non-raid way (just swap and a large root partition), yet the installer thinks md0 exists, and continuing the installation leads to a sequence of error messages. (Whether there will be data loss, I don't know. It seems if something tries to write to md0, it will end up writing into some random area of the now-root partition on hda, and this will lead to random data loss.) 8) Attempting to delete the md0 device isn't so easy. First off, it isn't clear that one needs to use Configure software RAID to get rid of it. But trying Configure software RAID leads to an error message that the partition table has changed and one should reboot before continuing. Thank you. Alexander Perlis __ Discover Yahoo! Have fun online with music videos, cool games, IM and more. Check it out! http://discover.yahoo.com/online.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#312558: debian-installer partition legend
Package: debian-installer Severity: wishlist Here are two feature requests for the partition portion of the debian-installer in Debian GNU/Linux 3.1r0. 1) In creating a partition, if one simply puts in a number, e.g., 20, it will create a 20 MB partition, not 20 GB. With today's hard drive sizes, defaulting to GB would make more sense. In fact, to clarify what will happen, the Hint on that screen could be rewritten to avoid confusion, e.g.: The maximum size you can use is 82.3 GB. Specify the desired size using these examples as guides: 20.5 GB (other available suffixes: MB, KB) 20.5(same as 20.5 GB) 30% (use 30% of the maximum size) max (same as 100%) New partition size: 82.3 GB_ 2) Back on the main partition screen, it is unclear what the various little icons mean. Among other things, I've seen a solid smily face, a hollow smily face, a lightning bolt... Can a Legend be added to that screen? Thank you. Alexander Perlis __ Discover Yahoo! Stay in touch with email, IM, photo sharing and more. Check it out! http://discover.yahoo.com/stayintouch.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
