Hello, first of all let me apologize for the wrong usage of the BTS by me, especially at you, Geert and Frans. Thank you very much for providing links where I learned about the correct usage, so I think this misuse won't happen again after this bug has been closed. Wasting developer's time is really the last thing I want to do. > > - With a German setup there are no umlauts in the output of console 4. > > Instead of the umlaut built by "ae" (an "a" > > with 2 dots above) the computer prints an upper case "A" folled by a > > character which looks like a filled square. > > After the installation (reboot) the umlauts worked in the console. > > Known issue, but as most of what's logged is in English, it's not > something that has high priority for us. You can always view > /var/log/syslog in an editor (the installer has nano) to work around this. > Ok, thanks for that hint. > > - I installed the desktop task on a 2.4 GB partition, which was too > > small so the installation stopped after > > downloading all packages and installing most of them. This is quite > > frustrating if you have a slow internet > > connection. It should be possible to estimate the necessary partition > > size after choosing tasks and abort or at least > > print a warning message if the available space is too small. > > Unfortunately we cannot get the information we need for that. The > installation guide has the minimal size requirements (although these have > not yet been updated for Etch). I had some ideas how it could work and wrote a little script appended as tasksize.sh. Wouldn't something like that work? Or did I miss something? The idea is to determine the task size during installation and put the size in brackets after the task name. Printing a warning if the available space is too small would be the next logical step. (if I should change or improve the script, please just tell me) > > > - Having a not big enough partition and unused diskspace directly in > > front of the partition I switched to another > > console and startet "parted" after the installation has aborted. But > > "parted" wasn't able to resize the ext3 > > partition created by the debian installer some minutes ago. Error > > Message: "Error: File System has an incompatible > > feature enabled". > > If you can identify which "feature" was blocking the resize, the parted > maintainers will probably be happy to look into this. Please file a > separate bug report against parted. Ok, I'll further investigate on this and then file the bug, thanks. > > > It would be quite handy if the parted version in the debian installer > > could handle the partition created by the > > debian installer, wouldn't it? > > So I had to go back to partitioning and choose a larger partition. > > There was no reboot necessary, which is great! > > The installer itself is also capable of resizing partitions, but as it > uses libparted as well, that could run into the same issue. I'll test this. > > > - I didn't choose a swap partition as I have 768 MB RAM. But debian > > installer printed a warning like: "You could get > > problems during installation if you don't have enough memory". This > > sounds like the debian installer would have no > > idea how much memory in my system is installed, which is definetely not > > the case and I'm quite sure you know how > > much memory D-I needs, so please only print this warning message if the > > user doesn't create a swap partition AND has > > not enough memory, as a normal user could get confused by this message. > > I guess we could check for "obviously enough memory". But no, we do not > know exactly how much memory the installer uses as that depends on the > architecture, installation method used and optional features used. > For example, the graphical installer uses significantly more memory than > the regular installer. And an installation using LVM or crypto also uses > more memory than an install that does not. > It is also dangerous to hardcode values like that as at some point you may > run over them. IMO the warning is worded neutrally enough so it is not > alarmist and as you are free to ignore it, I don't think we should change > it. swap-less installations are very uncommon, so having a check for it > and asking the user to confirm he does not want swap IMO makes sense. Ok, your arguments make sense. > > - grub did not detect my Debian Sarge installation on /dev/hdc1 > > (reiserfs). > > That is not grub, but os-prober. > Could you check if the /var/log/installer/syslog contains any indication > why this failed? > Would you be willing to debug this for us? Sure. Drive is found correctly: hdc: SAMSUNG SV1204H, ATA DISK drive Partition detection works equally well: 90linux-distro: result: /dev/discs/disc2/part1:Debian GNU/Linux (3.1):Debian:linux os-prober: debug: os detected by /usr/lib/os-probes/mounted/90linux-distro Then grubs seems to work fine, too: grub-installer: Could not find /boot/grub/menu.lst file. grub-installer: Generating /boot/grub/menu.lst grub-installer: Updating /boot/grub/menu.lst ... grub-installer: done But then I had to insert the entry in /boot/grub/menu.lst by hand anyway. I don't know where to look else. Any ideas? I could reinstall if that would help and see if I can reproduce this. > > > - grub detected my installed Windows 98 (/dev/hda1) and Windows 2000 > > (/dev/hda5) (huh, these were dark times!), but > > failed to name the Windows 98 partition correctly. > > To understand my point you first have to know the following: Windows > > 2000 installed its boot manager in the Windows 98 partition. > > I know this is not the easiest way, but it's the default, which Woody > > and Sarge created. > > No, Woody and Sarge have never set up a Windows 2000 bootloader in a > Windows 98 partition. That is something you have must done yourself, and > it is indeed what confuses the installer. I don't think we can improve > the detection of this. > Fixing it is trivial though: just edit /boot/grub/menu.lst. Sorry, my mistake. Windows 2000 and Windows XP install their bootloader (and some boot files) always into /dev/hda. You can't change that to the best of my knowledge. Windows doesn't install if /dev/hda is no FAT/NTFS partition. On /dev/hda I have Win 98 installed and os-prober named it as Windows 2000 in grub, which is really just a cosmetic problem. Should I file that as a separate Bug against os-prober with severity minor? > > But as I checked: Booting /dev/hda5 out of grub doesn't work. > > Must be because you told Windows 2000 to install its bootloader in the > Windows 98 partition. Again somewhat unusual and not something we can > easily support. Please forget about this. Everything is alright, I made a mistake with that. > > > All the following observations propably don't affect D-I but I don't > > know where to report it. So please forward it to > > the correct package or point me to the desired place. > > > > Wouldn't it be a nearly perfect guess if you assume that > > "A" should have "L" as the default language in > > Gnome if the desktop task gets installed as well? > > This should be fixed in current installations. Ok, thank you very much, I'll test that. > The remaining issues are indeed not related to the installer. Please file > separate bug reports against the respective packages if you want to > follow up on them. Ok, thanks again. > Anyway: Have fun with you Debian GNU/Linux computer system. Thank you, I sure have. It's really amazing what you are doing for a great work! Cheers Patrick
Attachment:
tasksize.sh
Description: application/shellscript
Attachment:
pgpCOiy8f_a9X.pgp
Description: PGP signature