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!

3 Answers 3

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
6
  • > Well, the filesystem was destroyed when the primary partition was created on-top of it | Is there a way to make the fdisk not destroy the image? or it is inevitable?
    – Yuki San
    Apr 21 at 13:48
  • 1
    @YukiSan Unless you are recovering a lost partition with great care (which is a data recovery procedure), you don't want to do that ... So, generally, I'd say "it is inevitable" as the new partition creation process alters how the disk is identified and it will always be identified as unformatted i.e. no filesystem so mounting tools will error with wrong fs type, bad option, bad superblock on ... and alike ... See the "Remarks" section here: askubuntu.com/a/1422748 discussing disks,partitions and filesystems concepts in more detail.
    – Raffa
    Apr 21 at 14:00
  • after following your instruction, I can't mount the disk, I just able to mount the partition, the error when I mount the disk: wrong fs type, bad option, bad superblock on /dev/loop0, missing codepage or helper program, or other error, how to fix it? I tried fscks on the disk but did not work :"
    – Yuki San
    Apr 22 at 12:16
  • I check some disk images provided by distros like Arch Linux; these images have partitions but can also be mounted directly.
    – Yuki San
    Apr 22 at 12:18
  • @Yuki San You can only mount filesystems, not disks (remember, fstab means "file system table"). We add a filesystem to each partition of a disk to be easyly recognized bye the system (except in the case of LVM partitions, that are components of volumes and are managed differently). Even if we want to use the full disk, we create one partition spanning al the available space, and format it with a desired filesystem. So, you do not "mount a disk", you "mount a filesystem present in the disk". So, you can "mount a filesystem present in a file" with the loop mechanism, without partitioning it.
    – Fjor
    Apr 23 at 21:03
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.

-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

2
  • 1
    I can't agree with this any less :D ... If you're learning, then learn the right way and don't patch your way up ... This is merely a patch and may work some times and not work other times,
    – Raffa
    Apr 21 at 12:27
  • In this case, the filesystem structure of mkfs.ext4 is present in the file even if you repartitioned it, and fsck can recover it and try to fix it for the whole file. The problem was trying to partition the file after formatting it. A file does not need partitions; for a disk, the partitions are used for the system to identify the used space in the disk and detect the beginning of each filesystem it contains.
    – Fjor
    Apr 23 at 21:07

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .