All data in home directory lost after kernel panic

[Polytropon]

On Wed, 14 Jun 2017 23:03:51 +0800, alphachi wrote:
> Today I upgraded my system to 10.3-STABLE r319937 successfully. It's
> installed on UFS with GELI.
> 
> When I double-click a VM in virtualbox, the system reboots because of a
> kernel panic. After autofsck, the login prompt shows, but the system
> reboots again while I input my login imformation and press Enter. I have to
> boot single user mode and run fsck manually, then login as root.

It's usually not a good idea to rely on background fsck. In case
of file system inconsistencies, always force a fsck foreground
scan prior to entering multi-user mode. Running with an inconsistent
file system can cause all kinds of unexpected results.



> Everything
> is fine, however I suddenly find all data in my home directory disappeared;
> that is to say, my home directory is empty.

It seems that somehow the directory's inode has been reset, so
all subsequent entries are gone. Depening on what actually happened
(background fsck possible damage, foreground fsck with -yf unwanted
inode clearing), you could "revive" the inode or at least get your
stuff back, while _maybe_ losing the "top level" names for the
entries (file names and directory names, as those are stored in
the inode of your home directory).

If you did not do any further writes to the disk, your data per se
(the actual data) is still there. If this is important to you, do
not do any writes to the disk (or the partition). Every single
write can significantly reduce your chances of recovery.



> I think my data still exists on the disk and this is just the problem about
> filesystem, because:
> 1. The total size of my home directory is about 132GB before. When I check
> the output of "df -h" now, the value of "Used" is still about 132GB.

Then examine the content of your home directory further, maybe
the files just have been "shift down". Use the -o ro option for
mounting. As I said - no further writes.

Use the archives of this mailing list to find my problem similar
to yours (which brought me here), plus the solution.



> 2. The operation of user login shouldn't cause a kernel panic, even though
> the home directory is empty.

In case of an inconsistent file system (maybe in the state of a
background fsck or after such a scan, still with defects) is able
to cause any kind of strange behaviour. A kernel panic is possible.
An inconsistent file system is something the OS cannot properly
work on.



> 3. "ls -a /home/fbsd" hasn't any output, but normally it should output .
> and .. at least.

This again shows that there is probably something still wrong with
the file system. Inspect it further. Make yourself familiar with the
lower-level tools such as fsdb.



> I try to use recoverdisk(1) to recover a file that I can remember its name.

The names are probably gone, at least at the top level.



> For example:
> 
> # recoverdisk /home/fbsd/.zshrc .zshrc
> Bigsize = 1048576, medsize = 32768, minsize = 512
> start    size    block-len    state    done    remaining    % done
> 0    4220    4220    0    4220    0    100.00000
> Completed
> 
> Although I checked this file and confirmed the recovery is successful, I
> can't recover all data by this way since it's impossible to remember all
> filenames.

Wrong tool for this task. Check my list of recovery tools to find
something that is a better deal, but first of all, check what you
can do with the file system in order to perform a _repair_ before
you go ahead with a recovery.

Here is the list:

System:
	dd
	fsck_ffs
	clri
	fsdb (!!!)
	fetch -rR <device>
	recoverdisk (!)

Ports:
	ddrescue
	dd_rescue
	ffs2recov
	magicrescue
	testdisk
	The Sleuth Kit:
		fls
		dls
		ils
		autopsy
	scan_ffs
	recoverjpeg
	foremost
	photorec
	fatback

Proprietary (free test version for diagnostics):

	SysDev Laboratories LLC "UFS Explorer

Again, there is no "one size fits all" kind of tool, and you have
to _know_ what you're doing...



> Any idea about this? Thanks!

I can understand your expectations, but don't fool yourself with
the misbelief that there is a "point & click all files back" tool.
Establish a proper understanding of what is your current state first,
then use the correct tool to deal with it.

And:

Under no circumstances _experiment_ with your data. Make a copy of
the partition and work with the image (disk-backed device: make
a copy with dd first, then "mdconfig -a -u 0 -t vnode -f home.dd"
and now you can do use mount, fsck, fsdb and other tools that
read or write data).

I shouldn't say it, but as I've been burned in a similar way as
you have been, I'm allowed to say it:

Recover from backup!

Yes, I know, it doesn't help right now, but it might be a good
reminder for the future.

Disks are cheap today.

https://blog.codinghorror.com/international-backup-awareness-day/



Good luck!




-- 
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...