Wrong frequency? Please help

[Franklin Weng]

Hi,


Recently I'm still trying to install debian edu to schools in Taiwan.
Today a teacher asked me about this problem.

His school bought about 40 new PCs and the teacher replaced them in the
computer classroom. However, the debian edu system which ran well in old
PCs got problem this time. Please see the two pictures:

Loading Image...

This one is the login screen, which is normal.

However, after login, the screen became

Loading Image...

It looks like new PCs got wrong frequency from old settings. However, I
have no idea where to change or to reset the X window settings.

I've asked the teacher to create a new account and tried to login with that
one. He reported back that the new account had the same problem too. I
think that it means the problem is not at settings in home directories. It
should be in the system wide configurations.

Would anyone please help us solve this problem?


Thanks,
Franklin

[Klaus Ade Johnstad]

I get "Forbidden" on those pictures.

[Franklin Weng]

Sorry. Please try again.
--
Sent from my phone

Post by Klaus Ade Johnstad
I get "Forbidden" on those pictures.
--
Klaus Ade Johnstad
Mobil:938 69 567
67E61D18B2C44F8A3DA35C6D849F9F5F 26FA477D

[Jonas Smedegaard]

Quoting Franklin Weng (2014-10-08 09:36:38)

Recently I'm still trying to install debian edu to schools in Taiwan. 

[...]

It looks like new PCs got wrong frequency from old settings.  However,
I have no idea where to change or to reset the X window settings.

I suggest to try install plain Debian on one of those machines. If that
works, compare settings (e.g. make a "diff -ruN" against /etc for each).
If that fails similarly, then hunt that issue as a regular Debian issue
rather than a DebianEdu one.

- Jonas

[Wolfgang Schweer]

Post by Jonas Smedegaard
Quoting Franklin Weng (2014-10-08 09:36:38)

Recently I'm still trying to install debian edu to schools in Taiwan. 

[...]

It looks like new PCs got wrong frequency from old settings.  However,
I have no idea where to change or to reset the X window settings.

I suggest to try install plain Debian on one of those machines. If that
works, compare settings (e.g. make a "diff -ruN" against /etc for each).
If that fails similarly, then hunt that issue as a regular Debian issue
rather than a DebianEdu one.

This might be an LTSP issue. LTSP uses some defaults that may cause the
trouble. Settings can be tweaked in /opt/ltsp/<arch>/etc/lts.conf on the
LTSP server. Information about default values and configuration details
should be available in the directory /usr/share/doc/ltsp (pdf and html
files) on the LTSP server.

Wolfgang

[Petter Reinholdtsen]

[Wolfgang Schweer]

Post by Wolfgang Schweer
This might be an LTSP issue. LTSP uses some defaults that may cause
the trouble. Settings can be tweaked in
/opt/ltsp/<arch>/etc/lts.conf on the LTSP server. Information about
default values and configuration details should be available in the
directory /usr/share/doc/ltsp (pdf and html files) on the LTSP
server.

The LTSP clients get their config either from that file or from LDAP,
in the ou=ltsp,dc=skole,dc=skolelinux,dc=no section.

Anyone remember how the X setup is generated? Looking at the
installated system, I suspect
/opt/ltsp/i386/user/share/ltsp/configure-x.sh, but am not sure.

You can try to log in on the LTSP client via SSH to check out what is
written to the logs in /var/log, to get an idea what is going on.
Perhaps some driver need to be updated, or a different driver need to
be selected?

[Wolfgang Schweer]

Post by Petter Reinholdtsen
[Wolfgang Schweer]

Post by Wolfgang Schweer
This might be an LTSP issue. LTSP uses some defaults that may cause
the trouble. Settings can be tweaked in
/opt/ltsp/<arch>/etc/lts.conf on the LTSP server. Information about
default values and configuration details should be available in the
directory /usr/share/doc/ltsp (pdf and html files) on the LTSP
server.

The LTSP clients get their config either from that file or from LDAP,
in the ou=ltsp,dc=skole,dc=skolelinux,dc=no section.

At runtime, both sources are queried and the resulting config is written
to /var/cache/ltsp/ltsp_config_env on the client. See below how to be
able to read the content.

Post by Petter Reinholdtsen
Anyone remember how the X setup is generated? Looking at the
installated system, I suspect
/opt/ltsp/i386/user/share/ltsp/configure-x.sh, but am not sure.

For diskless workstations: nothing is generated by default as nowadays
the X server configures itself and everything runs locally in this case.
For thin clients: X_COLOR_DEPTH is set to 16 by default to save
bandwidth for transfers from the server to the client.

All relevant X setting can be overwritten in both cases to match local
hardware. See LTSP manual.

Post by Petter Reinholdtsen
You can try to log in on the LTSP client via SSH to check out what is
written to the logs in /var/log, to get an idea what is going on.
Perhaps some driver need to be updated, or a different driver need to
be selected?

