On Wed, Feb 25, 2015 at 1:53 AM, Angelo Moreschini <mrangelo.fedora@xxxxxxxxx> wrote:
Welcome to emergency mode! after logging in , type "journalctl -xb" to view system log .......Hi,
my computer often (not all the time) has problem at booting ...
When it happen, it boot to emergency mode...
(after I install new updates, then this problem occurs regularly)
The message that I get, when the problem come, are (approximately):
========================SError: {RecovRecovCom PHYRdyChg CommWake 10B8B DevExch }
failed commend : READ DMA
Please don't trim the messages to tidy them, include the entire thing, or post the rdsosreport.txt if one was generated.
Statistically speaking, the errors you post are probably due to a failed read on a critical sector that the system simply can't proceed without reading, so it waits for the drive to recover, and hits the kernel SCSI command timer limit which is 30 seconds.
If that's true, you might be able to fix the problem by booting with parameter rd.break=cmdline which gets you to a command line before anything is mounted (not even read only). And then do:
# echo 120 > /sys/block/sda/device/timeout
This will change the command timer, allowing the drive to do a long recovery and possibly enabling the bad sector to be read. I would do an e2fsck -f (assuming it's an ext fs). If it's a bad sector, and if file system metadata is on it, there's a possibility it can be fixed. Any writes to this bad sector will solve the problem, either by refreshing the existing sector's data or by remapping it if it's persistently failing writes too. You'll see all of this in dmesg.
If there are no errors in dmesg or fsck, then it's not fs metadata that's affected, it's data (binaries most likely). And that's slightly more difficult to fix. But if you just use
# exit
that will continue with the startup process from the break. And the command timer change might allow the drive to recover this data. If not, at the very least, again if it's a bad sector, you'll get something in dmesg that's explicitly a read error and will have an LBA associated with it. Now you can find out what file's data is on that LBA using debugfs and reinstall that binary (hopefully) which causes the problem to be fixed also.
Chris Murphy
-- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx 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
