Fraser Campbell wrote: > Loading the second floppy, some dots or a spinning cursor would be useful here > just to show meaningful progress. I agree, though it will take some shell magic, since all I have is POSIX shell, and the following command: zcat floppy/initrd.gz > mnt/tmp-initrd To get a spinner, it would probably have to fork off a program that just spins, and then kill it when done. I'll get to it eventually. > In general flipping back and forth between my shell on tty2 and the installer > on tty1 did not work well. I had to press enter to get the screen to redraw > (hoping at the same time that I wasn't making a damaging choice). This is a known bug in bogl-bterm (ctrl-l works). > When "detecting network hardware and installing modules for it" I do not > consistently get warned that not all the modules are available. For example > my machine had a pcnet32 card and an 8139too, it loads the 8139too but > doesn't warn that the pcnet32 is unavailable. I did see the warning on one > of many runs through, just do not get the warnings consistently. I'd appreciate more information about this. Either discover is not always noticing your pcnet32, or there is a logic error causing it to fail to display a note when it does find the card. Given the intermittancy, I'd bet on discover. Note that the pcnet32 is not supported by the 2 floppy set, you have to load the net drivers floppy to get its driver. What you could do is boot up and repeatedly run discover on the seconf tty, and see if it consitently finds your pcnet32. The command line it uses to run discover is: discover --format="%m:%V %M\n" \ --disable-all --enable=pci,ide,scsi,pcmcia scsi cdrom ethernet If discover is consistently finding the card, a copy of the syslog would be a handy thing to have. You should already have the syslog from your successful install in /var/lib/messages/installer.log on the final system. (I think that's the name). > After exiting the detecting network hardware section I am *always* placed back > in the language selection menu. Known bug, the language chooser was broken and so it kept wanting to re-run it. It should be fixed in the next daily build. > When first trying to partition harddrive nothing seemed to be happening, > pressing enter moved the screen up a line but didn't wake anything up. After > 2-3 minutes I pressed CTRL-C. I had done the full hardware detection prior > to trying this and had confirmed that the disk was detected ... at least > /proc/ide/hda/ existed. After cancelling the first try I immediately went > back in to partitioning my disk was listed as available. I have filed a bug report on this. The syslog would probably be useful here too. It would be good to know if you can reproduce it. It would also be good if you could try a daily build with hw-detect 0.46 on it, this has some fixes for IDE drives, though it might not apply to yours. > I really liked the portion of the partitioning module, where it lists > partitions and you get to choose mount points and fs types, very intuitive. > One improvement would be to not offer a given mount point (let's say /var) if > it has already been selected for a previous partition. Wishlist bug filed. > Unfortunately I had some other problems with partitioning. One problem I had > was that once I committed to the formatting/mounting scheme there were no > progress bars (at least that I could see). We have progress bars for autopartkit as of this week, the manual partitioner is a lower priority. I'm sure it'll get them eventually.. > Another problem was that at first I was getting no progress when formatting, > I left it for a few minutes without seeing HDD activity and realized things > must be hung. On tty2 I could see a mkreiserfs process running but > apparently not getting to far. I was trying to use a mix of ext3 and > reiserfs (ext3 for /, /boot and /usr ... reiserfs for /var and /tmp). It was > always the mkreiserfs that was stuck so I eliminated the reiser filesystems > and then things completed fine. This is a known bug. #213314 There is a design for a fix, not yet implemented. > Progress bar does not move when downloading packages file. Again my screen > goes blank, on tty2 I can see that debootstrap is running though so I wait > ... eventually a progress bar does reappear. Package retrieval froze at > mawk, no progress seemed to be happening, I killed a few wget and debootstrap > processes until I got back to the main menu and then restarted base system > install. Second try got past mawk without incident, odd but didn't feel like > debugging that one too much. Packages installed, didn't have much trouble > then until the bootloader. Hmm, what kind of network uplink do you have? Packages file should download quite quickly, and it's hard to segment it to give progress. I am on dialup and it still downloads quickly. The hang you experienced also rather points to a network problem. > I used the grub boot loader, upon reboot it didn't boot, kernel could not be > found. Problem was that the root argument in each kernel stanza was > incorrect; "root(hd0,1)" instead of "root(hd0,0)". Perhaps grub-installer > is easily confused when /boot is not part of / ... there was no option to set > these parameters (though they should be detectable). This is a known bug, #215324. I've added your analysis to the bug log, and raised the bug to important. Thanks for your report, it was very useful, and great to hear that the two floppy install actually works for someone again! -- see shy jo
Attachment:
signature.asc
Description: Digital signature