[K12OSN] Gnome-panels missing on clients

[Lars Schade]

Am Samstag, den 05.03.2011, 20:11 -0500 schrieb Jeff Siddall:
> On 03/05/2011 10:15 AM, Lars Schade wrote:
> > Jeff,
> > 
> > thanks for the info. I would like to give the ZBOX another try since
> > only a detail seems to be missing.
> > 
> > I was looking for the Xorg.0.log file but could not find it. Just to be
> > sure, we are talking about the log of the xserver running on the TC?
> > Where do I find this file? When I log into the TC I always see the file
> > system and log files of the LTSP-server. How do I access the "inside" of
> > the TC?
> 
> To find out what is happening on the client you need to get the
> Xorg.whatever.log (note that "whatever" was in my case a "1") on the
> client.  There are a few ways to do this.  I did it by setting up sshd
> in the chroot so I could ssh to any client.  For that you need to
> install and enable the sshd stuff as well as set a root password in the
> chroot.  Other alternatives are to look at the file locally by setting
> something like:
> 
>     SCREEN_02=shell
> 
> in your lts.conf and then using CTRL-ALT-F2 _on the client_ to get to
> the shell, then do your normal CLI stuff after that.

Tried that with partial success. I could not get a proper login prompt
for some reason. CTRL-ALT-F2 got me to a shell which did not accept
keyboard input properly. And timed out back to a login prompt where I
could not enter letters in a sensible fashion. I used my notebook via
pxe as a client (not graphics issues there, everything runs smooth) and
got the same strange behavior at the CTRL-ALT-F2 shell.

So I decided to rebuild the client with Fedora-12 since that worked for
Jeff, i.e. ltsp-build-client --release 12. That did the job as far as
the CTRL-ALT-F2 shell is concerned - mostly. For some reason CTRL-ALT-F2
switches me right away to a root shell without prompting for a username
and password. Why is that, seems like a security issue?

> Another way is to use localapps to run something like:
> 
> ltsp-localapps xterm
> 
> on the client, which should bring up an xterm _from the client_ _on the
> client_.
> 
> > And I have another basic question: Do the xservers on the LTSP-server
> > and the client have to be identical? I guess not, but some sort
> > compatibility should be ensured, I suppose? And how about the
> > compatibility of the xserver and its drivers: Does it make sense to try
> > the xorg-x11-drv-intel from f12 or f14 with the xserver from f13, or is
> > that naive and futile?
> 
> The xservers don't have to match.  In my case I have a F12 chroot with
> an F13 server and entirely different hardware in both and it works fine.
>  If there is some major protocol change then you might have some
> problems but that has never been an issue for me and I doubt the xorg
> guys would let that happen anyway.
> 
> I would never try to mix an xorg driver from one distribution with a
> server from another.  That will almost certainly not work.  I am just
> using the latest stuff in the standard repos.  If you want to be really
> bleeding edge try enabling rawhide and upgrading it that way.  However,
> the fact that my F12 standard xorg stuff works with the NM10 chipset
> says to me that something else is wrong.  Are you sure
> xorg-x11-drv-intel is installed in the chroot and not just on the server?
> 

But at least I was able to take a look at the Xorg.1.log and other
things on the client (the panel issue is just as previously with f13):

kernel-2.6.32.26-175.fc12.i686
xorg-x11-drv-intel-2.9.1-1.fc12.i686

The Xorg.1.log file is attached, it looks very similar to what Jeff
posted, here are some pieces from my file:

...

(--) PCI:*(0:0:2:0) 8086:a001:8086:a001 Intel Corporation Pineview
Integrated Gr
aphics Controller rev 2, Mem @ 0xfe880000/524288, 0xd0000000/268435456,
0xfe9000
00/1048576, I/O @ 0x0000dc00/8, BIOS @ 0x????????/131072
(--) PCI: (0:0:2:1) 8086:a002:8086:a001 Intel Corporation Pineview
Integrated Gr
aphics Controller rev 2, Mem @ 0xfe780000/524288, BIOS @
0x????????/65536

...

(==) Matched intel for the autoconfigured driver
(==) Assigned the driver to the xf86ConfigLayout
(II) LoadModule: "intel"
(II) Loading /usr/lib/xorg/modules/drivers/intel_drv.so
(II) Module intel: vendor="X.Org Foundation"
	compiled for 1.7.0, module version = 2.9.1
	Module class: X.Org Video Driver
	ABI class: X.Org Video Driver, version 6.0
(II) intel: Driver for Intel Integrated Graphics Chipsets: i810,
	i810-dc100, i810e, i815, i830M, 845G, 852GM/855GM, 865G, 915G,
	E7221 (i915), 915GM, 945G, 945GM, 945GME, Pineview GM, Pineview G,
	965G, G35, 965Q, 946GZ, 965GM, 965GME/GLE, G33, Q35, Q33, GM45,
	4 Series, G45/G43, Q45/Q43, G41, B43, Clarkdale, Arrandale
(II) Primary Device is: PCI 00 at 00:02:0

...

(II) intel(0): Integrated Graphics Chipset: Intel(R) Pineview G
(--) intel(0): Chipset: "Pineview G"
(II) intel(0): Output LVDS1 has no monitor section
(II) intel(0): Output VGA1 has no monitor section

... (here comes probing of the monitor)

(II) intel(0): Output LVDS1 connected
(II) intel(0): Output VGA1 connected
(II) intel(0): Using spanning desktop for initial modes
(II) intel(0): Output LVDS1 using initial mode 1024x768 +0+0
(II) intel(0): Output VGA1 using initial mode 1280x1024 +1024+0

... (here comes info I cannot make sense of:)

(II) intel(0): Setting screen physical size to 609 x 270
(II) intel(0): Allocate new frame buffer 2304x1024 stride 4096

... (and more and more probing info????)

Is there info in the log file that points to a problem and thus to a
solution? The complete log is attached.

If someone has ideas how to further diagnose I would appreciate.
Otherwise I may have to give up on this machine...

- Lars

> Jeff
> 
> _______________________________________________
> K12OSN mailing list
> K12OSN at redhat.com
> https://www.redhat.com/mailman/listinfo/k12osn
> For more info see <http://www.k12os.org>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Xorg.1.log.bz2
Type: application/x-bzip
Size: 6321 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/k12osn/attachments/20110306/aecf053a/attachment.bin>