Search icon CANCEL
Arrow left icon
Explore Products
Best Sellers
New Releases
Books
Videos
Audiobooks
Learning Hub
Conferences
Free Learning
Arrow right icon
Arrow up icon
GO TO TOP
Red Hat Enterprise Linux Troubleshooting Guide

You're reading from   Red Hat Enterprise Linux Troubleshooting Guide Identify, capture and resolve common issues faced by Red Hat Enterprise Linux administrators using best practices and advanced troubleshooting techniques

Arrow left icon
Product type Paperback
Published in Oct 2015
Publisher
ISBN-13 9781785283550
Length 458 pages
Edition 1st Edition
Tools
Concepts
Arrow right icon
Author (1):
Arrow left icon
Benjamin Cane Benjamin Cane
Author Profile Icon Benjamin Cane
Benjamin Cane
Arrow right icon
View More author details
Toc

Table of Contents (14) Chapters Close

Preface 1. Troubleshooting Best Practices FREE CHAPTER 2. Troubleshooting Commands and Sources of Useful Information 3. Troubleshooting a Web Application 4. Troubleshooting Performance Issues 5. Network Troubleshooting 6. Diagnosing and Correcting Firewall Issues 7. Filesystem Errors and Recovery 8. Hardware Troubleshooting 9. Using System Tools to Troubleshoot Applications 10. Understanding Linux User and Kernel Limits 11. Recovering from Common Failures 12. Root Cause Analysis of an Unexpected Reboot Index

Recovering the filesystem


Now that we know why the filesystem is in the Read-Only mode, we can resolve it. Forcing the filesystem to go from Read-Only to Read-Write is actually pretty easy. However, because we don't know all of the circumstances around the failure that caused the filesystem to go into the Read-Only mode, we must be careful.

Recovering from filesystem errors can be extremely tricky; if not done properly, we could easily find ourselves in a situation where we have corrupted the filesystem or in other ways caused partial or even full data loss.

Since we have multiple filesystems in the Read-Only mode, we will first start with the /boot filesystem. The reason we are starting with the /boot filesystem is because this is technically the best filesystem to experience data loss. Since the /boot filesystem is only used during the server boot process, we can simply ensure that we do not reboot this server before the /boot filesystem can be recovered.

Whenever possible, it is always best...

lock icon The rest of the chapter is locked
Register for a free Packt account to unlock a world of extra content!
A free Packt account unlocks extra newsletters, articles, discounted offers, and much more. Start advancing your knowledge today.
Unlock this book and the full library FREE for 7 days
Get unlimited access to 7000+ expert-authored eBooks and videos courses covering every tech area you can think of
Renews at $19.99/month. Cancel anytime