[Macmini 5,1] Fatal server error: Can not run in framebuffer mode on reboot

[Para Siva]

Fatal server error: Can not run in framebuffer mode error occurs on the 2nd reboot onwards on a mac with external display.
The first reboot after a fresh installation is working fine and from the second attempt the desktop fails to start on the standard graphics mode and 'Your screen, graphics card, and input device settings could not be detected correctly....' error message is displayed.

The logs attached are directly from the first reboot.

A tar file will be added with the logs after the failure.

ProblemType: Bug
DistroRelease: Ubuntu 12.10
Package: xorg 1:7.7+1ubuntu4
ProcVersionSignature: Ubuntu 3.5.0-17.28-generic 3.5.5
Uname: Linux 3.5.0-17-generic x86_64
.tmp.unity.support.test.0:

ApportVersion: 2.6.1-0ubuntu3
Architecture: amd64
CompizPlugins: No value set for `/apps/compiz-1/general/screen0/options/active_plugins'
CompositorRunning: compiz
CurrentDmesg:

Date: Mon Oct 15 14:37:01 2012
DistUpgraded: Fresh install
DistroCodename: quantal
DistroVariant: ubuntu
ExtraDebuggingInterest: Yes
GraphicsCard:
 Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller [8086:0126] (rev 09) (prog-if 00 [VGA controller])
   Subsystem: Apple Inc. Device [106b:00e6]
InstallationMedia: Ubuntu 12.10 "Quantal Quetzal" - Release amd64+mac (20121014)
MachineType: Apple Inc. Macmini5,1
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.5.0-17-generic root=UUID=f5eb805b-ed9d-43f3-a316-9b906251e9d5 ro quiet splash vt.handoff=7
SourcePackage: xorg
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 10/20/2011
dmi.bios.vendor: Apple Inc.
dmi.bios.version: MM51.88Z.0077.B0F.1110201309
dmi.board.asset.tag: Base Board Asset Tag#
dmi.board.name: Mac-8ED6AF5B48C039E1
dmi.board.vendor: Apple Inc.
dmi.board.version: Macmini5,1
dmi.chassis.type: 16
dmi.chassis.vendor: Apple Inc.
dmi.chassis.version: Mac-8ED6AF5B48C039E1
dmi.modalias: dmi:bvnAppleInc.:bvrMM51.88Z.0077.B0F.1110201309:bd10/20/2011:svnAppleInc.:pnMacmini5,1:pvr1.0:rvnAppleInc.:rnMac-8ED6AF5B48C039E1:rvrMacmini5,1:cvnAppleInc.:ct16:cvrMac-8ED6AF5B48C039E1:
dmi.product.name: Macmini5,1
dmi.product.version: 1.0
dmi.sys.vendor: Apple Inc.
version.compiz: compiz 1:0.9.8.4-0ubuntu2
version.ia32-libs: ia32-libs N/A
version.libdrm2: libdrm2 2.4.39-0ubuntu1
version.libgl1-mesa-dri: libgl1-mesa-dri 9.0-0ubuntu1
version.libgl1-mesa-dri-experimental: libgl1-mesa-dri-experimental N/A
version.libgl1-mesa-glx: libgl1-mesa-glx 9.0-0ubuntu1
version.xserver-xorg-core: xserver-xorg-core 2:1.13.0-0ubuntu6
version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.7.3-0ubuntu2
version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:6.99.99~git20120913.8637f772-0ubuntu1
version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.20.9-0ubuntu2
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.2-0ubuntu3

[Para Siva (psivaa)]

The above logs were taken from the first boot, hence does not have the error information. The attached tar contains the log after the failure

[Ubuntu QA Website (ubuntuqa)]

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:
http://iso.qa.ubuntu.com/qatracker/reports/bugs/1066883

[Para Siva (psivaa)]

Reproducible with 20121015.2 as well, after entire disk fresh installation

[Jean-Baptiste Lallement (jibel)]

Similar to bug 1066228

[Para Siva (psivaa)]

When attempted with plymouth-splash disabled I am able to bring up the desktop in the standard graphics mode. When plymouth-splash was re-enabled, the issue is reproducible with mainline kernel 3.5.5.

[Para Siva (psivaa)]

Was able to reproduce with 3.5.4 mainline kernel version as well

[Para Siva (psivaa)]

Occurs with 3.5.3 mainline kernel as well with plymouth-splash enabled

[Para Siva (psivaa)]

A fresh install with quantal desktop - amd+mac 20121011 also has the same issue. First boot after the installation went well but the subsequent ones do not boot in standard graphics mode.

[Para Siva (psivaa)]

When tried with 20120724.2 amd+mac quantal desktop, this issue was not reproducible (with ~10 reboots). Hence looking at bug 1066228 it appears be a regression that occurred between alpha3 and beta 1.

[Para Siva (psivaa)]

So here is the list of test runs,

20120724.2 -> worked
20120918.1->worked
20121001 -> worked
20121011 -> FAILED

The kernel was updated to the latest on top of a working 20121001 and it still worked

[Andy Whitcroft (apw)]

@psivaa -- when updating the kernel there on 20121001 can you confirm that multiple boots were good. Also on the latest image (known bad) does it work for the next boot if you remove /var/lib/ureadahead/pack before reboot?

[Para Siva (psivaa)]

@apw
Rebooted many times (more than 20) after updating the kernel to the latest on a known (20121001) good image, it worked ok, no failures could be observed.

Removing /var/lib/ureadahead/pack from the known bad image seem to solve the issue.

When it was made sure the file is removed before the reboot, the next reboot did not have this issue, the desktop came up on the standard gfx mode. When the file was present the next reboot failed, not so deterministically every time, but most of the times.

[Andy Whitcroft (apw)]

@psivaa -- ok cool so that confirms it is most likely an initialisation race. Could we get dmesg from a good boot (ie without the pack) and the next bad boot (with the pack), and attach them to this bug please. Do make sure they are clearly labelled :)

Thanks.

[Para Siva (psivaa)]

Failure was observed in the second boot

[Bryce Harrington (bryce)]

This looks to me more like a plymouth issue holding on to the framebuffer too long, rather than an X issue. apw's probably the right guy to look into this so will unassign X from it; feel free to re-add us if there's something for us to do.

[Steve Langasek (vorlon)]

lightdm is responsible for killing plymouth before starting X, so this can't be a plymouth bug. It may be a bug in the drm layer being triggered by plymouth.

If booting with plymouth-splash intact, after triggering the bug, is it possible to switch to a console and run 'sudo service lightdm restart'? Does X then start up correctly?

It may be useful to get the dmesg output of a failed boot with --verbose added to the kernel commandline, to get information about the ordering of the upstart jobs on boot.

[Para Siva (psivaa)]

If booting with plymouth-splash intact, after triggering the bug, is it possible to switch to a console and run 'sudo service lightdm restart'? Does X then start up correctly?
 >>> Yes it was possible to switch to console and Yes X does start correctly

dmesg output of a failed boot with --verbose added to the kernel commandline
>>> attached -- file named 'failed_dmesg_with_verbose'

[Steve Langasek (vorlon)]

dmesg shows the below output. plymouth is clearly being stopped by lightdm (not by /etc/init/plymouth-stop.conf), so we're not hitting a race in the plymouth jobs. But after stopping plymouth, lightdm hits the problem with the X server and exits.

I think this is clearly a problem with either the kernel or with lightdm.

[ 15.801383] init: lightdm goal changed from stop to start
[ 15.801430] init: lightdm state changed from waiting to starting
[ 15.801559] init: plymouth-splash goal changed from stop to start
[ 15.801605] init: plymouth-splash state changed from waiting to starting
[...]
[ 15.803513] init: plymouth-stop goal changed from stop to start
[ 15.803563] init: plymouth-stop state changed from waiting to starting
[...]
[ 15.806338] init: plymouth-stop state changed from starting to pre-start
[ 15.806828] init: plymouth-stop pre-start process (1133)
[...]
[ 15.809173] init: plymouth-stop pre-start process (1133) exited normally
[ 15.809314] init: plymouth-stop state changed from pre-start to spawned
[ 15.809398] init: plymouth-stop state changed from spawned to post-start
[ 15.809477] init: plymouth-stop state changed from post-start to running
[...]
[ 15.811474] init: lightdm state changed from starting to pre-start
[ 15.811752] init: lightdm state changed from pre-start to spawned
[ 15.812406] init: lightdm main process (1136)
[ 15.812499] init: lightdm state changed from spawned to post-start
[ 15.812818] init: lightdm state changed from post-start to running
[...]
[ 15.817462] init: plymouth-splash state changed from starting to pre-start
[ 15.817511] init: plymouth-splash state changed from pre-start to spawned
[ 15.820635] init: plymouth-splash main process (1146)
[ 15.820690] init: plymouth-splash state changed from spawned to post-start
[ 15.820908] init: plymouth-splash state changed from post-start to running
[...]
[ 16.573039] init: plymouth-splash main process (1146) exited normally
[ 16.573104] init: plymouth-splash goal changed from start to stop
[ 16.573184] init: plymouth-splash state changed from running to stopping
[ 16.573242] init: Handling stopping event
[ 16.573332] init: plymouth-splash state changed from stopping to killed
[ 16.573382] init: plymouth-splash state changed from killed to post-stop
[ 16.573430] init: plymouth-splash state changed from post-stop to waiting
[ 16.573537] init: Handling stopped event
[ 16.591136] init: plymouth main process (259) exited normally
[ 16.591194] init: plymouth goal changed from start to stop
[ 16.591264] init: plymouth state changed from running to stopping
[...]
[ 17.610321] init: lightdm main process (1136) terminated with status 1
[ 17.610429] init: lightdm goal changed from start to stop
[ 17.610490] init: lightdm state changed from running to stopping
[...]
[ 16.591619] init: plymouth state changed from stopping to killed
[ 16.591669] init: plymouth state changed from killed to post-stop
[ 16.591721] init: plymouth state changed from post-stop to waiting

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[penalvch (penalvch)]

Parameswaran Sivatharman, as per http://support.apple.com/kb/HT1237 an update is available for your BIOS (MM51.0077.B10). If you update to this following https://help.ubuntu.com/community/BiosUpdate , does it change anything? If it doesn't, could you please both specify what happened, and just provide the output of the following terminal command:
sudo dmidecode -s bios-version && sudo dmidecode -s bios-release-date

For more on BIOS updates and linux, please see https://help.ubuntu.com/community/ReportingBugs#Bug_reporting_etiquette .

Thank you for your understanding.

[Joseph Salisbury (jsalisbury)]

This bug was nominated against a series that is no longer supported, ie saucy. The bug task representing the saucy nomination is being closed as Won't Fix.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

[Joseph Salisbury (jsalisbury)]

This bug was nominated against a series that is no longer supported, ie quantal. The bug task representing the quantal nomination is being closed as Won't Fix.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

[Joseph Salisbury (jsalisbury)]

This bug was nominated against a series that is no longer supported, ie raring. The bug task representing the raring nomination is being closed as Won't Fix.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

[Rolf Leggewie (r0lf)]

quantal has seen the end of its life and is no longer receiving any updates. Marking the quantal task for this ticket as "Won't Fix".

[Rolf Leggewie (r0lf)]

raring has seen the end of its life and is no longer receiving any updates. Marking the raring task for this ticket as "Won't Fix".

[Rolf Leggewie (r0lf)]

saucy has seen the end of its life and is no longer receiving any updates. Marking the saucy task for this ticket as "Won't Fix".

[Robert Ancell (robert-ancell)]

Closing assumed fixed.