mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Thomas Stewart <thomas@stewarts.org.uk>
To: linux-kernel@vger.kernel.org
Subject: Mounting BorderWare UFS File Systems
Date: Tue, 11 May 2010 22:53:04 +0100	[thread overview]
Message-ID: <20100511215300.GA22152@stewarts.org.uk> (raw)

Hi,

I recently had to recover some files from an old broken machine that was
running BorderWare Document Gateway. It's basically a drop in web server
for sharing files. From the look of the init process and using strings
on of a few files it seems to be based on FreeBSD 3.3. The process
turned out to be more difficult than I imagined, but to cut a long story
short BorderWare in their wisdom use a nonstandard magic number in their
UFS (ufstype=44bsd) file systems. Thus Linux refuses to mount the file
systems in order to recover the data. After a bit of hunting I was able
to make a quick fix to fs/ufs/super.c in order to detect the new magic
number. I don't think this needs to get into mainline, but hopefully
this will hit the archives to save anyone else the effort. I'm assume
that this number is the same for all installations. It's quite easy to
find out from ufs_fs.h. The superblock sits 8k into the block device and
the magic number its 1372 bytes into the superblock struct.

# dd if=/dev/sda5 skip=$(( 8192 + 1372 )) bs=1 count=4 2> /dev/null | hd
00000000  97 26 24 0f                                       |.&$.|
#

Here is the patch, please cc any questions or comments as I'm off list.

diff -urN linux-2.6.33.1.orig/fs/ufs/super.c linux-2.6.33.1/fs/ufs/super.c
--- linux-2.6.33.1.orig/fs/ufs/super.c  2010-05-11 20:07:08.000000000 +0100
+++ linux-2.6.33.1/fs/ufs/super.c       2010-05-11 21:23:06.000000000 +0100
@@ -918,6 +918,7 @@
        sbi->s_bytesex = BYTESEX_LE;
        switch ((uspi->fs_magic = fs32_to_cpu(sb, usb3->fs_magic))) {
                case UFS_MAGIC:
+               case UFS_MAGIC_BW:
                case UFS2_MAGIC:
                case UFS_MAGIC_LFN:
                case UFS_MAGIC_FEA:
@@ -927,6 +928,7 @@
        sbi->s_bytesex = BYTESEX_BE;
        switch ((uspi->fs_magic = fs32_to_cpu(sb, usb3->fs_magic))) {
                case UFS_MAGIC:
+               case UFS_MAGIC_BW:
                case UFS2_MAGIC:
                case UFS_MAGIC_LFN:
                case UFS_MAGIC_FEA:
diff -urN linux-2.6.33.1.orig/fs/ufs/ufs_fs.h linux-2.6.33.1/fs/ufs/ufs_fs.h
--- linux-2.6.33.1.orig/fs/ufs/ufs_fs.h 2010-03-15 16:09:39.000000000 +0000
+++ linux-2.6.33.1/fs/ufs/ufs_fs.h      2010-05-11 21:20:35.000000000 +0100
@@ -48,6 +48,7 @@
 #define UFS_SECTOR_SIZE 512
 #define UFS_SECTOR_BITS 9
 #define UFS_MAGIC  0x00011954
+#define UFS_MAGIC_BW 0x0f242697
 #define UFS2_MAGIC 0x19540119
 #define UFS_CIGAM  0x54190100 /* byteswapped MAGIC */
 
Regards
--
Tom

             reply	other threads:[~2010-05-11 22:30 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-11 21:53 Thomas Stewart [this message]
2010-05-12 20:56 ` Andrew Morton
2010-05-19 21:19   ` Thomas Stewart

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100511215300.GA22152@stewarts.org.uk \
    --to=thomas@stewarts.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®