Date: Wed, 14 Jun 2017 18:38:13 +0200 From: Polytropon <freebsd@edvax.de> To: alphachi <alphachi@mediaspirit.org> Cc: "list: freebsd" <freebsd-questions@freebsd.org> Subject: Re: All data in home directory lost after kernel panic Message-ID: <20170614183813.ec1e54ec.freebsd@edvax.de> In-Reply-To: <CAJN5%2BGv1bOWdcW4DB1ahTE0wTUBp=KZeKsQmh3BfcspdhFG=eQ@mail.gmail.com> References: <CAJN5%2BGtkVXOWPZqEnOrJOCD=TsDNUVx8EakqWC9JsmCXnq8%2BWw@mail.gmail.com> <CAJN5%2BGtVdXkMKVmjSxu96F%2BLUrcWAgAwsVWE5h=Q27N5ZBfwaw@mail.gmail.com> <CAJN5%2BGs%2BpuXR12Thfzm4ws73ZK5mgx0wvZo2Ybf_ytZpaKZKkA@mail.gmail.com> <CAJN5%2BGtyHFPCN2XH-SP4kfBypT%2Bs9BMyvRz0nMy5h6icKhtuvQ@mail.gmail.com> <CAJN5%2BGtLwaAfLXR%2B4SKUWqrqabqWOTsDY4qB%2BMVpG2AbgC31qQ@mail.gmail.com> <CAJN5%2BGukW_y9Oa3zyy=PKqd1ZxS8-jwdMjMusE13QqbmxPjuOA@mail.gmail.com> <CAJN5%2BGsQdx=Qevf0yPH65j5dgJ46Pf0GZcv8dgR6D5Cj4OqKyA@mail.gmail.com> <CAJN5%2BGvgORgqvr3WSekANZeK9JFDAsJK2Jh9EGG%2B3HA9WyqiNA@mail.gmail.com> <CAJN5%2BGv1bOWdcW4DB1ahTE0wTUBp=KZeKsQmh3BfcspdhFG=eQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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, ...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20170614183813.ec1e54ec.freebsd>