dist-upgrade from 12.04 -> 14.04 axes /etc/X11/xorg.conf

I'm not certain the release upgrader made this change. xorg_fix_proprietary.py does look at xorg.conf but it doesn't back it up and it doesn't look like it ran during your upgrade.

2014-04-14 08:45:36,097 DEBUG Running PostInstallScript: './xorg_fix_proprietary.py'
2014-04-14 08:45:36,134 ERROR got error from PostInstallScript ./xorg_fix_proprietary.py (Failed to execute child process "./xorg_fix_proprietary.py" (No such file or directory))

Hmm, both myself and rhpot1991 were affected by this on two separate boxes after upgrade process. Wonder if it's some postinst that's doing it then.

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

I upgraded two boxes from 12.04 to 13.04. On both boxes xorg.conf was renamed. This caused a DPI issue on one box, and removed several vdpau fixes on both boxes.

Correction 14.04 not 13.04, sorry.

I think it's likely the nvidia prime postrm script that did it.

snippet:

case "$1" in
    purge|remove|upgrade|failed-upgrade|abort-install|abort-upgrade|disappear)
        # Remove the xorg.conf
        if [ -f $xorg_conf ]; then
            mv $xorg_conf $xorg_conf.$now
        fi

Actually - nvidia-prime seems less likely now that I read gpu-manager code. It's a "new" tool for upgrades, and consequently would run it's enable_nvidia routine the first boot.

It checks how many cards are in the system, and if it only finds 1, removes the old xorg.conf without making a new one.

    /* See if enabling the driver failed */
    if (status) {
        /* If xorg.conf exists, make sure it contains
         * the right BusId and NO NOUVEAU or FGLRX. If it doesn't, create a
         * xorg.conf from scratch */
        if (!check_vendor_bus_id_xorg_conf(devices, cards_n,
                                           vendor_id, "nvidia")) {
            fprintf(log_handle, "Check failed\n");

            /* Remove xorg.conf */
            remove_xorg_conf();

            /* Only useful if more than one card is available */
            if (cards_n > 1) {
                /* Write xorg.conf */
                write_to_xorg_conf(devices, cards_n, vendor_id);
            }
        }
        else {
            fprintf(log_handle, "No need to modify xorg.conf. Path: %s\n", xorg_conf_file);
        }
    }

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

Attaching gpu-manager log that shows xorg.conf being removed.

I've come up with a patch for this and submitted a pull request.

https://github.com/tseliot/ubuntu-drivers-common/pull/8

This bug was fixed in the package ubuntu-drivers-common - 1:0.2.92.2

---------------
ubuntu-drivers-common (1:0.2.92.2) utopic; urgency=medium

  * gpu-manager.c:
    - Revert switch to the intel driver from modesetting until
      some issues are fixed.
 -- Alberto Milone <email address hidden> Mon, 28 Apr 2014 18:37:02 +0200

Based on #13, should I attempt another LTS upgrade to 14.04 with a system having Nvidia graphics to see if the xorg.conf no longer gets deleted? Just let me know, I have additional systems ready to test with and would be happy to validate the fix.

Unfortunately that only means it was fixed in 14.10. It still needs to be SRU'ed into 14.04.

Hello Mario, or anyone else affected,

Accepted ubuntu-drivers-common into trusty-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/ubuntu-drivers-common/1:0.2.91.5 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!

Based on #16, I submit the same question as I asked in #14... "Ready for me to test another 12.04 --> 14.04 LTS upgrade at this point?" Please confirm and I will kick one off.

Since it says "Please test proposed package" in #16, is there any special steps I need to perform when doing the LTS upgrade to insure I actually test the proposed package?

Before you reboot after doing the dist upgrade you should fetch that
package specifically from the proposed repository and install it. It will
run the first time you reboot after the upgrade.
On May 26, 2014 8:25 PM, "Michael Lueck" <email address hidden> wrote:

> Based on #16, I submit the same question as I asked in #14... "Ready for
> me to test another 12.04 --> 14.04 LTS upgrade at this point?" Please
> confirm and I will kick one off.
>
> Since it says "Please test proposed package" in #16, is there any
> special steps I need to perform when doing the LTS upgrade to insure I
> actually test the proposed package?
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1307546
>
> Title:
> dist-upgrade from 12.04 -> 14.04 axes /etc/X11/xorg.conf
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/mythbuntu/+bug/1307546/+subscriptions
>

I apologize, I find I have drained my supply of test systems with custom xorg.conf files. The rest of them are simple machines directly attached to their display, thus get by just fine without any xorg.conf file at all. The more complex configurations are at my desk where I make use of a KVM switch, thus require xorg.conf files as the system can not directly communicate with my display - the KVM switch blocks direct access.

Someone else will need to test this.

Michael,

You can make an xorg.conf that doesn't functionally change anything for example: http://askubuntu.com/questions/217758/how-to-make-an-xorg-conf-file

After you make the xorg.conf and put it in place, reboot to make sure the system still boots with it.

If it does, do the dist-upgrade, install the proposed package and then reboot.

If the xorg.conf remains in place then this bug is fixed. If it gets renamed, then you have hit the bug again.

I've verified that this is fixed on an upgrade from Mythbuntu 12.04.4 to Mythbuntu 14.04. I tested this inside an Virtualbox VM, by creating a default xorg.conf file. The xorg.conf file remains in it's location (/etc/X11/xorg.conf) and is untouched after the upgrade.

Attached is the xorg.conf file I used in my testing

I set the tag back to verification-needed after consulting the wiki, it appears the SRU team is supposed to handle that. My testing was still successful.

I confirmed the proposed update in #16 on an Xubuntu i386 12.04 to 14.04 LTS upgrade just now. Works flawlessly. Thank you so much! :-)

This bug was fixed in the package ubuntu-drivers-common - 1:0.2.91.5

---------------
ubuntu-drivers-common (1:0.2.91.5) trusty-proposed; urgency=medium

  * During first boot, don't remove existing xorg.conf. (LP: #1307546)
 -- Mario Limonciello <email address hidden> Fri, 18 Apr 2014 11:35:27 -0500

The verification of the Stable Release Update for ubuntu-drivers-common 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 regresssions.