Networking not automaticly starting after upgrade from 3.4 to 4.0

[notfixingit]

Have a weird issue with a server that was upgraded from 3.4 to 4.0 where network interfaces do not come up on boot after following the 3.4 to 4.0 upgrade guide.

Nothing on console during boot that would explain anything and I don't see anything in the logs so far that would explain it either. Connecting to console and doing "systemctl start networking" and everything works. Doing a "systemctl enable networking" does not seem to affect anything either.


I'm at a loss here, any thoughts?

 

[notfixingit]

Finally found what I think is the issue using journalctl -b (still getting use to systemd)

Oct 23 20:33:00 pve1 systemd-sysv-generator[277]: Ignoring creation of an alias umountiscsi.service for itself
Oct 23 20:33:00 pve1 systemd[1]: [/run/systemd/generator.late/qemu-server.service:7] Failed to add dependency on +iscsi.service, ignoring: Invalid argument
Oct 23 20:33:00 pve1 systemd[1]: [/run/systemd/generator.late/vz.service:7] Failed to add dependency on +iscsi.service, ignoring: Invalid argument
Oct 23 20:33:00 pve1 systemd[1]: [/run/systemd/generator.late/rgmanager.service:7] Failed to add dependency on +vz.service, ignoring: Invalid argument
Oct 23 20:33:00 pve1 systemd[1]: [/run/systemd/generator.late/rgmanager.service:7] Failed to add dependency on +qemu-server.service, ignoring: Invalid argument
Oct 23 20:33:00 pve1 systemd[1]: Cannot add dependency job for unit display-manager.service, ignoring: Unit display-manager.service failed to load: No such file or directory.
Oct 23 20:33:00 pve1 systemd[1]: Found ordering cycle on basic.target/start
Oct 23 20:33:00 pve1 systemd[1]: Found dependency on sysinit.target/start
Oct 23 20:33:00 pve1 systemd[1]: Found dependency on networking.service/start
Oct 23 20:33:00 pve1 systemd[1]: Found dependency on openvswitch-switch.service/start
Oct 23 20:33:00 pve1 systemd[1]: Found dependency on basic.target/start
Oct 23 20:33:00 pve1 systemd[1]: Breaking ordering cycle by deleting job networking.service/start
Oct 23 20:33:00 pve1 systemd[1]: Job networking.service/start deleted to break ordering cycle starting with basic.target/start

 

[notfixingit]

Got a little further by doing the below (I did a fresh install on another box and did not see these enabled):

systemctl disable qemu-server
systemctl disable vz
systemctl disable rgmanager

Maybe there is a better way to clean these up?

Now I'm at this:

Oct 24 00:47:52 pve1 systemd-sysv-generator[277]: Ignoring creation of an alias umountiscsi.service for itself
Oct 24 00:47:52 pve1 systemd[1]: Cannot add dependency job for unit display-manager.service, ignoring: Unit display-manager.service failed to load: No such file or directory.
Oct 24 00:47:52 pve1 systemd[1]: Found ordering cycle on basic.target/start
Oct 24 00:47:52 pve1 systemd[1]: Found dependency on sysinit.target/start
Oct 24 00:47:52 pve1 systemd[1]: Found dependency on networking.service/start
Oct 24 00:47:52 pve1 systemd[1]: Found dependency on openvswitch-switch.service/start
Oct 24 00:47:52 pve1 systemd[1]: Found dependency on basic.target/start
Oct 24 00:47:52 pve1 systemd[1]: Breaking ordering cycle by deleting job networking.service/start
Oct 24 00:47:52 pve1 systemd[1]: Job networking.service/start deleted to break ordering cycle starting with basic.target/start

Being new to systemd and I'm not sure how to track down a ordering problem or why this particular system would have this issue, any help would be appreciated.

 

[notfixingit]

Made it a little farther...


time-sync.target
tsort: -: input contains a loop:
tsort: apparmor.service
tsort: sysinit.target
tsort: uuidd.socket
tsort: sockets.target
tsort: basic.target
tsort: openvswitch-switch.service
tsort: networking.service
tsort: network.target
tsort: network-online.target
tsort: mnt-pve-backups.mount
tsort: remote-fs.target
apparmor.service
tsort: -: input contains a loop:
tsort: openvswitch-switch.service
tsort: networking.service
tsort: network.target
tsort: network-online.target
tsort: mnt-pve-backups.mount
tsort: remote-fs.target
tsort: console-screen.service
tsort: sysinit.target
tsort: uuidd.socket
tsort: sockets.target
tsort: basic.target

 

[dietmar]

systemctl disable vz
systemctl disable rgmanager

There is no openvz or rgmanager on Proxmox 4.0, so you can do:

# dpkg --purge vzctl
# dpkg --purge rgmanager

 

[notfixingit]

There is no openvz or rgmanager on Proxmox 4.0, so you can do:

# dpkg --purge vzctl
# dpkg --purge rgmanager

FYI doing purge still leaves /etc/init.d/rgmanager for some reason?? I've also noticed a bunch of other files left after upgrade in /etc/init.d

Items in /etc/init.d after upgrade that's not in a fresh install:
clvm
cman
cpglockd
openvswtich-switch
pvebanner
pvenetcommit
qemu-server
rbdmap
rgmanager


Removing /etc/init.d/openvswitch-switch solves networking not starting on boot, the time-sync loop, and the apparmor loop. (openvswitch-switch appears to be covered now by /lib/systemd/system/openvswitch.service and for some reason the init.d version was messing with systemd ordering). Why this particular system has this issue and another system that was upgraded does not, I have no idea since the one that worked and is fine has the init.d script also.

Can the above list just be deleted or is there maybe a better way to clean these up after a upgrade from 3.4 to 4.0?

If so maybe the purging and how to properly clean up init.d could be added to the upgrade guide?


Thank you for the help on this Dietmar, it's much appreciated.

 

[dietmar]

If so maybe the purging and how to properly clean up init.d could be added to the upgrade guide?

Yes, we should document that - after careful testing. I think we need to purge

vzctl
rgmanager
cman

and simply remove the other stale files? Or maybe it is better to implement that in the package upgrade scripts?

 

[notfixingit]

Package upgrade scripts would make sense or a post install script. I'll leave the system that upgraded successfully but still has these files untouched for now, if you guys come up with a method that you want to do I would be happy to test or something you would like me to try, let me know.

 

[dietmar]

seems cman and rgmanager belongs to package redhat-cluster-pve, so you need to purge redhat-cluster-pve

 

[notfixingit]

That appears to have worked, thanks =)