lubuntu-qa team mailing list archive

[Erick Brunzell <lbsolost@xxxxxxxxx>]

On 09/02/2013 02:00 PM, JM wrote:
> On Mon, 02 Sep 2013 10:10:08 -0500
> Erick Brunzell <lbsolost@xxxxxxxxx> wrote:
>
>> On 09/02/2013 02:56 AM, JM wrote:
>>> On Mon, 02 Sep 2013 02:24:57 -0500
>>> however, Graphics are not related to DE, or to window managers, but depend on the
>>> driver provided to work with Xorg.
>> That's not entirely true. That VIA P4M800 chip has never worked with
>> Compiz due to a lack of 3d rendering, so up through Precise Ubuntu would
>> always fall back to using the Metacity WM. The same was true of GNOME 3
>> until they dropped the fallback-session entirely. But Metacity is going
>> to be maintained by Edubuntu for their LTSP installs.
> 3D: the driver does not provide 3D for this chipset. The Compiz window manager not being
> supported is a consequence not a cause, as it depends on 3D to work.
>
>
> (...)
>>> It seems according to your report that only the progress bar is a problem to you. And
>>> you can't start X from the recovery mode of course, it's an init mode which is too
>>> low for that. 
>>>
>>> If it is only the progress bar which bothers you: the progress bar does not matter.
>>> You can hit a key before booting (it might be F6, look at the lower part of the
>>> screen to check) and replace "quiet splash" in the kernel command line with
>>> "noquiet" (leave the '--' at the end of the line) and you will have a text mode boot
>>> instead. Or just ignore what the progress bar looks like and go do something else by
>>> the time the system finishes the boot?
>> One thing has changed between Alpha 2 and now. Rather than a frozen
>> progress bar, I now boot the live image directly to a blank screen.
>> Server installs seem to work OK, as does booting in "text" mode. I'll
>> try the "noquiet" option rather than "text" and see what happens.
> Ok, let's see how it goes.
>
>
>> Oh, one thing I tried with Alpha 2 to help rule out a kernel problem was
>> upgrading from Raring to Saucy and then booting the old Raring kernel
>> which was still a no-go. Since it effects both the live image and
>> installed images I believe I should be able to collect info if an Xorg
>> dev tells me what to do, and what to look for.
> I am not a dev, but if I can help with ideas where to look at:
>
> /var/log/Xorg.0.log 
> /var/log/dmesg (just after a boot, if you can access a tty, cd to /var/log and pastebin
> the dmesg file to get a copy to a pastebin page on the web)
>
> /var/log/syslog 
>
> All three can be pastebined if you have installed pastebinit (unless it is already in the
> distro?)
>
> Regards,
> Mélodie
>
> --
>
> Linuxvillage
> http://forum.linuxvillage.net
>
Based on that I dropped some new info here:

https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1205643

I hope that's helpful.

Thanks for the suggestion.

Lance

PS: I probably won't bother with that bug again until Beta 1 testing is
complete because we have about 48 hours to test images, so I'm going to
shift my focus to another box just to be sure nothing is seriously hosed
with ubiquity :^)

And I also need to run upgrade tests which are time consuming.