Bug 177538 - tunefs(8) and mount(8) can not access a newfs(8)'d filesystem (clang, EABI).
Summary: tunefs(8) and mount(8) can not access a newfs(8)'d filesystem (clang, EABI).
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: arm (show other bugs)
Version: 10.0-CURRENT
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-arm (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-04-01 09:40 UTC by rz-rpi03
Modified: 2015-05-25 02:04 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description rz-rpi03 2013-04-01 09:40:00 UTC
It looks like there is a reproduceable problem with geom when creating/accessing
a ufs using clang and EABI.

newfs(8) creates a filesystem, but tunefs(8) and mount(8) can not use it.

The problem shows up as:
# tunefs -n enable /dev/mmcsd0s3a
tunefs: /dev/mmcsd0s3a: could not read superblock to fill out disk
# mount /dev/mmcsd0s3a /mnt
mount: /dev/mmcsd0s3a: Invalid argument

Kernel and world are at the same revision.

How-To-Repeat: Kernel and world are build on a i386 9.1-STABLE revision 248678 with:

make -C $SRCROOT -DWITH_ARM_EABI kernel-toolchain
make -C $SRCROOT KERNCONF=$KERNCONF WITH_FDT=yes -DWITH_ARM_EABI buildkernel
make -C $SRCROOT MALLOC_PRODUCTION=yes -DWITH_ARM_EABI buildworld

KERNCONF is RPI-B with serial console enabled (RPI-Bsc).

Initial SD-card layout:
# gpart show
=>      1  7788543  mmcsd0  MBR  (3.7G)
        1       62          - free -  (31k)
       63    65520       1  !12  [active]  (32M)
    65583  2031561       2  freebsd  (992M)
  2097144  5691400          - free -  (2.7G)

=>      0  2031561  mmcsd0s2  BSD  (992M)
        0  2031561         1  freebsd-ufs  (992M)


Now I add a new MBR slice, create a BSD disklabel on it and add a
partition on that. After that I create a new ufs filesystem and try
tunefs(8) and mount(8) on it.

# gpart add -t freebsd mmcsd0
mmcsd0s3 added, but partition is not aligned on 65536 bytes

The alignment warning is caused by the stripesize[1].

# gpart create -s BSD mmcsd0s3
mmcsd0s3 created
# gpart add -t freebsd-ufs mmcsd0s3
mmcsd0s3a added
# newfs /dev/mmcsd0s3a
/dev/mmcsd0s3a: 2778.8MB (5691008 sectors) block size 32768, fragment size 4096
        using 5 cylinder groups of 626.09MB, 20035 blks, 80256 inodes.
super-block backups (for fsck -b #) at:
 192, 1282432, 2564672, 3846912, 5129152
# tunefs -n enable /dev/mmcsd0s3a
tunefs: /dev/mmcsd0s3a: could not read superblock to fill out disk
# mount /dev/mmcsd0s3a /mnt
mount: /dev/mmcsd0s3a: Invalid argument

Resulting SD-card layout:
# gpart show
=>      1  7788543  mmcsd0  MBR  (3.7G)
        1       62          - free -  (31k)
       63    65520       1  !12  [active]  (32M)
    65583  2031561       2  freebsd  (992M)
  2097144       63          - free -  (31k)
  2097207  5691168       3  freebsd  (2.7G)
  7788375      169          - free -  (84k)

=>      0  2031561  mmcsd0s2  BSD  (992M)
        0  2031561         1  freebsd-ufs  (992M)

=>      0  5691168  mmcsd0s3  BSD  (2.7G)
        0       73            - free -  (36k)
       73  5691008         1  freebsd-ufs  (2.7G)
  5691081       87            - free -  (43k)


Creating the ufs on the i386 system results in a mountable filesystem on the
pi.

[1] # diskinfo -v mmcsd0
mmcsd0
        512             # sectorsize
        3987734528      # mediasize in bytes (3.7G)
        7788544         # mediasize in sectors
        65536           # stripesize
        0               # stripeoffset
                        # Disk ident.
Comment 1 Andreas Schwarz 2013-08-08 01:02:33 UTC
The problem is still existing with current head (r254005), seems that newfs is 
not working correctly. Tunefs and mount can't work with a corrupt ufs structure.
When doing the newfs at my separate pc, all is fine.
Comment 2 Ian Lepore freebsd_committer freebsd_triage 2015-05-25 02:04:17 UTC
I believe this should be fixed by r283014.