On Mar 19, 2014, at 11:24 AM, "pgaltieri ." <pgaltieri(a)gmail.com> wrote:
The above series of commands do not power off the system, it resets it. Same with the
poweroff command.
What's strange is I was running 3.13.5-103 kernel without issues until I turned the
power off by hitting the switch.
I tried 2 earlier kernels, 3.12.11-201 and 3.13.5-101. Both of these worked, i.e. the
system went straight to the graphical login and a shutdown resulted in the system powering
off. What's interesting is that I tried the 3.13.5-101 kernel a couple of days ago
and it went straight to rescue mode as well. I also checked and all modules got loaded so
it looks like I can boot the older kernel and try to do an update and see if the most
recent kernel exhibits the same problem.
Well the fact you're getting different results with different kernels implies there is
a kernel bug or regression. But then the fact you're also getting different results
with a particular kernel version also, implies some kind of on-disk corruption. So if
previously working kernels are now not working, while older ones do work, then just
reinstall them.
What do you get for
smartctl -x /dev/sda
But I have no patience for corruption. I personally don't just do reinstalls for that,
because corruption is like mice. Where there's one, there's more and I go for
complete extermination by reverting to the basics: manufacturer hardware test [1], memtest
86+[2], backup then obliterate the drive contents with ATA secure erase [3], reinstall,
smartctl -t long /dev/ test followed by smartctl -x, then restore user data and apps.
Good opportunity to upgrade to Fedora 20. :-)
[1] For UEFI systems, this can be built-into the firmware, or reside on the EFI System
partition so you should inspect your ESP to see if it's there somewhere so you can
back it up for future use. Doing a 'tree /boot/efi' is useful for this. Or it may
be a separate download.
[2]
You want one of the first two, use dd to write to a USB stick.
http://www.memtest.org/#downiso
[3]
Applies to SSDs and HDDs alike.
http://mackonsti.wordpress.com/2011/11/22/ssd-secure-erase-ata-command/
A couple of other issues. First when I boot the kernel with the above
recommended options it looks like I get 2 shells.
What I see is the following:
Welcome to emergency mode! After logging in, type "journalctl -xb" to view
Welcome to rescue mode! Type "systemctl default" or ^D to enter default mode.
system logs, …...
Hmm. Well I'm dense and reversed rescue and emergency targets.
single = 1 = rescue.target
emergency.target is like runlevel 0.5, it's more minimal.
I'm not sure what's going on in your case because whether I use boot param single,
1, rescue.target, or emergency.target I don't see both emergency mode and rescue mode
on the same boot.
After I provide my password I get the expected prompt, when I hit
return I get another password prompt, another return gives me the command prompt again. I
can't type any commands in. If I do Ctrl-Alt-Delete, and wait a while, then I manage
to have only one password prompt. The other issue is that when I plug my USB stick in
the kernel detects it, since I see the messages on the console, however, it doesn't
create a device node and running fdisk -l does not show the device.
I'm going to remove the systemd.unit=rescue.target parameter
It should work since it's the same thing as single user mode.
The system was purchased in December of 2013, but I have not checked
for an update.
I would. My main laptop is an Apple Macbook Pro and it had a firmware update out of the
gate upon arrival the very month of its assembly (and about 4 more after that mostly all
Thunderbolt related). It's not a given that the new firmware is better. But that's
usually the case when experiencing weird problems like being unable to power off the
computer.
Chris Murphy