1. Connect to xServe and see login dialog. All is well so far.
2. Login as Administrator. Screen becomes garbled (file too large to
upload --- send eMail to conr2286@uidaho.edu and I'll mail it).
Problem does not occur if you attach a "real" monitor to the xServe and
login/logout before running 2.0b4. You can even remove the "real"
monitor and 2.0b4 will continue to operate correctly. But reboot the
xServe and you're back to Step 1.
Client is OS/X 10.4.4 on dual G5 2.0 gHz.
xServe Profile follows:
2/9/06 7:33:48 PM: Apple System Profiler report requested, waiting for
response…
2/9/06 7:33:50 PM: Hardware:
Hardware Overview:
Machine Name: Xserve
Machine Model: RackMac1,1
CPU Type: PowerPC G4 (2.1)
Number Of CPUs: 1
CPU Speed: 1 GHz
L2 Cache (per CPU): 256 KB
L3 Cache (per CPU): 2 MB
Memory: 1.25 GB
Bus Speed: 133 MHz
Boot ROM Version: 4.4.4f1
Network:
Built-in Ethernet:
Type: Ethernet
Hardware: Ethernet
BSD Device Name: en0
Has IP Assigned: Yes
Software:
System Software Overview:
System Version: Mac OS X Server 10.4.4 (8G32)
Kernel Version: Darwin 8.4.0
ATA:
ATA Bus:
LG CD-ROM CRN-8245B:
Model: LG CD-ROM CRN-8245B
Revision: AHT9
Serial Number:
Detachable Drive: No
Protocol: ATAPI
Unit Number: 0
Socket Type: Internal
ATA Bus:
ST3160023A:
Capacity: 149.05 GB
Model: ST3160023A
Revision: 8.01
Serial Number: 5JS692GJ
Removable Media: No
Detachable Drive: No
BSD Name: disk0
Protocol: ATA
Unit Number: 0
Socket Type: Media Bay
Bay Name: "Bay 1"
OS9 Drivers: No
S.M.A.R.T. status: Verified
ATA Bus:
ST3160023A:
Capacity: 149.05 GB
Model: ST3160023A
Revision: 8.01
Serial Number: 4JS0F9HZ
Removable Media: No
Detachable Drive: No
BSD Name: disk1
Protocol: ATA
Unit Number: 0
Socket Type: Media Bay
Bay Name: "Bay 2"
OS9 Drivers: No
S.M.A.R.T. status: Verified
Diagnostics:
Power On Self-Test:
Last Run: 2/9/06 7:18 PM
Result: Passed
FireWire:
FireWire Bus:
Maximum Speed: Up to 400 Mb/sec
Unknown Device:
Manufacturer: Unknown
Model: Unknown Device
Maximum Speed: Up to 400 Mb/sec
Connection Speed: Up to 400 Mb/sec
Graphics/Displays:
ATY,Rage128:
Chipset Model: ATY,Rage128
Type: Display
Bus: PCI
Slot: SLOT-B
VRAM (Total): 16 MB
Vendor: ATI (0x1002)
Device ID: 0x5245
Revision ID: 0x0000
ROM Revision: 113-57405-108
Displays:
Display:
Memory:
DIMM0/J21:
Size: 256 MB
Type: DDR SDRAM
Speed: PC2100U-25330
Status: OK
DIMM1/J22:
Size: 512 MB
Type: DDR SDRAM
Speed: PC2100U-25330
Status: OK
DIMM2/J23:
Size: 512 MB
Type: DDR SDRAM
Speed: PC2100U-25330
Status: OK
DIMM3/J20:
Size: Empty
Type: Empty
Speed: Empty
Status: Empty
PCI Cards:
pci106b,9:
Type: Ethernet Controller
Bus: PCI
Slot: SLOT-1
Vendor ID: 0x14e4
Device ID: 0x16a7
Subsystem Vendor ID: 0x106b
Subsystem ID: 0x0009
Revision ID: 0x0002
ATY,Rage128:
Name: ATY,Rage128o
Type: display
Bus: PCI
Slot: SLOT-B
Vendor ID: 0x1002
Device ID: 0x5245
Subsystem Vendor ID: 0xb530
Subsystem ID: 0x0408
Revision ID: 0x0000
USB:
USB Bus:
Host Controller Location: Built In USB
Host Controller Driver: AppleUSBOHCI
PCI Device ID: 0x0019
PCI Revision ID: 0x0001
PCI Vendor ID: 0x106b
Bus Number: 0x08
USB Bus:
Host Controller Location: Built In USB
Host Controller Driver: AppleUSBOHCI
PCI Device ID: 0x0019
PCI Revision ID: 0x0001
PCI Vendor ID: 0x106b
Bus Number: 0x09
Modems:
Modem Information:
Interface Type: Serial
Driver: com.apple.driver.AppleRS574Serial (v1.3.0)
2/9/06 7:33:50 PM: Apple System Profiler report received from server
Logged In: YES
user_id=1338156
No, tinkering with encodings doesn't seem to help. Nor does tinkering with
colors do anything other than bump into the known 256-color problem.
Logged In: YES
user_id=351330
The image mentioned by the original submitter can be seen at
http://www.geekspiff.com/unlinkedCrap/chickenBug1428804.png
That said, it sounds like this is a problem with the VNC server. Chicken has no
idea whether the server has a physical monitor connected or not, so if the
problem occurs when switching that, that indicates a bug in the server.
Logged In: NO
same problem here but with version 2.0b2
100% same picture after log in
I had trouble like this using ARD with a headless XServe as well. I filed it as an ARD bug, and heard back that it was due to the way virtual displays are handled. I think what is happenning is that the resolution changes, but it still thinks the resolution is what it was at the login window, and reconnecting does not adjust to the new resolution either. I had to use cscreen (and find it first) to adjust the resolution back and then it would work. You can find a link to a report of cscreen since it disappeared a couple years ago here: http://forums.macosxhints.com/showthread.php?t=59575