Hi Scott,

Sadly, I also tried this and it didn't make any change. Seems, however, that this is a workaround for systems that have been working at any time but get hung, in my case, I wasn't able to start a X session in all this time along. Something else must be missing, but I'm unable to find out what.

El 29/05/2014 21:56, Nishimura, Scott L (ESS) escribió:

I have experienced problems in the past with stuff in /tmp/SUNWut.

Once I did a "find" for the particular MAC and deleted all instances [6 files and 1 entry in a file that said "do not edit"]. Certain TCs would show a black screen and no boot. Maybe you're experiencing something similar. I thought this was in SRSS 3.x and the problem went away with 4.x.

*From:*sunray-users-boun...@filibeto.org [mailto:sunray-users-boun...@filibeto.org] *On Behalf Of *Nicolás
*Sent:* Thursday, May 29, 2014 1:47 PM
*To:* sunray-users@filibeto.org
*Subject:* EXT :Re: [SunRay-Users] Sun-Ray client stucked at '26D' and not starting the graphic environment on RHEL6 64bits

Hi Christian and thanks for replying,

Let's see:

1) I can ping the client from the server side, also as I said it's under the same VLAN and any firewall (iptables) is disabled, so I'd discard a network problem.
2) Running the 'utwho' command produces this result:

[root@srs ~]# /opt/SUNWut/bin/utwho -ca
 11.0 pseudo.00144f574400           root     192.168.1.203 P8.00144f574400

In the /var/opt/SUNWut/displays directory there's just one file (seems logic, as I'm just testing with one client):

[root@srs ~]# cat /var/opt/SUNWut/displays/11
SESSION=srs.mysite.es:7007:5362229792637346934
TOKEN=pseudo.00144f574400
SESSION_TYPE=default
TOKEN_SET=pseudo.00144f574400
CALLBACK_COOKIE=5843968652673758964
DISPLAY=11
INSERT_TOKEN=pseudo.00144f574400

There's no 'Xnewt' process running at any time. I know this has to be launched from a client session, so I cannot test it from the server side. However, regarding to this, I've noticed something weird. In the '/tmp/SUNWut/config/xconfig/Xservers' file I see this line:

:11 SunRay local /usr/X11R6/bin/Xnewt :11

However, this path doesn't exist on my machine. The Xnewt file is located at /opt/SUNWut/lib/Xnewt. I tried to add a symbolic link to this path but it doesn't seem to help. Could this be related?

3) There's no log file under /var/log/gdm, it's an empty directory.

4) No way there's no space at /tmp or some kind of cron that would erase files there. I've more than 10GB of free space on that partition and it's a 'clean' distro, so no crons of that kind are being run.

5) Regarding to your other mail: The server is a HP ProLiant DL360. However, I'm now trying to do the same running the server on a VMWare virtual machine and the same happens. And no, there's no monitor connected to the server side (we use iLO to manage it).

Thanks for any help, this is starting to be quite frustrating...

Regards,

Nicolás

El 29/05/2014 20:55, Christian Montero Hernández escribió:

    Did you check the options on this link?

    http://www.filibeto.org/pipermail/sunray-users/2011-January/017008.html

    Regards,

    Christian Montero H.

    On Thursday, May 29, 2014 6:42 AM, Nicolás <nico...@devels.es>
    <mailto:nico...@devels.es> wrote:

        Unfortunately, even installing the OL 6.3 version, I get
        exactly the same result. I was wondering this could be a
        hardware problem, but I also tried another Sun Ray 2 and it
        produces the same behavior. So I'm really befuddled now.

        I tried following the guide to debug a kiosk session, but no
        additional logging is being generated so I assume the kiosk
        session isn't even being started.

        Any other idea? Something I could be missing?

        Thanks.


        El 28/05/2014 19:40, Nicolás escribió:

        Thanks for the answer, Lucas.

        I'll make a try tomorrow with RHEL 6.3 and I'll provide some
        feedback afterwards.

        Regards,

        Nicolás

        El 28/05/2014 19:12, Lucas Migueles escribió:

            Nicolás:

            RHEL 6.5 is not even supported on SRS 5.4.2. Maybe that's
            the problem. I would try the same but with RHEL 6.3.

            Here is the platform support list for you version of SRS:
            
