Re: F22: rebooting to emergency mode

2015-07-06 Thread Chris Murphy
 On Mon, Jul 6, 2015, 12:11 AM Heinz Diehl htd...@fritha.org wrote:

On 03.07.2015, Chris Murphy wrote:

 And after that, over the weekend if you can afford to be without the
 use of this computer, run memtest86+ as long as you can stand it.
 Sometimes it takes days for problems to show up.

Most often, mprime95 is a better alternative and fails within a short
amount of time in case of failing RAM or heat problems:
http://www.mersenne.org/download/

One full hour with each of the three stress-tests (respectively) will
usually
suffice.


The description days it can be used to stress test the CPU including on
board caches. It doesn't say it's a memory tester. The reason it can take a
long time for memtest to find a defect is that sometimes they produce only
intermittent error.

Chris Murphy
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org


Re: F22: rebooting to emergency mode

2015-07-06 Thread Heinz Diehl
On 03.07.2015, Chris Murphy wrote: 

 And after that, over the weekend if you can afford to be without the
 use of this computer, run memtest86+ as long as you can stand it.
 Sometimes it takes days for problems to show up.

Most often, mprime95 is a better alternative and fails within a short
amount of time in case of failing RAM or heat problems:
http://www.mersenne.org/download/

One full hour with each of the three stress-tests (respectively) will usually
suffice.

-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org


Re: F22: rebooting to emergency mode

2015-07-05 Thread Craig Goodyear

On 07/03/2015 04:25 PM, Chris Murphy wrote:

Given how many reinstalls you've done, I suspect a hardware problem.
Instead of waiting for it to happen again, you could do two things.

Post the output from

smartctl -x /dev/sdX###where X is the letter for the drive that
you've installed Fedora

And after that, over the weekend if you can afford to be without the
use of this computer, run memtest86+ as long as you can stand it.
Sometimes it takes days for problems to show up.




I ran memtest86+ for 30 hours. No errors were found.


Here is the output from smartctl -x /dev/sda:

smartctl 6.2 2014-07-16 r3952 [x86_64-linux-4.0.6-200.fc21.x86_64] 
(local build)

Copyright (C) 2002-13, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family: Seagate Barracuda 7200.14 (AF)
Device Model: ST500DM002-1BD142
Serial Number:W3TEGX3B
LU WWN Device Id: 5 000c50 07d130b7d
Firmware Version: KC48
User Capacity:500,107,862,016 bytes [500 GB]
Sector Sizes: 512 bytes logical, 4096 bytes physical
Rotation Rate:7200 rpm
Device is:In smartctl database [for details use: -P show]
ATA Version is:   ATA8-ACS T13/1699-D revision 4
SATA Version is:  SATA 3.0, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is:Sun Jul  5 17:08:56 2015 CDT
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
AAM level is: 208 (intermediate), recommended: 208
APM feature is:   Unavailable
Rd look-ahead is: Enabled
Write cache is:   Enabled
ATA Security is:  Disabled, frozen [SEC2]
Wt Cache Reorder: Enabled

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

General SMART Values:
Offline data collection status:  (0x82) Offline data collection activity
was completed without error.
Auto Offline Data Collection: Enabled.
Self-test execution status:  (   0)	The previous self-test routine 
completed

without error or no self-test has ever
been run.
Total time to complete Offline
data collection:(  600) seconds.
Offline data collection
capabilities:(0x7b) SMART execute Offline immediate.
Auto Offline data collection on/off 
support.
Suspend Offline collection upon new
command.
Offline surface scan supported.
Self-test supported.
Conveyance Self-test supported.
Selective Self-test supported.
SMART capabilities:(0x0003) Saves SMART data before entering
power-saving mode.
Supports SMART auto save timer.
Error logging capability:(0x01) Error logging supported.
General Purpose Logging supported.
Short self-test routine
recommended polling time:(   1) minutes.
Extended self-test routine
recommended polling time:(  87) minutes.
Conveyance self-test routine
recommended polling time:(   2) minutes.
SCT capabilities:  (0x303f) SCT Status supported.
SCT Error Recovery Control supported.
SCT Feature Control supported.
SCT Data Table supported.

