datzit
asked on
Centos 6.6 encrypted volumes do not show up on reboot
I have two servers that recently shut down due to a UPS failure. Effectively 2 identical builds - Centos 6.6 OS Servers on Dell hardware RAID 5 over 4 drives. There are some encrypted volumes that do not show up after this unscheduled/ungraceful shut down happened. The server is rebooted but there is no dev/mapper/crypot device showing. I think that the 'cryptsetup luksOpen /dev/sda2 crypt command is failing at boot.
Error message when trying to access volumes says: "fsk.ext4: No such file or directory while trying to open /dev/vg_00/DIRECTORYNAME. The superblock could not be read or does not describe a correct ext2 file system. If the file is valid and it really contains a ext2 file system (and not swap or ufs or something else) then the superblock is corrupt and you might try running ef2sck with an alternate superblock. eft2ck -b 8193.
This is on both servers after an ungraceful shutdown.
Error message when trying to access volumes says: "fsk.ext4: No such file or directory while trying to open /dev/vg_00/DIRECTORYNAME. The superblock could not be read or does not describe a correct ext2 file system. If the file is valid and it really contains a ext2 file system (and not swap or ufs or something else) then the superblock is corrupt and you might try running ef2sck with an alternate superblock. eft2ck -b 8193.
This is on both servers after an ungraceful shutdown.
ASKER
Thank you for your reply Arnold. I will attempt to run that command and provide results. Thank you.
Just to be clearer, the -n option MUST be present when running mkfs.extx to make sure you do NOT overwrite the data in the partition.
If other options were provided when the partition was created, those option should be used to get a more accurate representation of where the alternate copies of the superblock might be.
Otherwise, it provides a representation using default settings/options.
If other options were provided when the partition was created, those option should be used to get a more accurate representation of where the alternate copies of the superblock might be.
Otherwise, it provides a representation using default settings/options.
ASKER
So I received this tidbit of info. Apparently a script was created to purge files that were older than 30 days to save on disc space. It was mistakenly run on root and not on the right volume. It apparently deleted the encryption keys /passphrase files....and they did not get restored.
I was able to find the encryption password and am working to restore the keyfile. This script that was run about 6 months ago was not brought to my attention until just now. That is why the volumes are not being mounted.
I was able to find the encryption password and am working to restore the keyfile. This script that was run about 6 months ago was not brought to my attention until just now. That is why the volumes are not being mounted.
This question needs an answer!
Become an EE member today
7 DAY FREE TRIALMembers can start a 7-Day Free trial then enjoy unlimited access to the platform.
View membership options
or
Learn why we charge membership fees
We get it - no one likes a content blocker. Take one extra minute and find out why we block content.
Mkfs.ext4 -n when run on a partition lists the other locations where superblock data is stored and can be referenced.
Running the suggested efsck -b 8132 or any other of the possible variants, could restore the superblock data missing.
....