Code: Select all
$ dd if=/dev/zero of=test bs=1M count=50
50+0 records in
50+0 records out
52428800 bytes (52 MB) copied, 0.0258527 s, 2.0 GB/s
$ mkfs.xfs test
meta-data=test isize=512 agcount=2, agsize=6400 blks
= sectsz=512 attr=2, projid32bit=1
= crc=1 finobt=1
data = bsize=4096 blocks=12800, imaxpct=25
= sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0 ftype=1
log =internal log bsize=4096 blocks=855, version=2
= sectsz=512 sunit=0 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0
$ mkdir /mnt/test
$ mount -o loop test /mnt/test
mount: wrong fs type, bad option, bad superblock on /dev/loop1,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so.
$ dmesg|tail -n 6
[39571.687004] XFS (loop1): Version 5 superblock detected. This kernel has EXPERIMENTAL support enabled!
Use of these features in this kernel is at your own risk!
[39571.687007] XFS (loop1): Superblock has unknown read-only compatible features (0x1) enabled.
[39571.687009] XFS (loop1): Attempted to mount read-only compatible filesystem read-write.
Filesystem can only be safely mounted read only.
[39571.687014] XFS (loop1): SB validate failed with error 22.
According to some google searching, this is because of the `finobt=1` option which was turned on by default in the userspace utilities.
The xfs team says they wait a year after a stable kernel release supporting a new feature before turning said feature on by default in the userspace utilities. So is there any reason why system rescue cd is using such an ancient kernel?