SMART Attributes Data Structure revision number: 10
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME  FLAGSVALUE WORST THRESH FAIL RAW_VALUE
  1 Raw_Read_Error_Rate POSR--   110   099   006-27448144
  3 Spin_Up_TimePO   100   100   000-0
  4 Start_Stop_Count-O--CK   100   100   020-37
  5 Reallocated_Sector_Ct   PO--CK   100   100   036-0
  7 Seek_Error_Rate POSR--   063   060   030-1927500
  9 Power_On_Hours  -O--CK   100   100   000-155
 10 Spin_Retry_CountPO--C-   100   100   097-0
 12 Power_Cycle_Count   -O--CK   100   100   020-37
183 Runtime_Bad_Block   -O--CK   100   100   000-0
184 End-to-End_Error-O--CK   100   100   099-0
187 Reported_Uncorrect  -O--CK   100   100   000-0
188 Command_Timeout -O--CK   100   100   000-0 0 0
189 High_Fly_Writes -O-RCK   100   100   000-0
190 Airflow_Temperature_Cel -O---K   067   063   045-33 (Min/Max 
33/35)

194 Temperature_Celsius -O---K   033   040   000-33 (0 24 0 0 0)
195 Hardware_ECC_Recovered  -O-RC-   060   039   000-27448144
197 Current_Pending_Sector  -O--C-   100   100   000-0
198 Offline_Uncorrectable 

Re: F22: rebooting to emergency mode

2015-07-05 Thread Chris Murphy
Well I don't see any problems there. If you have a backup of the
contents of /var/log/journal, then you can point journalctl to it with
-D and see if anything weird was happening before the failure. You can
use -r to reverse the log, so as you scroll it goes backwards in time.
You can also filter it

grep ERR
grep UNC
grep -i error
grep -i sector

If you get a hit you'll need to note the time stamp and then pick some
time maybe 5 minutes before and plug that into --since

journalctl -since=2015-07-05 13:00:00

And scroll until you find some instigator or at least the first part
of what will probably be multiple error lines. Assuming the problems
were written in the journal of course.

If there's nothing or the journals are gone or corrupt -  There is a
way to point systemd-journald's journal to another computer. I haven't
done that so I can't tell you how. But it might be worth setting that
up now so that if/when this problem happens again, you'll have logs of
the problem.


Chris Murphy
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org


Re: F22: rebooting to emergency mode

2015-07-03 Thread Craig Goodyear

On 07/02/2015 06:01 PM, Chris Murphy wrote:

On Thu, Jul 2, 2015 at 1:38 PM, Craig Goodyear cjhs...@cableone.net wrote:



What's really needed are logs, to troubleshoot why there's a boot
failure. What's supposed to happen if you're dropped to emergency mode
by dracut, is you get an rdsosreport.txt produced that typically
contains a bunch of information useful for troubleshooting.




I wish you had responded to my original request for help before I did a 
fresh install. I was not aware of the rdsosreport.txt file and emergency 
mode only refers to journalctl for troubleshooting. I will keep this in 
mind if the problem repeats.


Craig

--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org


Re: F22: rebooting to emergency mode

2015-07-03 Thread Chris Murphy
On Fri, Jul 3, 2015 at 3:21 PM, Chris Murphy li...@colorremedies.com wrote:

 If an rdsosreport.txt is created, there's a hint displayed where to
 find it.

Example:
https://ask.fedoraproject.org/en/question/71011/how-do-i-get-past-the-dracula-emergency-hell/


-- 
Chris Murphy
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org


Re: F22: rebooting to emergency mode

2015-07-03 Thread Chris Murphy
Given how many reinstalls you've done, I suspect a hardware problem.
Instead of waiting for it to happen again, you could do two things.

Post the output from

smartctl -x /dev/sdX###where X is the letter for the drive that
you've installed Fedora

And after that, over the weekend if you can afford to be without the
use of this computer, run memtest86+ as long as you can stand it.
Sometimes it takes days for problems to show up.


-- 
Chris Murphy
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org


Re: F22: rebooting to emergency mode

