UFS Mount prblem on UFS(2) USB drive

Dear Anybody!

I try to mount (manipulate) USB disk containing freebsd (ufs(2)) partition.

The FreeBSD version is 13.x on amd64 and in LiveCD mode.

If I try to mount (just for test) a fat32 USB disk, then it is works well.

If I try to mount the ufs disk with no type or with ufs type then I get error message “No such file or directory”.

If I try to mount the ufs on linux (with type ufs2) then it is work fine (read and write) except the 2GB write limit of kernel.

The usf partition by "gpart show" is freebsd.

Thanks for any idea.
 
The usf partition by "gpart show" is freebsd.
It's likely a BSD label partition. Is it freebsd or freebsd-ufs? If it's freebsd then this is a BSD label. The partition is inside that slice, i.e. da0s1a.

Post the output from gpart show please.
 
The disk is da1.
The partition type is "freebsd" (by gpart).
In /dev I have da1s1 device file. This is what I try to use for mount.
But gpart NOT display parititon entry of da1s1!
 
Here I attach for you the screenshots.
The da0 is a boot disk (USB stick).
The da1 is a problematic disk.
 

Attachments

  • freebsd_2.jpg
    freebsd_2.jpg
    163.7 KB · Views: 85
  • freebsd_1.jpg
    freebsd_1.jpg
    242.3 KB · Views: 170
It's an MBR partitioned disk, so da1s1 is a slice. The partition is da1s1a. Unless someone did something stupid and formatted the slice instead of the partition. But that's not the case or else you would have been able to mount da1s1.

mount /dev/da1s1a /mnt
 
It's an MBR partitioned disk, so da1s1 is a slice. The partition is da1s1a. Unless someone did something stupid and formatted the slice instead of the partition. But that's not the case or else you would have been able to mount da1s1.

mount /dev/da1s1a /mnt
The result is "No such file or directory". Remark: The da1s1a device file not exists just a da1s1. And I cant mount /dev/da1s1.
 
What does file -s /dev/da1s1 and file -s /dev/diskid/DISK-nnn show?
 
The answer is attached.
Do not forget: The da0 is a boot disk (USB stick). The da1 is a subject disk.
 

Attachments

  • freebsd_3.jpg
    freebsd_3.jpg
    248.7 KB · Views: 95
You forgot the -s option.

Code:
     -s, --special-files
             Normally, file only attempts to read and determine the type of
             argument files which stat(2) reports are ordinary files.  This
             prevents problems, because reading special files may have
             peculiar consequences.  Specifying the -s option causes file to
             also read argument files which are block or character special
             files.  This is useful for determining the filesystem types of
             the data in raw disk partitions, which are block special files.
             This option also causes file to disregard the file size as
             reported by stat(2) since on some systems it reports a zero size
             for raw disk partitions.

We already know they're character special devices, they're disks and/or partitions (FreeBSD doesn't have block devices).
 
As you can see both da1s1 and /dev/diskid/DISK-0000002CE11C4s1 refer to the same partition. It's also clear someone did something bad and formatted the slice itself.
These should work:
mount /dev/diskid/DISK-0000002CE11C4s1 /mnt
or
mount /dev/da1s1 /mnt
 
Thank you guys!
This is an filesystem of commercial device controller engineer'd in Japan.
Maybe this is the reason for big endian.
I try netbsd.
 
the fs looks to be big endian which could be a problem
you may need netbsd to access it properly
Are you sure about netbsd (or sunos)?
I read about, and for this operating system the ufs endianess binded to processor endianess.
This mean, on AMD64 or Intel64 hardware you never handle ufs big endian (because it is little endian processors).

As far as I known the only exception is linux where both little and big endian ufs are implemented on little endian (e.g. AMD64) processors.
But there the ufs support is many times "blacklisted".
 
I vaguely remember that some BSD publication discusses the endianness of on-disk data structures for FFS/UFS. I just looked in the index of the "black daemon book" (Design and Implementation of FreeBSD, by Kirk McKusick et al), and it's not referenced there. But that's just the index.

If I remember right (big if!), the endianness is set by the CPU endianness of the machine that creates the file system, and if you later attach the formatted and written disk to a different-endian CPU it will be usable. If someone has some time, they could dig this up in the book, the old FFS paper, or the source code.
 
im not 100% sure about netbsd but according to a comment here netbsd ufs code is byte order independent

seems that their newfs can also specify byteorder
"intel x86 machine which is little endian ... just newfs an md partition, mount it and copy. But that won't work for a big endian image."

The process described at blogspot is contain limitation make this solution for me useless.

Other side this qulaity of a netbsd is littlebit strange for me.
Because the network operation translation from big to little endian and back is common function.
Looks like it is not implemented (well) for the file system.

I try a latest linux kernel (le opsys and be nfs disk).
If it is not works the maybe I try to acquire a be hardware.
 
I vaguely remember that some BSD publication discusses the endianness of on-disk data structures for FFS/UFS. I just looked in the index of the "black daemon book" (Design and Implementation of FreeBSD, by Kirk McKusick et al), and it's not referenced there. But that's just the index.

If I remember right (big if!), the endianness is set by the CPU endianness of the machine that creates the file system, and if you later attach the formatted and written disk to a different-endian CPU it will be usable. If someone has some time, they could dig this up in the book, the old FFS paper, or the source code.
This can mean, the mkfs cannot implement le<->be swap but the mount can.
What we recognize (se above) against this.
Looks like mount not implement le<->be swap (mount be disk on le opsys).
 
i posted the blogspot link for the comment not for the article itself
the comment implied that netbsd ufs code is byte order independent and i speculated that bigendian machines can mount little endian ufs and viceversa
also netbsds newfs has a byte order switch which makes the above more credible (didn't check kernel code tbh)
 
Back
Top