After using the latest Ubuntu Long Term Support release (14.04) on my laptop for the past few weeks, I upgraded my home workstation on Friday. And hit a few upgrade challenges I thought worth jotting down for posterity (and the next poor sucker who can't find an answer on Google).
(Yes, I did install on my laptop a few weeks early -- I was traveling for a conference and 12.04 was practically unusable on the thing, nice performance improvments on 14.04, and no issues with it -- but I did do a clean install).
Upgrade process
I kicked it off before leaving for work on Friday, and when I returned that evening, the screen was still up waiting for a decision of how to handle a changed /etc file -- typical for these kinds of upgrades. Had to respond to the 7 - 8 files we manage in Salt -- mainly keeping the installed version, except for the apache2.conf.
I did get one question I wasn't sure how to answer -- choice of Display Manager, between GDM and LightDM. I went with the default, LightDM.
Installation finished, and rebooted.
First issue: Grub reported "hwmatch command not found", and some file not found errors. That did not seem to affect anything -- pressing a key continued to boot. The splash screen came up, booting progressed.
Second issue: And then I came to a black screen with a flashing _ in the upper left corner. And... nothing. No way to proceed. Basically the display manager failed to start, and at that point I could not even switch to a VT (e.g. use Ctrl-Alt-F1).
After forcing a restart and experimenting, I found that I could switch to a VT if I did it while the splash screen was visible. And from there I could log in, and as long as I didn't go to vt7 (where the login screen should be) I had full control of the system. And I could finish booting into a full graphical mode using "sudo stop lightdm; sudo start lightdm". And from there everything was fine. I also tried starting GDM, and that took me into Gnome by default instead of Unity -- a bit confusing, but it worked fine. But it still failed on a normal boot.
I tried dpkg-reconfigure lightdm, and that did not fix the issue, either.
Finally I did a dpkg-reconfigure gdm, switched to GDM, and I finally had a fully bootable system, with GDM.
Once that succeeded, dpkg-reconfigure lightdm allowed me to switch back to lightdm, and this time it worked completely fine.
So to solve a problem getting a display manager to successfully start, try switching to another display manager and then switch back.
I have not yet solved the first issue.
Apache challenges
As a dev workstation, I had a bunch of Apache virtual hosts set up, and these have been a scripted setup. While Apache and MariaDB upgraded cleanly, all my virtual hosts running Drupal failed, for several different reasons:
First, the conf files in /etc/apache2/sites-enabled did not get loaded because they did not end in .conf. Came up with a slick way to rename them:
john@Freelock-07:/etc/apache2/sites-enabled$ find . -not -name "*.conf" -type l -exec bash -c 'echo mv "$0" "$0.conf"' {} \;
(actually I did this in sites-available with -type f, then deleted the broken symlinks in sites-enabled and used a2ensite to enable the ones I was working on).
Next I was getting access denied errors. It turns out the syntax for allowing access has changed, between Apache 2.2 and 2.4. Now instead of the two lines:
Order Deny,Allow
Allow from all
... you need to use the new require syntax:
Require all granted
I also had trouble because our code is outside the /var/www/* path, and symlinked in. I have not found a way to get this directive to apply to a parent directory of all my web sites -- so I'm having to add it in a <Directory> block inside each virtual host configuration, with the full path specified.
Finally, one more challenge: friendly URLs. It took me a bit to notice, because I was starting with a new site install, that URL rewriting was disabled, and all my Drupal paths were rewritten using the ?q= argument handler. mod_rewrite was enabled, everything looked fine, but nothing in the .htaccess file was getting read. I already had AllowOverrides All set in a parent directory, but that, too had to be moved into a <Directory> block for the site root.
So as best I can tell, the key difference here in the Apache 2.2 - 2.4 upgrade is that AllowOverride and access rules that are in parent directories of a DocumentRoot are entirely ignored -- you will need to specify these for each DocumentRoot.
Now to get compass working again...
Industry
Add new comment