dd to smaller partition gives corrupt superblock or partition table
Linux - GeneralThis Linux forum is for general Linux questions and discussion.
If it is Linux Related and doesn't seem to fit in any other forum then 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.
dd to smaller partition gives corrupt superblock or partition table
An external hard disk recently started failing, so I bought a new one and partitioned it at approximately the same sizes, although a few turned out slightly smaller. The old partitions were nowhere near full.
(and same for sda3 etc.). For the partitions that were slightly smaller (including sbd2) I got a "no space left on device" error at the end. After this, running fsck on sdb2 gives an error:
Quote:
The filesystem size (according to the superblock) is 1310720 blocks
The physical size of the device is 1308929 blocks
Either the superblock or the partition table is likely to be corrupt!
I assume this is because dd writes data including the old superblocks to the new partition, which means that I probably want to regenerate the superblocks. When searching for solutions to the error above, all seem to use resize2fs to resize the partitions. Will this recreate the superblocks etc. but keep the partition table intact?
Another option seems to be to start over and simply copy the whole disk with dd if=/dev/sda of=/dev/sdb; will this work even if the new disk is a different brand (but approx. same size) and has different sector sizes etc.?
Last edited by manscher; 07-09-2014 at 11:34 PM.
Reason: typo
"dd" writes every block that it can read, even if it is in error. There are much better alternatives - ddrescue for example.
What you have done is truncate the filesystem - check the arithmetic in the messages you cited above. This is never going to work - ensure the target partition is at least as big as the source, or use a file-aware tool that will only copy the used portiions of the filesystem.
Copying the whole disk may mess with the architecture of the target disk - less of an issue these days, but I don't ever do it; partition by partition gives much better control over the whole affair.
Thanks for your reply. I understand that I should stick to copying partition-by-partition.
The problem with using a file-aware tool (I assume you mean something like cp -R) is that because of the disk problems, I have trouble mounting the old file systems. So I have two questions:
If I'm willing to accept that the partition is truncated (and thus lose small amounts of data), how do I clean up the file system structure?
The alternative to accepting a truncated file system is to re-partition the new disk to exactly match the old one and copy the data again using dd or ddrescue, right? I'm not sure if I'm able to create exactly the same size for the last partition (i.e. since the sector structure is different for the new disk, it might be a tiny bit smaller), so if that happens, how do I clean up the file system structure? for this last partition, I can probably repair any errors this might create.
Truncating the file system invalidates it - you (effectively) lose the lot, not just a bit. After that is forensic recovery - slooooow and indefinite.
Seems you bought a second disk of the same (FSVO "same") size. Newer tools align new partitions differently, especially on the newer devices with bigger physical blocks. This might explain why you can't allocate all the partitions the "same" (FSVO ...) size. If it was me, I would work on just the partition that could give back the most space. Get it across to the new disk using a larger size, fix the filesystem, shrink it to release space, then shrink the partition to match (gparted is good for this), then work on the other partitions on the now larger than strictly required free space.
Recovery is always more work simply restoring from a current backup.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.