Closed Bug 838351 Opened 12 years ago Closed 12 years ago

Get Ubuntu testers running on external graphics cards, plus audio

Categories

(Infrastructure & Operations :: RelOps: General, task)

Product:
Infrastructure & Operations
Component:
RelOps: General
Type:
task
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: dustin, Assigned: rail)

References

Details

Attachments

(9 files, 2 obsolete files)

XOrg config file used for headless nvidia gt430 @ 1600x1200
1.72 KB, text/plain
Details
screenshot.jpg
15.71 KB, image/jpeg
Details
screenshot2.jpg
22.61 KB, image/jpeg
Details
good-xvfb.txt
18.90 KB, text/plain
Details
bad-X.txt
8.36 KB, text/plain
Details
EDID data for a Dell 16:9 display
128 bytes, application/macbinary
Details
bug838351-interim.patch
26.55 KB, patch
Details | Diff | Splinter Review
bug838351-r3.patch
33.63 KB, patch
Details | Diff | Splinter Review
use .xsessionrc
3.19 KB, patch
catlee
: review+
rail
: checked-in+
Details | Diff | Splinter Review
These hosts will be running GPU tests on the external graphics cards. We need to run an X11 environment on those cards, in such a way that Firefox is rendered and GPU-accelerated, and that VNC can see the result. We may also need to set up Audio, which should be simple enough to just handle in this bug.
I spoke with :dustin on Vidyo and IRC and we went over the requirements - I *think* I know what needs to be done, and based on that I did the following: # apt-get install xserver-xorg mesa-utils xinit x11vnc x11vnc-data By default it seems to probe and use the GF108 over the onboard Matrix G200eW, I confirmed this with glxinfo (thanks :bkero) root@ix-mn-linux64-001:~# export DISPLAY=:0.0; glxinfo | grep 'direct rendering' direct rendering: Yes It's been awhile since I had to configure a bunch of XOrg stuff, but I believe the best way to invoke X+VNC without a heavy window manager is to do so directly with startx. I've added the following to /etc/rc.local: echo Starting XOrg subsystem /usr/bin/startx & echo Starting x11vnc subsystem /usr/bin/x11vnc -nopw -auth guess -display :0 -forever & I poked around the system but I didn't find 'testuser' or another FF test suite, so I put a dummy command in /root/.xinitrc to simulate FF tests: root@ix-mn-linux64-001:~# cat /root/.xinitrc xterm -e 'sleep 600' Note: I had some trouble connecting to VNC on this host, it turned out to be the OSX VNC client. I installed 'Chicken of the VNC' and everything seemed to behave properly. I'm not sure if an OSX-compatible VNC server is a requirement of this bug.
OSX's VNC is pretty badly hacked, so that's not a worry. We'll need to run Firefox as a non-root user (cltbld, which puppet will set up). Will the startup process need to change at all to accomplish that? Also, I'm a little worried about two backgrounded processes started in sequence - if x11vnc starts up before startx sets up the unix socket, will it fail? At the moment, it's not running, and trying to run manually gives: root@ix-mn-linux64-001:~# /usr/bin/x11vnc -nopw -auth guess -display :0 -forever 05/02/2013 16:41:00 x11vnc version: 0.9.12 lastmod: 2010-09-09 pid: 10345 05/02/2013 16:41:00 -auth guess: failed for display=':0' 05/02/2013 16:41:00 -auth guess: since we are root, retrying with FD_XDM=1 05/02/2013 16:41:00 -auth guess: failed for display=':0' In general, this looks great - I'll get some puppet manifests to implement this set up tomorrow.
:dustin Great; thanks for clarifying. Based on new information I've made a few tweaks to this setup: * Changed startx command in rc.local to run as non-root user, I don't think sudo via rc.local is optimal here but I am not sure of a better way to do it. sudo -H -u cltbld startx * Invoked x11vnc from .xinitrc as cltbld, this will guarantee that X is up and running before x11vnc is started. root@ix-mn-linux64-001:/home/cltbld# cat .xinitrc /usr/bin/x11vnc -nopw -auth guess -display :0 -forever & xterm * Changed allowed_users to anybody in /etc/X11/Xwrapper.config: root@ix-mn-linux64-001:~# grep allowed_users /etc/X11/Xwrapper.config allowed_users=anybody I tested this stack by starting with the 'sudo <...> startx' command above and was able to VNC into the system and open an xterm as the user cltbld.
I should also add that it appears the sound drivers work out of the box, I installed aplay temporarily to gather a list of available output devices. root@ix-mn-linux64-001:~# aplay -l **** List of PLAYBACK Hardware Devices **** card 0: NVidia [HDA NVidia], device 3: HDMI 0 [HDMI 0] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: NVidia [HDA NVidia], device 7: HDMI 0 [HDMI 0] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: NVidia [HDA NVidia], device 8: HDMI 0 [HDMI 0] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: NVidia [HDA NVidia], device 9: HDMI 0 [HDMI 0] Subdevices: 1/1 Subdevice #0: subdevice #0 I installed and subsequently removed the alsa-utils package after testing, if you want to test with aplay you'll need to install it first.
There's still some work to do here. The startup process for the headless Ubuntu systems just run Xvfb directly, and don't use any auth. We should do the same for Xorg -- these are single-user systems, so there's no need to protect access. I'll add '-nolisten tcp'. I installed Firefox and looked at about:support. It said it's running on the internal graphics. I confirmed that by using the remote console - sure enough, there's my xterm on the onboard chipset's output. Looking at /var/log/Xorg.log confirms this. As a first step, I think this needs the nvidia drivers. I installed nvidia-current and rebooted, but the next startup only added [ 63.224] (II) Module glx: vendor="NVIDIA Corporation" [ 63.224] compiled for 4.0.2, module version = 1.0.0 [ 63.224] Module class: X.Org Server Extension [ 63.224] (II) NVIDIA GLX Module 295.40 Thu Apr 5 21:57:38 PDT 2012 [ 63.900] (EE) Failed to initialize GLX extension (Compatible NVIDIA X driver not found) to the logs. The kernel module is installed: root@ix-mn-linux64-001:~# lsmod | grep nvidia nvidia 12319264 0 I ran nvidia-xconfig, which seems to just write /etc/X11/xorg.conf. The critical portion of that appears to be Section "Device" Identifier "Device0" Driver "nvidia" VendorName "NVIDIA Corporation" EndSection and I see more action in the logs, but still no love: root@ix-mn-linux64-001:~# grep -i nvidia /var/log/Xorg.0.log [ 823.453] (II) Module glx: vendor="NVIDIA Corporation" [ 823.453] (II) NVIDIA GLX Module 295.40 Thu Apr 5 21:57:38 PDT 2012 [ 823.454] (II) LoadModule: "nvidia" [ 823.454] (II) Loading /usr/lib/x86_64-linux-gnu/xorg/extra-modules/nvidia_drv.so [ 823.525] (II) Module nvidia: vendor="NVIDIA Corporation" [ 823.546] (II) NVIDIA dlloader X Driver 295.40 Thu Apr 5 21:38:35 PDT 2012 [ 823.546] (II) NVIDIA Unified Driver for all Supported NVIDIA GPUs [ 823.567] (II) NVIDIA dlloader X Driver 295.40 Thu Apr 5 21:38:35 PDT 2012 [ 823.567] (II) NVIDIA Unified Driver for all Supported NVIDIA GPUs [ 824.120] (II) UnloadModule: "nvidia" [ 824.120] (II) Unloading nvidia [ 824.485] (EE) Failed to initialize GLX extension (Compatible NVIDIA X driver not found) [ 824.494] (II) config/udev: Adding input device HDA NVidia HDMI/DP,pcm=9 (/dev/input/event4) [ 824.494] (II) config/udev: Adding input device HDA NVidia HDMI/DP,pcm=8 (/dev/input/event5) [ 824.494] (II) config/udev: Adding input device HDA NVidia HDMI/DP,pcm=7 (/dev/input/event6) [ 824.495] (II) config/udev: Adding input device HDA NVidia HDMI/DP,pcm=3 (/dev/input/event7) [ 884.058] (EE) Failed to initialize GLX extension (Compatible NVIDIA X driver not found) [ 884.067] (II) config/udev: Adding input device HDA NVidia HDMI/DP,pcm=9 (/dev/input/event4) [ 884.067] (II) config/udev: Adding input device HDA NVidia HDMI/DP,pcm=8 (/dev/input/event5) [ 884.067] (II) config/udev: Adding input device HDA NVidia HDMI/DP,pcm=7 (/dev/input/event6) [ 884.067] (II) config/udev: Adding input device HDA NVidia HDMI/DP,pcm=3 (/dev/input/event7) running glxinfo on :0 says "Xlib: extension "GLX" missing on display ":0"." I tried adding a BusId pointing to the PCI bus identifier for the external card. That removed all of the "MGA" log entries, but still no GLX. Incidentally, I'm running X as: X -nolisten tcp :0 I'll work more on this tomorrow, but any advice is appreciated!
Just to get this down: BusId "PCI:01:00:0" points Xorg at the right device. I'm not sure how best to encode that in Puppet, but I'll figure that out later. There's still more to wrestle with, but this is progress.
To fix resolution issue (seems it was just stuck @ 640x480), did the following; killed current running X server. echo "exec xterm" >> /root/.xinitrc Started X; startx Started x11vnc; x11vnc connected via vnc and ran; nvidia-settings X Server Display Configuration -> Display -> Advanced; Panning: 640x480 -> 1600x1200 Save to X Configuration File killed X The panning settings added the following to the xorg.conf ; Option "metamodes" "nvidia-auto-select @1600x1200 +0+0" which did the trick.
Just dumping stuff here in case puppet or kickstart undesirably overwrites it.. root@ix-mn-linux64-001:~# dmesg | grep -i nvidia .. [ 10.006747] NVRM: loading NVIDIA UNIX x86_64 Kernel Module 295.40 Thu Apr 5 21:37:00 PDT 2012 .. root@ix-mn-linux64-001:~# dpkg --get-selections | grep nvid | cut -d$'\t' -f 1 nvidia-common nvidia-current nvidia-current-updates nvidia-settings nvidia-settings-updates root@ix-mn-linux64-001:~# cat ~/.nvidia-settings-rc # # /root/.nvidia-settings-rc # # Configuration file for nvidia-settings - the NVIDIA X Server Settings utility # Generated on Wed Feb 6 18:33:55 2013 # # ConfigProperties: RcFileLocale = C ToolTips = Yes DisplayStatusBar = Yes SliderTextEntries = Yes IncludeDisplayNameInConfigFile = No ShowQuitDialog = Yes Timer = PowerMizer_Monitor_(GPU_0),Yes,1000 Timer = Thermal_Monitor_(GPU_0),Yes,1000 # Attributes: 0/CursorShadow=0 0/CursorShadowAlpha=64 0/CursorShadowRed=0 0/CursorShadowGreen=0 0/CursorShadowBlue=0 0/CursorShadowXOffset=4 0/CursorShadowYOffset=2 0/SyncToVBlank=0 0/LogAniso=0 0/FSAA=0 0/TextureSharpen=0 0/TextureClamping=0 0/AllowFlipping=1 0/FSAAAppControlled=1 0/LogAnisoAppControlled=1 0/OpenGLImageSettings=1 0/FSAAAppEnhanced=0 0/RedBrightness=0.000000 0/GreenBrightness=0.000000 0/BlueBrightness=0.000000 0/RedContrast=0.000000 0/GreenContrast=0.000000 0/BlueContrast=0.000000 0/RedGamma=1.000000 0/GreenGamma=1.000000 0/BlueGamma=1.000000 0/DigitalVibrance[DFP-0]=0 0/GPUScaling[DFP-0]=65537 0/OverscanCompensation[DFP-0]=0 0/ColorSpace[DFP-0]=0 0/ColorRange[DFP-0]=0 0/XVideoTextureBrightness=0 0/XVideoTextureContrast=0 0/XVideoTextureHue=0 0/XVideoTextureSaturation=0 0/XVideoTextureSyncToVBlank=1 0/XVideoSyncToDisplay=65536
Attached image screenshot.jpg —
At the moment, via VNC the resolution is correct, but there are no menus or toolbars visible onscreen, and the right-click popup looks like this.
Attached image screenshot2.jpg —
I switched back to Xvfb, just to see if that was still working. It's not - this is what I get!
No progress. I had dcops hook up a spider to see if this was related to VNC. It's not. Still problems with bogus coloration (like comment 10), although occasionally it will just work. At no point are the launcher, etc. visible. I haven't seen comment 11 again. Vaguely useful reference: ftp://download.nvidia.com/XFree86/Linux-x86/295.40/README/xconfigoptions.html
I'm bouncing this back to Brian. The remaining problems are: 1. Graphics artifacts a la comment 10 2. No launcher bar Neither of these is a problem with Xvfb. I'll attach .xesssion-errors and ps -auxwwf | grep [c]ltbld for both a good (Xvfb) and bad (X) run. I suspect #developers or someone from the graphics could help explain the graphics artifacts. There's a Lantronix Spider KVM set up at 10.26.16.131, that's showing the same output as VNC (although it looks like it's missing the R component - probably just a loose connection). I'm going to set up a second machine for comparison testing, and to rule out hardware issues. I'll post here when it's ready.
Assignee: dustin → bhourigan
Attached file good-xvfb.txt —
Attached file bad-X.txt —
I copied EDID data from a connected display and forced the nvidia driver to think that monitor is always connected. That seems to of stopped compiz from crashing, but there's still something up with the color palette. It's a 16:9 display so I was unable to force the desired resolution of 1600x1200, but getting EDID data from a display connected to a nvidia graphics adapter is a simple process. Add the following to xorg.conf: Section "Device" Driver "nvidia" <...> Option "ModeDebug" "true" EndSection Restart XOrg. Run nvidia-xconfig: nvidia-xconfig --extract-edids-from-file=/var/log/Xorg.0.log --extract-edids-output-file=/etc/X11/edid.bin Make note of the output, it will indicate which port the display was connected to. In this case it's DFP-0. Configure XOrg to use this data: Replace ModeDebug with the following: Option "ConnectedMonitor" "DFP-0" Option "CustomEDID" "DFP-0:/etc/X11/edid.bin" Option "IgnoreEDID" "false" Option "UseEDID" "true"
Blocks: 829135
I think we should hold off here until we see the new hardware. Maybe it will Just Work™ That may be sometime today, if we're lucky.
I reached out to a few folks including the developer of colord, and got a positive response. I'de like to gather some information and exhaust the help while it's available
Have at it. I'm going to bring up the new hardware now, assuming it's functional.
The new hardware's doing about the same thing :( More time at the drawing board.
new hosts are talos-linux{32,64}-ix-001.test.releng.scl3.mozilla.com. Both are running 64-bit Ubuntu, as there's no need to add more variables!
Add the following options in the "Device" section to make use of the EDID data: # Fake nvidia into thinking a DELL U2410 (DFP-0) is connected Option "ConnectedMonitor" "DFP-0" Option "CustomEDID" "DFP-0:/etc/X11/edid.bin" Option "IgnoreEDID" "false" Option "UseEDID" "true" I also observed a intermittent race condition where Xsession would invoke things such as the window manager before XOrg had established the X socket. I implemented the following work-around in /etc/X11/Xsession.d/00-delay: #!/bin/sh sleep 5
I've incorporated comment 23 into my (as-yet uncommitted) puppet changes.
(In reply to Dustin J. Mitchell [:dustin] from comment #10) > Created attachment 711338 [details] > screenshot.jpg Karl, do you have any thoughts on what might be causing this? We're currently using NVIDIA driver version 295.40, which is nvidia-current.
Success at last - many thanks to the folks in #gfx which pointed us to the solution! - Disable xrender in xorg.conf: Section "Extensions" Option "RENDER" "disable" EndSection It seems as though this breaks compiz in unity, it hangs indefinitely. Ubuntu removed unity-2d by default, but we can still get it back (for now) by following the instructions at https://wiki.ubuntu.com/Unity2D sudo add-apt-repository ppa:unity-team/staging sudo apt-get update sudo apt-get install unity-2d Configure unity-2d to start via Xsession: export DESKTOP_SESSION="ubuntu-2d" GDMSESSION="ubuntu-2d" su - -c "DISPLAY=:0 /etc/X11/Xsession '/usr/bin/gnome-session --session=ubuntu-2d'" cltbld
Better yet (since it doesn't require an external repo), we can just use lxde. Now, to figure out what, exactly, needs to be installed for lxde to work..
The patch for now. I need to test this out on a freshly-imaged system to make sure I'm not depending on some leftovers from ubuntu-desktop. This also has some TODO items. I also need to get the right EDID data. So just FYI.
Assignee: bhourigan → dustin
Depends on: 840774
Comment on attachment 713160 [details] [diff] [review] bug838351-interim.patch Looks like the problem was something between compiz and the NVIDIA drivers. I'm hoping it was compiz doing something wrong or we may have trouble with GL later. >+# Disable RENDER, as it doesn't work with compiz >+# TODO: seems unnecessary with lxde?! >+#Section "Extensions" >+# Option "RENDER" "disable" >+#EndSection Yes, please leave RENDER enabled. Firefox rendering when RENDER is not available is very much a fallback and much slower in many situations.
Given the number of issues in https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/982485 , it may be worth having more recent drivers.
Noted regarding RENDER. I'll work on getting newer drivers installed. First I need to just get this working to the point where tests run properly. Once that's in place, we can upgrade drivers at some point in the midst of the "put in production" and "unhide tests" events. Thanks again, and please do feel free to add as many $0.02 as you'd like here lest we spend time doing things wrong.
I just got EDID data from an Extron EDID simulator -- the same kind we use on the mac minis.
This is blocked on bug 840765 for the moment :(
Good news first: my puppet manifests, which just install 'lxde' and depend on its requirements and suggests, work fine on freshly imaged, production hardware. Bad news: still with the black backgrounds. RENDER fixes it. Boo.
Good news! Upgrading to 304.64 fixes it. Now to get that installed via puppet.
I'd like to build an installation process that uses nvidia's .run file directly. I've verified this is legit in the T&C: 2.1.2 Linux/FreeBSD Exception. Notwithstanding the foregoing terms of Section 2.1.1, SOFTWARE designed exclusively for use on the Linux or FreeBSD operating systems, or other operating systems derived from the source code to these operating systems, may be copied and redistributed, provided that the binary files thereof are not modified in any way (except for unzipping of compressed files).
This seems to work silently: ./NVIDIA-Linux-x86_64-310.32.run -a --dkms -q -s then add /etc/modprobe.d/blacklist.conf blacklist nouveau options nouveau modeset=0 ---- I can put all of that in puppet and test it, but I think we're on the home stretch here.
After hitting bump after bump with manually installing the drivers, I've decided to pull them from the xorg-edgers PPA, which seems to track the latest from nvidia pretty closely (they have the latest as of right now, anyway). This lets someone else do the packaging, makes sure dependencies are in order, etc. If we later need to install a version we can't find a package for, we can rebuild one of their packages.
And I should say, this is in the late testing stages. I hope to have a patch up for review today. Then we'll need to talk about how to deploy it safely, without hurting AWS testers.
Bug 843847 just bit me :(
Attached patch bug838351-r1.patch (obsolete) — — Splinter Review
I'm going to pessimistically call this "r1". Let's get this reviewed on general merit, and once that's roughly agreed, figure out how to deploy it. This will obviously be a significant change to the existing Xvfb testers (mostly since it will run LXDE instead of Compiz), so that will require some finesse.
Attachment #716826 - Flags: review?(rail)
This has been tested on 64-bit by installing with an empty node definition, then running puppet against my environment. Stuff to document: - new 'gui' module - approach to installing nvidia drivers - changes to 'vnc' module - removed 'screenresolution' module - Exec['reboot_after_puppet']
Comment on attachment 716826 [details] [diff] [review] bug838351-r1.patch In overall it looks good. We'll need to test it for both GPU and non-GPU platforms before we land.
Attachment #716826 - Flags: review?(rail) → review+
Depends on: 845803
OK, so I think the plan is this: 1. Pin my environment on several AWS hosts, as well as on the two hosts in scl3: talos-linux32-ix-001 talos-linux64-ix-001 (I'll need help with the AWS hosts) 2. Attach those hosts to a staging master (rail's, presumably) and put some unit test builds on them. 3. Observe the results. If not similar to what we're seeing with AWS hosts, fix.
The ubuntu hosts are busily building, looking mostly green at least - I'll leave it to rail to know what those should look like. The ix hosts aren't in slavealloc yet, but they are up and running. I'll look at that tomorrow.
We talked about this issue yesterday during the releng weekly meeting. The outcome: 1) Try to use Unity since it's a default DE 2) changing GPUs is no-go 3) if we can't fix 1) we should proceed with the current LXDE scenario I'm going to look at some of the ix machines to have better idea what can be done for 1). I need a couple of days for this.
(In reply to Rail Aliiev [:rail] from comment #46) > We talked about this issue yesterday during the releng weekly meeting. The > outcome: > > 1) Try to use Unity since it's a default DE > 2) changing GPUs is no-go > 3) if we can't fix 1) we should proceed with the current LXDE scenario Clarifying (3) - "proceed with" means get formal sign off on that approach with product management and ateam. There are, at least, deployment timing concerns with LXDE.
You might also try the x-updates PPA (ppa:ubuntu-x-swat/x-updates) for nvidia driver updates. This is different from the xorg-edgers repo in that you won't be pulling bleeding-edge X packages, you will keep the Xorg server comes packaged with the distro. I hope this has some effect on fixing the compiz rendering problem.
We tried that version, too - same black backgrounds.
* killed everything lxde related * installed ubuntu-desktop metapackage * added the following to ~cltbld/.xinitrc: #!/bin/sh exec unity * Edited /etc/X11/Xwrapper.config allowed_users=anybody * ran startx and x1vnvc in a different console (to watch the output) This is what I'm getting now (glxinfo, pop-up menu, overall view): http://people.mozilla.org/~raliiev/sattap/31a12ffb.png Should I check anything else?
err, * added the following to ~cltbld/.xinitrc: #!/bin/sh gnome-settings-daemon & exec unity
>root 815 0.0 0.0 49956 2848 ? Ss 07:52 0:00 /usr/sbin/sshd -D >root 1989 0.0 0.0 56808 3352 ? Ss 10:49 0:00 \_ sshd: root@pts/1 >root 1991 0.0 0.0 23156 4488 pts/1 Ss+ 10:49 0:00 | \_ -bash >root 2445 0.0 0.0 56656 3276 ? Ss 10:55 0:00 \_ sshd: cltbld [priv] >cltbld 2447 0.0 0.0 56804 1532 ? S 10:55 0:00 | \_ sshd: cltbld@pts/3,pts/0 >cltbld 2448 0.0 0.0 23164 4488 pts/3 Ss 10:55 0:00 | \_ -bash >cltbld 28282 0.0 0.0 4400 708 pts/3 S+ 11:58 0:00 | | \_ /bin/sh /usr/bin/startx >cltbld 28299 0.0 0.0 15952 860 pts/3 S+ 11:58 0:00 | | \_ xinit /home/cltbld/.xinitrc -- /etc/X11/xinit/xserverrc :0 -auth /tmp/serverauth.CKtzaaQ0s9 >root 28300 3.2 0.8 204956 66928 tty8 Ss+ 11:58 0:37 | | \_ /usr/bin/X -nolisten tcp :0 -auth /tmp/serverauth.CKtzaaQ0s9 >cltbld 28302 0.0 0.1 83800 9096 pts/3 S 11:58 0:00 | | \_ /usr/bin/python /usr/bin/unity >cltbld 28303 0.0 0.2 667724 17840 pts/3 Sl 11:58 0:00 | | \_ gnome-settings-daemon >cltbld 28313 0.0 0.0 4400 616 pts/3 S 11:58 0:00 | | \_ /bin/sh -c compiz --replace >cltbld 28315 8.8 2.2 1374640 184580 pts/3 Sl 11:58 1:42 | | | \_ compiz --replace >cltbld 28352 0.0 0.0 4400 612 ? Ss 11:58 0:00 | | | \_ /bin/sh -c /usr/bin/compiz-decorator >cltbld 28353 0.0 0.1 317064 11800 ? Sl 11:58 0:00 | | | \_ /usr/bin/gtk-window-decorator >cltbld 28314 0.0 0.0 0 0 pts/3 Z 11:58 0:00 | | \_ [killall] <defunct> >cltbld 26795 0.0 0.0 23284 4504 pts/0 Ss 11:20 0:00 | \_ -bash >cltbld 28640 0.2 0.2 107864 22736 pts/0 S+ 12:03 0:02 | \_ x11vnc -forever >root 28641 0.0 0.0 56792 3532 ? Ss 12:11 0:00 \_ sshd: root@pts/4 >root 28643 0.0 0.0 20452 4460 pts/4 Ss 12:11 0:00 \_ -bash >root 28752 0.0 0.0 15416 1172 pts/4 R+ 12:18 0:00 \_ ps auxwwf I'm going to switch my patch around to use ubuntu-desktop again, and reimage talos-linux32-ix-001 (with 64-bit ubuntu - don't mind the name) and see what happens
Attached patch bug838351-r2.patch (obsolete) — — Splinter Review
Revised version that runs Unity. It seems to work now. We're not quite sure why/how.
Attachment #716826 - Attachment is obsolete: true
Attachment #722356 - Flags: review?(rail)
Comment on attachment 722356 [details] [diff] [review] bug838351-r2.patch Sorry, I was swamped with 19.0.2 yesterday. The diff and the interdiff look good to me. Let' land it next week! Monday maybe?
Attachment #722356 - Flags: review?(rail) → review+
Great - how do you want to do that - pin two and run them in production? If so, should we set that up today to test over teh weekend?
Yeah, we can. Can you grab tst-linux64-ec2-001 (10.134.56.10) and tst-linux32-ec2-001 (10.134.57.9), generate certs for them and attach to your env?
Differences from -r1: - remove Xsession xterm loop, which seems to cause issues with compiz - start unity from .xinitrc instead of Xsession - add Xwrapper.conf (probably unnecessary) This is running on ix-mn-linux64-{001,002}.test.releng.scl3.mozilla.com tst-linux{32,64}-ec2-001.releng.use1.mozilla.com talos-linux{32,64}-ix-001.test.releng.scl3.mozilla.com
Attachment #722356 - Attachment is obsolete: true
How is this looking?
shipped
There was a little bustage with mountain lion systems where the gui classes weren't adjusted correctly. Fixes are below. Otherwise, this seems to be running just fine. We can deal with any further tweaks in other bugs. ---- commit 07564a0a87d550cf4e8edf1cbd862189ffd7389d Author: Dustin J. Mitchell <dustin@mozilla.com> Date: Tue Mar 12 11:19:40 2013 -0400 Bug 838351: fix screen resolution on OS X; a=bustage diff --git a/modules/gui/manifests/init.pp b/modules/gui/manifests/init.pp index fc97f99..43a118f 100644 --- a/modules/gui/manifests/init.pp +++ b/modules/gui/manifests/init.pp @@ -20,7 +20,7 @@ class gui($on_gpu) { # set the screen resolution appropriately include packages::mozilla::screenresolution - $resolution = "${width}x${height}x${depth}@${refresh}" + $resolution = "${screen_width}x${screen_height}x${screen_depth}@${refresh}" # this can't run while puppetizing, since the automatic login isn't in place yet, and # the login window does not allow screenresolution to run. (sandbox)dustin@euclid ~/code/puppetagain/t/puppetagain [master] $ git show HEAD^ commit 746ea2e163a0e0c9bb0c7a66adb846895e10ff21 Author: Dustin J. Mitchell <dustin@mozilla.com> Date: Tue Mar 12 11:09:40 2013 -0400 Bug 838351: only include packages::libglib20_bin on Ubuntu; a=bustage diff --git a/modules/gui/manifests/appearance.pp b/modules/gui/manifests/appearance.pp index e6ff42a..7927de6 100644 --- a/modules/gui/manifests/appearance.pp +++ b/modules/gui/manifests/appearance.pp @@ -2,7 +2,6 @@ # License, v. 2.0. If a copy of the MPL was not distributed with this # file, You can obtain one at http://mozilla.org/MPL/2.0/. class gui::appearance { - include packages::libglib20_bin include dirs::usr::local::bin include users::root @@ -29,6 +28,8 @@ class gui::appearance { } } Ubuntu: { + include packages::libglib20_bin + file { "/usr/share/glib-2.0/schemas/99_gsettings.gschema.override": notify => Exec['update-gsettings'],
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
As new machines were imaged, we were seeing errors like this: Tue Mar 12 18:01:11 -0700 2013 /Stage[main]/Packages::Nvidia_drivers/Package[nvidia-310]/ensure (err): change from absent to latest failed: Could not update: Execution of '/usr/bin/apt-get -q -y -o DPkg::Options::=--force-confold install nvidia-310' returned 100: Reading package lists... Building dependency tree... Reading state information... Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: nvidia-310 : Depends: libc6-dev but it is not going to be installed E: Unable to correct problems, you have held broken packages. at /etc/puppet/production/modules/packages/manifests/nvidia_drivers.pp:23 Tue Mar 12 18:01:14 -0700 2013 /Stage[main]/Packages::Linux_desktop/Package[ubuntu-desktop]/ensure (err): change from purged to latest failed: Could not update: Execution of '/usr/bin/apt-get -q -y -o DPkg::Options::=--force-confold install ubuntu-desktop' returned 100: Reading package lists... Building dependency tree... Reading state information... Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: ubuntu-desktop : Depends: eog but it is not going to be installed Depends: evince but it is not going to be installed Depends: gnome-control-center but it is not going to be installed Depends: gnome-session but it is not going to be installed Depends: nautilus but it is not going to be installed Depends: nautilus-sendto but it is not going to be installed Depends: software-center but it is not going to be installed Depends: system-config-printer-gnome but it is not going to be installed Depends: ubuntu-artwork but it is not going to be installed Depends: unity but it is not going to be installed Depends: unity-2d but it is not going to be installed Depends: yelp but it is not going to be installed Depends: zenity Recommends: brasero but it is not going to be installed Recommends: empathy but it is not going to be installed Recommends: gnome-screensaver but it is not going to be installed Recommends: gwibber but it is not going to be installed Recommends: nautilus-share but it is not going to be installed Recommends: network-manager-gnome but it is not going to be installed Recommends: rhythmbox but it is not going to be installed Recommends: rhythmbox-plugin-magnatune but it is not going to be installed Recommends: rhythmbox-ubuntuone but it is not going to be installed Recommends: shotwell but it is not going to be installed Recommends: simple-scan but it is not going to be installed Recommends: totem but it is not going to be installed Recommends: totem-mozilla but it is not going to be installed Recommends: ubuntu-docs but it is not going to be installed Recommends: ubuntuone-client-gnome but it is not going to be installed E: Unable to correct problems, you have held broken packages. at /etc/puppet/production/modules/packages/manifests/linux_desktop.pp:13 Tue Mar 12 18:01:15 -0700 2013 /Stage[main]/Packages::Mozilla::Python27/Package[python2.7-dev]/ensure (err): change from purged to latest failed: Could not update: Execution of '/usr/bin/apt-get -q -y -o DPkg::Options::=--force-confold install python2.7-dev' returned 100: Reading package lists... Building dependency tree... Reading state information... Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: python2.7-dev : Depends: libexpat1-dev but it is not going to be installed Depends: libssl-dev but it is not going to be installed Recommends: libc6-dev but it is not going to be installed or libc-dev E: Unable to correct problems, you have held broken packages. at /etc/puppet/production/modules/packages/manifests/mozilla/python27.pp:29 rail mirrored libc6-dev into releng-updates, and that seems to have cleared up the problem.
Now we have a similar problem with libgtk-3-common. Rail, can you fix that up? My attempts failed. I think we need a new plan for handling Ubuntu repos -- this isn't going very well. But that's a different bug.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Rail cleaned out the releng-updates repo to only contain gnome-settings-daemon and not its dependencies (in particular, not libc6). I did a reinstall on talos-linux64-ix-001, and it completed without incident. It's running Buildbot. Over to rail to do a final verify on that host. Rail, can you let Amy know if it's OK, and she'll re-reimage the rest?
Assignee: dustin → rail
Blocks: 850502
Attached patch use .xsessionrc — — Splinter Review
When I was testing iX slaves I used startx to start X. It turns out that Xsession doesn't read .xinitrc file. * We don't need to use .xinitrc * Addiing "DESKTOP_SESSION=ubuntu" to .xsessionrc makes /etc/X11/Xsession.d/50_check_unity_support set DESKTOP_SESSION to ubuntu-2d in case if there is no HW acceleration. * "respawn" will make sure that Xsession is restarted on failures.
Attachment #725021 - Flags: review?(catlee)
Attachment #725021 - Flags: review?(catlee) → review+
iX and AWS slaves look OK.
Status: REOPENED → RESOLVED
Closed: 12 years ago → 12 years ago
Resolution: --- → FIXED
Blocks: 852680
Component: Server Operations: RelEng → RelOps
Product: mozilla.org → Infrastructure & Operations
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: