I recently had to purchase a new hard drive. Since I was at it I bought two instead of one as they were on offer (both are the same model). Since there was a lot of space left on the second hard disk I simply used it for a full scale backup of my root partition:

# single user mode.
# dd if=/dev/sda1 of=/dev/sdb3 bs=32M

After that I changed the UUID of the backed up partition and double-checked that it had a different UUID.

# tune2fs -U random /dev/sdb3

After that everything worked fine for some weeks, booting up each day and working as normal.

Recently, after booting up the computer, I suddenly had the backup partition (sdb3) as root, instead of my real root partition(sda1).

So, I shut down the computer, restarted and again, the backup partition. I modified the boot command line and booted directly to the correct device (sda1) and checked what was going on. I couldn't believe it, but the backup partition (sdb3) magically had the same UUID as the real root (sda1).

How could this happen (assuming no evil manipulations from an unknown third party)? Is it systemd? :)

I am running Debian testing, and this is a home computer where only I should have physical access.


  • The backup superblocks all have the modified UUID -- I checked that with dumpe2fs.
  • I did not rerun the dump command. Actually, the first thing I checked was that I did not run it again (by searching all of bash history).
  • I checked SMART information for all drives. I compared smart information with old revisions since I have everything versioned in a configuration repository. Nothing suspicious.
  • Check the fstab, check that sda didn't die by off-lining sdb. The possibility of a disk error randomly creating a duplicate UUID is outrageously tiny. I have to suspect operator error. Did you re-image db3 after the first copy?
    – msw
    Mar 7 '15 at 2:21
  • The first thing I suspected was user error as well since this is the only thing I could think of. Surprisingly that seems not the case. I compared SMART information of the drives with older versions to see if anything changed. Nothing.
    – hochl
    Mar 7 '15 at 10:00

I haven't tested this—not sure if it actually can happen. But if:

  1. you lost the primary superblock on sdb3 (e.g., bad sector), there are backup superblocks (I'm sure of that).
  2. If e2fsck automatically tries a backup superblock (I think it does, but am not sure)
  3. tune2fs only updates the primary superblock (I have no idea)

Then fsck would repair the primary superblock by copying from the backup—restoring the old UUID.

But really, I think it's far more likely you ran your dd again to refresh the backup and forgot to change the UUID.

I suggest taking a look at partclone or partimage.

  • Interesting ideas, but see my edits.
    – hochl
    Mar 7 '15 at 9:58
  • @hochl hmm... Can I go for "computer is haunted, consider telling as ghost story" then? I guess it's possible there is a weird bug somewhere that wrote to the wrong block...
    – derobert
    Mar 7 '15 at 13:41
  • Both would be scary! My hopes were on a "weird feature of systemd overwrites UUID of filesystem if it looks similar and it is in the right mood" thing ...
    – hochl
    Mar 7 '15 at 17:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.