http://docs.oracle.com/cd/E35310_01/E35308/html/SRS-5.4-Whats-New.html#Whats-New-Platforms

            Hope that helps.

            Lucas

            2014-05-28 14:03 GMT-03:00 Nicolás <nico...@devels.es
            <mailto:nico...@devels.es>>:

            Hi people,

            I'm writing this mail as my last resource because
            currently I'm in a deadlock, so I hope someone could shed
            some light on this problem. I'm trying to run SRS v.
            5.4.0.0.44 together with SROS v. 11.1.3.0.26 on a RHEL6
            64b distribution. I've followed these steps:

            * Removed the ::1 entry from /etc/hosts, and added a line
            with the actual host with the corresponding static IP of
            the server.
            * Disabled SELinux and iptables (plus I removed it from
            the init via chkconfig iptables off)
            * Downloaded the public Oracle repo from
            http://public-yum.oracle.com/public-yum-ol6.repo, disabled
            all repositories except ol6_u5_base, ol6_UEK_base and
            ol6_gdm_multiseat. I also run 'yum update' after the
            changes and installed any proposed package.

            Before installing SRS & SROS, I run 'utpkgcheck' and
            'utpkgcheck -i', any package is installed successfully so
            then I could see:

            [root@srs ~]# /opt/SUNWut/sbin/utpkgcheck
            Checking required dependent packages
            All dependent packages are installed

            At this point I installed both the SROS and SRS packages,
            this latter via the 'utsetup' command. Everything goes
            smoothly, no errors. I also configured the kiosk mode as
            this is my aim. As proposed, I rebooted.

            Once restarted, I run these 3 commands:

            /opt/SUNWut/sbin/utadm -L on
            /opt/SUNWut/sbin/utstart
            /etc/init.d/utsyscfg start

            No errors shown in the '/var/opt/SUNWut/log/messages'
            file. Well, and now comes the problem: I turn on the
            Sun-Ray client, it downloads the latest firmware from the
            server, and gets stuck at the '26D' screen. No matter what
            I do, really, I can't get through that step. I connected
            to the Web Administration and chose the kiosk mode, also
            tried with mobile sessions. In this latter case, I'm asked
            for the user and password, once entered, the same happens.

            I'm aware this is related to the fact it can't init a
            graphic session, but there's no error in the log, so I
            can't find out what else to do to know what's going wrong.
            All I can see in the log is this:

            May 28 14:37:00 srs xinetd[1789]: START: tftp pid=2905
            from=10.107.19.56
            May 28 14:37:02 srs utauthd: Worker7 NOTICE: whichServer
            pseudo.00144f574400:
            May 28 14:37:02 srs utauthd: Worker7 NOTICE: CLAIMED by
            StartSession.m5 NAME: pseudo.00144f574400 PARAMETERS:
            {stealProtected=true, terminalIPA=10.107.19.56,
            type=pseudo,
            fw=11.1.3.0_26_2013.10.28.09.53,Boot:MfgPkg_4.15_2006.07.20.16.57;
            2006.07.20-17:04:56-PDT, state=disconnected, cause=insert,
            doamgh=true, barrierLevel=451, lockaction=disconnect,
            rawId=00144f574400, terminalCID=IEEE802.00144f574400,
            MTU=1500, tokenSeq=1, firstServer=0a6b130f,
            namespace=IEEE802, keyTypes=dsa-sha1-x1,dsa-sha1,
            ddcconfig=1,
            clientRand=2hIW/4MZB5u9pK8eb09E5Atg5zRPbLE1BVS4hOPinwm,
            id=00144f574400, realIP=0a6b1338,
            startRes=1280x1024:1280x1024, useReal=true, event=insert,
            sn=00144f574400, rawType=pseudo, hw=SunRayP8, initState=1,
            usersession=false, _=1}
            May 28 14:37:02 srs utauthd: Worker7 NOTICE: CONNECT
            IEEE802.00144f574400, pseudo.00144f574400, all connections
            allowed
            May 28 14:37:02 srs utauthd: Worker7 NOTICE: MTU = 1500
            May 28 14:37:02 srs utauthd: Worker7 NOTICE:
            SessionManager.getSessionManager: Initiate callback to
            utsessiond at localhost:7007
            May 28 14:37:02 srs utauthd: Worker7 NOTICE:
            SessionManager.initiateCallback localhost:7010 established
            communication
            May 28 14:37:02 srs utdtsession: Add
            (11,pseudo.00144f574400,normal)

            And that's all. The DNS records are configured properly,
            as can be seen in the 'utquery' output (being 10.107.19.15
            the SRS server's IP address):

            [root@srs ~]# /opt/SUNWut/sbin/utquery -d 10.107.19.56
            terminalID=00144f574400
                terminalIPA=10.107.19.56
                model=SunRayP8
                currentAuth=10.107.19.15
            currentFW=11.1.3.0_26_2013.10.28.09.53
                currentBarrier=451
                currentBarrierLevel=451
                currentMTU=1500
                currentLease=17755
                Subnet=255.255.255.0
                Router=10.107.19.1
                LeaseTim=18000
                DHCPServer=10.1.3.194
                AuthSrvr=10.107.19.15
                FwSrvr=10.107.19.15
                tftpSrvr=10.107.19.15
                FWservType=FWSrvr
                speed=100F
            parmsVersion=11.1.3.0_26_2013.10.28.09.53
                parmsBarrier=451
                configMTU=1500
                AltAuth=10.107.19.15
            dnsList=10.1.3.130,10.1.5.130,10.1.4.130
                dname=dns.myplace.es <http://dns.myplace.es/>
                confEnabled=0
                stopqon=0
                bandwidth=7500000
                cmdcachesize=0

            I doubt this is a network related problem, as both the
            server and the client are under the same VLAN. it just
            seems to not start the X session, but I can't diagnoze
            why. I also tried the 'utcapture' utility and no packets
            are being lost or dropped.

            I neither think this is caused by the java version, as I'm
            using the package's 1.6 jre version:

            [root@srs ~]# /opt/jre1.6.0_41/bin/java -version
            java version "1.6.0_41"
            Java(TM) SE Runtime Environment (build 1.6.0_41-b02)
            Java HotSpot(TM) Server VM (build 20.14-b01, mixed mode)

            There's no 'gdm' process when the clients try to establish
            the session, nor 'Xnewt'.

            I'd be really grateful if someone could provide some
            additional tests or ideas on how to debug this, as I've
            been really stucked with this for 5 days and don't know
            what else to try. If I missed any information just ask for it.

            Thanks so much in advance.

            Nicolas
            _______________________________________________
            SunRay-Users mailing list
            SunRay-Users@filibeto.org <mailto:SunRay-Users@filibeto.org>
            http://www.filibeto.org/mailman/listinfo/sunray-users



            _______________________________________________

            SunRay-Users mailing list

            SunRay-Users@filibeto.org  <mailto:SunRay-Users@filibeto.org>

            http://www.filibeto.org/mailman/listinfo/sunray-users




        _______________________________________________

        SunRay-Users mailing list

        SunRay-Users@filibeto.org  <mailto:SunRay-Users@filibeto.org>

        http://www.filibeto.org/mailman/listinfo/sunray-users

        _______________________________________________
        SunRay-Users mailing list
        SunRay-Users@filibeto.org <mailto:SunRay-Users@filibeto.org>
        http://www.filibeto.org/mailman/listinfo/sunray-users




    _______________________________________________

    SunRay-Users mailing list

    SunRay-Users@filibeto.org  <mailto:SunRay-Users@filibeto.org>

    http://www.filibeto.org/mailman/listinfo/sunray-users



_______________________________________________
SunRay-Users mailing list
SunRay-Users@filibeto.org
http://www.filibeto.org/mailman/listinfo/sunray-users

_______________________________________________
SunRay-Users mailing list
SunRay-Users@filibeto.org
http://www.filibeto.org/mailman/listinfo/sunray-users

Reply via email to