Or you can login at the client as root using Ctrl-Alt-F1 up to
Ctrl-Alt-F6. Both ssh and local login requires to have set a root
password in the LTSP chroot before. This can be done by executing
'ltsp-chroot passwd' on the LTSP server.

Check /var/log/Xorg.0.log on a diskless workstation and
/var/log/Xorg.7.log on a thin client for X related information and
/var/cache/ltsp/ltsp_config_env to see if your settings were fetched
correctly.

Wolfgang

[Franklin Weng]

Hi,


I collected some extra information for this problem. Please see:

.xsession-errors for a newly created account:
http://pastebin.com/5dsQpYLU

I've mentioned that we created a new account (hence running with system
default) but the lowfat client still got problems. The above one is the
.xsession-errors in the home directory.


Xorg.7.log for abnormal client:
http://pastebin.com/Y4AC0gCP

The above one is the Xorg.7.log when booting lowfat client and logged into
KDE.


Xorg.0.log for normally run kubuntu 13.04 on the same machine:
http://pastebin.com/RRyydjSY

We used Kubuntu 13.04 which was installed in the hard drive. It could run
normally, and this is the normal Xorg.0.log.

I have no idea where I should find the problem. Please help me with this.


Thanks,
Franklin

[Wolfgang Schweer]

Post by Franklin Weng
http://pastebin.com/Y4AC0gCP
http://pastebin.com/RRyydjSY
We used Kubuntu 13.04 which was installed in the hard drive. It could run
normally, and this is the normal Xorg.0.log.

According to the logs, with Kubutu the intel driver is used. On the LTSP
client it's vesa (used if X was unable to figure it out).

Try to set XSERVER=intel in lts.conf (or in LDAP) for this group of
machines.

Wolfgang

[Jonas Smedegaard]

Quoting Franklin Weng (2014-10-13 07:42:44)

We used Kubuntu 13.04 which was installed in the hard drive.  It could
run normally, and this is the normal Xorg.0.log.

I still suggest you to test with a plain Debian system. Kubuntu is less
helpful in triangulating the problem.

If problem also exist with plain Debian, then try Debian
testing/unstable, as it can be an issue with your hardware needing newer
kernel and/or Xorg.

In addition to .xsession-errors and Xorg.0.log, it is also relevant to
gather the output of "lspci" to know which graphics hardware it is: I
notice in your provided Xorg log that you use VESA driver, which may be
an indication that your hardware is too new to be recognized/supported
by the kernel+Xorg drivers.

None of of I wrote above is specific to DebianEdu - except the detail
that Debian is the _ancestor_ of DebianEdu whereas Kubuntu is more of a
cousin (it is a _different_ derivative of Debian) and therefore Debian
is a better reference platform for triangulating than Kubuntu.

Debian has a much larger community than DebianEdu - I don't say that as
a competition, but because this means you may be better off checking if
issues you experience are specific to DebianEdu or common also for
Debian and if the latter then involve yourself with the larger Debian
community in resolving the bug - and then naturally share your findings
with DebianEdu community too, to get it fixed there as well. :-)


- Jonas

[Franklin Weng]

Hi Jonas,

Post by Jonas Smedegaard
Quoting Franklin Weng (2014-10-13 07:42:44)

Post by Franklin Weng
We used Kubuntu 13.04 which was installed in the hard drive. It could
run normally, and this is the normal Xorg.0.log.

I still suggest you to test with a plain Debian system. Kubuntu is less
helpful in triangulating the problem.
If problem also exist with plain Debian, then try Debian
testing/unstable, as it can be an issue with your hardware needing newer
kernel and/or Xorg.
In addition to .xsession-errors and Xorg.0.log, it is also relevant to
gather the output of "lspci" to know which graphics hardware it is: I
notice in your provided Xorg log that you use VESA driver, which may be
an indication that your hardware is too new to be recognized/supported
by the kernel+Xorg drivers.
None of of I wrote above is specific to DebianEdu - except the detail
that Debian is the _ancestor_ of DebianEdu whereas Kubuntu is more of a
cousin (it is a _different_ derivative of Debian) and therefore Debian
is a better reference platform for triangulating than Kubuntu.
Debian has a much larger community than DebianEdu - I don't say that as
a competition, but because this means you may be better off checking if
issues you experience are specific to DebianEdu or common also for
Debian and if the latter then involve yourself with the larger Debian
community in resolving the bug - and then naturally share your findings
with DebianEdu community too, to get it fixed there as well. :-)

Thanks. I know that it will be much better to test with plain Debian
install. However the school is 100km away from where I'm now, and it's not
easy for the teacher there to test this way. All the logs I provided was
from what I told him, step by step.

Using Kubuntu was because those new machines were pre-installed with latest
ezgo, which was derived from Kubuntu, and could run without problem.




Franklin

[Franklin Weng]

Hi,

