Re: Corrupted partitions after upgrade from 12.3 to 13.0-RELEASE

Reply: Kaya Saman : "Re: Corrupted partitions after upgrade from 12.3 to 13.0-RELEASE"
In reply to: Kaya Saman : "Corrupted partitions after upgrade from 12.3 to 13.0-RELEASE"
Go to: [ bottom of page ] [ top of archives ] [ this month ]
From: Ian Smith <smithi_at_nimnet.asn.au>
Date: Thu, 01 Sep 2022 12:38:44 UTC
On 1 September 2022 11:54:14 am AEST, Kaya Saman <kayasaman@optiplex-networks.com> wrote:
 > Hi,
 > 
 > I was trying to update one of my servers earlier from 12.3-RELEASE to
 > 
 > 13.0 RELEASE and after issuing:
 > 
 > freebsd-update install
 > 
 > shutdown -r now
 > 
 > after following Chapter 24 from the Handbook: 
 > https://docs.freebsd.org/en/books/handbook/
 > 
 > the Bootloader came up with an error about not being able to access
 > the 
 > file system on the disk. Having read around a little, information 
 > pointed to updating the bootcode on the disk.

When reporting errors, show precisely what was shown.

 > Following the docs here: 
 > https://www.freebsd.org/cgi/man.cgi?query=gptboot&sektion=8&format=html
 > 
 > I ran: gpart bootcode -b /boot/pmbr    -p /boot/gptboot -i 1 ada0
 > 
 > 
 > Now I get a message saying "Invalid Partitions".
 > 
 > 
 > Currently I have a 13.0-RELEASE usb stick in the system which I'm 
 > booting from and am able to read the information from /dev/ada0 which
 > is 
 > fine.

Specifically make and keep a copy of the first 128 512-byte sectors:

# dd if=/dev/ada0 of=somefile bs=512 count=128

You probably need to mount another USB stick r/w for 'somefile' for transport, recording sessions ...

 > If I run: mount /dev/ada0s1 /mnt
 > 
 > The a. slice mounts and the data is there!

Please show at this stage:

# gpart show -p ada0
and
# gpart show -p ada0s1

 > However, I think the partition table has become corrupted or altered 
 > somehow after attempting to update the bootcode as the layout used to
 > be:
 > 
 > /dev/ada0s1a
 > 
 > /dev/ada0s1b

If the above is accurate - that your partitions were called ada0s1a and ada0s1b - then your disk was NOT previously partitioned with the GPT scheme, but with the MBR scheme.

If so, running gptboot(8) will have destroyed the master boot record (MBR) and replaced it with its 'protective' MBR instead, and perhaps clobbered the boot record from the first UFS partition.

It's very old-school, but run and record accurately, to see what the pmbr slice table contains:

# fdisk ada0

 > b. slice was for swap.

The swap space is dispensable, if you can recover the 'a' partition.


 > The FS is UFS of course.... now I only get a single partition and no 
 > slices at: /dev/ada0s1

You have the terminology backwards: 'slices' are the up to 4 partitions under the MBR scheme, and BSD 'partitions' subdivide a slice with a (/), b (swap), d,e,f ... optionally others like /var, /usr, /home

The handbook in effect just says "we're going with GPT for all these examples" so is no help with this unless you started with GPT, in which case there would be such as ada0p1 etc, not ada0s1a etc.

See gpart(8) section PARTITIONING SCHEMES for much more detail.

 > In an attempt at recovery I mounted an NFS share on the LiveCD and
 > ran a 
 > dd backup of the boot drive.
 > 
 > First attempt was: dd if=/dev/ada0s1
 > of=/path_to_share/freebsd_bak.img
 > 
 > Secondly I tried: dd if=/dev/ada0 of=/path_to_share/freebsd_bak_1.img

Good.  The second whole-disk one is what you want.  Using dd and hd (hexdump) you might find the X? GiB swap partition near the very end.

In case I'm on the the right track with this, here's a 12.3-RELEASE system built with bsdinstall on a SSD that came already MBR-scheme with Win10pro taking first 2 slices, then FreeBSD on a 48G s4 - after I had W10 shrink itself and add a FAT32 slice.

<code>
Root@t430s:~ # gpart show -p ada0
=>       63  250069617    ada0  MBR  (119G)
         63       1985          - free -  (993K)
       2048    1185792  ada0s1  ntfs  (579M)
    1187840   80353280  ada0s2  ntfs  (38G)
   81541120   67108864  ada0s3  fat32lba  (32G)
  148649984  100663296  ada0s4  freebsd  [active]  (48G)
  249313280     756400          - free -  (369M)

Root@t430s:~ # gpart show -p ada0s4
=>        0  100663296   ada0s4  BSD  (48G)
          0    8388608  ada0s4a  freebsd-ufs  (4.0G)
    8388608    8388608  ada0s4b  freebsd-swap  (4.0G)
   16777216    8388608  ada0s4d  freebsd-ufs  (4.0G)
   25165824   16777216  ada0s4e  freebsd-ufs  (8.0G)
   41943040   58720256  ada0s4f  freebsd-ufs  (28G)
</code>

With MBR scheme it's common to see the disk shown as starting at sector 63, so sectors 0..62 are reserved, and include the MBR itself plus first stage boot sectors.  Linux puts GRUB there as I recall.

Here, s1 (win10 NTFS) starts at 2048 (1MiB) and hd shows |.R.NTFS    .....| as the start of the NTFS loader.

In my case I look at 8k (16 sectors) from 148649984 and see among the binary, such as .. .Read.Boot. error' and 'BTX' and later strings like /boot/kernel/kernel and FreeBSD/x86 boot, ie it may not be too hard to find the start of your ada0s1a partition. Try:

# dd if=/dev/ada0 skip=2048 count=16 | hd | less

 > In either case when attempting to mount the image I get a message 
 > saying: "Block device required"

vnode-backed mdconfig(8) perhaps? Make sure to use '-o readonly' on your image.

How big is the disk and image?

 > Is it possible to recover the slices or at least read the data from
 > the 
 > backup image?

Should be, once you figure out exactly where the partition starts, unless the gptboot clobbered it.

 > I don't mind reinstalling as long as I can access the backup.

Need more data first.

 > gpart show/list ada0 doesn't give any indication about the a. or b. 
 > slices, so either they are completely gone or I'm not using the
 > correct 
 > tools.

Don't tell, show.

# gpart show -p ada0

 > Would anyone be able to suggest anything to either get the system to 
 > boot again or at least read the information from the backup image?

If it was GPT originally, ignore me.  Otherwise, let's see what's there.

Cheers, Ian