Ubuntu

System halts instead of rebooting (Award 6.00 PG BIOS)

Reported by Jeremy LaCroix on 2005-09-26
28
Affects Status Importance Assigned to Milestone
linux-source-2.6.15 (Ubuntu)
Medium
Ben Collins

Bug Description

I just wiped my hard drive, and installed Ubuntu Breezy Colony 5. When it was
finished installing, it said remove the cd and press enter to reboot. I did, and
it said that it was rebooting, and it actually shut down, causing me to have to
manually turn it back on. When selecting reboot from the logout menu during
using the installed product, it says that its rebooting but it just shut down.
With the previous Breezy version I had it worked fine.

Sebastien Bacher (seb128) wrote :

Thanks for your bug. Does the reboot work from the gdm login screen?

I just tried it. Rebooting from the GDM/Ubuntu Login Screen shuts down the PC
instead.

Sebastien Bacher (seb128) wrote :

what happens if you restart your box with "sudo shutdown -r now"?

Same problem again. I had to manually turn my PC back on.

Sebastien Bacher (seb128) wrote :

Thanks, that's not a desktop issue since it happens from the command line too,
reassigning

Matt Zimmerman (mdz) wrote :

What is the last message printed by the system before it shuts down? It will
contain either "Restarting system" or "System halted".

I don't know actually, it all goes by really fast.

Matt Zimmerman (mdz) wrote :

Please watch and see if you can make it out; it's important.

Sorry, it says that it's rebooting in red text, then rebooting right before it
turns off.

Just in case you needed to know, I have:
900mhz AMD Athlon
256MB Geforce
512MB RAM
80GB Drive
(Not sure if that's important).

Also, not sure if this matters, or if any of this is related, but here is some
more info:
1.) When I boot up, I get some errors about error inserting modules or something
like that, but it stays on the screen two seconds before the NVidia Logo comes up.
2.) I haven't had this problem with previous Breezy releases, I was upgraded
from Hoary via APT. My wife upgraded from Hoary as well, she doesn't have this
problem. This problem for me started when I did a fresh install of Colony CD 5
after wiping my drive.

Matt Zimmerman (mdz) wrote :

Please attach /var/log/dmesg, and the output from "sudo dmidecode".

Try booting with the "reboot=b" or "reboot=h" option

Created an attachment (id=4223)
DMESG

Created an attachment (id=4224)
dmidecode

I did reboot=b at the command line, nothing happened. I rebooted and it did the
same thing.

Ben Collins (ben-collins) wrote :

reboot=b is for the GRUB command line. Reboot your machine, and when GRUB comes
up do "linux reboot=b" and hit enter. Then when the machine finishes booting,
use the reboot command and let us know if it did in fact reboot correctly.

The reboot=b is a kernel option. It will tell the kernel to use a specific
method for rebooting the machine. If reboot=b doesn't work, try reboot=h next time.

How do I get to the Grub command line?

Grondr (grondr) wrote :

I just got zapped by this, too, and I've some additional debugging data, from
two different machine; let's call them WHITE and BLACK below. They're both AMD
Athlons, but with different motherboards.

On WHITE, anything that attempts to restart (phase two of the installer, or
shutdown from the GUI, or even a restart from the LiveCD) will instead turn off
the machine. This happens w/the Colony 5 images, but did -not- happen when the
machine was running a two-year-old version of Mandrake, nor Windows 98, nor even
the Knoppix 3.7 disk I just tried while debugging this. I haven't tried any
Breezy's except Colony 5, and this machine hasn't run any other Ubuntus.

On BLACK, on the other hand, reboot from the LiveCD correctly restarts the
machine. BLACK is running Hoary, and restarting that has always worked fine.
If it's important to debugging, I can do an install on BLACK and see what
happens; I've got a spare disk on which I can do a clean install without losing
my Hoary.

I can't figure out how to try Ben Collins' reboot=b|h tests below. Typing
"linux" at Grub isn't a valid command. I tried editing the boot line inside
Grub's built-in editor to say either "boot reboot=b" or "boot reboot=h" and then
booting; neither one made any difference & I don't even know if they're noticed
on that line in the first place.

WHITE (the failing machine) has an MSI K7T Turbo 2 motherboard; BLACK (the
working machine) has an MSI K7N2 Delta-L motherboard. They also have vastly
different video hardware, FWIW, but I'm not going to go into the rest of the
machine configurations unless someone thinks it's important for debugging.

I'll attach /var/log/dmesg and the output of dmidecode for each machine in one
large attachment after I submit this.

