Incorrect udev-fallback-graphics.conf

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

Adding SRU proposal for Precise.

Adding SRU proposal for Trusty.

Adding SRU proposal for Utopic.

Utopic fix committed to git, thanks! I keep this open for trusty, but as it's neither a data loss nor critical bug and just a cosmetical corner case I keep it as low importance.

You say "since 3.13.0-16.36" which is trusty -- i. e. precise's kernel still has it as a module? So it seems to me that this doesn't affect precise at all. But even if it would, if such a cosmetical bug hasn't caused trouble in 2.5 years, it's certainly going to be fine for the other 1.5 years.

Thanks Martin for taking a look.

In my precise (12.04.5) install the default kernel is 3.13.0-32-generic, which is affected by the issue:
$ grep FB_VESA /boot/config-3.13.0-32-generic
CONFIG_FB_VESA=y

In fact initially this has been reported by a CTS customer for precise.

Ah right, that's the backported trusty kernels I figure (12.04.4 or later).

I'm still not fully convinced about the SRUs -- this might have a potential to break existing setups if they run custom kernels? It's ok to add the expectancy to build in vesafb for a new release (utopic), but not for existing stables?

Or is it impossible to build vesafb as a module now?

Building vesafb as a module should still be possible.

Trusty had vesafb build in the kernel from the very first release, so I believe the assumption is safe here.

Regarding precise:
Instead of removing the script I could leave it but alter it to check the feature (e.g. kernel version number or the option in /boot/config-`uname-r`) and undertake no actions in the script if we have this module compiled in.

> Trusty had vesafb build in the kernel from the very first release, so I believe the assumption is safe here.

Well no, one could still run a self-built kernel.

So I think for an SRU it would be safer to not drop the script, but instead do some 2>/dev/null to quiesce the error.

> do some 2>/dev/null to quiesce the error.

or if that's not possible (because it's the kernel who spits out errors, but that's unlikely), it could also do "if modinfo vesafb >/dev/null 2>&1; then modprobe -q vesafb; fi"

Actually I think the second approach would be better, since the error comes not from the message (which is redirected to upstart logs anyway), but from the return code of the script.

Unfortunately, according to my knowledge, the upstart scripts are executed with the "-e" switch making it stop with a failure on a first failed call. This ties our hands a bit as we cannot have any failing commands there (even those we expect to fail in a particular configuration) and makes our potential script less flexible.

So in any case we would be interested in not returning anything other than 0. A commonly used work-around for this limitation could be used like this:
modprobe -q -b vesafb || true

This would load the module if available, but would remain quiet (-q switch to modprobe with additional || true) if the module is not there.

Right, protecting this with "|| true" sounds perfectly fine and safe for an SRU.

Adding new SRU proposal for Precise.

Adding new SRU proposal for Trusty.

I have uploaded new patches updated as agreed.

I sponsored these with changing the changelog to

  * udev-fallback-graphics.conf: Avoid failure if vesafb module is compiled
    in. (LP: #1367241).

as "removed the script" isn't true with those.

Hello Dariusz, or anyone else affected,

Accepted systemd into trusty-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/systemd/204-5ubuntu20.7 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Hello Dariusz, or anyone else affected,

Accepted udev into precise-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/udev/175-0ubuntu9.7 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

This bug was fixed in the package systemd - 208-8ubuntu4

---------------
systemd (208-8ubuntu4) utopic; urgency=medium

  * debian/tests/boot-and-services: Accept lower-case spelling of "command
    line" in dmesg log. Curiously the case differs between amd64 and i386..
 -- Martin Pitt <email address hidden> Thu, 18 Sep 2014 21:10:42 +0200

I have verified this on my machines, although I still wait for a verification from a user.

I will update this issue after getting the confirmation.

seems like the changes got uploaded, unsubscribing sponsors

This resolves our issue, so +1 on the migration from proposed.

TWC Service, which package and version did you test?

@TWC Service Thank you for checking this.

Its not clear for which release the verification of this SRU took place, so I'm changing the tag back to verification-needed. Since this is being fixed in two releases the tag verification-done-precise or verification-done-trusty should be added to the bug report.

This script cannot be simply removed, other parts of the boot recovery rely on the events it triggers by existing. Removing this wholesale breaks plymouth-splash.conf in the face of no "primary" displays being detected, and prevents us from loading the display manager of choice.

The fix as applied in the SRUs works correctly. There is a new bug filed for the fallout from this in utopic. Bug #1375805. We will use that one to reinstate it and fix it to match the SRU fix here.

TWC Service verified trusty. Adding correct tag.

The verification of the Stable Release Update for systemd has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

This bug was fixed in the package systemd - 204-5ubuntu20.7

---------------
systemd (204-5ubuntu20.7) trusty; urgency=medium

  * udev-fallback-graphics.conf: Avoid failure if vesafb module is compiled
    in. (LP: #1367241).
 -- Dariusz Gadomski <email address hidden> Fri, 12 Sep 2014 13:31:52 +0200

Verification done for Precise

This bug was fixed in the package udev - 175-0ubuntu9.7

---------------
udev (175-0ubuntu9.7) precise; urgency=low

  * udev-fallback-graphics.conf: Avoid failure if vesafb module is compiled
    in. (LP: #1367241).
 -- Dariusz Gadomski <email address hidden> Fri, 12 Sep 2014 13:29:08 +0200