Date: Sat, 03 Sep 2022 07:48:27 +1000 From: Ian Smith <smithi@nimnet.asn.au> To: Kaya Saman <kayasaman@optiplex-networks.com>,freebsd-questions <freebsd-questions@freebsd.org> Subject: Re: Corrupted partitions after upgrade from 12.3 to 13.0-RELEASE Message-ID: <2C37F841-E57B-4192-8280-5E523412D01D@nimnet.asn.au> In-Reply-To: <a81deccc-af45-2b43-e410-a1c0ed19392c@optiplex-networks.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2 September 2022 2:23:37 am AEST, Kaya Saman <kayasaman@optiplex-network= s=2Ecom> 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=2E > > > the Bootloader came up with an error about not being able to > access > > > the > > > file system on the disk=2E Having read around a little, > information > > > pointed to updating the bootcode on the disk=2E > > > > When reporting errors, show precisely what was shown=2E >=20 > Yep, apologies=2E Was running off my memory as I didn't have network=20 > access till I managed to create NFS mounts=2E It needed a network rejig > as=20 > the box uses a 2-way lagg and lacp=2E You're way ahead of me there; apologies for my terse tone=2E > > > I ran: gpart bootcode -b /boot/pmbr=C2=A0=C2=A0=C2=A0 -p /boot/gp= tboot -i 1 > ada0 =20 > > > Now I get a message saying "Invalid Partitions"=2E Did you get any error message when you issued that gpart command? According to gpart(8), 'gpart bootcode' will use bootcode that is appropri= ate for the scheme in use, ie it should not have installed gptboot on an MB= R-scheme disk=2E 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 slic= e=2E strings -n5 -td gives you offsets, to aid calculating dd offsets, I f= ind=2E > > > Currently I have a 13=2E0-RELEASE usb stick in the system which > I'm > > > booting from and am able to read the information from /dev/ada0 > > > which is fine=2E > > # dd if=3D/dev/ada0 of=3Dsomefile bs=3D512 count=3D128 >=20 > 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=2E The particular image that worked > was=20 > the one I made using: >=20 > dd if=3D/dev/ada0s1 =2E=2E=2E >=20 > mdconfig -a -t vnode -f freebsd_bak=2Eimg > md0 >=20 > mount /dev/md0a /tmp/1 'md0a' is interesting=2E The ancient FreeBSD installation images (*memstic= k=2Eimg), 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=2E 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=2E > > You probably need to mount another USB stick r/w for 'somefile' for > transport, recording sessions =2E=2E=2E > Yep, got NFS up so recording output is easy now=2E > > > > > If I run: mount /dev/ada0s1 /mnt > > > > > > The a=2E slice mounts and the data is there! If it all looks good, maybe all you need is to get swap back, either my us= ing bsdlabel (below) or adding a swapfile? And perhaps (re)installing the right boot code, likely just 'boot' which = is 'boot1' plus 'boot2' (8kB)=2E I use boot0 instead of boot1, but that's = for choosing which OS to boot=2E > > # 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 ada= 0s1=C2=A0 freebsd=C2=A0 [active]=C2=A0 (37G) Looks like what gpart bootcode with -i 1 would do, perhaps, though maybe i= t should have quit when you asked for gptboot on an MBR disk? > > and > > # gpart show -p ada0s1 >=20 >=20 > gpart=2E no such Geom Yeah, looks like the bsdlabel has been clobbered (with your a (/) and b (s= wap) partitions=2E 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=2E Hopefully some other/s who still remember using the MBR / bsdlabel scheme = will chip in, I'm struggling=2E > > > 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=2E > > > > 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=2E >=20 > I think you're above statement is true for this issue=2E It's an old > 40GB=20 > Intel SSD that I've been using since FreeBSD 8=2E Of course it's > difficult=20 > to remember what I did on the previous update which is why I wanted > to=20 > rely on the docs=2E Seems I even forgot about the partitioning scheme > not=20 > being GPT based but the previous MBR=2E I always have to start with 'gpart show -p <drive>' to remember =2E=2E=2E > 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 (activ= e) > =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=2E slice was for swap=2E > > > > The swap space is dispensable, if you can recover the 'a' > partition=2E If you can't recover it with bsdlabel, you could always add a swapfile =2E= =2E=2E > > > In an attempt at recovery I mounted an NFS share on the LiveCD > and > > > ran a > > > dd backup of the boot drive=2E > > > > > > First attempt was: dd if=3D/dev/ada0s1 > > > of=3D/path_to_share/freebsd_bak=2Eimg > > > > > > Secondly I tried: dd if=3D/dev/ada0 > of=3D/path_to_share/freebsd_bak_1=2Eimg > > > > Good=2E The second whole-disk one is what you want=2E=20 Turned out the slice1 image is more useful for mdconfig=2E > > With MBR scheme it's common to see the disk shown as starting at > sector 63, so sectors 0=2E=2E62 are reserved, and include the MBR itsel= f > plus first stage boot sectors=2E Linux puts GRUB there as I recall=2E > I think you're correct on the Linux part=2E Partitioning with Linux > seems=20 > to be easier to debug from previous experience=2E I probably just have= =20 > never met a stubborn issue before though=2E=2E=2E I have to sleep =2E=2E manyana, Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2C37F841-E57B-4192-8280-5E523412D01D>