Note that this behavior is pretty much a showstopper for me---WHITE is slated to
become an unattended server, but I can't put Breezy on it if this shutdown
behavior isn't fixed. Even if I had remote-power-cycle hardware available for
it (which I don't), the fact that the machine is commanding itself off means
that removing and resupplying power won't turn it back on, unless the correct
bit it set in the BIOS. I can do that on this particular motherboard, but it's
a fragile solution, and anyway won't work without remote power cycle, which
almost no one has. I'd therefore argue that the severity of this bug should be
increased.

Grondr (grondr) wrote :

Created an attachment (id=4261)
Working and nonworking dmesg & dmidecode output

Grondr (grondr) wrote :

Btw, after I discovered the halting behavior of the Colony 5 CD, I let the
updater run and brought the machine fully up-to-date with whatever the current
state of the network repositories, then rebooted twice (once to pick up changes
that required a reboot, and once again to see if those changes changed
anything). Nothing changed; reboot still powers off every time.

Grondr (grondr) wrote :

Despite several new kernels from various updates, this bug is still with me.
I'm still waiting for some advice on what I can do to help developers debug this
further; note that the comments to this bug contain unanswered questions about
how to run various suggested tests (such as a developer request to run a grub
command which grub rejects as illegal).

Thanks!

I agree, I have been apt-get dist-upgrading for a while now, each time hoping
this problem has been fixed, but it hasn't. I don't understand how to do what
you guys want me to.

Mirza (mirza-seznam) wrote :

I can confirm bug on my Athlon machine, 5.10 official release.

Dennis Kaarsemaker (dennis) wrote :

*** Bug 23854 has been marked as a duplicate of this bug. ***

Radu Cornea (raduc) wrote :

I can also confirm this bug on an Athlon machine, official 5.10 release.

Did a fresh install of the final Breezy version downloaded yesterday. Same
problem. To help you find the problem fast (this should nail the problem) it
worked fine on Hoary but not on Breezy. Whatever you did with Hoary worked and
whatever you are doing with Breezy does not.

Ben Collins (ben-collins) wrote :

(In reply to comment #24)
> Did a fresh install of the final Breezy version downloaded yesterday. Same
> problem. To help you find the problem fast (this should nail the problem) it
> worked fine on Hoary but not on Breezy. Whatever you did with Hoary worked and
> whatever you are doing with Breezy does not.

Yeah, that makes it really easy. Narrows it down to just a few thousand lines of
code between 2.6.10 and 2.6.12 kernels, related to the reboot code :)

Really, I need you to try those reboot= options. Edit /boot/grub/menu.lst, and
add the options to the your current config. Look near the bottom for groups of
lines. Each boot setup has a line that starts with "kernel" and ends with
something like "splash". Add the reboot=h or reboot=b option to the end of those
lines (for whatever kernel you are testing this with). Then reboot (to boot the
system with the right option) and try the reboot command again.

Thanks for explaining, you have to go easy on me because I am not an expert yet. :)

Neither option fixed the problem.

Grondr (grondr) wrote :

(In reply to comment #25)
> (In reply to comment #24)
> > Did a fresh install of the final Breezy version downloaded yesterday. Same
> > problem. To help you find the problem fast (this should nail the problem) it
> > worked fine on Hoary but not on Breezy. Whatever you did with Hoary worked and
> > whatever you are doing with Breezy does not.
>
> Yeah, that makes it really easy. Narrows it down to just a few thousand lines of
> code between 2.6.10 and 2.6.12 kernels, related to the reboot code :)

Jeremy's original report said that in "the previous Breezy version it had worked
fine". Jeremy, was that Colony 4? (I started with Colony 5, so I can't tell if
it worked at any point before that.) That might at least narrow it down a
-little- more... I can also try rebooting w/the two options and see if my
results differ from Jeremy's, but not for a few hours yet (the machine is
currently tied up doing something else), and if there's some other test that I
can run instead or in addition that would help more, let me know and I'll do all
of them when I can finally reboot.

Matt Zimmerman (mdz) wrote :

*** Bug 23379 has been marked as a duplicate of this bug. ***

To be honest I don't remember anymore when it worked during the Breezy cycle. I
know it did once though. Probably Colony 4 or 5. Sorry, I'm not much help.

Ben Collins (ben-collins) wrote :

Should be fixed in a breezy update (not sure when that will happen). Problem is
a one liner patch that was assumed removed, but wasn't.

Just wanted to say thank you to all you bugtesters, you guys really seem to care about users like
me and that's hard to find. Ubuntu rocks!

Grondr (grondr) wrote :

(In reply to comment #30)
> Should be fixed in a breezy update (not sure when that will happen). Problem is
> a one liner patch that was assumed removed, but wasn't.

Nice to know. Is there any word on when that update will go out? I've just
updated and there's still no sign of it some 12 days after your post---but I
have no idea how long the pipeline is for this sort of update.

(When it does come out---or the next time I receive a new kernel, which I'm
guessing might be the same thing---I'll report back here on whether it works or
not for me.)

Thanks!

Grondr (grondr) wrote :

I just took the offered update from 2.6.12-9 to 2.6.12-10, and this behavior has
not improved. Was the patch slated to go into that kernel? If not, how long
will it be before it winds up in an available kernel?

Thanks!

Ben Collins (ben-collins) wrote :

This bug was pending on an upload which is complete now. Closing.

I've been apt-get updating and dist-upgrading twice a day now, and its still
having the same problem.

Ben Collins (ben-collins) wrote :

With which kernel?

My kernel is 2.6.12-10-386. Should I be using the K7 kernel?

Ben Collins (ben-collins) wrote :

(In reply to comment #37)
> My kernel is 2.6.12-10-386. Should I be using the K7 kernel?

The issue is fixed in dapper with 2.6.15 kernel. There are no plans to update
breezy kernel other than for security updates.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.