2015-07-03 Thread Chris Murphy
On Fri, Jul 3, 2015 at 6:43 AM, Craig Goodyear cjhs...@cableone.net wrote:
 On 07/02/2015 06:01 PM, Chris Murphy wrote:

 On Thu, Jul 2, 2015 at 1:38 PM, Craig Goodyear cjhs...@cableone.net
 wrote:


 What's really needed are logs, to troubleshoot why there's a boot
 failure. What's supposed to happen if you're dropped to emergency mode
 by dracut, is you get an rdsosreport.txt produced that typically
 contains a bunch of information useful for troubleshooting.



 I wish you had responded to my original request for help before I did a
 fresh install. I was not aware of the rdsosreport.txt file and emergency
 mode only refers to journalctl for troubleshooting. I will keep this in mind
 if the problem repeats.

If an rdsosreport.txt is created, there's a hint displayed where to
find it. If you're dropped to a shell, and nowhere on that screen is
such a hint, then it wasn't created, so you'll have to fake one up.
First you need  to mount a file system, like a USB stick. /mnt doesn't
exist so you can mount it at /sysroot and then:

journalctl -b -l -o short-monotonic  /sysroot/journal.txt

That'll write out the entire journal for just the current (failed)
boot, long format in case there's important stuff there, and use
monotonic time. All but -b are optional, but they make the log more
readable.

-- 
Chris Murphy
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org


Re: F22: rebooting to emergency mode

2015-07-02 Thread Chris Murphy
On Thu, Jul 2, 2015 at 1:38 PM, Craig Goodyear cjhs...@cableone.net wrote:
 On 07/01/2015 09:45 AM, Craig Goodyear wrote:

 I have done a fresh install of Fedora 22 on the same computer 4 times.
 Each time, after using the system from 1 day to 3 days and having
 successfully rebooted several times, a reboot results in being started
 in emergency mode. This computer was running Fedora 21 since its release
 without any problems. I am using an ASUS P9X79 Deluxe motherboard.

 I have tried installing to a new hard disk. I have tried a different
 video card. I have run fsck on the hard disk after booting a live image.
 No errors were found. Nothing I have tried has changed the result.


 To close this thread. I think I have found the problem. Upon inspecting the
 BIOS settings, I found that I had not completely disabled UEFI support.

This is sub-optimal, and is basically used as a last ditch effort.
There is no actual way to disable UEFI, what actually happens, this
setting enables a compatibility support module that presents a
faux-BIOS to the OS to bridge between the OS and UEFI. So UEFI isn't
actually disabled, you've just added another layer.

What's really needed are logs, to troubleshoot why there's a boot
failure. What's supposed to happen if you're dropped to emergency mode
by dracut, is you get an rdsosreport.txt produced that typically
contains a bunch of information useful for troubleshooting.


-- 
Chris Murphy
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org


Re: F22: rebooting to emergency mode

2015-07-02 Thread Craig Goodyear

On 07/01/2015 09:45 AM, Craig Goodyear wrote:

I have done a fresh install of Fedora 22 on the same computer 4 times.
Each time, after using the system from 1 day to 3 days and having
successfully rebooted several times, a reboot results in being started
in emergency mode. This computer was running Fedora 21 since its release
without any problems. I am using an ASUS P9X79 Deluxe motherboard.

I have tried installing to a new hard disk. I have tried a different
video card. I have run fsck on the hard disk after booting a live image.
No errors were found. Nothing I have tried has changed the result.



To close this thread. I think I have found the problem. Upon inspecting 
the BIOS settings, I found that I had not completely disabled UEFI support.


I may have also created a problem for the boot devices when changing the 
first boot device to the DVD drive for the Fedora 22 install. There were 
two UEFI entries for Fedora with only one Fedora version installed.


I removed all boot options except the DVD drive and the hard disk. I 
have done a fresh install of Fedora 21. If it proves to be stable for a 
couple of weeks, I will proceed with the Fedora 22 install.


Craig
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org


Re: F22: rebooting to emergency mode

2015-07-01 Thread jd1008



On 07/01/2015 08:45 AM, Craig Goodyear wrote:
I have done a fresh install of Fedora 22 on the same computer 4 times. 
Each time, after using the system from 1 day to 3 days and having 
successfully rebooted several times, a reboot results in being started 
in emergency mode. This computer was running Fedora 21 since its 
release without any problems. I am using an ASUS P9X79 Deluxe 
motherboard.


At the emergency mode console the following is displayed in yellow:

