I have just completed the upgrade from F23 to F24 and rebooted to the new version.
The system now boots to console mode and I have to login and type startx to get to KDE. F23 started X and KDE automagically.
I also seem to have lost some libraries. e.g. the 32-bit version of libncurses.so.5
Several daemons failed to start at reboot. These include all those in rc.local (yes. I do still have a few.) and openvpn.
Running rc.local manually works and starting openvpn manually with systemctl also works.
What could cause these issues?
Cheers and thanks, Stephen
On 11/26/2016 07:58 PM, Stephen Davies wrote:
Several daemons failed to start at reboot. These include all those in rc.local (yes. I do still have a few.) and openvpn.
Running rc.local manually works and starting openvpn manually with systemctl also works.
systemctl enable rc-local.service and systemctl enable openvpn@yourvpn
On 27/11/16 15:13, Samuel Sieb wrote:
On 11/26/2016 07:58 PM, Stephen Davies wrote:
Several daemons failed to start at reboot. These include all those in rc.local (yes. I do still have a few.) and openvpn.
Running rc.local manually works and starting openvpn manually with systemctl also works.
systemctl enable rc-local.service and systemctl enable openvpn@yourvpn _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org
Both have been enabled ever since systemctl was introduced and, as I said earlier, manually entering systemctl start openvpn@server works.
On 11/26/2016 08:46 PM, Stephen Davies wrote:
On 27/11/16 15:13, Samuel Sieb wrote:
On 11/26/2016 07:58 PM, Stephen Davies wrote:
Several daemons failed to start at reboot. These include all those in rc.local (yes. I do still have a few.) and openvpn.
Running rc.local manually works and starting openvpn manually with systemctl also works.
systemctl enable rc-local.service and systemctl enable openvpn@yourvpn
Both have been enabled ever since systemctl was introduced and, as I said earlier, manually entering systemctl start openvpn@server works.
Were enabled, but are they still enabled? Sometimes the settings change over versions.
On 11/27/16 12:43, Samuel Sieb wrote:
On 11/26/2016 07:58 PM, Stephen Davies wrote:
Several daemons failed to start at reboot. These include all those in rc.local (yes. I do still have a few.) and openvpn.
Running rc.local manually works and starting openvpn manually with systemctl also works.
systemctl enable rc-local.service and systemctl enable openvpn@yourvpn
There is no need to enable rc-local since it is a "static" service.
All that is required is that /etc/rc.d/rc.local is executable.
See the comments in /usr/lib/systemd/system/rc-local.service for details.
On 11/26/2016 08:49 PM, Ed Greshko wrote:
On 11/27/16 12:43, Samuel Sieb wrote:
On 11/26/2016 07:58 PM, Stephen Davies wrote:
Several daemons failed to start at reboot. These include all those in rc.local (yes. I do still have a few.) and openvpn.
Running rc.local manually works and starting openvpn manually with systemctl also works.
systemctl enable rc-local.service and systemctl enable openvpn@yourvpn
There is no need to enable rc-local since it is a "static" service.
All that is required is that /etc/rc.d/rc.local is executable.
See the comments in /usr/lib/systemd/system/rc-local.service for details.
Ok, thanks. I've never used it yet, but now I do remember a thread on that a while back.
On 11/26/2016 07:58 PM, Stephen Davies wrote:
I have just completed the upgrade from F23 to F24 and rebooted to the new version.
The system now boots to console mode and I have to login and type startx to get to KDE. F23 started X and KDE automagically.
I think you have to enable the display manager, but I don't use KDE, so I'm not sure which one it is. I think it's sddm, so try systemctl enable sddm.
I also seem to have lost some libraries. e.g. the 32-bit version of libncurses.so.5
No idea, was it a third-party application that required it?
On 27/11/16 15:14, Samuel Sieb wrote:
On 11/26/2016 07:58 PM, Stephen Davies wrote:
I have just completed the upgrade from F23 to F24 and rebooted to the new version.
The system now boots to console mode and I have to login and type startx to get to KDE. F23 started X and KDE automagically.
I think you have to enable the display manager, but I don't use KDE, so I'm not sure which one it is. I think it's sddm, so try systemctl enable sddm.
I also seem to have lost some libraries. e.g. the 32-bit version of libncurses.so.5
No idea, was it a third-party application that required it? _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org
Both of these worked fine with F23. The upgrade somehow broke them. Nothing else has changed since yesterday when everything worked as expected.
On 11/26/2016 08:48 PM, Stephen Davies wrote:
Both of these worked fine with F23. The upgrade somehow broke them. Nothing else has changed since yesterday when everything worked as expected.
Yes, there was some change from 23 to 24 that sometimes caused that problem. Try enabling sddm or find out which window manager is used for login for KDE.
On 11/27/16 12:50, Samuel Sieb wrote:
On 11/26/2016 08:48 PM, Stephen Davies wrote:
Both of these worked fine with F23. The upgrade somehow broke them. Nothing else has changed since yesterday when everything worked as expected.
Yes, there was some change from 23 to 24 that sometimes caused that problem. Try enabling sddm or find out which window manager is used for login for KDE.
Well, FWIW, any window manager will work just fine. I have two systems installed with both GNOME and KDE as options. One is running GDM and the other SDDM. No issues.
I'm not certain, but I believe F23 used to use KDM.
So, yes, the OP should ensure that one of those are enabled and that it started properly.
[egreshko@meimei ~]$ systemctl status sddm ● sddm.service - Simple Desktop Display Manager Loaded: loaded (/usr/lib/systemd/system/sddm.service; enabled; vendor preset: ena Active: active (running) since Tue 2016-11-22 07:37:06 CST; 5 days ago Docs: man:sddm(1) man:sddm.conf(5) Main PID: 1257 (sddm) Tasks: 3 (limit: 512) CGroup: /system.slice/sddm.service ├─1257 /usr/bin/sddm └─5283 /usr/libexec/Xorg -nolisten tcp -auth /var/run/sddm/{16a38934-d60d
Nov 22 07:37:06 meimei systemd[1]: Started Simple Desktop Display Manager.
for example.
On 27/11/16 15:29, Ed Greshko wrote:
On 11/27/16 12:50, Samuel Sieb wrote:
On 11/26/2016 08:48 PM, Stephen Davies wrote:
Both of these worked fine with F23. The upgrade somehow broke them. Nothing else has changed since yesterday when everything worked as expected.
Yes, there was some change from 23 to 24 that sometimes caused that problem. Try enabling sddm or find out which window manager is used for login for KDE.
Well, FWIW, any window manager will work just fine. I have two systems installed with both GNOME and KDE as options. One is running GDM and the other SDDM. No issues.
I'm not certain, but I believe F23 used to use KDM.
So, yes, the OP should ensure that one of those are enabled and that it started properly.
[egreshko@meimei ~]$ systemctl status sddm ● sddm.service - Simple Desktop Display Manager Loaded: loaded (/usr/lib/systemd/system/sddm.service; enabled; vendor preset: ena Active: active (running) since Tue 2016-11-22 07:37:06 CST; 5 days ago Docs: man:sddm(1) man:sddm.conf(5) Main PID: 1257 (sddm) Tasks: 3 (limit: 512) CGroup: /system.slice/sddm.service ├─1257 /usr/bin/sddm └─5283 /usr/libexec/Xorg -nolisten tcp -auth /var/run/sddm/{16a38934-d60d
Nov 22 07:37:06 meimei systemd[1]: Started Simple Desktop Display Manager.
for example.
I think you are correct regarding F23 in that I have KDM installed (but now disabled) but neither GDM nor SDDM is installed.
I shall try installing and enabling SDDM.
Cheers and thanks, Stephen
On 27/11/16 16:29, Stephen Davies wrote:
On 27/11/16 15:29, Ed Greshko wrote:
On 11/27/16 12:50, Samuel Sieb wrote:
On 11/26/2016 08:48 PM, Stephen Davies wrote:
Both of these worked fine with F23. The upgrade somehow broke them. Nothing else has changed since yesterday when everything worked as expected.
Yes, there was some change from 23 to 24 that sometimes caused that problem. Try enabling sddm or find out which window manager is used for login for KDE.
Well, FWIW, any window manager will work just fine. I have two systems installed with both GNOME and KDE as options. One is running GDM and the other SDDM. No issues.
I'm not certain, but I believe F23 used to use KDM.
So, yes, the OP should ensure that one of those are enabled and that it started properly.
[egreshko@meimei ~]$ systemctl status sddm ● sddm.service - Simple Desktop Display Manager Loaded: loaded (/usr/lib/systemd/system/sddm.service; enabled; vendor preset: ena Active: active (running) since Tue 2016-11-22 07:37:06 CST; 5 days ago Docs: man:sddm(1) man:sddm.conf(5) Main PID: 1257 (sddm) Tasks: 3 (limit: 512) CGroup: /system.slice/sddm.service ├─1257 /usr/bin/sddm └─5283 /usr/libexec/Xorg -nolisten tcp -auth /var/run/sddm/{16a38934-d60d
Nov 22 07:37:06 meimei systemd[1]: Started Simple Desktop Display Manager.
for example.
I think you are correct regarding F23 in that I have KDM installed (but now disabled) but neither GDM nor SDDM is installed.
I shall try installing and enabling SDDM.
Cheers and thanks, Stephen _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org
Installing SDDM did the trick. I didn't need to enable it. The install did that too.
On 11/27/16 14:32, Stephen Davies wrote:
Installing SDDM did the trick. I didn't need to enable it. The install did that too.
Good.
Now that I think about it, I think any install of a DM results in it being enabled and if any DM was previously installed is disable. It is this same thing that results when using the --force option when enabling a DM.
On 11/27/16 11:58, Stephen Davies wrote:
I also seem to have lost some libraries. e.g. the 32-bit version of libncurses.so.5
FYI....
[egreshko@meimei ~]$ dnf whatprovides /usr/lib/libncurses.so.5
ncurses-compat-libs-6.0-6.20160709.fc24.i686 : Ncurses compatibility libraries Repo : @System
ncurses-compat-libs-6.0-5.20160116.fc24.i686 : Ncurses compatibility libraries Repo : fedora
ncurses-compat-libs-6.0-6.20160709.fc24.i686 : Ncurses compatibility libraries Repo : updates
[egreshko@meimei ~]$ rpm -q ncurses-compat-libs ncurses-compat-libs-6.0-6.20160709.fc24.x86_64 ncurses-compat-libs-6.0-6.20160709.fc24.i686
So, if you "lost" that just make sure they are installed/updated.
On 27/11/16 15:22, Ed Greshko wrote:
On 11/27/16 11:58, Stephen Davies wrote:
I also seem to have lost some libraries. e.g. the 32-bit version of libncurses.so.5
FYI....
[egreshko@meimei ~]$ dnf whatprovides /usr/lib/libncurses.so.5
ncurses-compat-libs-6.0-6.20160709.fc24.i686 : Ncurses compatibility libraries Repo : @System
ncurses-compat-libs-6.0-5.20160116.fc24.i686 : Ncurses compatibility libraries Repo : fedora
ncurses-compat-libs-6.0-6.20160709.fc24.i686 : Ncurses compatibility libraries Repo : updates
[egreshko@meimei ~]$ rpm -q ncurses-compat-libs ncurses-compat-libs-6.0-6.20160709.fc24.x86_64 ncurses-compat-libs-6.0-6.20160709.fc24.i686
So, if you "lost" that just make sure they are installed/updated.
Sure enough, ncurses-compat-libs for i686 had become "uninstalled". Why do these things break at upgrade?
On 11/27/16 12:57, Stephen Davies wrote:
On 27/11/16 15:22, Ed Greshko wrote:
On 11/27/16 11:58, Stephen Davies wrote:
I also seem to have lost some libraries. e.g. the 32-bit version of libncurses.so.5
FYI....
[egreshko@meimei ~]$ dnf whatprovides /usr/lib/libncurses.so.5
ncurses-compat-libs-6.0-6.20160709.fc24.i686 : Ncurses compatibility libraries Repo : @System
ncurses-compat-libs-6.0-5.20160116.fc24.i686 : Ncurses compatibility libraries Repo : fedora
ncurses-compat-libs-6.0-6.20160709.fc24.i686 : Ncurses compatibility libraries Repo : updates
[egreshko@meimei ~]$ rpm -q ncurses-compat-libs ncurses-compat-libs-6.0-6.20160709.fc24.x86_64 ncurses-compat-libs-6.0-6.20160709.fc24.i686
So, if you "lost" that just make sure they are installed/updated.
Sure enough, ncurses-compat-libs for i686 had become "uninstalled". Why do these things break at upgrade?
Well, usually they "break" when the upgrade process determines that no other package uses that library.
-
Ed Greshko -
Samuel Sieb -
Stephen Davies