4

I'm trying to create a disk image and mount the partition for further work, but I'm encountering a frustrating error message: "wrong fs type, bad option, bad superblock." Here's the steps I took and the output I received:

$ dd if=/dev/zero of=test.img status=progress bs=200M count=1
1+0 records in
1+0 records out
209715200 bytes (210 MB, 200 MiB) copied, 0.191841 s, 1.1 GB/s

$ mkfs.ext4 test.img
mke2fs 1.47.0 (5-Feb-2023)
Discarding device blocks: done

Creating filesystem with 204800 1k blocks and 51200 inodes
Filesystem UUID: b4c4d7d0-0341-4f48-880f-de2110f36825
Superblock backups stored on blocks: 
        8193, 24577, 40961, 57345, 73729


Allocating group tables: done

Writing inode tables: done

Creating journal (4096 blocks): done
Writing superblocks and filesystem accounting information: done


$ fdisk test.img


Welcome to fdisk (util-linux 2.39.3).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.


The device contains 'ext4' signature and it will be removed by a write command. See fdisk(8) man page and --wipe option for more details.


Device does not contain a recognized partition table.
Created a new DOS (MBR) disklabel with disk identifier 0xca60123f.


Command (m for help): n
Partition type
   p   primary (0 primary, 0 extended, 4 free)
   e   extended (container for logical partitions)
Select (default p): p
Partition number (1-4, default 1): 
First sector (2048-409599, default 2048): 
Last sector, +/-sectors or +/-size{K,M,G,T,P} (2048-409599, default 409599):


Created a new partition 1 of type 'Linux' and of size 199 MiB.


Command (m for help): w
The partition table has been altered.
Syncing disks.


$ fdisk -lu test.img
Disk test.img: 200 MiB, 209715200 bytes, 409600 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xca60123f


Device     Boot Start    End Sectors  Size Id Type
test.img1        2048 409599  407552  199M 83 Linux


$ sudo mount test.img mount-point/ -o loop,offset=$((512*2048))
mount: /home/reyuki/code/linux-system/mount-point: wrong fs type, bad option, bad superblock on /dev/loop1, missing codepage or helper program, or other error.
       dmesg(1) may have more information after failed mount system call.


$ sudo dmesg
[ 8616.381787] loop1: detected capacity change from 0 to 407552
[ 8616.384637] EXT4-fs (loop1): VFS: Can't find ext4 filesystem
[ 8616.384782] EXT4-fs (loop1): VFS: Can't find ext4 filesystem
[ 8616.384874] EXT4-fs (loop1): VFS: Can't find ext4 filesystem
[ 8616.385973] ISOFS: Unable to identify CD-ROM format.

Have I missed a crucial step in the process? Any insights or suggestions would be greatly appreciated!

Raffa
  • 34,963
ReYuki
  • 49

3 Answers3

4

You formatted the whole image with a filesystem and then created a primary partition afterwards spanning the whole same image and assumed the filesystem will still exist ... Well, the filesystem was destroyed when the primary partition was created on-top of it and the image is left with a partition that is not formatted.

With disk images that contain partitions, there are simpler methods with tools available from the official repositories that can read an map partition tables available on disk images like kpartx ...

So, basically, you would create the image file with e.g. dd, then partition it with e.g. fdisk like you did ... and then use a tool like kpartx to read the partition table and map it creating block device on your system that you then can handle, format, and even mount like you'd normally do like so:

$ sudo kpartx -av test.img
add map loop1p1 (252:0): 0 407552 linear 7:1 2048

... notice the reported name(s) of the block device file(s) for the partition loop1p1 that you can access under /dev/mapper/ to e.g. format it like this:

$ sudo mkfs.ext4 /dev/mapper/loop1p1 
mke2fs 1.47.0 (5-Feb-2023)
Discarding device blocks: done                            
Creating filesystem with 50944 4k blocks and 50944 inodes
Filesystem UUID: d02236d0-27c3-46ab-8806-a9f936f6d947
Superblock backups stored on blocks: 
    32768

Allocating group tables: done

Writing inode tables: done

Creating journal (4096 blocks): done
Writing superblocks and filesystem accounting information: done

... and then mount it like this:

$ sudo mount /dev/mapper/loop1p1  mount-point/
$
$
$ findmnt -T mount-point
TARGET                        SOURCE              FSTYPE OPTIONS
/home/ubuntu/test/mount-point /dev/mapper/loop1p1 ext4   rw,relatime
guntbert
  • 13,475
Raffa
  • 34,963
0

I encountered a similar issue with a USB hard drive saying bad fs, etc. I used Ubuntu's 'disks' utility to Check Filesystem (was fine) then Repair Filesystem (did some corrections). Mounted using Disks (the black square at lower left. next to the gear which is how I got to the above).
Everything looked OK but my script still didn't work (worked fine until the error. I was also getting an error message about the hard drive being RO (read-only). chmod - not fix. Then I noticed a detail: there were two external drives: one "WD_10TB" (I'm not creative when it comes to namings!) and the other WD_10TB1". Something changed/updated the volume name. Pointing mount points, backup script to the 'new' drive got rid of the "wrong fs type, bad option, bad superblock" error message for me.

Barry Martin
  • 133
-1
$ losetup -f test.img
$ losetup -a
/dev/loop1: []: (/home/reyuki/code/linux-system/test.img)
/dev/loop0: []: (/home/reyuki/code/distro/boot.img)
$ sudo fsck -fv /dev/loop1
fsck from util-linux 2.39.3
e2fsck 1.47.0 (5-Feb-2023)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Block bitmap differences:  +(40961--41219) +(57345--57603) +(73729--73987)
Fix<y>? yes
Free blocks count wrong for group #3 (8192, counted=7933).
Fix<y>? yes

/dev/loop1: ***** FILE SYSTEM WAS MODIFIED *****

          12 inodes used (0.02%, out of 51200)
           0 non-contiguous files (0.0%)
           0 non-contiguous directories (0.0%)
             # of inodes with ind/dind/tind blocks: 0/0/0
             Extent depth histogram: 4
       18565 blocks used (9.06%, out of 204800)
           0 bad blocks
           0 large files

           0 regular files
           2 directories
           0 character device files
           0 block device files
           0 fifos
           0 links
           0 symbolic links (0 fast symbolic links)
           0 sockets
------------
           2 files
$ sudo mount test.img mount-point/ -o loop
$ ls mount-point/
lost+found

got the idea of using fsck from this answer but still don't know why the newly created disk image was corrupt? that seems odd given that the file was just created

ReYuki
  • 49