Ignoring BGRT: invalid status 0 (expected 1)
ata16.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6
ata16.00: irq_stat 0x4001
ata16.00: cmd a0/01:00:00:00:01/00:00:00:00:00/a0 tag 1 dma 16640 in
Inquiry 12 01 00 00 ff 00res 00/00:00:00:00:00/00:00:00:00:00/00 Emask 
0x3 (HSM violation)


Running journalctl -xb has the following lines in red:

Jun 30 14:48:15 mac.localdomain kernel: Ignoring BGRT: invalid status 
0 (expected 1)
Jun 30 14:48:15 mac.localdomain kernel: ata16.00: exception Emask 0x0 
SAct 0x0 SErr 0x0 action 0x6

Jun 30 14:48:15 mac.localdomain kernel: ata16.00: irq_stat 0x4001
Jun 30 14:48:15 mac.localdomain kernel: ata16.00: cmd 
a0/01:00:00:00:01/00:00:00:00:00/a0 tag 1 dma 16640 in
Inquiry 12 01 00 00 ff 00res 00/00:00:00:00:00/00:00:00:00:00/00 Emask 
0x3 (HSM violation)
Jun 30 14:48:32 mac.localdomain kernel: EDAC sbridge: ECC is disabled. 
Aborting
Jun 30 14:48:32 mac.localdomain kernel: EDAC sbridge: Couldn't find 
mci handler


I have tried installing to a new hard disk. I have tried a different 
video card. I have run fsck on the hard disk after booting a live 
image. No errors were found. Nothing I have tried has changed the result.


Where do I start in order to determine the cause of this problem?


Some googling showed similar problems since 2010 on ubuntu and rhel 
platforms.

Some were dated 2014.
So, somehow, an old bug has re-incarnated??
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org


Re: F22: rebooting to emergency mode

2015-07-01 Thread Chris Murphy
On Wed, Jul 1, 2015 at 8:45 AM, Craig Goodyear cjhs...@cableone.net wrote:

 Where do I start in order to determine the cause of this problem?

The closest thing I find that are semi recent is
https://bbs.archlinux.org/viewtopic.php?id=184783

So it sounds like a hardware bug that the kernel previously worked
around and now it's not working around it (?) and thus is a kernel
bug. Try using a different kernel. kernel-4.0.7-300.fc22 is in
updates-testing repo so you could easily try that. If that doesn't
work then I'd go to koji and get kernel-4.1.0-1.fc23.

If that doesn't work, then I suggest you go backwards to the newest
Fedora 21 kernel available which presumably will work since it worked
for you before. And you can stick with that for now. But then you'll
need to file a bug report, including which kernels you've tested,
which versions have the problem and don't. And full details on your
hardware, like an lspci -vvnn  lspci.txt and attach that file. Same
with dmesg  dmest.txt, and attach that. (Anything either long, or
important to format correctly without web browser wrapping issues
should be attachments.)

Before you get started, you should probably change /etc/dnf/dnf.conf
such that installonly_limit is set to something like 10, just to make
sure dnf doesn't start deleting kernels. You can clean this up later,
which is a bit tedious, but that's another matter.



-- 
Chris Murphy
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org


F22: rebooting to emergency mode

2015-07-01 Thread Craig Goodyear
I have done a fresh install of Fedora 22 on the same computer 4 times. 
Each time, after using the system from 1 day to 3 days and having 
successfully rebooted several times, a reboot results in being started 
in emergency mode. This computer was running Fedora 21 since its release 
without any problems. I am using an ASUS P9X79 Deluxe motherboard.


At the emergency mode console the following is displayed in yellow:

Ignoring BGRT: invalid status 0 (expected 1)
ata16.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6
ata16.00: irq_stat 0x4001
ata16.00: cmd a0/01:00:00:00:01/00:00:00:00:00/a0 tag 1 dma 16640 in
Inquiry 12 01 00 00 ff 00res 00/00:00:00:00:00/00:00:00:00:00/00 Emask 
0x3 (HSM violation)


Running journalctl -xb has the following lines in red:

Jun 30 14:48:15 mac.localdomain kernel: Ignoring BGRT: invalid status 0 
(expected 1)
Jun 30 14:48:15 mac.localdomain kernel: ata16.00: exception Emask 0x0 
SAct 0x0 SErr 0x0 action 0x6

