18.04 daily build "hang"

[Robert Heller]

At Tue, 13 Feb 2018 10:26:17 -0800 "Ubuntu user technical support,  not for general discussions" <ubuntu-users at lists.ubuntu.com> wrote:

> 
> 
> 
> On Tue, Feb 13, 2018 at 10:02 AM, Robert Heller <heller at deepsoft.com> wrote:
> 
> > At Tue, 13 Feb 2018 09:47:13 -0800 "Ubuntu user technical support,  not
> > for general discussions" <ubuntu-users at lists.ubuntu.com> wrote:
> >
> > >
> > >
> > >
> > > I downloaded and installed a daily build of bionic-desktop-amd64.iso
> > yesterday
> > > and found it to be unstable... the X interface became unresponsive other
> > > than the ability to move the mouse. This happened using the default
> > > environment and in plasma with and without Wayland. I have 4 monitors
> > with
> > > an nvidia graphics card.
> > >
> > > VGA compatible controller: NVIDIA Corporation GK106 [GeForce GTX 660]
> > (rev
> > > a1)
> > >
> > > I didn't try to install the proprietary driver for it. I understand that
> > > daily builds can be unstable, so my question is, should I bother trying
> > to
> > > report this problem and if so, how can I get any useful debug info from a
> > > system that is non-responsive other than the ability to move the mouse?
> > Or
> > > is this kind of bug typical at this stage in testing and I should wait
> > and
> > > try again in a month?
> >
> > About getting "useful debug info from a system that is non-responsive other
> > than the ability to move the mouse": can you do any of these:
> >
> > ssh into the machine from another computer?
> >
> Didn't try yet. I didn't know the IP address and my firewalls are locked
> down pretty tight on that network, so I'd have to reconfigure things to
> try. If I did get in, what should I look for? tail of logs, dmesg???

Looking at /var/log/Xorg.0.log could be enlightening, otherwise, yes looking 
at log files can could be useful.  Seeing what sort of state X is in (S or D 
or R or what).  Seeing what kill X or kill -9 X does, etc.

> 
> > did you try installing as a non-graphical startup/login?
> >
> No I didn't but I don't anticipate any problems in that environment, so
> there would be nothing to debug.

*Excecpt* you could verify that it is indeed the *GUI* subsystem that is 
borked.  Also, you can separate the GUI *login* from the GUI itself.  And you 
can try ctrl-alt-backspace to kill X11 and return to the console terminal and 
then look at log files, etc.  Doing ctrl-alt-backspace with a GUI login, just 
restarts the GUI login and if the *GUI* is borked, that can be fruitless.

> 
> 
> > were you able to switch to another virtual console?
> >
> 
> I didn't try that yet either... would that be ctrl-alt-F2? Again, what
> commands would I run to capture useful data on a partially responsive
> graphical session?

ctrl-alt-F[1234567]

Usually ctrl-alt-F7 would be the GUI screen, but sometimes ctrl-alt-F1 is.  
ctrl-alt-F2 is likely be safe and will give you a terminal console.

Looking at /var/log/Xorg.0.log and/or various other log files. 

(The commands cat, more, less, tail, or vi would be your friends here.)

Looking at /var/log/Xorg.0.log may also be cluefull in terms of what you can
try putting in /etc/X11/xorg.conf.d/ to deal with possible problems
(incompatable hardware, workarounds for buggy video drivers, etc.). And if
some hack there "works" then that can be helpful for the people writing those
video drivers in terms of what they can do to fix the video drivers.

> 
> Thanks again,
> 
>          Dave
> 
> MIME-Version: 1.0
> 

-- 
Robert Heller             -- 978-544-6933
Deepwoods Software        -- Custom Software Services
http://www.deepsoft.com/  -- Linux Administration Services
heller at deepsoft.com       -- Webhosting Services