can't boot F19 system

[Chris Murphy]

On Mar 19, 2014, at 11:24 AM, "pgaltieri ." <pgaltieri at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/users/attachments/20140319/5c9b40a5/attachment.html>