Jun 30 14:48:15 mac.localdomain kernel: ata16.00: irq_stat 0x4001
Jun 30 14:48:15 mac.localdomain kernel: ata16.00: cmd 
a0/01:00:00:00:01/00:00:00:00:00/a0 tag 1 dma 16640 in
Inquiry 12 01 00 00 ff 00res 00/00:00:00:00:00/00:00:00:00:00/00 Emask 
0x3 (HSM violation)
Jun 30 14:48:32 mac.localdomain kernel: EDAC sbridge: ECC is disabled. 
Aborting
Jun 30 14:48:32 mac.localdomain kernel: EDAC sbridge: Couldn't find mci 
handler


I have tried installing to a new hard disk. I have tried a different 
video card. I have run fsck on the hard disk after booting a live image. 
No errors were found. Nothing I have tried has changed the result.


Where do I start in order to determine the cause of this problem?
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org


Re: F22: rebooting to emergency mode

2015-07-01 Thread Patrick O'Callaghan
On Wed, 2015-07-01 at 09:45 -0500, Craig Goodyear wrote:
 Inquiry 12 01 00 00 ff 00res 00/00:00:00:00:00/00:00:00:00:00/00 
 Emask 
 0x3 (HSM violation)

Googling HSM violation linux throws up a bunch of possibilities.
Start there.

poc
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org


Re: F22: rebooting to emergency mode

2015-07-01 Thread Craig Goodyear

On 07/01/2015 10:37 AM, Patrick O'Callaghan wrote:

On Wed, 2015-07-01 at 09:45 -0500, Craig Goodyear wrote:

Inquiry 12 01 00 00 ff 00res 00/00:00:00:00:00/00:00:00:00:00/00
Emask
0x3 (HSM violation)


Googling HSM violation linux throws up a bunch of possibilities.
Start there.

poc



Thank you for the suggestion. This error is related to the Marvell SATA 
controller that is not being used. Disabling it in the BIOS elimates the 
error.


Craig
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org


Re: F22: rebooting to emergency mode

2015-07-01 Thread Craig Goodyear

On 07/01/2015 10:45 AM, Chris Murphy wrote:

On Wed, Jul 1, 2015 at 8:45 AM, Craig Goodyear cjhs...@cableone.net wrote:


Where do I start in order to determine the cause of this problem?


The closest thing I find that are semi recent is
https://bbs.archlinux.org/viewtopic.php?id=184783

So it sounds like a hardware bug that the kernel previously worked
around and now it's not working around it (?) and thus is a kernel
bug. Try using a different kernel. kernel-4.0.7-300.fc22 is in
updates-testing repo so you could easily try that. If that doesn't
work then I'd go to koji and get kernel-4.1.0-1.fc23.

If that doesn't work, then I suggest you go backwards to the newest
Fedora 21 kernel available which presumably will work since it worked
for you before.



Thank you for the response. I have downloaded and tested kernels 
4.0.7-300.fc22, 4.1.0-1.fc23 and 3.17.4-301.fc21. All resulted in 
booting to emerengcy mode.


At this point, I will install Fedora 21 and test. If not successful, I 
will assume that I have a motherboard failure.


--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org


Re: F22: rebooting to emergency mode

2015-07-01 Thread Joe Zeff

On 07/01/2015 01:35 PM, Craig Goodyear wrote:


At this point, I will install Fedora 21 and test. If not successful, I
will assume that I have a motherboard failure.


Can you boot off of a LiveUSB?  If so, it might not be the mobo.
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org


Re: F22: rebooting to emergency mode

2015-07-01 Thread Craig Goodyear

On 07/01/2015 03:44 PM, Joe Zeff wrote:

On 07/01/2015 01:35 PM, Craig Goodyear wrote:


At this point, I will install Fedora 21 and test. If not successful, I
will assume that I have a motherboard failure.


Can you boot off of a LiveUSB?  If so, it might not be the mobo.


I can boot from a LiveDVD. I have not tried a LiveUSB. I am able to 
mount a USB thumb drive in emergency mode.

--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org


Re: F22: rebooting to emergency mode

2015-07-01 Thread Joe Zeff

On 07/01/2015 02:44 PM, Craig Goodyear wrote:


I can boot from a LiveDVD. I have not tried a LiveUSB. I am able to
mount a USB thumb drive in emergency mode.


That's OK; if you can boot from a DVD, it's unlikely to be your mobo, 
and that's what I wanted to test.

--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org