Hmm, I'll try it... > Yves, > > Since you're familiar with Linux, try using Ethereal > (http://www.ethereal.com) or tcpdump (generally installed by default) > to monitor the network traffic from your Qube when it boots. You should > see it making DHCP requests when it boots if the installation went > properly. > > Cheers, > > Andreas
On Tue, Dec 30, 2003 at 04:45:06PM -0800, Nicholas Jackson wrote: > What is the way to access single-user mode from the serial terminal? Use -s switch. Just type at the PROM prompt something like Cobalt: /boot/boot.gz -s (or /boot/netbsd.gz if you are not using the boot loader). HTH, --cdi
All, Hello, I recently obtained an unmodified Cobalt Qube 2 (the one with a 250MHz CPU, 16MB RAM and a 10GB hard disk). I tried installing NetBSD 1.6.1 using the ISO image found here: ftp://ftp.netbsd.org/pub/NetBSD/arch/cobalt/restore-cd/ But after installation, the Qube rebooted and, and I got this out of the serial port: Cobalt Microserver Diagnostics - 'We serve it, you surf it' > Built Tue May 25 15:58:41 PDT 1999 > > 1.LCD Test................................PASS > 2.Controller Test.........................PASS > 5.Bank 0:.................................16M > 6.Bank 1:.................................0M > 7.Bank 2:.................................0M > 8.Bank 3:.................................0M > 9.Serial Test.............................PASS > 10.PCI Expansion Slot....................**EMPTY** > 12.IDE Test................................PASS > 13.Ethernet Test...........................PASS > 16.RTC Test................................PASS > BOOTLOADER ramcode: selected partition /dev/hda1 > Decompressing done > Executing bootloader kernel... > Decompressing -- done. ... and then nothin else. I wanted quite a while, just in case.(Continue reading)
Hi Christopher, On Fri, Jan 02, 2004 at 04:49:49PM -0500, Christopher Schultz wrote: > > Decompressing done > > Executing bootloader kernel... > > Decompressing -- done. > > ... and then nothin else. I wanted quite a while, just in case. Can you ping the box or login into it over the network after that? (Asking just in case if the kernel fails to attach to a serial port) In the context of 1.6.1 installation, would it make any difference if you type Cobalt: /boot/boot.gz nbsd=wd0a or Cobalt: /boot/nebtsd.gz at the PROM boot prompt? SY, --cdi
Dennis, >>>Decompressing done >>>Executing bootloader kernel... >>>Decompressing -- done. >> >>... and then nothin else. I wanted quite a while, just in case. > > Can you ping the box or login into it over the network after that? (Asking > just in case if the kernel fails to attach to a serial port) I didn't try to ping it. I didn't get any messages on my DHCP server's request log, so I wouldn't even know what IP to hit :( The IP address used during installation / netbooting is something like 10.0.0.24, and my network is set up for 192.168.1.xyz, so I would have had to change some routing setup on at least one router. I figured I'd try simpler approaches instead :) I did watch the bootup pretty closely and listened to the box. After it said " Decompressing -- done." there was no activity whatsoever; no HD, no nothing. My disk is pretty loud, so I would have noticed if it had booted all the way with no serial output. > In the context of 1.6.1 installation, would it make any difference if you > type > > Cobalt: /boot/boot.gz nbsd=wd0a > > or(Continue reading)
Dennis, > Can you ping the box or login into it over the network after that? (Asking > just in case if the kernel fails to attach to a serial port) Okay, I took note of the IP address used during installation (10.0.0.160) this time, and I can't ping it from the installation box once it has rebooted itself after the install. :( > In the context of 1.6.1 installation, would it make any difference if you > type > > Cobalt: /boot/boot.gz nbsd=wd0a > > or > > Cobalt: /boot/nebtsd.gz > > at the PROM boot prompt? I've attached a complete transcript of my re-install, along with the two attempts to start the machine using those two kernel commands from the PROM prompt. The second of these two commands seemed to do the trick -- see the transcript. Is there any way to make this the default kernel? Is a simply symlink the right thing to do? I couldn't find the path "/boot" anywhere...(Continue reading)
Hi all,
I've not got any further in terms of kernel debugging, but as the Qube
is/was my main server I've been setting up a second machine to do the
work and this has had an expected result: a more stable Qube. At this
point in time the Qube is still doing all the SMTP/IMAP/HTTP/SMB stuff
- it's only had the DNS and DHCP removed which weren't a huge load but
were easiest to remove without any downtime.
Previously I was getting 23 to 25 day uptimes before the system would
simply lock up and need a manual reboot, and this is the data as I'm
writing this email:
# Uptime | System
Boot up
----------------------------
+-------------------------------------------------
-> 1 83 days, 19:46:03 | NetBSD 1.6 Sat Oct 11
13:42:57 2003
2 25 days, 08:18:16 | NetBSD 1.6 Sat Sep 6
08:58:46 2003
3 24 days, 03:40:25 | NetBSD 1.6 Mon Aug 4
16:29:38 2003
4 23 days, 01:21:42 | NetBSD 1.6 Sat Jul 12
15:06:02 2003
5 8 days, 08:48:14 | NetBSD 1.6 Thu Aug 28
20:12:10 2003
6 5 days, 23:20:34 | NetBSD 1.6 Sun Oct 5
13:30:03 2003
7 3 days, 18:20:22 | NetBSD 1.6 Wed Oct 1
(Continue reading)On Fri, Jan 02, 2004 at 07:39:45PM -0500, Christopher Schultz wrote: > The second of these two commands seemed to do the trick -- see the > transcript. ...meaning it is the boot loader that fails. Please contact me off-list if you're willing to debug the problem. > Is there any way to make this the default kernel? Is a simply symlink > the right thing to do? I couldn't find the path "/boot" anywhere... It is on /dev/wd0e partition, just mount it and take a look into /boot folder. SY, --cdi
Ok, here's an update: I tried another HD and had the same problems. So it's obviously not the HD. No matter which HD, it spins up, starts reading for a second and then stops reading with teh display showing "Starting up". Ethereal didn't get any DHCP requests or othe signals. Up to now I couldn't get any output from the serial port (don't know, how? cable is attached, but where do I look for the data?). Looks like Chris Schultz has the similar problem, so should I try using the 1.6 version instead of the 1.6.1, too? Greetings, Yves
RSS Feed2 | |
|---|---|
4 | |
1 | |
6 | |
5 | |
1 | |
5 | |
14 | |
3 | |
5 | |
12 | |
10 | |
3 | |
6 | |
1 | |
1 | |
1 | |
11 | |
20 | |
2 | |
4 | |
7 | |
15 | |
2 | |
2 | |
1 | |
5 | |
4 | |
9 | |
33 | |
3 | |
15 | |
6 | |
15 | |
5 | |
12 | |
17 | |
9 | |
4 | |
11 | |
7 | |
91 | |
13 | |
4 | |
2 | |
13 | |
39 | |
12 | |
49 | |
13 | |
18 | |
31 | |
6 | |
31 | |
20 | |
91 | |
48 | |
28 | |
30 | |
34 | |
32 | |
51 | |
71 | |
45 | |
9 | |
59 | |
16 | |
57 | |
14 | |
16 | |
36 | |
63 | |
64 | |
37 | |
86 | |
46 | |
114 | |
28 | |
32 | |
25 | |
68 | |
33 | |
69 | |
55 | |
215 | |
63 | |
41 | |
36 | |
137 | |
59 | |
21 | |
55 | |
83 | |
30 | |
50 | |
42 | |
56 | |
48 | |
129 | |
76 | |
52 | |
73 | |
21 | |
35 | |
39 | |
11 | |
4 | |
20 | |
18 | |
13 | |
84 | |
11 | |
21 | |
5 | |
5 | |
22 | |
8 | |
13 | |
11 | |
22 | |
9 |
