Bug#248047: Cobalt install
* christian mock <email@example.com> [2004-05-09 17:17]:
> It would be easier if the install required either NFS _or_ tftp.
Yes; the problem is that CoLo currently doesn't support NFS while the
Cobalt firmware doesn't support TFTP. However, NFS support for CoLo
> The initial netboot step (which brings the menu on the LCD where
> you're supposed to choose "TFTP") has a rather short timeout in that
> menu and proceeds to boot from the HD; there should be no timeout
> here, IMHO.
> The LCD could be more verbose, i.e. after "loading debian-installer"
> it could say "connect to the console now".
I will consider doing this unless we get SSH support.
> > - check how long cobo-installer takes, and maybe add a progress bar
> I thought it was rather quick -- as opposed to some situations in the
Yeah, it is pretty quick. I've put in a simple progress bar in the
> > - support installs via SSH, w/o serial console
> Definitely. And an option to set the serial baudrate (from CoLo
> onwards) to other speeds, i.e. 9600 like god intended.
d-i and colo should just support any baud rate... however, I have no
idea how to change the Cobalt to something else. Do you know?
> Misc stuff:
> There could be a problem with the tty settings -- ^U doesn't work in
> the installer, but does after the reboot in base-config.
This sounds ike a generic thing. I think I also noticed that the
window frame is broken after reboot, while it works alright before.
> The partitioning tool doesn't set the swap partition type on the swap
> partition (it works, so it's a cosmetic error).
I've seen this too recently. I've to check if this is still there.
> inittab apparently has entries for virtual terminals, which those
> INIT: Id "2" respawning too fast: disabled for 5 minutes
> INIT: Id "3" respawning too fast: disabled for 5 minutes
This should be gone now (in unstable).
> The instructions to install CoLo in your mail to debian-mips are a bit
> wrong, the right sequence is
colo is in testing now and will be installed correctly. Also, if you
do an installation from unstable, you will be able to generate an ext2
revision 0 /boot partition, and then it should just work. In fact, if
you choose the guided partitioning, it should create a proper boot
partition. (And, tomorrow evening (with tomoror's dinstall run), even
warn you if you don't have a correct boot partition.)
Do you perhaps have time to test an installation from unstable? You
can use the initrd from
(same kernel as before), and the install unstable rather than testing.
You should be able to do a 100% successful installation on the Cobalt
- if not, let me know soon so I can fix it before rc1.