How to mount FFS partition under Linux

From NetBSD Wiki

Jump to: navigation, search

Contents

[edit] Verify UFS support

To check whether your Linux kernel supports the UFS filesystem you may execute the following command:

$ cat /proc/filesystems
nodev   sysfs
nodev   rootfs
nodev   proc
        .
        .
        .
        ext3
nodev   usbfs
        vfat
        ufs

The keyword nodev in the first column means that filesystem does not require a block device to be mounted, that's why it is also called virtual filesystem. The support is either compiled inside the kernel or as a module:

$ ls -l /lib/modules/2.6.21-ARCH/kernel/fs/ufs/ufs.ko 
-rw-r--r-- 1 root root 84828 2007-05-25 20:11 /lib/modules/2.6.21-ARCH/kernel/fs/ufs/ufs.ko

[edit] Mount

In order to find the device that corresponds to your FFS partition, run:

  1. sfdisk -l
Disk /dev/hda: 155061 cylinders, 16 heads, 63 sectors/track
Warning: extended partition does not start at a cylinder boundary.
DOS and Linux will interpret the contents differently.
Units = cylinders of 516096 bytes, blocks of 1024 bytes, counting from 0
  Device Boot Start     End   #cyls    #blocks   Id  System
/dev/hda1   *      0+  34536-  34537-  17406396    7  HPFS/NTFS
               end: (c,h,s) expected (1023,15,63) found (1023,254,63)
/dev/hda2      34536+ 134767- 100231-  50516392+   f  W95 Ext'd (LBA)
               start: (c,h,s) expected (1023,15,63) found (1023,255,63)
               end: (c,h,s) expected (1023,15,63) found (1023,254,63)
/dev/hda3     134767+ 144935-  10169-   5124735   a5  FreeBSD
               start: (c,h,s) expected (1023,15,63) found (1023,255,63)
               end: (c,h,s) expected (1023,15,63) found (1023,254,63)
/dev/hda4     144935+ 155060   10126-   5103189   a9  NetBSD
               start: (c,h,s) expected (1023,15,63) found (1023,255,63)
               end: (c,h,s) expected (1023,15,63) found (1023,80,63)
/dev/hda5      34536+ 102366-  67830-  34186288+  83  Linux
               start: (c,h,s) expected (1023,15,63) found (0,1,1)
               end: (c,h,s) expected (1023,15,63) found (1023,254,63)
/dev/hda6     102366+ 104294    1929-    971901   82  Linux swap / Solaris
               start: (c,h,s) expected (1023,15,63) found (0,1,1)
               end: (c,h,s) expected (1023,15,63) found (120,254,63)
/dev/hda7     104295+ 134767-  30473-  15358108+  83  Linux
               start: (c,h,s) expected (1023,15,63) found (0,1,1)
               end: (c,h,s) expected (1023,15,63) found (1023,254,63)
/dev/hda8     134767+ 143910-   9143-   4608000
/dev/hda9     143910+ 144935-   1026-    516735
/dev/hda10    144935+ 154078-   9143    4608072
/dev/hda11    154078+ 155060     983-    495117
/dev/hda12         0+  34536-  34537-  17406396
/dev/hda13     34536+ 102366-  67830-  34186288+
/dev/hda14    102366+ 104294    1929-    971901
/dev/hda15    104295+ 144935-  40641-  20482843+

So for FreeBSD (FFSv2), we have /dev/hda3 which is equivalent to /dev/ad0s3

And for NetBSD (FFSv1), we have /dev/hda4 which is equivalent to /dev/wd0c

But these devices are whole BSD slices (BIOS partitions), not BSD partitions.

By examinating carefully sfdisk - l output, we find that: /dev/hda3 (134767+,144935-) includes /dev/hda8 (134767+,143910-) and /dev/hda9 (143910+,144935-) /dev/hda4 (144935+,155060) includes /dev/hda10 (144935+,154078-) and /dev/hda11 (154078+,155060)

And we may deduce that for FreeBSD: /dev/hda8 is equivalent to /dev/ad0s3a (FreeBSD root partition) /dev/hda9 is equivalent to /dev/ad0s3b (FreeBSD swap)

And for NetBSD: /dev/hda10 is equivalent to /dev/wd0a (NetBSD root partition) /dev/hda11 is equivalent to /dev/wd0b (NetBSD swap)

Thus FreeBSD root partition lies at /dev/hda8. First create a directory to mount FFS partition and then mount it:

# mkdir /mnt/freebsd
# mount -t ufs -o ro,ufstype=ufs2 /dev/hda8 /mnt/freebsd/

And NetBSD root partition lies at /dev/hda10. First create a directory to mount FFS partition and then mount it:

# mkdir /mnt/netbsd
# mount -t ufs -o ro,ufstype=44bsd /dev/hda10 /mnt/netbsd/

Let's browse it:

# ls /mnt/*bsd
/mnt/freebsd:
bin   cdrom   COPYRIGHT  dist     etc   lib      media  proc    root  sys  usr
boot  compat  dev        entropy  home  libexec  mnt    rescue  sbin  tmp  var
/mnt/netbsd:
altroot  etc                 gnome-screensave.core  mnt      root   var
bin      GENERIC             kern                   netbsd   sbin
boot     GENERIC-DIAGNOSTIC  lib                    onetbsd  stand
CUSTOM   GENERIC-LAPTOP      libdata                proc     tmp
dev      GENERIC-NOACPI      libexec                rescue   usr

[edit] Edit /etc/fstab

Add the following line to your /etc/fstab file:

/dev/hda8       /mnt/freebsd     ufs     ufstype=ufs2,ro        0       2
/dev/hda10      /mnt/netbsd      ufs     ufstype=44bsd,ro       0       2

Now you can mount the FFS partitions by typing:

# mount /mnt/freebsd
# mount /mnt/netbsd

and verify with:

$ mount
[...]
/dev/hda8 on /mnt/freebsd type ufs (ro,ufstype=ufs2)
/dev/hda10 on /mnt/netbsd type ufs (ro,ufstype=44bsd)
[...]

[edit] Write support

Write support is available given several conditions are satisfied: - ufs write support option compiled in Linux kernel (CONFIG_UFS_FS_WRITE=y): it is disabled by default. - FFSv1 filesystem (FFSv2 not yet supported)

Please note that as I do not really need write support on NetBSD partitions from GNU/Linux, I did not bother to rebuild my Linux kernel and hence have not tested this feature.

[edit] Remarks

  • If you forget the ro option, you will get the following message at dmesg:
$ dmesg | grep ufs
ufs was compiled with read-only support, can't be mounted as read-write
  • If you forget to set the ufstype option, you will get the following message at dmesg:
$ dmesg | grep ufstype
mount -t ufs -o ufstype=sun|sunx86|44bsd|ufs2|5xbsd|old|hp|nextstep|nextstep-cd|openstep ...
>>>WARNING<<< Wrong ufstype may corrupt your filesystem, default is ufstype=old

So, extra care should be taken.

People have reported crashes using FFS partitions access under GNU/Linux (even in read-only mode, that is very strange). I am half convinced that has been caused by accessing a whole BSD slice (BSD dedicated BIOS partition) instead of a BSD partition.

Personal tools