From nobody Thu Sep 1 16:23:37 2022 X-Original-To: freebsd-questions@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MJRFT6jm6z4ZrBc for ; Thu, 1 Sep 2022 16:24:13 +0000 (UTC) (envelope-from kayasaman@optiplex-networks.com) Received: from mail.optiplex-networks.com (mail.optiplex-networks.com [212.159.80.20]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4MJRFT4W8rz3LTs for ; Thu, 1 Sep 2022 16:24:12 +0000 (UTC) (envelope-from kayasaman@optiplex-networks.com) Received: from localhost (localhost [127.0.0.1]) by mail.optiplex-networks.com (Postfix) with ESMTP id 1C5AE15C2E83; Thu, 1 Sep 2022 17:24:03 +0100 (BST) Received: from mail.optiplex-networks.com ([127.0.0.1]) by localhost (mail.optiplex-networks.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id KKpSOQhnVodi; Thu, 1 Sep 2022 17:23:45 +0100 (BST) Received: from localhost (localhost [127.0.0.1]) by mail.optiplex-networks.com (Postfix) with ESMTP id C4F4715C2E6E; Thu, 1 Sep 2022 17:23:45 +0100 (BST) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.optiplex-networks.com C4F4715C2E6E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=optiplex-networks.com; s=AE93A2AC-7F67-11EA-90AE-8A1FE64F6997; t=1662049425; bh=jAcQMLrAR7sRzMnB8/SpRHztppKIu80+3sTH66ER+gY=; h=Message-ID:Date:MIME-Version:To:From; b=fUprInHeLxKUJb+YtYrxieYQAcpqR4ojsNGCZVjN4+j+DWBQ24HSVl8FT5DteO2Mg 4OZvRuuTBMnL00kXKjhJSjtpy0RUdV4lQL9NdZ9qVcYJgl5tsZz4a8sRE10aN+Xvqo nkB/ZvRCChRxoyR4fQE7XXUz6UDC954iescsZaDSlfmaHgUKAh1krNjGV0JoivZBn9 6FHM1tnNTXJCllaSYjcMPc8HNoHdMhs2zZ1abnpm97ks52gTtDIMAGaZ9pK60Flelg awYZiJ9889+orkIyeP/X9WJPj1EtTvDBdyoIN5SZLM3m//ZxNMnV8eut/OSM9OyX8p bHLxPQMR7waiQ== X-Virus-Scanned: amavisd-new at mail.optiplex-networks.com Received: from mail.optiplex-networks.com ([127.0.0.1]) by localhost (mail.optiplex-networks.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id VEhdC8sZzbPm; Thu, 1 Sep 2022 17:23:45 +0100 (BST) Received: from [192.168.0.227] (unknown [192.168.0.227]) by mail.optiplex-networks.com (Postfix) with ESMTPSA id 9195F15C2E33; Thu, 1 Sep 2022 17:23:40 +0100 (BST) Message-ID: Date: Thu, 1 Sep 2022 17:23:37 +0100 List-Id: User questions List-Archive: https://lists.freebsd.org/archives/freebsd-questions List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-questions@freebsd.org X-BeenThere: freebsd-questions@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.12.0 Subject: Re: Corrupted partitions after upgrade from 12.3 to 13.0-RELEASE Content-Language: en-US To: Ian Smith , freebsd-questions References: From: Kaya Saman In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Rspamd-Queue-Id: 4MJRFT4W8rz3LTs X-Rspamd-Pre-Result: action=no action; module=multimap; Matched map: local_wl_ip X-Spamd-Result: default: False [0.00 / 15.00]; ASN(0.00)[asn:6871, ipnet:212.159.64.0/18, country:GB]; local_wl_ip(0.00)[212.159.80.20] X-ThisMailContainsUnwantedMimeParts: N 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 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: The data for partition 3 is: The data for partition 4 is: > > > 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. > > > 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) > > > 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