UFS Cannot mount filesystem

Hi,
I have an SSD (240 GB size) with Windows 10 and FreeBSD 11.1-RELEASE
I needed to reinstall Windows 10, and so my bootmanager was lost..
I tried to recover it with live FreeBSD (using boot0cfg command..)
Unfortunately, after reboot, I had no way to boot anything.
I booted my system with gparted live CD, and I noticed that all space was "unallocated".
So, I ran testdisk (from a live Linux cd) and it seems it was able to restore partiton layout.

My problem is: I can mount even Windows 10 partition and FreeBSD from a Linux live system, but I am not able to mount FreeBSD partition from FreeBSD live cd!

The error I get is:

Code:
g_vfs_done():ada1s5[READ(offset=65536, length=8192)]error = 5

This is gpart output (from FreeBSD 11.1-RELEASE live):
Code:
root@:~ # gpart show /dev/ada1                                                 

=>       63  468862065  ada1  MBR  (224G)                                       

         63       1985        - free -  (993K)                                 

       2048    1024000     1  ntfs  [active]  (500M)                           

    1026048  407601152     2  ntfs  (194G)                                     

  408627200     970752     3  ntfs  (474M)                                     

  409597952   59262976     4  ebr  (28G)                                       

  468860928       1200        - free -  (600K)

This is fdisk output from Linux live cd:
Code:
# fdisk -l /dev/sdb

WARNING: GPT (GUID Partition Table) detected on '/dev/sdb'! The util fdisk doesn't support GPT. Use GNU Parted.


Disk /dev/sdb: 240.1 GB, 240057409536 bytes
255 heads, 63 sectors/track, 29185 cylinders, total 468862128 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xa8a8a8a8

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1   *        2048     1026047      512000    7  HPFS/NTFS/exFAT
/dev/sdb2         1026048   408627199   203800576    7  HPFS/NTFS/exFAT
/dev/sdb3       408627200   409597951      485376    7  HPFS/NTFS/exFAT
/dev/sdb4       409597952   468860927    29631488    f  W95 Ext'd (LBA)
/dev/sdb5       409600000   409599998  2147483647+  a5  FreeBSD

any suggestion?
Thank you very much
 
Hi, honestly, I don't remember..

This is gparted (under Linux) output:


Code:
/dev/sdb contains GPT signatures, indicating that it has a GPT table.  However, it does not have a valid fake msdos partition table, as it should.  Perhaps it was corrupted -- possibly by a program that doesn't understand GPT partition tables.  Or perhaps you deleted the GPT table, and are now using an msdos partition table.  Is this a GPT partition table?
Partition(s) 2 on /dev/sdb have been written, but we have been unable to inform the kernel of the change, probably because it/they are in use.  As a result, the old partition(s) will remain in use.  You should reboot now before making further changes

Anyway, if I choose "NO" (I mean: this is MBR), I see all space as "unallocated".
If I choose "YES" (this is GPT), partition layout seems fine.. so I think it is GPT.
 
How did you create that partition / filesystem? From what I can tell your problem is two fold. First the slice sits in an extended partition (ebr) which isn't the best approach. Second: is this MBR or GPT? The software can't even tell so that's obviously not good either.

My guess is that you somehow created (or changed) this slice with tools outside FreeBSD thus effectively rendered it invalid.

(edit)

From gpart(8):
Code:
     ebr                        A partition subdivided into filesystems with a
                                EBR.  The scheme-specific type is "!5" for
                                MBR.
EBR being Extended Boot Record. However, as hinted at in the quote, you can only use other EBR-like partition types. And freebsd-ufs isn't one of those (nor is freebsd). That's your problem. See also this link (wikipedia page on EBR).

Always remember that just because some partitioning software can change a partition type doesn't automatically imply that it's also valid.
 
Hi, I used again testdisk, now specifing GPT scheme, and it seems a little better.
This is gpart show ada1 output:

Code:
=>         40    468862048   ada1   GPT    (224G)
           40      1026008          - free -  (501M)
      1206048    407601152      1   ms-basic-data  (194G)
    408627200       970752      2   ms-basic-data   (474M)
    409597952         2048          - free -   (1.0M)
    409600000     56623104      3   !6a85cf4d-1dd2-11b2-99a6-080020736631   (27G)
    466223104      2638984          - free -   (1.3G)


If I use FreeBSD live cd, now I am able to mount partition, but when I dismount, I get this:


Code:
root@:~ # umount /tmp/bsd
GEOM: ada1p3: invalid disklabel
GEOM: gptid/b13275b8-3723-4948-9c4b-73e99507de54: invalid disklabel
GEOM: ufsid/5932c48c481ba25c: invalid disklabel
GEOM: diskid/DISK-161768402642p3: invalid disklabel

I tried to restore gptboot with:

Code:
root@:~/tmp/bsd/boot # gpart bootcode -p ./gptboot -i 3 ada1
gpart: /dev/ada1p3: Operation not permitted
root@:~/tmp/bsd/boot # gpart bootcode -b ./pmbr ada1
bootcode written to ada1

But when I reboot, I get: "Missing boot loader"

Thank you very much for your patience!
 
I'd like to help you, but the information given is rather chaotic and hard to understand....

One thing first:
This...
gpart bootcode -p ./gptboot -i 3 ada1
and this....
gpart bootcode -b ./pmbr ada1
does not fit together.
Only UEFI boot partitions can be anywhere on the disk. The PMBR though, will allways expect the bootcode to be in the first partition, which it is not.

If your computer can boot in UEFI mode, then you could shrink /dev/ada1p3 and write EFI bootcode to it.
Then create a bigger 4th partition /dev/ada1p4 on the remaining 28G to hold FreeBSD.
That would require your motherboard/computer to strictly adhere to the UEFI standard and ignore the PMBR on your disk when booting in UEFI mode.
That, sadly isn't the case since most motherboards/computers fall back to booting in legacy mode when a MBR is detected on the disk,
even when set to UEFI mode and with valid EFI bootcode on the disk. It's a shame, but worth a try.

Some questions:
- /dev/ada1p1 (partion 1) and /dev/ada1p2 (partition 2) hold a working install of Windows 10 which you want to keep?
How does Windows boot since you have written the PMBR to the disk?
- What is on the disk ada0? How is that one involved?
 
Some questions:
- /dev/ada1p1 (partion 1) and /dev/ada1p2 (partition 2) hold a working install of Windows 10 which you want to keep?

Hi, I'd prefer to keep them, but it is not strictly necessary.
Basically I am going to take opportunity to better understand some concepts related to gpart, boot0cfg, uefi and so on.

How does Windows boot since you have written the PMBR to the disk?

Indeed, Windows it is not working, too
- What is on the disk ada0? How is that one involved?

It is another disk with a Linux installation (Debian). I ran testdisk from there.
Anyway, it is not a UEFI computer.
Thank you very much, and sorry for the confusion..
 
Back
Top