[SOLVED] ext4 partition turned into Unknown according to gparted
Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
ext4 partition turned into Unknown according to gparted
I was using gparted to resize my /var partition, which is supposed to be an ext4 partition, and during the beginning stages of the resize/move procedure I cancelled out of the process despite the warning this might be bad. The process was in the middle of the "read" stage so I figured nothing can go wrong during a read, but now I cannot access this partition mount wise. Is there anyway to repair this?
Think you have it. If you resized the partition the filing index could be among the first few that get changed but you stopped the files moved to the correct position.
You could try to fix the partition table with "testdisk". As long as the only thing that has been broken is that, of course. You might need to run fsck on the fs afterwards (if you manage to get it back at all first).
But first, if you value the data inside that fs, you should be doing an integral backup using an fs-agnostic tool like dd, so you can dump back the contents of the disk if something goes wrong and try again (and it will likely be that way).
I don't know that testdisk (good as it is) can help with this.
If you choose to ignore warning messages, your backups had better be good - and current.
Very fortunate for me the partition that was affected was the /var partition and being that this system was fairly new, it is not as serious as if it were / or /home. I had a feeling I should have used dd to back up the partitions before attempting anything, but I neglected to heed my own inner warning =( It is probably more trouble to fix this than reinstall Slackware and copy /etc and /root over. I believe saikee is right in that the files and their index are in limbo, which is why testdisk was not able to help in this situation...
Testdisk excels at repairing partition tables, even in rare cases. But it doesn't do a thing related to the data inside. There's a tool for that from them as well, it's "photorec", regardless of its name it can recover many types of files.
This is just for the record, since you seem to have sorted your problem already.
Testdisk excels at repairing partition tables, even in rare cases. But it doesn't do a thing related to the data inside. There's a tool for that from them as well, it's "photorec", regardless of its name it can recover many types of files.
This is just for the record, since you seem to have sorted your problem already.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.