Bug#526586: mkfs.ufs: could not find special device
Package: ufsutils
Version: 7.1-2
Severity: important
Tags: patch
Currently mkfs.ufs is not working in a Linux environment and is just
returning an error message when used:
> # mkfs.ufs /dev/md0
> mkfs.ufs: /dev/md0: could not find special device
This has been outlined in great detail by Dmitriy Kryuk before[0]. Attached
to his report is a diff to libufs/type.c; a dpatch will be attached to this
report later on. After applying the patch, I was able to successfully create,
mount and read/write from/to the newly created filesystem.
Thanks,
Christian.
[0] http://www.mail-archive.com/debian-bsd@lists.debian.org/msg04275.html
# mkfs.ufs /dev/md0
/dev/md0: 3812.1MB (7807104 sectors) block size 16384, fragment size 2048
using 21 cylinder groups of 183.72MB, 11758 blks, 23552 inodes.
super-block backups (for fsck -b #) at:
160, 376416, 752672, 1128928, 1505184, 1881440, 2257696, 2633952, 3010208,
3386464, 3762720, 4138976, 4515232, 4891488, 5267744, 5644000, 6020256,
6396512, 6772768, 7149024, 7525280
# mount -t ufs -o ufstype=ufs2 /dev/md0 /mnt/md0
# grep md0 /proc/mounts
/dev/md0 /mnt/md0 ufs rw,relatime,ufstype=ufs2,onerror=lock 0 0
-- System Information:
Debian Release: squeeze/sid
APT prefers experimental
APT policy: (900, 'experimental'), (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.30-rc4
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C)
Shell: /bin/sh linked to /bin/dash
Versions of packages ufsutils depends on:
ii libbsd0 0.0.1-2 utility functions from BSD systems
ii libc6 2.9-9 GNU C Library: Shared libraries
ii libedit2 2.11~20080614-1 BSD editline and history libraries
ii libncurses5 5.7+20090411-1 shared libraries for terminal hand
ii libufs2 7.1-2 UFS filesystem shared library
ufsutils recommends no packages.
ufsutils suggests no packages.
-- no debconf information#DPATCHLEVEL=1
Index: ufsutils/libufs/type.c
===================================================================
--- ufsutils.orig/libufs/type.c
+++ ufsutils/libufs/type.c
@@ -23,6 +23,9 @@
* STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING
* IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
* POSSIBILITY OF SUCH DAMAGE.
+ *
+ * Modified by Dmitriy Kryuk <motoprogger@users.sourceforge.net> to
+ * port libufs to Linux.
*/
#include <sys/cdefs.h>
@@ -108,32 +111,19 @@ again: if ((ret = stat(name, &st)) < 0)
*/
name = oname;
}
- if (ret >= 0 && S_ISCHR(st.st_mode)) {
+ /* There is a portability issue between BSD and Linux in that Linux
+ * mounts filesystems from block devices, not the character ones. I
+ * also consider it unlikely to format a device a filesystem is mounted
+ * from
+ */
+ if (ret >= 0 && S_ISBLK(st.st_mode)) {
/* This is what we need, do nothing. */
;
- } else if ((fs = getfsfile(name)) != NULL) {
- /*
- * The given mount point is listed in /etc/fstab.
- * It is possible that someone unmounted file system by hand
- * and different file system is mounted on this mount point,
- * but we still prefer /etc/fstab entry, because on the other
- * hand, there could be /etc/fstab entry for this mount
- * point, but file system is not mounted yet (eg. noauto) and
- * statfs(2) will point us at different file system.
- */
- name = fs->fs_spec;
- } else if (ret >= 0 && S_ISDIR(st.st_mode)) {
- /*
- * The mount point is not listed in /etc/fstab, so it may be
- * file system mounted by hand.
- */
- if (statfs(name, &sfs) < 0) {
- ERROR(disk, "could not find special device");
- return (-1);
- }
- strlcpy(dev, sfs.f_mntfromname, sizeof(dev));
- name = dev;
} else {
+ /* I consider adding a more detailed analysis on the root of
+ * the problem - in particular, if a file doesn't exist or is
+ * not a block special device
+ */
ERROR(disk, "could not find special device");
return (-1);
}
Index: ufsutils/include/ufs/ffs/fs.h
===================================================================
--- ufsutils.orig/include/ufs/ffs/fs.h
+++ ufsutils/include/ufs/ffs/fs.h
@@ -33,6 +33,9 @@
#ifndef _UFS_FFS_FS_H_
#define _UFS_FFS_FS_H_
+#include <sys/types.h>
+#include <stdint.h>
+
/*
* Each disk drive contains some number of filesystems.
* A filesystem consists of a number of cylinder groups.
Index: ufsutils/include/ufs/ufs/dinode.h
===================================================================
--- ufsutils.orig/include/ufs/ufs/dinode.h
+++ ufsutils/include/ufs/ufs/dinode.h
@@ -68,6 +68,8 @@
#ifndef _UFS_UFS_DINODE_H_
#define _UFS_UFS_DINODE_H_
+#include <sys/types.h>
+
/*
* The root inode is the root of the filesystem. Inode 0 can't be used for
* normal purposes and historically bad blocks were linked to inode 1, thus
Index: ufsutils/include/ufs/ufs/dir.h
===================================================================
--- ufsutils.orig/include/ufs/ufs/dir.h
+++ ufsutils/include/ufs/ufs/dir.h
@@ -38,6 +38,8 @@
#ifndef _UFS_UFS_DIR_H_
#define _UFS_UFS_DIR_H_
+#include <sys/types.h>
+
/*
* Theoretically, directories can be more than 2Gb in length, however, in
* practice this seems unlikely. So, we define the type doff_t as a 32-bit
Index: ufsutils/libufs/Makefile
===================================================================
--- ufsutils.orig/libufs/Makefile
+++ ufsutils/libufs/Makefile
@@ -1,26 +1,16 @@
# $FreeBSD: src/lib/libufs/Makefile,v 1.14 2006/10/31 21:21:48 pjd Exp $
LIB= ufs
-SHLIBDIR?= /lib
+SHLIB_MAJOR= 2
-SRCS= block.c cgroup.c inode.c sblock.c type.c
+LIBSRCS= block.c cgroup.c inode.c sblock.c type.c
INCS= libufs.h
-MAN= bread.3 cgread.3 libufs.3 sbread.3 ufs_disk_close.3
-MLINKS+= bread.3 bwrite.3
-MLINKS+= cgread.3 cgread1.3
-MLINKS+= cgread.3 cgwrite1.3
-MLINKS+= sbread.3 sbwrite.3
-MLINKS+= ufs_disk_close.3 ufs_disk_fillout.3
-MLINKS+= ufs_disk_close.3 ufs_disk_fillout_blank.3
-MLINKS+= ufs_disk_close.3 ufs_disk_write.3
+ALL_CFLAGS+= -D_LIBUFS
+ifdef LIBUFS_DEBUG
+ALL_CFLAGS+= -D_LIBUFS_DEBUGGING
+endif
+LDADD += -lbsd
+INCLUDES = -I.
-WARNS?= 2
-
-CFLAGS+= -D_LIBUFS
-.if defined(LIBUFS_DEBUG)
-CFLAGS+= -D_LIBUFS_DEBUGGING
-.endif
-CFLAGS+= -I${.CURDIR}
-
-.include <bsd.lib.mk>
+include ../Makefile.common
Reply to: