Date: Thu, 1 Sep 2022 17:23:37 +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: <a81deccc-af45-2b43-e410-a1c0ed19392c@optiplex-networks.com> In-Reply-To: <B47D8DF2-1121-4809-801B-F0764B5B0297@nimnet.asn.au> References: <f0a7b860-391c-a4c9-b0f1-538c7db20a02@optiplex-networks.com> <B47D8DF2-1121-4809-801B-F0764B5B0297@nimnet.asn.au>
next in thread | previous in thread | raw e-mail | index | archive | help
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-ne= tworks.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=20 access till I managed to create NFS mounts. It needed a network rejig as=20 the box uses a 2-way lagg and lacp. > > > Following the docs here: > > https://www.freebsd.org/cgi/man.cgi?query=3Dgptboot&sektion=3D8&for= mat=3Dhtml > > > > I ran: gpart bootcode -b /boot/pmbr=C2=A0=C2=A0=C2=A0 -p /boot/gptb= oot -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 whi= ch > > is > > fine. > > Specifically make and keep a copy of the first 128 512-byte sectors: > > # 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 this? > > You probably need to mount another USB stick r/w for 'somefile' for tra= nsport, 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 =3D>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 63=C2=A0 78165297=C2=A0=C2=A0=C2=A0 ad= a0=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 ada0s= 1=C2=A0 freebsd=C2=A0 [active]=C2=A0 (37G) > and > # gpart show -p ada0s1 gpart. no such Geom > > > However, I think the partition table has become corrupted or altere= d > > 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 sch= eme, but with the MBR scheme. > > If so, running gptboot(8) will have destroyed the master boot record (M= BR) and replaced it with its 'protective' MBR instead, and perhaps clobbe= red the boot record from the first UFS partition. I think you're above statement is true for this issue. It's an old 40GB=20 Intel SSD that I've been using since FreeBSD 8. 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. Seems I even forgot about the partitioning scheme not=20 being GPT based but the previous MBR. > > It's very old-school, but run and record accurately, to see what the pm= br slice table contains: > > # fdisk ada0 ******* Working on device /dev/ada0 ******* parameters extracted from in-core disklabel are: cylinders=3D77545 heads=3D16 sectors/track=3D63 (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=3D77545 heads=3D16 sectors/track=3D63 (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) =C2=A0=C2=A0=C2=A0 start 63, size 78165297 (38166 Meg), flag 80 (active) =C2=A0=C2=A0 =C2=A0beg: cyl 0/ head 1/ sector 1; =C2=A0=C2=A0 =C2=A0end: 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 n= o > > 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=20 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 ex= amples" so is no help with this unless you started with GPT, in which cas= e 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=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. Using dd and hd (he= xdump) 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 sys= tem built with bsdinstall on a SSD that came already MBR-scheme with Win1= 0pro taking first 2 slices, then FreeBSD on a 48G s4 - after I had W10 sh= rink itself and add a FAT32 slice. > > <code> > Root@t430s:~ # gpart show -p ada0 > =3D> 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 > =3D> 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=20 to be easier to debug from previous experience. I probably just have=20 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 b= inary, such as .. .Read.Boot. error' and 'BTX' and later strings like /bo= ot/kernel/kernel and FreeBSD/x86 boot, ie it may not be too hard to find = the start of your ada0s1a partition. Try: > > # dd if=3D/dev/ada0 skip=3D2048 count=3D16 | hd | less 00000000=C2=A0 00 00 00 00 00 00 00 00=C2=A0 00 00 00 00 00 00 00 00=20 |................| * 00000020=C2=A0 e0 2d 0d 63 00 00 00 00=C2=A0 0b 35 0d 63 00 00 00 00=20 |.-.c.....5.c....| 00000030=C2=A0 0b 35 0d 63 00 00 00 00=C2=A0 e0 2d 0d 63 00 00 00 00=20 |.5.c.....-.c....| 00000040=C2=A0 30 fc 97 2c 78 da 12 27=C2=A0 30 fc 97 2c 90 d6 12 27=20 |0..,x..'0..,...'| 00000050=C2=A0 be 5c 10 1b 00 00 00 00=C2=A0 00 00 00 00 00 00 00 00=20 |.\..............| 00000060=C2=A0 00 00 00 00 00 00 00 00=C2=A0 00 00 00 00 00 00 00 00=20 |................| * 000000e0=C2=A0 00 00 00 00 00 00 00 00=C2=A0 ec 00 00 00 00 00 00 00=20 |................| 000000f0=C2=A0 00 00 00 00 00 00 00 00=C2=A0 00 00 00 00 00 00 00 00=20 |................| * 00000120=C2=A0 e0 2d 0d 63 00 00 00 00=C2=A0 0b 35 0d 63 00 00 00 00=20 |.-.c.....5.c....| 00000130=C2=A0 0b 35 0d 63 00 00 00 00=C2=A0 e0 2d 0d 63 00 00 00 00=20 |.5.c.....-.c....| 00000140=C2=A0 40 69 b6 2c c0 50 27 27=C2=A0 40 69 b6 2c d8 4c 27 27=20 |@i.,.P''@i.,.L''| 00000150=C2=A0 b4 0f db 2d 00 00 00 00=C2=A0 00 00 00 00 00 00 00 00=20 |...-............| 00000160=C2=A0 00 00 00 00 00 00 00 00=C2=A0 00 00 00 00 00 00 00 00=20 |................| * 000001e0=C2=A0 00 00 00 00 00 00 00 00=C2=A0 9e 00 00 00 00 00 00 00=20 |................| 000001f0=C2=A0 00 00 00 00 00 00 00 00=C2=A0 00 00 00 00 00 00 00 00=20 |................| * 00000220=C2=A0 e0 2d 0d 63 00 00 00 00=C2=A0 0b 35 0d 63 00 00 00 00=20 |.-.c.....5.c....| 00000230=C2=A0 0b 35 0d 63 00 00 00 00=C2=A0 e0 2d 0d 63 00 00 00 00=20 |.5.c.....-.c....| 00000240=C2=A0 88 1c 29 2d 18 a1 33 27=C2=A0 88 1c 29 2d 30 9d 33 27=20 |..)-..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 you= r image. > > How big is the disk and image? I'll have a look at mdconfig. I have found another thread where the OP=20 of said thread needed to use this. It's a little surprising for me=20 because I thought that I could just simply 'mount' the .img file. Maybe=20 I have Linux procedures stuck in my head or just have never encountered=20 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, unle= ss 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 =3D>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 63=C2=A0 78165297=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=C2=A0= =C2=A0=C2=A0 1=C2=A0 freebsd=C2=A0 [active]=C2=A0 (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 =C2=A0=C2=A0 Mediasize: 40020632064 (37G) =C2=A0=C2=A0 Sectorsize: 512 =C2=A0=C2=A0 Stripesize: 4096 =C2=A0=C2=A0 Stripeoffset: 3584 =C2=A0=C2=A0 Mode: r0w0e0 =C2=A0=C2=A0 efimedia: HD(1,MBR,0x90909090,0x3f,0x4a8b531) =C2=A0=C2=A0 attrib: active =C2=A0=C2=A0 rawtype: 165 =C2=A0=C2=A0 length: 40020632064 =C2=A0=C2=A0 offset: 32256 =C2=A0=C2=A0 type: freebsd =C2=A0=C2=A0 index: 1 =C2=A0=C2=A0 end: 78165359 =C2=A0=C2=A0 start: 63 Consumers: 1. Name: ada0 =C2=A0=C2=A0 Mediasize: 40020664320 (37G) =C2=A0=C2=A0 Sectorsize: 512 =C2=A0=C2=A0 Stripesize: 4096 =C2=A0=C2=A0 Stripeoffset: 0 =C2=A0=C2=A0 Mode: r0w0e0 > > # gpart show -p ada0 > > > Would anyone be able to suggest anything to either get the system t= o > > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?a81deccc-af45-2b43-e410-a1c0ed19392c>