Description of problem: I migrated from FreeBSD 6.1 to FC6 Pre x86_64 and tried to mount my UFS2-formatted drives... here's what I did: # mount -r -t ufs -o ufstype=ufs2 /dev/sdd1 /mnt mount: wrong fs type, bad option, bad superblock on /dev/sdd1, missing codepage or other error In some cases useful info is found in syslog - try dmesg | tail or so here's what dmesg said: ufs_read_super: bad magic number # cat /proc/filesystems nodev sysfs nodev rootfs nodev bdev nodev proc nodev cpuset nodev binfmt_misc nodev debugfs nodev securityfs nodev sockfs nodev usbfs nodev pipefs nodev futexfs nodev tmpfs nodev inotifyfs nodev eventpollfs nodev devpts ext2 nodev ramfs nodev hugetlbfs iso9660 nodev mqueue nodev selinuxfs ext3 nodev rpc_pipefs nodev autofs ufs # ./modinfo ufs filename: /lib/modules/2.6.18-1.2708.fc6/kernel/fs/ufs/ufs.ko license: GPL srcversion: 28C144D2C43C6B79635A5AA depends: vermagic: 2.6.18-1.2708.fc6 SMP mod_unload gcc-4.1 How reproducible: just try to mount a UFS2-formatted drive on x86_64 ;) Additional info: i'm using FC6 Pre x86 now and mounting the drives works perfectly!
The on-disk structure definition for the 3rd superblock was getting improper alignment due to the natural alignment of 64-bit vars on x86_64. This caused it to look for fs_magic at the wrong offset in memory. This patch lets me mount a test ufs2 filesystem. Can you try this patch on your kernel? I don't actually have a populated ufs2 filesystem to test further than a simple mount. (I'd stick with read-only!) Index: linux-2.6.18/include/linux/ufs_fs.h =================================================================== --- linux-2.6.18.orig/include/linux/ufs_fs.h +++ linux-2.6.18/include/linux/ufs_fs.h @@ -900,7 +901,7 @@ struct ufs_super_block_third { __fs64 fs_csaddr; /* blk addr of cyl grp summary area */ __fs64 fs_pendingblocks;/* blocks in process of being freed */ __fs32 fs_pendinginodes;/*inodes in process of being freed */ - } fs_u2; + } __attribute__ ((packed)) fs_u2; } fs_un1; union { struct {
Created attachment 139666 [details] structure alignment patch Properly formatted patch... I should know better than to paste one inline :)
fwiw, I think the cylinder group on-disk structure may suffer from similar alignment issues.
I take that back, the cylinder group stuff should be ok. The patch in comment #2 is in -mm, and I have proposed it for -stable as well, since this is a regression since 2.6.17.
*** Bug 212708 has been marked as a duplicate of this bug. ***
>This patch lets me mount a test ufs2 filesystem. Can you try this patch on your >kernel? I don't actually have a populated ufs2 filesystem to test further than >a simple mount. (I'd stick with read-only!) I applied the patch frp, Comment #1 on Fedora Core 6 x86_64 and tried to mount a solaris ufs filesystem ; It did not work. I got: mount: wrong fs type, bad option, bad superblock on /dev/hda3, missing codepage or other error In some cases useful info is found in syslog - try dmesg | tail or so when trying mount -t ufs -o ro /dev/hda3 /mnt/sol mount -t ufs -o ro,ufstype=sunx86 /dev/hda3 /mnt/sol mount -t ufs -o ro,ufstype=ufs2 /dev/hda3 /mnt/sol Rami Rosen
re: comment #7, and what did dmesg say after each mount failure?
Sorry, I should have mentioned it : the error were the same as before applying the patch. Namely, dmesg showed in all three cases Nov 2 13:04:01 rh kernel: ufs_read_super: bad magic number (In the first case , it also added a warning because of using the default "old" ufstype Nov 2 13:04:01 rh kernel: >>>WARNING<<< Wrong ufstype may corrupt your filesystem , default is ufstype=old Rami Rosen
Is there any chance you could dd out the first 256k or so of the filesystem, and I can try a test on it here? I don't have access to a solaris ufs image... Otherwise maybe I can ring up a friend at Sun... :) Thanks, -Eric
Created attachment 140145 [details] dump of dd if=/dev/sda5 of=/work/sda5.txt bs=1K count=256
It seems to work for me with the patch in place... [root@neon tmp]# file sda5.txt sda5.txt: Unix Fast File system (little-endian), last mounted on /mnt/solaris1, last written at Thu Oct 26 09:45:25 2006, clean flag 253, number of blocks 20482875, number of data blocks 20172604, number of cylinder groups 417, block size 8192, fragment size 1024, minimum percentage of free blocks 1, rotational delay 0ms, disk rotational speed 60rps, TIME optimization [root@neon tmp]# dd if=/dev/zero seek=167795712000 bs=1 count=1 of=ufsfile [root@neon tmp]# dd if=sda5.txt of=ufsfile [root@neon ufs]# mount -t ufs -o ufstype=sun,loop,ro ufsfile mnt/ [root@neon ufs]# mount | grep ufs /src/ufs/ufsfile on /src/ufs/mnt type ufs (ro,loop=/dev/loop0,ufstype=sun) [root@neon ufs]# umount mnt [root@neon ufs]# mount -t ufs -o ufstype=sunx86,loop,ro ufsfile mnt/ [root@neon ufs]# umount mnt/ [root@neon ufs]# mount -t ufs -o loop,ro ufsfile mnt/ [root@neon ufs]# umount mnt/ can you point gdb at your patched ufs.ko module: [root@neon ufs]# gdb ufs.ko GNU gdb Red Hat Linux (6.3.0.0-1.134.fc5rh) Copyright 2004 Free Software Foundation, Inc. ... (gdb) print sizeof(struct ufs_super_block_third) $1 = 356 (gdb) and make sure that size is coming out as shown?
It works ! My check was incorrect, sorry. With the patch applied I am able to mount it thus: mount -t ufs -o ro,ufstype=sunx86 /dev/sda5 /mnt/sol/ -- when mounting thus: mount -t ufs -o ro,ufstype=sunx86 /dev/sda5 /mnt/sol/ I see in the kernel log the following: Nov 2 20:06:52 rh kernel: ufs_read_super: can't grok fs_clean 0xfffffffd but it is mounted nevertheless; mount |grep ufs returns: /dev/sda5 on /mnt/sol type ufs (ro) Rami
Hmm. That 0xfffffffd corresponds to the "clean flag" value of 253 (0xfd) in the "file" output: [root@neon ufs]# file /tmp/sda5.txt /tmp/sda5.txt: Unix Fast File system (little-endian), last mounted on /mnt/solaris1, last written at Thu Oct 26 09:45:25 2006, clean flag 253, number of blocks 20482875, number of data blocks 20172604, number of cylinder groups 417, block size 8192, fragment size 1024, minimum percentage of free blocks 1, rotational delay 0ms, disk rotational speed 60rps, TIME optimization based on: http://cvs.opensolaris.org/source/xref/on/usr/src/uts/common/sys/fs/ufs_fs.h it looks like there are some solaris flag states that linux does not know: /* * fs_clean values */ #define FSACTIVE ((char)0) #define FSCLEAN ((char)0x1) #define FSSTABLE ((char)0x2) #define FSBAD ((char)0xff) /* mounted !FSCLEAN and !FSSTABLE */ #define FSSUSPEND ((char)0xfe) /* temporarily suspended */ #define FSLOG ((char)0xfd) /* logging fs */ #define FSFIX ((char)0xfc) /* being repaired while mounted */ while the linux code only knows: #define UFS_FSACTIVE ((__s8)0x00) #define UFS_FSCLEAN ((__s8)0x01) #define UFS_FSSTABLE ((__s8)0x02) #define UFS_FSOSF1 ((__s8)0x03) /* is this correct for DEC OSF/1? */ #define UFS_FSBAD ((__s8)0xff) Looks like you have FSLOG. But I think that is a bug for another day :) Since you can mount now, can you close the osdl bug too? It might be worth logging a bug on this unknown clean state, but it is a separate issue from this bug. Thanks! -Eric
I had mentioned the message "can't grok fs_clean 0xfffffffd" only to draw your intention to it in order make sure it does not cause problems elsewhere; and since it does not, this BUG is solved and closed. Rami
should be fixed in 2.6.18-1.2849.fc6 now in updates