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

Thanks Ian,


please see inline:

On 9/1/22 13:38, Ian Smith wrote:
> 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.

Yep, apologies. Was running off my memory as I didn't have network 
access till I managed to create NFS mounts. It needed a network rejig as 
the box uses a 2-way lagg and lacp.


>
>   > 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

As I have the whole disk backed up per below, should I still do this?


>
> You probably need to mount another USB stick r/w for 'somefile' for transport, recording sessions ...
Yep, got NFS up so recording output is easy now.
>
>   > 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
=>      63  78165297    ada0  MBR  (37G)
         63  78165297  ada0s1  freebsd  [active]  (37G)


> and
> # gpart show -p ada0s1


gpart. no such Geom



>
>   > 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.

I think you're above statement is true for this issue. It's an old 40GB 
Intel SSD that I've been using since FreeBSD 8. Of course it's difficult 
to remember what I did on the previous update which is why I wanted to 
rely on the docs. Seems I even forgot about the partitioning scheme not 
being GPT based but the previous MBR.


>
> It's very old-school, but run and record accurately, to see what the pmbr slice table contains:
>
> # fdisk ada0
******* Working on device /dev/ada0 *******
parameters extracted from in-core disklabel are:
cylinders=77545 heads=16 sectors/track=63 (1008 blks/cyl)

Figures below won't work with BIOS for partitions not in cyl 1
parameters to be used for BIOS calculations are:
cylinders=77545 heads=16 sectors/track=63 (1008 blks/cyl)

Media sector size is 512
Warning: BIOS sector numbering starts with sector 1
Information from DOS bootblock is:
The data for partition 1 is:
sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD)
     start 63, size 78165297 (38166 Meg), flag 80 (active)
     beg: cyl 0/ head 1/ sector 1;
     end: cyl 1023/ head 15/ sector 63
The data for partition 2 is:
<UNUSED>
The data for partition 3 is:
<UNUSED>
The data for partition 4 is:
<UNUSED>

>
>   > 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
Probably, like said above it's been ages and have been using ZFS for the 
last many years, so this is my sole UFS based machine.
>
> 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.
I think you're correct on the Linux part. Partitioning with Linux seems 
to be easier to debug from previous experience. I probably just have 
never met a stubborn issue before though...
>
> 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
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 
|................|
*
00000020  e0 2d 0d 63 00 00 00 00  0b 35 0d 63 00 00 00 00 
|.-.c.....5.c....|
00000030  0b 35 0d 63 00 00 00 00  e0 2d 0d 63 00 00 00 00 
|.5.c.....-.c....|
00000040  30 fc 97 2c 78 da 12 27  30 fc 97 2c 90 d6 12 27 
|0..,x..'0..,...'|
00000050  be 5c 10 1b 00 00 00 00  00 00 00 00 00 00 00 00 
|.\..............|
00000060  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 
|................|
*
000000e0  00 00 00 00 00 00 00 00  ec 00 00 00 00 00 00 00 
|................|
000000f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 
|................|
*
00000120  e0 2d 0d 63 00 00 00 00  0b 35 0d 63 00 00 00 00 
|.-.c.....5.c....|
00000130  0b 35 0d 63 00 00 00 00  e0 2d 0d 63 00 00 00 00 
|.5.c.....-.c....|
00000140  40 69 b6 2c c0 50 27 27  40 69 b6 2c d8 4c 27 27 
|@i.,.P''@i.,.L''|
00000150  b4 0f db 2d 00 00 00 00  00 00 00 00 00 00 00 00 
|...-............|
00000160  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 
|................|
*
000001e0  00 00 00 00 00 00 00 00  9e 00 00 00 00 00 00 00 
|................|
000001f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 
|................|
*
00000220  e0 2d 0d 63 00 00 00 00  0b 35 0d 63 00 00 00 00 
|.-.c.....5.c....|
00000230  0b 35 0d 63 00 00 00 00  e0 2d 0d 63 00 00 00 00 
|.5.c.....-.c....|
00000240  88 1c 29 2d 18 a1 33 27  88 1c 29 2d 30 9d 33 27 
|..)-..3'..)-0.3'|
:

>
>   > 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?

I'll have a look at mdconfig. I have found another thread where the OP 
of said thread needed to use this. It's a little surprising for me 
because I thought that I could just simply 'mount' the .img file. Maybe 
I have Linux procedures stuck in my head or just have never encountered 
to do this before.


>
>   > 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 ada0

=>      63  78165297  ada0  MBR  (37G)
         63  78165297     1  freebsd  [active]  (37G)


gpart list ada0

Geom name: ada0
modified: false
state: OK
fwheads: 16
fwsectors: 63
last: 78165359
first: 63
entries: 4
scheme: MBR
Providers:
1. Name: ada0s1
    Mediasize: 40020632064 (37G)
    Sectorsize: 512
    Stripesize: 4096
    Stripeoffset: 3584
    Mode: r0w0e0
    efimedia: HD(1,MBR,0x90909090,0x3f,0x4a8b531)
    attrib: active
    rawtype: 165
    length: 40020632064
    offset: 32256
    type: freebsd
    index: 1
    end: 78165359
    start: 63
Consumers:
1. Name: ada0
    Mediasize: 40020664320 (37G)
    Sectorsize: 512
    Stripesize: 4096
    Stripeoffset: 0
    Mode: r0w0e0

>
> # 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

Again, many thanks Ian!


Regards,


Kaya