<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <br>
    <div class="moz-cite-prefix">On 09/27/2014 05:43 PM, Bert wrote:<br>
    </div>
    <blockquote
cite="mid:CACfxU0OgD_KCV_+f5=kddbodEMf2NDEDFtOxoG=8xgUx6_sCmg@mail.gmail.com"
      type="cite">
      <div dir="ltr">To David Mansfield,
        <div><br>
        </div>
        <div>My name is Bert, I'm on the Centos-Doc mailing list and
          I've been doing a bit of further write up on the C6.5 -&gt; C7
          upgrade process - basically on how to avoid common problems
          and pitfalls. In other words, give the user the best
          experience possible. I've been doing a fair bit of
          experimenting before I go ahead and "put up a bunch of
          suggested ways of doing things to avoid problematic upgrades"
          and would like to share what I've learnt so far, and ask for
          some more info.</div>
        <div>
          <div><br>
          </div>
          <div>Regarding issue #1:</div>
          <div>I too did an upgrade on that had an NTFS partition (was
            for dual-boot Windows 2008R2).  I commented out the
            mountpoint in  /etc/fstab BEFORE doing the upgrade (as
            removing ntfs3g would obviously cause mount to complain it
            didn't know about the partition, and there's no FUSE add-ons
            in the upgrade image kernel) and that avoided any problems
            for me.  It is helpful to know from your experience that the
            upgrade process ended up in an emergency shell.  This will
            scare some people, so I will be adding a specific note about
            checking for mount points (specifically that use FUSE
            add-ons) and a suggestion to comment them out of /etc/fstab
            before running the preupgrade advisor.</div>
          <div><br>
          </div>
          <div>I suggest commenting them out and unmounting before
            running the advisor because (from what I gather) the tool
            scans and any all mount points collecting a list of files,
            which wastes time on the NTFS partition. You wouldn't expect
            someone to install Linux-related libraries or executables on
            their NTFS partition... though you never know.</div>
          <div>One system of mine also had a md RAID6 array, which I
            unmounted and commented out for the same reasons above.</div>
          <div><br>
          </div>
          <div>After the upgrade, yum isntall ntfs-3g went as expected,
            and un-commenting the mountpoint got it mounting again.</div>
          <div>I'm glad that worked for you in the end.</div>
          <div><br>
          </div>
          <div>Perhaps there are issues with automount that you were
            encountering prior to the upgrade.  With the new </div>
          <div><br>
          </div>
          <div>Regarding issue #2:</div>
          <div>My write-up basically guides the user through removing
            (read as exorcising if you'll pardon the expression)
            anything X Window System and Gnome related before running
            the upgrade advisor (at least for the last time).</div>
          <div>I include the X window system packages because there have
            been a few changes that I suspect would lead to a "bad
            experience".  Some preferences seem to have been brought
            across after a re-install once running C7.</div>
          <div><br>
          </div>
          <div>There was a couple of tricks I did before the upgrade.</div>
          <div>1. Change to runlevel 3 so the GUI doesn't start up
            straight after the upgrade.  (i.e. get to a text-only shell)
            so we can re-install our GUI aftewards.<br>
          </div>
          <div>2. Removed X, Gnome and MESA packages.</div>
          <div><br>
          </div>
          <div>I had disabled NetworkManager and for the interfaces in
            the ifcfg scripts so I can't comment on NM-related issues
            but there were a few niggles after the upgrade.   </div>
          <div><br>
          </div>
          <div>Post upgrade...</div>
          <div><br>
          </div>
          <div>yum groups mark convert <br>
          </div>
          <div>to fix the group package assignment changes between C6
            and C7.</div>
          <div><br>
          </div>
          <div>yum groups install "GNOME Desktop" "Graphical
            Administration Tools"<br>
          </div>
          <div>to install GNOME again... It's no longer "yum
            groupinstall ....."</div>
          <div><br>
          </div>
          <div>This more/less got GNOME up and running again for me
             (via VNC server)</div>
          <div><br>
          </div>
          <div>Once in GNOME, use the package maanger to install
            anything else.</div>
          <div><br>
          </div>
          <div>
            <div>/etc/inittab is no longer relevant.  Use </div>
            <div>ln -sf /lib/systemd/system/graphical.target
              /etc/systemd/system/default.target<br>
            </div>
            <div>to get X and your window manager starting up by
              default.</div>
          </div>
          <div><br>
          </div>
          <div>Network manager:</div>
          <div>Was starting again by default.   Once I got around that,
            and switching over to fiewall-cmd (from plain IPTABLES) and
            setting up an appropriate zone, my networking has been fine.</div>
          <div><br>
          </div>
          <div>May I ask, why did you choose to install MATE?  Could you
            not get GNOME working?</div>
          <div>Can anyone else comment on NM?  (before and after)</div>
          <br>
        </div>
      </div>
    </blockquote>
    <br>
    <br>
    Hi Bert,<br>
    <br>
    Here's another NetworkManager one that I just learned about which
    took about 30 minutes hard debugging to find out (and I'm not the
    first one to be bitten, see link below).<br>
    <br>
    (Regarding MATE - It's our desktop of choice because it's MUCH more
    friendly for remote access.  We used NX and the x2go for a long
    time, and GNOME3 was broken in that environment.  Recently we
    starting using VM's and SPICE, and although it runs (with software
    3d emulation) it's a slow, fat, pig so we prefer MATE.  So it all
    boils down to remote access...)<br>
    <br>
    Openvpn in C7 does not allow for "md5" signed certificates by
    default, even though C6 _AND_ the latest Fedora both allow them. 
    The clue is in the client side log:<br>
    <br>
    <code>Mon Jul 14 16:24:23 2014 us=213271 TLS_ERROR: BIO read
      tls_read_plaintext error: error:14090086:SSL
      routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed<br>
      <br>
    </code><br>
    And the solution (as documented originally here:
    <a class="moz-txt-link-freetext" href="https://www.centos.org/forums/viewtopic.php?f=50&amp;t=47210">https://www.centos.org/forums/viewtopic.php?f=50&amp;t=47210</a>) is to
    either get re-issued certificates, or change the environment
    variables that the NetworkManager service run under. In
    /usr/lib/systemd/system/NetworkManager.service<br>
    <br>
    <pre><code>
[Service]
Environment="OPENSSL_ENABLE_MD5_VERIFY=1 NSS_HASH_ALG_SUPPORT=+MD5"

</code></pre>
    <code></code><code>Then:</code><br>
    <br>
    <pre>systemctl daemon-reload</pre>
    <pre>systemctl restart  NetworkManager.service</pre>
    <pre><code></code></pre>
    <br>
    Hope this helps someone else (I'm never going to forget!)<br>
    <br>
    Oh, and another one that I haven't figured out yet: my C7 machines I
    installed from scratch do dual logging (journalctl and
    /var/log/messages) while the upgraded one is only journalctl.<br>
    <br>
    -- <br>
    Thanks,<br>
    David Mansfield<br>
    Cobite, INC.<br>
    <br>
  </body>
</html>