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

Hi Ian,

On 9/2/22 22:48, Ian Smith wrote:
> 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


I think the answer to this would have been to use disklabel.


Rather then going through the whole laborious process of trying to 
recreate the MBR layout and reinstall the bootloader, I decided as I 
have access to the full disk backup to perform a clean install.

Now the system is on 13.1 as per suggested previously here and using GPT 
and ZFS with 2GB swap.


The most important thing from the previous install was a jail which I 
can simply rsync across and run without too much effort.


Thank you so much for all the detailed help and explanations. The 
mdconfig suggestion was a real life saver :)


Best regards and many thanks again!!!


Kaya