Post by Wolfgang Schweer

Post by Franklin Weng
http://pastebin.com/Y4AC0gCP
http://pastebin.com/RRyydjSY
We used Kubuntu 13.04 which was installed in the hard drive. It could

run

Post by Franklin Weng
normally, and this is the normal Xorg.0.log.

According to the logs, with Kubutu the intel driver is used. On the LTSP
client it's vesa (used if X was unable to figure it out).
Try to set XSERVER=intel in lts.conf (or in LDAP) for this group of
machines.
Wolfgang

The teacher reported that, after setting XSERVER=intel in
/opt/ltsp/i386/etc/lts.conf, the login screen was gone this time.

Xorg.7.log from client is here:
http://pastebin.com/bgFzM9pn

BTW, I have a question. Will the information of LTSP (or lowfat) clients
such as hardware, driver, MAC addr, ... etc. be stored in server side? If
yes, where?

I'll install a new main server at that school on Wednesday next week.
Before that I will try to clarify and find out where the problem is.



Thanks,
Franklin

[Petter Reinholdtsen]

[Franklin Weng]

Post by Franklin Weng
BTW, I have a question. Will the information of LTSP (or lowfat) clients
such as hardware, driver, MAC addr, ... etc. be stored in server side? If
yes, where?

Yes. It is stored in /var/lib/sitesmmary/, and a few scripts like
/usr/lib/sitesummary/hardware-model-summary are provided to create
reports from this data set. More reports are very welcome.

The data set is also used to create the Nagios and Munin server
configuration.

[Wolfgang Schweer]

Post by Franklin Weng
The teacher reported that, after setting XSERVER=intel in
/opt/ltsp/i386/etc/lts.conf, the login screen was gone this time.

Most probably the intel chipset is too new to be supported.

Post by Franklin Weng
http://pastebin.com/bgFzM9pn

If you compare the chipsets supported as reported by the intel driver
with the chipset detected by the vesa driver (HSW Mobile/Desktop) this
seems to be the case.

As there are newer kernel and xserver-xorg-video-intel packages in
wheezy backports you might get the machines working if you install
xserver-xorg-video-intel (maybe kernel, too) from wheezy-backports in
the LTSP chroot. See the manual (HowTo:general administration /
HowTo:networked clients) for details.

Wolfgang

[Franklin Weng]

Hi,

Post by Wolfgang Schweer

Post by Franklin Weng
The teacher reported that, after setting XSERVER=intel in
/opt/ltsp/i386/etc/lts.conf, the login screen was gone this time.

Most probably the intel chipset is too new to be supported.

Post by Franklin Weng
http://pastebin.com/bgFzM9pn

If you compare the chipsets supported as reported by the intel driver
with the chipset detected by the vesa driver (HSW Mobile/Desktop) this
seems to be the case.
As there are newer kernel and xserver-xorg-video-intel packages in
wheezy backports you might get the machines working if you install
xserver-xorg-video-intel (maybe kernel, too) from wheezy-backports in
the LTSP chroot. See the manual (HowTo:general administration /
HowTo:networked clients) for details.
Wolfgang

New update for this problem.

I upgraded the kernel and every packages I could upgrade from wheezy
backports. The problem is still there.

In the ldm screen it was normal. When logging in, the KDE splash screen
would be normal at the first HDD icons,
then the screen became blank, after coming back the screen was all wrong
like what I posted in the first mail.

Then, if I switch to console with ctrl-alt-F1, then back to the X window
with ctrl-alt-F7, the screen would be back to normal, but which is not
actually normal. Then I found that the resolution was wrong.

The resolution became 1440x1024. The desktop was larger than the screen
display. I need to change the resolution in systemsettings to 1280x1024,
and everything is back to normal.

When next login, the whole problem will be the same. I need to switch to
console and back and set the resolution again.

I'm wondering if this is because KDE didn't get the correct resolution.
However I have no idea how to force the resolution to 1280x1024.

In the main server, though changing to a new one (with the same spec), all
the display are normal and correct.

I'm now installing a new server in another hard drive. However I'd still
like to know if there are workarounds for this problem, like assigning a
fixed resolution from the client's system config. I couldn't find the X11
configuration in current version. Before it was just in Xorg.conf. Now I
have no any idea about how to do this.


Any help will be very appreciated.


Franklin

[Wolfgang Schweer]

Post by Franklin Weng
However I have no idea how to force the resolution to 1280x1024.

This can be set in lts.conf (or LDAP), see LTSP manual and Debian Edu
manual.

Post by Franklin Weng
I couldn't find the X11 configuration in current version. Before it
was just in Xorg.conf. Now I have no any idea about how to do this.

xorg.conf has gone since the xserver does the configuration itself.

If needed a config file can be given to the xserver. This is done for
LTSP clients on runtime if there are settings in lts.conf. Nothing is
stored persistently for the clients.

Wolfgang