0

I've googled this extensively and can't quite come up with an answer.

Overview

I created two image files of a filesystem I'm actively using (/) and it sometimes is ok, and othertimes is not.

What I do

Using the following cmdline, I use dd to copy my / filesystem device (/dev/sda2, ext4) to an image file. It's a 470GB image, so I place it on an external USB HD auto-mounted on /media/me/Elements:

dd if=/dev/sda2 of=/media/me/Elements/test.img bs=1024K status=progress

This yields a roughly half TB test.img file.

When I then mount this as a loop device:

mount -o loop /media/me/Elements/test.img /mnt/iso

It works for some image files but not others. In the cases where it works I can traverse the loop filesystem /mnt/iso easily, and wander around the saved / as expected.

━━━━ /home/me ━━━━ sudo mount -o loop /media/me/Elements/test.img /mnt/iso

━━━━ /home/me ━━━━ ls /mnt/iso
bin/    dev/    games/  lib32/       media/  proc/  sbin/  sys/  var/             vmlinuz@
boot/   devel/  home/   lib64/       mnt/    root/  snap/  tmp/  initrd.img@      vmlinuz.old@
cdrom/  etc/    lib/    lost+found/  opt/    run/   srv/   usr/  initrd.img.old@

For other image files it always fails with the following error message:

━━━━ /home/me ━━━━ sudo mount -o loop /media/me/Elements/210130.stargazer.img /mnt/iso 
mount: wrong fs type, bad option, bad superblock on /dev/loop0,
       missing codepage or helper program, or other error

   In some cases useful info is found in syslog - try
   dmesg | tail or so.

...So I look at the bottom of the syslog (lines ommitted):

━━━━ /home/me ━━━━ dmesg | tail
[661659.208600] EXT4-fs (loop0): warning: mounting fs with errors, running e2fsck is recommended
[661666.570406] EXT4-fs (loop0): mounted filesystem with ordered data mode. Opts: (null)

BUT

I made both filesystems precisely the same way.

I'm investigating if it's partly because of a screensaver or because the filesystem itself might be in flux while saving, but it's difficult because this takes a long time between runs.

Is there a utility that can help me diagnose this? It's suggesting that I run e2fsck, but how can I when I can't even mount the thing in the first place to give it a filesystem to check?

tgm1024--Monica was mistreated
  • 111
  • @Freddy, it almost does. It seemed like there was some disagreement as to whether or not just the data might be in flux (which I expect) or the filesystem structure itself would be. I can see what might happen if, say, an inode or directory were only partially configured because of being caught "mid stream" by the bit copy, but why would that clobber the entire mount? Wouldn't that corruption be local to whatever directory/inode/whatever was in flux? – tgm1024--Monica was mistreated Feb 11 '21 at 13:01
  • I wouldn't expect the filesystem to be completely unreadable, but data (file content) and the filesystem itself (inode table, metadata, etc.) can be damaged. dd is "stupid" and doesn't care about any structures. The possibility of wrong/corrupted data should be reason enough not to do it. – Freddy Feb 11 '21 at 13:50
  • @Freddy, is there an easy way of accomplishing a similar result? 1. How to mount as active / filesystem as readonly (not compatible across unix variants) or 2. Boot quickly into a grub-like state and save to a USB drive that itself hasn't yet been mounted (this results in multiple places for screwup)? I always seem to leave some critical component behind in a backup that is esoterically stuffed away in some corner of /usr/etc/share/something/hoohah that I wasn't expecting----hence the push for a byte copy at the device level. – tgm1024--Monica was mistreated Feb 11 '21 at 16:39
  • I wouldn't mount the root filesystem at all and boot a Live Linux distro from USB or GRUB. Then mount the target partition (USB or internal), double check that I select the correct source device/partition (e.g. gdisk -l /dev/sda) and run dd. – Freddy Feb 11 '21 at 17:20

0 Answers0