Date: Sat, 3 Sep 2022 00:38:11 +0100 From: Kaya Saman <kayasaman@optiplex-networks.com> To: Ian Smith <smithi@nimnet.asn.au>, freebsd-questions <freebsd-questions@freebsd.org> Subject: Re: Corrupted partitions after upgrade from 12.3 to 13.0-RELEASE Message-ID: <d35d6f2f-be0e-62a9-b672-966c9266a7ba@optiplex-networks.com> In-Reply-To: <2C37F841-E57B-4192-8280-5E523412D01D@nimnet.asn.au> References: <f0a7b860-391c-a4c9-b0f1-538c7db20a02@optiplex-networks.com> <B47D8DF2-1121-4809-801B-F0764B5B0297@nimnet.asn.au> <a81deccc-af45-2b43-e410-a1c0ed19392c@optiplex-networks.com> <2C37F841-E57B-4192-8280-5E523412D01D@nimnet.asn.au>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Ian, On 9/2/22 22:48, Ian Smith wrote: > On 2 September 2022 2:23:37 am AEST, Kaya Saman <kayasaman@optiplex-net= works.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 rej= ig > > 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=C2=A0=C2=A0=C2=A0 -p /boo= t/gptboot -i 1 > > ada0 > =20 > > > > 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 appro= priate 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) y= ou'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/ad= a0 > > > > which is fine. > > > > # dd if=3D/dev/ada0 of=3Dsomefile bs=3D512 count=3D128 > > > > As I have the whole disk backed up per below, should I still do thi= s? > > 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=3D/dev/ada0s1 ... > > > > mdconfig -a -t vnode -f freebsd_bak.img > > md0 > > > > mount /dev/md0a /tmp/1 > > 'md0a' is interesting. The ancient FreeBSD installation images (*memsti= ck.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 y= our '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' f= or > > 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' whi= ch is 'boot1' plus 'boot2' (8kB). I use boot0 instead of boot1, but that= 's for choosing which OS to boot. > > > > # gpart show -p ada0 > > =3D>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 63=C2=A0 78165297=C2=A0=C2=A0=C2= =A0 ada0=C2=A0 MBR=C2=A0 (37G) > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 63=C2=A0 78165297=C2=A0= ada0s1=C2=A0 freebsd=C2=A0 [active]=C2=A0 (37G) > > Looks like what gpart bootcode with -i 1 would do, perhaps, though mayb= e 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 yo= ur 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 sche= me 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 ada0s= 1a > > and ada0s1b - then your disk was NOT previously partitioned with th= e > > 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) > > =C2=A0=C2=A0=C2=A0 start 63, size 78165297 (38166 Meg), flag 80 (a= ctive) > > =C2=A0=C2=A0 =C2=A0beg: cyl 0/ head 1/ sector 1; > > =C2=A0=C2=A0 =C2=A0end: 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 LiveC= D > > and > > > > ran a > > > > dd backup of the boot drive. > > > > > > > > First attempt was: dd if=3D/dev/ada0s1 > > > > of=3D/path_to_share/freebsd_bak.img > > > > > > > > Secondly I tried: dd if=3D/dev/ada0 > > of=3D/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 itsel= f > > 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 hav= e > > 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=20 recreate the MBR layout and reinstall the bootloader, I decided as I=20 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=20 and ZFS with 2GB swap. The most important thing from the previous install was a jail which I=20 can simply rsync across and run without too much effort. Thank you so much for all the detailed help and explanations. The=20 mdconfig suggestion was a real life saver :) Best regards and many thanks again!!! Kaya
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?d35d6f2f-be0e-62a9-b672-966c9266a7ba>