Clicking reboot doesn't actually reboot the system

Bug #412825 reported by Mario Limonciello on 2009-08-13
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
ubiquity (Ubuntu)
Undecided
Unassigned
upstart (Ubuntu)
Undecided
Unassigned

Bug Description

Binary package hint: ubiquity

When operating in the gnome environment, the GTK and Mythbuntu UI's have the ability to use the gnome session dbus calls to request the system be rebooted.

Operating under XFCE, the command "reboot" is executed, but the system doesn't actually restart.

ProblemType: Bug
Architecture: i386
Date: Thu Aug 13 03:27:16 2009
DistroRelease: Ubuntu 9.10
LiveMediaBuild: Mythbuntu 9.10 "Karmic Koala" - Alpha i386 (20090812.1)
Package: ubiquity 1.99.5
ProcEnviron:
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-5.24-generic
SourcePackage: ubiquity
Uname: Linux 2.6.31-5-generic i686

Mario Limonciello (superm1) wrote :
Mario Limonciello (superm1) wrote :

This only fails in normal "live" mode. Using only-ubiquity mode, the restart button works properly.

It doesn't appear to be caused by permissions either as if you have a terminal open while pressing the reboot button in ubiquity, this message is echo'ed to the terminal:

"
Broadcast message from root@ubuntu
    (unknown) at 4:03 ...

The system is going down for reboot NOW!
"

This would lead me to believe ubiquity is doing everything correctly, but upstart(?) is not handling the reboot properly.

The wall message comes from Upstart's shutdown utility

Changed in upstart (Ubuntu):
status: New → Invalid

Scott: That's what I suspected, so how to further debug why the shutdown
isn't proceeding then even though the wall message was displayed?

On Thu, Aug 13, 2009 at 06:27, Scott James Remnant <email address hidden>wrote:

> The wall message comes from Upstart's shutdown utility
>
> ** Changed in: upstart (Ubuntu)
> Status: New => Invalid
>
> --
> Clicking reboot doesn't actually reboot the system
> https://bugs.launchpad.net/bugs/412825
> You received this bug notification because you are a member of Ubuntu
> Installer Team, which is subscribed to ubiquity in ubuntu.
>

--
Mario Limonciello
<email address hidden>

On Thu, 2009-08-13 at 12:06 +0000, Mario Limonciello wrote:

> Scott: That's what I suspected, so how to further debug why the shutdown
> isn't proceeding then even though the wall message was displayed?
>
A good start is to add "set -x" to the top of /etc/init.d/rc - that'll
at least hint which shutdown script is hanging.

Scott
--
Scott James Remnant
<email address hidden>

Mario Limonciello (superm1) wrote :

Now that syslog is working again, here's some more useful information:

Sep 2 15:02:43 ubuntu ubiquity[16945]: log-output -t ubiquity umount /target
Sep 2 15:02:43 ubuntu ubiquity: shutdown: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
Sep 2 15:02:43 ubuntu ubiquity: shutdown:sysv.c:181: Unhandled error from sysv_change_runlevel: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
Sep 2 15:02:43 ubuntu ubiquity[16945]: log-output -t ubiquity reboot

Changed in upstart (Ubuntu):
status: Invalid → New

There's a couple of bugs there, one is simply that the error is "unhandled" - could you open an Upstream bug about that alone ("shutdown: doesn't handle error from sysv_change_runlevel")

I'm not sure why it did not receive a reply, it should contact the init daemon directly.

Obvious question - is shutdown being run as a normal user or as root?

Mario Limonciello (superm1) wrote :

As ubiquity does this dance around permissions so that the UI isn't ran as root, but things executed by it are, it was a bit confusing as to whether it was actually executing reboot as root. Somehow it appears to not have been, which begs the question as to why this was working for OEM Config, or for ubiquity-only mode in the first place. It doesn't seem like it should have been.

Nonetheless, a fix should be committed now.

Changed in upstart (Ubuntu):
status: New → Invalid
Changed in ubiquity (Ubuntu):
status: New → Fix Committed
Mario Limonciello (superm1) wrote :

This was fixed with today's upload:

ubiquity (1.99.18) karmic; urgency=low

  [ Evan Dandrea ]
  * Do not provide an inaccurate remaining time estimate for the file copy
    process (LP: #199834). Thanks rugby471!
  * Call reboot as root. Thanks Mario Limonciello!
  * Don't let the user proceed past the timezone page until a selection has
    been made (LP 425011).
  * Automatic update of included source packages: partman-auto
    89ubuntu1, partman-partitioning 71ubuntu1.

  [ Michael Terry ]
  * Add a default oem-config post-install hook that restarts HAL. This lets
    HAL pick up any keyboard changes we made. LP: #395625

  [ Colin Watson ]
  * More packaging simplifications: move dh_clean arguments to debian/clean;
    remove old $(BUILDDIR) cruft; move architecture-specific
    build-dependencies to debian/control, which dpkg has supported for quite
    a while; use dh-di for partman scripts.
  * Update translations from Launchpad.
  * Fix method name to allow page changing in partitioner (LP: #427347).
  * Fix oem-config crash if the KDE frontend is detected, due to trying to
    delete UBIQUITY_MIGRATION_ASSISTANT from the environment when it's not
    there (LP: #414854).
  * Stop ubiquity-dm crashing if a process it's trying to kill doesn't exist
    (LP: #423700).

  [ Jonathan Riddell ]
  * Update path to kdesu in ubiquity-wrapper

 -- Evan Dandrea < <email address hidden>> Fri, 11 Sep 2009 19:26:50 +0100

Changed in ubiquity (Ubuntu):
status: Fix Committed → Won't Fix
status: Won't Fix → Fix Released
tags: added: iso-testing
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers