This is a bug, so I'm assuming you're asking how to collect the necessary information to report it. (Otherwise, this question is probably off-topic; see the FAQ and this meta question.)
Consult the Bug Reporting Documentation First
I'm running the Project Neon ppa and when I login with the user asscocatied w/ that i don't seem to have any lockups.
I'm assuming that means when you log in to a KDE desktop, the problem does not occur, but that it does occur when you log into a dekstop not provided by packages from the Project Neon PPA.
However, if this is happening in a GUI provided by Project Neon, please make sure you've read this carefully and are following its guidelines when reporting the bug.
Whether or not this is a bug in Project Neon software, I highly recommend reading this all the way through before reporting bugs in Ubuntu. For Kubuntu, I recommend still reading that, but also this (and take a look at this portal page). This question is also a useful resource. And here's some good general bug reporting advice.
If you've already read all that and understand how to report bugs, you can skip ahead...
Figure Out What Package Is Probably Affected
If you report the bug against the wrong package, provided that the report is otherwise good and has all the necessary information, this usually can be figured out by a triager or developer, and the bug report can be pretty easily retargeted to another package.
However, since much of the important technical information in an Ubuntu bug report is often provided by running Apport, and Apport figures out what to send based on what package the bug is being reported against, it's good to make an initial effort to select the right one, especially for video, sound, driver, or kernel problems, where Apport can often submit a lot of highly valuable information.
The screen freeze is probably due either to, or at least closely related to, the X server or the window manager.
The X Server
At the login screen you can select between different interfaces. All of them use the same X server, but some use different window managers.
If you're experiencing this with all options, then this bug probably relates to the X server, and it can be reported against
xserver-xorg by running
ubuntu-bug xserver-xorg. But it's better to run
ubuntu-bug with the PID of the running
Xorg process that may be malfunctioning.
ubuntu-bug $(pidof Xorg) should do this.
(See below for an explanation of how to run
ubuntu-bug when your screen is frozen.)
The Window Manager
However, it sounds from what you said that this is not the case--that at least one option (logging in with a desktop provided by Project Neon) works.
Kubuntu's window manager is
kwin, provided by the
kde-window-manager package. To report a bug against it, you can run
ubuntu-bug kde-window-manager, but it's better to run
ubuntu-bug with the PID of the running
kwin process that may be malfunctioning.
ubuntu-bug $(pidof kwin) should do this.
If the problem is specific to a 3D Unity session, the window manager running when it occurs is
ubuntu-bug compiz is okay.
ubuntu-bug $(pidof compiz) is better
On the other hand if it just happens in Unity 2D (and a GNOME Classic/Fallback session), the window manager is
ubuntu-bug metacity is okay.
ubuntu-bug $(pidof metacity) is better.
If it happens in a GNOME 3 desktop running GNOME Shell (not Unity), the window manager is
ubuntu-bug mutter is okay.
ubuntu-bug $(pidof mutter) is better.
If it happens in an Xubuntu desktop, the window manager is
ubuntu-bug xfwm4 is okay.
ubuntu-bug $(pidof xfwm4) is better.
If it happens in an LXDE desktop, the window manager is
ubuntu-bug openbox is okay.
ubuntu-bug $(pidof openbox) is better.
If you have one user account that boots to one UI by default, and another user account that boots to another UI by default, and the bug happens in one but not the other, then (since this is a UI bug) the UI difference is probably what's important.
But you sure make sure, since sometimes a specific user's configuration manages to trigger a bug. You should verify that it happens with a user account logged in with one UI, and with the same user account logged in to a different UI.
You should also see if usage patterns are what trigger the bug. For example, see if the number of windows you're Alt+Tabing through is relevant to whether or not the bug occurs. (If it occurs with only one window, that's particularly interesting.) This sort of information should be included in your bug report.
It's possible the bug is in some package other than the X Server or the window manager.
- It could be higher level (that is, most of the problem might be happening in an process that runs on top of the GUI, which is only triggering another bug in the window manager or X server).
- Or it could be lower level. Probably not a bug in the kernel itself (your system still works fine, you can SSH in). But it could be a video driver problem.
In any case, reporting the bug against either the window manager or the X Server, depending on which appears more likely, will usually cause Apport to upload enough of the right information that if the bug is in something else, that can be figured out.
Reporting The Bug, While The Bug Makes Itself Hard To Report
You've found you can SSH in. So it seems likely that you can access a virtual console with Ctrl+Alt+F1, Ctrl+Alt+F2, and so forth, up to F6.
(To switch back to the GUI, use Alt+F7.)
If that works, you can report the bug from the virtual console while the GUI is still running and malfunctioning.
ubuntu-bug, when run in a virtual console, should detect there is no GUI and run in text mode instead. Or if you prefer to use the
apport-cli command instead, that works too.
SSHing in to report it is probably easier though, as then you can copy the Launchpad URL provided by
apport-cli and paste it into a graphical web browser on the SSH client.
Alternatively you might consider using
ssh -X to connect. Then you can run GUI programs on the malfunctioning machine (that you're SSHed into), and make their interfaces (their windows) appear on the SSH client. You could then run
ubuntu-bug graphically and report the bug from a graphical web browser that runs on the malfunctioning machine that is the SSH server but displays on the properly functioning machine that is the SSH client.
More Ways to Find the Affect Process's PID
Depending on the nature of the bug, it might be particularly helpful to run
apport-cli) with the PID of the buggy process, rather than just with the name of the package. This will automatically include information about the running state of the process, in the files uploaded to Launchpad by Apport.
ubuntu-bug $(pidof processname) doesn't work or doesn't get the right process, you can also:
pidof manually and see what you get. If you get nothing, it means no process by that name is running.
pgrep, which shows PID's of all processes matching the argument as a regular expression (rather than whose names are equal to the argument, as
Use the tried-and-true, classic technique (
ps, piped to
ps ax | grep -v grep | grep processname
That provides more detailed information--it gives a listing of the name, PID, and states of any matching processes.
Files to Make Sure Are Attached
/var/log/Xorg.0.log and (if it exists)
/var/log/Xorg.0.log.old are attached.
Similarly, make sure
~/.xsession-errors and (if it exists)
~/.xsession-errors.old are attached. (
~ represents your home folder.) Dotfiles are not shown in Nautilus by default, so if you want to see them in a graphical file browser window, do Ctrl+H (or View > Show Hidden Files).
When you report a bug on Launchpad, Apport will have automatically sent a number of files, which will have been attached. You can also attach one more file. To attach different files, submit the bug report first--then you can attach them.