Description of problem: After standard upgrade Fedora 14 running inside openvz container and reboot system is not starting. init process consumes all processor. System can be started by 'telinit 3'. Version-Release number of selected component (if applicable): upstart-1.2-2.fc14.x86_64 upstart-sysvinit-1.2-2.fc14.x86_64 How reproducible: Update any running inside openVZ (Virtuozzo) container Fedora 14. Steps to Reproduce: 1. Update upstart on any running inside openVZ (Virtuozzo) container Fedora 14. 2. Reboot. Actual results: System going to unknown runlevel: root@luxon /]# ps axu USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 1 94.7 0.1 2780 1112 ? Rs 19:56 0:13 init root 1090 0.0 0.0 11232 576 ? Ss 19:56 0:00 vzctl: ttyp0 root 1091 0.0 0.1 3116 1572 ttyp0 Ss 19:56 0:00 -bash root 1105 0.0 0.0 2480 700 ? S<s 19:56 0:00 /sbin/udevd -d root 1121 0.0 0.0 2476 616 ? S< 19:56 0:00 /sbin/udevd -d root 1122 0.0 0.0 2476 668 ? S< 19:56 0:00 /sbin/udevd -d root 1199 0.0 0.0 2664 852 ttyp0 R+ 19:56 0:00 ps axu [root@luxon /]# runlevel unknown [root@luxon /]# Expected results: Normal boot.
Can you please boot without "rghgb quite" but with "init=/sbin/init --verbose" and attach output here? Can you boot into runlevel 1 ?
It is OS-level virtualized container. The same bug is submitted in openvz bugzilla. I can't understand why upstart version vas changed during release lifecycle. if runlevel 1 is activated in /etc/inittab (id:1:initdefault:): [root@luxon /]# runlevel unknown [root@luxon /]# ps axu USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 1 98.2 0.1 2780 1112 ? Rs 16:49 1:00 init ^^^^^^^^^^^^^^^^^^^ root 1090 0.0 0.0 2480 704 ? S<s 16:49 0:00 /sbin/udevd -d root 1099 0.0 0.0 2476 620 ? S< 16:49 0:00 /sbin/udevd -d root 1100 0.0 0.0 2476 672 ? S< 16:49 0:00 /sbin/udevd -d root 1170 0.0 0.0 11232 492 ? Rs 16:49 0:00 vzctl: pts/0 root 1171 0.0 0.1 3116 1576 pts/0 Ss 16:49 0:00 -bash root 1197 0.0 0.0 2664 856 pts/0 R+ 16:50 0:00 ps axu The same thing.
I've reproduced your problem and probably found problem part. This build [1] works for me. Please try it. [1] http://plautrba.fedorapeople.org/upstart/
temporary scratch build http://koji.fedoraproject.org/koji/taskinfo?taskID=3100537
I just had the same problem with a Fedora 14 container under OpenVZ. I rebuilt the above upstart-1.2-3 for 32 bit and it fixed things for me.
I can confirm that http://plautrba.fedorapeople.org/upstart/ fixes the issue. Is this going to be pushed upstream?
Hardly. Upstream changed logger from syslog to kmsg and above upstart just reverts patch [1] with this change. It seems to me that openvz technology doesn't support /dev/kmgs queue. [1] http://bazaar.launchpad.net/~upstart-devel/upstart/trunk/revision/1260
oh. should I expect this issue with every upcoming release of fedora then?
Since Fedora 15, upstart init was replaced with systemd and systemd and it looks like that there is similar problem with systemd, see #708629
This message is a notice that Fedora 14 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 14. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '14' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 14 reached end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping