Date: Fri, 29 Mar 2024 07:50:16 -0500 (CDT) Message-ID: <1628533300.1576.1711716616730@wiki.ncsa.illinois.edu> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_1575_1869484346.1711716616728" ------=_Part_1575_1869484346.1711716616728 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
The default behavior on many Linux operating systems is to set a file sy= stem to read-only if critical information can't be written to disk. If this= happens the file system is corrupt and fsck has to be run to fix it. The d= efault behavior can be changed but it is not advisable. If it is changed to= "continue" errors can accumulate and corrupt the file system. If it is cha= nged to "panic" the system will halt and fsck will need to be run on the fi= le system before it can be restarted.
The following command can be run to find read-only file systems in your = instance.
grep "\sro[\s,]" /proc/mounts
Browse to the Nebula dashboard at nebula.ncsa.illino= is.edu.
In the drop-down "Actions" menu to the= right of your instance select "Hard Reboot Instance". A soft reboot tries = to shut down the instance gracefully and normally would be preferable to a = hard reboot, which halts the instance immediately. However, in this case, t= he soft reboot will try shutting down services and writing to disk a= nd at this point the disk is read-only.
Confirm the instance has rebooted.
To log in as root you must previously have set a pas= sword for root in the instance.
Browse to the Nebula dashboard a= t nebula.ncsa.illinois.edu.
In the drop-= down "Actions" menu to the right of your instance select "Console".<= /span>
You will be given a login prompt= .
There is no guaranteed way to re=
store an instance with disk corruption. Good backups are the only way to av=
oid losing data.
The fsck
command can recover your disk partition but there =
is no guarantee that it will work correctly. The fsck
operatio=
n can occasionally cause data corruption on active disks. For this reason, =
the fsck
procedure should only be performed on unmounted or re=
ad-only file systems to minimize this risk. Problems can still occur in cas=
es of severe damage.
Use the "mount" command to verify the file system you wish to fix is rea= d-only.
/dev/vdb1 on /tmp/newdir type ext4 (ro,relatime,seclabel,data=3Dordered)
Run fsck on the file device you wish to check.
fsck /dev/vdb1
Normally, the file system is consistent, a= nd the fsck command merely reports on the number of files, used blocks, and= free blocks in the file system. If the file system is inconsistent, the fs= ck command displays information about the inconsistencies found and prompts= you for permission to repair them.
After fsck has been run it is important to check the /lost+found=
code> directory in the checked file system. This is where fsck puts partial=
ly recovered files. Sometimes, fsck is able to recover file data, but it ca=
nnot find a reference to the file on the filesystem.When this happens, fsck=
places the files in the
/lost+found
directory so that you can=
manually try to figure out what the file is. If there are files in this di=
rectory check to see if you can identify them. Often these are files that w=
ere previously deleted but were still being used when the system crashed. I=
t is worth checking them though to be sure.
Contact "nebula@ncsa.illinois.edu" with any questions.