In a case, where you want to delete the journal and then remake the journal below is a two step process:
1) Process to delete the journal
1
tune2fs -O ^has_journal /dev/sdx1
2) Remake the journal
1
tune2fs -O has_journal /dev/sdx1
In a case, where you want to delete the journal and then remake the journal below is a two step process:
1) Process to delete the journal
1
tune2fs -O ^has_journal /dev/sdx1
2) Remake the journal
1
tune2fs -O has_journal /dev/sdx1
This is a firedrill post on how to recover partition table, if partition table was accidently deleted.
I have a CoreOS VM deployed in Azure. I manually deleted all partitions from the disk, as you notice from below output
1
|
|
Don’t panic! This is not my production server.
Before we start recovering the partition table, let’s backup the MBR code
1
|
|
To find the lost partitions, there is testdisk tool developed by Christophe Grenier. So, I have copied the package to the server and then extracted the files.
1 2 3 4 5 6 7 8 9 |
|
After that, I ran testdisk command on /dev/sda and you will notice a screen similar to below screenshot
After clicking proceed, I choosed EFI GPT partition map (because I knew on my CoreOS VM it has GPT with hybrid MBR), then Analyse, then Quick Search, and it found partitions.
Looking at the partition table, there are some missing partitions. I took a copy of the found partition table and then added the partitions manually then pressed Enter to continue and then write out the partition table.
For CoreOS specific, we need to additionally
-> fix type codes
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 |
|
-> name the partitions
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 |
|
-> number the partitions
1 2 3 4 5 6 7 8 9 10 11 12 |
|
-> change it to hybrid MBR
1 2 3 4 5 6 7 8 9 |
|
-> set the required attributes
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
|
-> update the UUID of disk /dev/sda3
1 2 3 4 5 6 7 |
|
Now, we are ready to restore the backed up MBR
1
|
|
Finally, we have our lost partition table (~!~). I rebooted the server and ensured server is indeed booting successfully.
1
|
|
Before, you read can you guess what above kernel message say? Above line suggests, kernel code tried to read some memory that isn’t loaded into RAM, which resulted in a page fault.
1
|
|
In general, superblock errors would indicate some data corruption in the sector. It can either be due to faulty hardware or power failures.
1
|
|
ext filesystems are pretty fragmentation resistant and defragging isn’t really needed except in few cases like transferring large files while the disk was nearly full.
1
|
|
fsck (easy to remember ;))
1
|
|
chattr +i filename
1
|
|
lsattr
1
|
|
Command reloads the rules from disk, and they will then apply to any new device that is added after that.
1
|
|
ipcs -sul