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

On 2 September 2022 2:23:37 am AEST, Kaya Saman <kayasaman@optiplex-networks.com> wrote:
 > On 9/1/22 13:38, Ian Smith wrote:
 > > On 1 September 2022 11:54:14 am AEST, Kaya Saman

Hi Kaya,

trimming quotes, this Android client gets messy fast at 2 levels.

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

You're way ahead of me there; apologies for my terse tone.

 > >   > I ran: gpart bootcode -b /boot/pmbr    -p /boot/gptboot -i 1
 > ada0
 
 > >   > Now I get a message saying "Invalid Partitions".

Did you get any error message when you issued that gpart command?

According to gpart(8), 'gpart bootcode' will use bootcode that is appropriate for the scheme in use, ie it should not have installed gptboot on an MBR-scheme disk.

If you look at the files "/boot/*boot*" with hd(1) or with strings(1) you'll get good clues for spotting what's at the first part of your ada0s1 slice.  strings -n5 -td gives you offsets, to aid calculating dd offsets, I find.

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

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

No :)  And in light of your later post:

 > I managed to mount the disk image. The particular image that worked
 > was 
 > the one I made using:
 > 
 > dd if=/dev/ada0s1 ...
 > 
 > mdconfig -a -t vnode -f freebsd_bak.img
 > md0
 > 
 > mount /dev/md0a /tmp/1

'md0a' is interesting. The ancient FreeBSD installation images (*memstick.img), when dd'd to USB drives, appeared as '/dev/da0a' which was a raw UFS disk without going via any slice 1, and without using a bsdlabel, as I recall.

This seems to be maybe what gpart bootcode has left you with; perhaps your 'a' root partition is intact there, just wrongly represented?

Whether it clobbered the original boot is what needs finding out.

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

If it all looks good, maybe all you need is to get swap back, either my using bsdlabel (below) or adding a swapfile?

And perhaps (re)installing the right boot code, likely just  'boot' which is 'boot1' plus 'boot2' (8kB).  I use boot0 instead of boot1, but that's for choosing which OS to boot.

 > > # gpart show -p ada0
 > =>      63  78165297    ada0  MBR  (37G)
 >          63  78165297  ada0s1  freebsd  [active]  (37G)

Looks like what gpart bootcode with -i 1 would do, perhaps, though maybe it should have quit when you asked for gptboot on an MBR disk?

 > > and
 > > # gpart show -p ada0s1
 > 
 > 
 > gpart. no such Geom

Yeah, looks like the bsdlabel has been clobbered (with your a (/) and b (swap) partitions. See bsdlabel(8) which looks like you could restore your b swap partition easily enough, and you can work on (another copy of) your image till it works right.

Hopefully some other/s who still remember using the MBR / bsdlabel scheme will chip in, I'm struggling.

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

I always have to start with 'gpart show -p <drive>' to remember ...

 > 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

Ok, that reaffirms gpart show (-r)

 > >   > b. slice was for swap.
 > >
 > > The swap space is dispensable, if you can recover the 'a'
 > partition.

If you can't recover it with bsdlabel, you could always add a swapfile ...


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

Turned out the slice1 image is more useful for mdconfig.

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

I have to sleep .. manyana, Ian