SlackwareThis Forum is for the discussion of Slackware Linux.
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.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
in preparation for the update to Slackware64 13.1 I did a complete backup of my system with dd.
I used the Slackware 13.0 (not 64 bit) DVD to boot and executed the command:
# dd if=/dev/sda of=/dev/sdb
The command finished without any errors as expected.
First I tried to boot the destination hard disk to check if the backup was successful and I can start with updating the source disk to 13.1. But at boot time I got the message that the last file system check is 197 day ago, the file system check started automatically and found errors which it could not correct. At this point I thought it was maybe a copy or a hard disk error and tried to boot the source disk.
But the behaviour was exactly the same on the source disk. With the source disk I followed then the recommendation, logged in with root password and executed the recommended command which was something like e2fsck -v -h /dev/sda1. Then the system did a file system check and scrolled a lot of numbers over the screen. After a while it reported that it's ready and the system needs a restart.
I switched off and on again. Then the system bootet as usual, and seems to run okay at the moment. But now I'm unsure if really everything is okay.
What I'm confused of is, why the system reported that the last file system check was 197 days ago and why this was just after the dd backup. Shouldn't the automatic file system check at boot time run more often as every 197 days or mounts? I didn't change any default settings (as far as I know). The file system of the root partition is ext4 and my computer normally is switched on and off once every day.
My question now is, if this behaviour can have something to do with the dd backup.
Is my system after the file system check okay again, or should I expect further problems?
Every explanations and suggestions are welcome.
Did you remember to modify /etc/fstab before booting /dev/sdb. If not then fstab will still be pointing to /dev/sdax for your root file system, which may explain how your original file system became corrupt.
When I bootet the backup disk (sdb) to check if it's working, it was not recognized as /dev/sdb but /dev/sda because I unplugged the source disk before booting the backup disk.
So it should not be necessary to modify /etc/fstab.
This is also the reason why I did the backup with dd, because then I (should) have a backup that I only have to plug instead of the original disk and have a working system without restoring something, or so.
I wouldn't blame dd for this, I've never heard of it corrupting data, especially when it is reading from that data. The cause must be something else. Are you sure the drive you copied from is ok, check with 'smartctl -A' and maybe a long test.
There's only a few reasons one should use dd to backup/clone a hard drive. Other tools are not available, other tools don't support the file system, you're making an image for forensics and need an exact bit to bit copy.
Some gotcha's for dd. When you dd dev/sda to dev/sdb this copies everything not just the data, but geometry, partition layout, everything. Unless the disks are identical, it's not a wise thing to do. It's better to dd specific partitions. Not only that, but dd copies sector to sector regardless if it is occupied with data or not.
The two drives have exactly the same size and the behaviour of the two disks after the dd backup was exactly the same. With both drives I got the message the the last file system check was 197 days ago and finally I could (hopefully) get rid of the file system errors with the recommended command "e2fsck -v -y /dev/sda1".
If only the destination drive would have shown a weird behaviour, then I would have thought it was an error in the backup process. But what I found strange was, that both drives had the same behaviour.
What is the default setting for the interval of a file system check on ext4?
If it's something between 200 and 300 boots then maybe it was just an accident that the file system check had to happen exactly after the backup and the errors were already present before and were also copied to the destination disk.
At the end it seems that both disk are working again after the file system check and could do my update to 13.1.
There ARE areas that are hidden..even to dd.. and most forensics specialists.. Some of these areas are known, partially, as the 'Hidden Partition Area' (HPA) and 'Device Configuration Overlay (DCO). These areas, if you are interested in more research, are sometimes legitimate, and sometimes not. However be forewarned, there is scant, inclusive, and questionable data available on the Net about these mysterious areas of forensics.
There is nothing mysterious about HPA. And the state of documentation definitely is not "scant" or "questionable". The Linux kernel will tell you on boot if it detects a HPA ('dmesg|grep HPA'), the libata LKM has a compatibility switch ('modinfo libata|grep ignore_hpa') and userland tools are available to detect ('hdparm', 'disk_stat') and reset ('setmax', 'disk_sreset') a HPA.
Originally Posted by halvy
This obviously could be part of the reason for the phantom type errors and results that OP got.
'dd' makes a bit-level copy of the drive. The OP experienced FS-level problems. Completely different layer, completely different type of problem.
Why you had problem after running dd? First, in your case, you do not correctly used the command dd. You need use option 'bs' in such cases (see man dd). By default dd copies per small block (in your case, without options), it is very heavy for disk subsystem when copying large amounts of data. In fact, you tested your hard drive for durability. The test was not passed. The reasons may be several. In my case, in similar circumstances, it was the temperature above 50 degrees Celsius. In your case, when there was copying, has failed and the disk subsystem mark bad sector(s) as unreadable, respectively a small piece of information was lost, respectively copied file system came in inconsistent state, hence the errors at startup. As for the time: check the system time in BIOS, it lags behind the real on 197 days.
If you have no idea about S.M.A.R.T., to quickly check if everything is in order, you can download the latest livecd Fedora. Boot from it and wait 2-5 minutes. If there are problems in the notification area will notice, if not, read smartmontools's docs (a lot of useful information on their site).