NetBSD Problem Report #56643
From paul@whooppee.com Tue Jan 18 19:07:26 2022
Return-Path: <paul@whooppee.com>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))
(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
by mollari.NetBSD.org (Postfix) with ESMTPS id 2BF0B1A9239
for <gnats-bugs@gnats.NetBSD.org>; Tue, 18 Jan 2022 19:07:26 +0000 (UTC)
Message-Id: <20220118190722.AAD0C30F2C4@speedy.whooppee.com>
Date: Tue, 18 Jan 2022 11:07:22 -0800 (PST)
From: paul@whooppee.com
Reply-To: paul@whooppee.com
To: gnats-bugs@NetBSD.org
Subject: problem with restore(8)
X-Send-Pr-Version: 3.95
>Number: 56643
>Category: bin
>Synopsis: restore generates ``getfile: lost data'' messages
>Confidential: no
>Severity: serious
>Priority: high
>Responsible: bin-bug-people
>State: closed
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Tue Jan 18 19:10:00 +0000 2022
>Closed-Date: Wed Jan 26 22:14:21 +0000 2022
>Last-Modified: Wed Jan 26 22:14:21 +0000 2022
>Originator: Paul Goyette
>Release: NetBSD 9.99.93
>Organization:
+--------------------+--------------------------+----------------------+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired) | FA29 0E3B 35AF E8AE 6651 | paul@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoyette@netbsd.org |
| & Network Engineer | | pgoyette99@gmail.com |
+--------------------+--------------------------+----------------------+
>Environment:
System: NetBSD speedy.whooppee.com 9.99.93 NetBSD 9.99.93 (SPEEDY 2022-01-08 03:00:28 UTC) #0: Sat Jan 8 13:04:35 UTC 2022 paul@speedy.whooppee.com:/build/netbsd-local/obj/amd64/sys/arch/amd64/compile/SPEEDY amd64
Architecture: x86_64
Machine: amd64
>Description:
Using restore(8) to restore from a dump results in error
message ``getfile: lost data''. Seems to occurs (at least)
twice in every restore operation.
I've tried it with previously-created dumps, as well as
with new dump piped directly from dump(8) and both methods
fail the same way.
This may be a result of rev 1.71 to sbin/restore/tape.c
>How-To-Repeat:
Easy example:
(run newfs and cd into destination filesystem)
dump 0f- / | restore rf-
>Fix:
Please
>Release-Note:
>Audit-Trail:
From: Paul Goyette <paul@whooppee.com>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: bin/56643: problem with restore(8)
Date: Thu, 20 Jan 2022 10:31:32 -0800 (PST)
After some discussion on IRC, this problem might be a problem with
dump(8) and not with restore.
I was able to locate an old dump file, created prior to June 2021 (when
the latest changes - to accomodate ACLs - were made), and a current
restore(*) was able to process it without error. Only the other hand,
all observed failures occurred with the same restore(8) binary but with
dump files created by current dump(8) binary.
This appears to happen only when running on a system that does NOT have
``options UFS_EXTATTR''. Running on a normal GENERIC kernel does not
produce any error.
+--------------------+--------------------------+----------------------+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired) | FA29 0E3B 35AF E8AE 6651 | paul@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoyette@netbsd.org |
| & Network Engineer | | pgoyette99@gmail.com |
+--------------------+--------------------------+----------------------+
From: Christos Zoulas <christos@zoulas.com>
To: gnats-bugs@netbsd.org
Cc: gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org,
paul@whooppee.com
Subject: Re: bin/56643: problem with restore(8)
Date: Sat, 22 Jan 2022 12:31:13 -0500
--Apple-Mail=_577FF62E-E33D-4666-B625-E21D0D914FF0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=us-ascii
UFS_EXTATTR is only applicable to UFS1. Is the filesystem you are =
dumping UFS1?
christos
--Apple-Mail=_577FF62E-E33D-4666-B625-E21D0D914FF0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
iF0EARECAB0WIQS+BJlbqPkO0MDBdsRxESqxbLM7OgUCYew/YQAKCRBxESqxbLM7
Ol0uAKC7EQY1Vqc1YMOhAigKRFK14WDSwQCgpUAerukQ+m+p18uxzw7PTMlST94=
=6A4P
-----END PGP SIGNATURE-----
--Apple-Mail=_577FF62E-E33D-4666-B625-E21D0D914FF0--
From: Paul Goyette <paul@whooppee.com>
To: Christos Zoulas <christos@zoulas.com>
Cc: gnats-bugs@netbsd.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: bin/56643: problem with restore(8)
Date: Sat, 22 Jan 2022 17:06:22 -0800 (PST)
On Sat, 22 Jan 2022, Christos Zoulas wrote:
> UFS_EXTATTR is only applicable to UFS1. Is the filesystem you are
> dumping UFS1?
no - FFS2
+--------------------+--------------------------+----------------------+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired) | FA29 0E3B 35AF E8AE 6651 | paul@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoyette@netbsd.org |
| & Network Engineer | | pgoyette99@gmail.com |
+--------------------+--------------------------+----------------------+
From: Christos Zoulas <christos@zoulas.com>
To: gnats-bugs@netbsd.org
Cc: gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org,
paul@whooppee.com
Subject: Re: bin/56643: problem with restore(8)
Date: Sun, 23 Jan 2022 11:25:36 -0500
--Apple-Mail=_7D18D305-39B1-4D89-A2FB-962915309CE0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=us-ascii
Cannot reproduce:
[11:22am] 2518#dd if=3D/dev/zero of=3Ddisk seek=3D1024m count=3D1
1+0 records in
1+0 records out
512 bytes transferred in 0.001 secs (512000 bytes/sec)
[11:22am] 2519#vnconfig -c vnd0 disk
[11:23am] 2520#newfs -O2 /dev/rvnd0a
/dev/rvnd0a: 524288.0MB (1073741824 sectors) block size 32768, fragment =
size 4096
using 707 cylinder groups of 741.59MB, 23731 blks, 46848 inodes.
super-block backups (for fsck_ffs -b #) at:
192, 1518976, 3037760, 4556544, 6075328, 7594112, 9112896, 10631680, =
12150464,
=
..........................................................................=
.....
[11:23am] 2521#mount /dev/vnd0a /mnt
[11:23am] 2522#cp -rp /bin /mnt
[11:23am] 2523#umount /mnt
[11:23am] 2524#dump 0f - /dev/rvnd0a | restore -rf -
DUMP: Date of this level 0 dump: Sun Jan 23 11:23:41 2022
DUMP: Date of last level 0 dump: the epoch
DUMP: Dumping /dev/rvnd0a (an unlisted file system) to standard output
DUMP: Label: none
DUMP: mapping (Pass I) [regular files]
DUMP: mapping (Pass II) [directories]
DUMP: estimated 14761 tape blocks.
DUMP: Volume 1 started at: Sun Jan 23 11:23:42 2022
DUMP: dumping (Pass III) [directories]
DUMP: dumping (Pass IV) [regular files]
DUMP: 10662 tape blocks
DUMP: Volume 1 completed at: Sun Jan 23 11:23:45 2022
DUMP: Volume 1 took 0:00:03
DUMP: Volume 1 transfer rate: 3554 KB/s
DUMP: Date of this level 0 dump: Sun Jan 23 11:23:41 2022
DUMP: Date this dump completed: Sun Jan 23 11:23:45 2022
DUMP: Average transfer rate: 3554 KB/s
DUMP: DUMP IS DONE
TIME=3D0:07.59 CPU=3D87.8% (4.820u 1.852s) SWAPS=3D0 (0+51853)pf =
(0i+41o) (0Kc+1Kd)
[11:23am] 2525#config -x /netbsd | grep UFS
options QUOTA # legacy UFS quotas
options QUOTA2 # new, in-filesystem UFS quotas
# Note that UFS_DIRHASH is suspected of causing kernel memory =
corruption.
#options UFS_DIRHASH # UFS Large Directory Hashing - =
Experimental
#options UFS_ACL # UFS Access Control Lists
#options UFS_EXTATTR # Extended attribute support for UFS1
###> #options APPLE_UFS # Apple UFS support in FFS
###> file-system FFS # UFS
[11:24am] 2526#
> On Jan 22, 2022, at 8:10 PM, Paul Goyette <paul@whooppee.com> wrote:
>=20
> The following reply was made to PR bin/56643; it has been noted by =
GNATS.
>=20
> From: Paul Goyette <paul@whooppee.com>
> To: Christos Zoulas <christos@zoulas.com>
> Cc: gnats-bugs@netbsd.org, gnats-admin@netbsd.org, =
netbsd-bugs@netbsd.org
> Subject: Re: bin/56643: problem with restore(8)
> Date: Sat, 22 Jan 2022 17:06:22 -0800 (PST)
>=20
> On Sat, 22 Jan 2022, Christos Zoulas wrote:
>=20
>> UFS_EXTATTR is only applicable to UFS1. Is the filesystem you are
>> dumping UFS1?
>=20
> no - FFS2
>=20
>=20
>=20
> =
+--------------------+--------------------------+----------------------+
> | Paul Goyette | PGP Key fingerprint: | E-mail addresses: =
|
> | (Retired) | FA29 0E3B 35AF E8AE 6651 | paul@whooppee.com =
|
> | Software Developer | 0786 F758 55DE 53BA 7731 | pgoyette@netbsd.org =
|
> | & Network Engineer | | pgoyette99@gmail.com =
|
> =
+--------------------+--------------------------+----------------------+
>=20
--Apple-Mail=_7D18D305-39B1-4D89-A2FB-962915309CE0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
iF0EARECAB0WIQS+BJlbqPkO0MDBdsRxESqxbLM7OgUCYe2BgAAKCRBxESqxbLM7
OvZEAJ0SitFonf5d5IyR3OSQ4cpZ+Jdi+ACg2CEgk6sxfLze5MWNw3SSqvNrw3E=
=ithu
-----END PGP SIGNATURE-----
--Apple-Mail=_7D18D305-39B1-4D89-A2FB-962915309CE0--
From: Paul Goyette <paul@whooppee.com>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: bin/56643: problem with restore(8)
Date: Sun, 23 Jan 2022 08:53:47 -0800 (PST)
One more piece of information that might be relevant...
In addition to running a kernel without UFS_EXTATTR enabled, this
kernel also does not have UFS or FFS built-in! Instead, these
two _modules_ are "pushed" by the boot-loader (along wiwth wapbl):
# modstat | grep '[uf]fs'
ffs vfs boot - 0 96569 ufs,wapbl
ufs misc boot a 1 75629 wapbl
# cat /boot.cfg
load=ufs
load=wapbl
load=ffs
menu=Boot normally:rndseed /var/db/entropy-file;boot
menu=Boot single user:rndseed /var/db/entropy-file;boot -s
menu=Drop to boot prompt:prompt
menu=Run memory test:boot /usr/pkg/mdec/memtestplus
default=1
timeout=5
clear=1
#
+--------------------+--------------------------+----------------------+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired) | FA29 0E3B 35AF E8AE 6651 | paul@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoyette@netbsd.org |
| & Network Engineer | | pgoyette99@gmail.com |
+--------------------+--------------------------+----------------------+
From: Christos Zoulas <christos@zoulas.com>
To: gnats-bugs@netbsd.org
Cc: gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org,
paul@whooppee.com
Subject: Re: bin/56643: problem with restore(8)
Date: Sun, 23 Jan 2022 11:56:44 -0500
--Apple-Mail=_BA33E80C-7CB0-4EF6-B653-AE2F95C9AA75
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=us-ascii
Why don't you attach the full kernel config and boot.conf so that I can =
reproduce
your exact setup?
christos
> On Jan 23, 2022, at 11:55 AM, Paul Goyette <paul@whooppee.com> wrote:
>=20
> The following reply was made to PR bin/56643; it has been noted by =
GNATS.
>=20
> From: Paul Goyette <paul@whooppee.com>
> To: gnats-bugs@netbsd.org
> Cc:
> Subject: Re: bin/56643: problem with restore(8)
> Date: Sun, 23 Jan 2022 08:53:47 -0800 (PST)
>=20
> One more piece of information that might be relevant...
>=20
> In addition to running a kernel without UFS_EXTATTR enabled, this
> kernel also does not have UFS or FFS built-in! Instead, these
> two _modules_ are "pushed" by the boot-loader (along wiwth wapbl):
>=20
> # modstat | grep '[uf]fs'
> ffs vfs boot - 0 96569 ufs,wapbl
> ufs misc boot a 1 75629 wapbl
> # cat /boot.cfg
> load=3Dufs
> load=3Dwapbl
> load=3Dffs
> menu=3DBoot normally:rndseed /var/db/entropy-file;boot
> menu=3DBoot single user:rndseed /var/db/entropy-file;boot -s
> menu=3DDrop to boot prompt:prompt
> menu=3DRun memory test:boot /usr/pkg/mdec/memtestplus
>=20
> default=3D1
> timeout=3D5
> clear=3D1
> #
>=20
>=20
>=20
> =
+--------------------+--------------------------+----------------------+
> | Paul Goyette | PGP Key fingerprint: | E-mail addresses: =
|
> | (Retired) | FA29 0E3B 35AF E8AE 6651 | paul@whooppee.com =
|
> | Software Developer | 0786 F758 55DE 53BA 7731 | pgoyette@netbsd.org =
|
> | & Network Engineer | | pgoyette99@gmail.com =
|
> =
+--------------------+--------------------------+----------------------+
>=20
--Apple-Mail=_BA33E80C-7CB0-4EF6-B653-AE2F95C9AA75
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
iF0EARECAB0WIQS+BJlbqPkO0MDBdsRxESqxbLM7OgUCYe2IzAAKCRBxESqxbLM7
Oif0AKDcla9krxPgEhYbVdfSjtr9VdsrSwCg7GwaYPuXYL2nO4bRncb/dc5tIsg=
=rALr
-----END PGP SIGNATURE-----
--Apple-Mail=_BA33E80C-7CB0-4EF6-B653-AE2F95C9AA75--
From: Paul Goyette <paul@whooppee.com>
To: Christos Zoulas <christos@zoulas.com>
Cc: gnats-bugs@netbsd.org
Subject: Re: bin/56643: problem with restore(8)
Date: Sun, 23 Jan 2022 09:32:56 -0800 (PST)
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
--0-985055574-1642959176=:7921
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
On Sun, 23 Jan 2022, Christos Zoulas wrote:
> Why don't you attach the full kernel config and boot.conf so that I can reproduce
> your exact setup?
Attached!
+--------------------+--------------------------+----------------------+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired) | FA29 0E3B 35AF E8AE 6651 | paul@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoyette@netbsd.org |
| & Network Engineer | | pgoyette99@gmail.com |
+--------------------+--------------------------+----------------------+
--0-985055574-1642959176=:7921
Content-Type: TEXT/PLAIN; charset=US-ASCII; name=C
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.NEB.4.64.2201230932560.7921@speedy.whooppee.com>
Content-Description:
Content-Disposition: attachment; filename=C
IyMjIFNUQVJUIENPTkZJRyBGSUxFICIvYnVpbGQvbmV0YnNkLWxvY2FsL3Ny
Y19yby9zeXMvYXJjaC9hbWQ2NC9jb25mL1NQRUVEWSINCmluY2x1ZGUJImFy
Y2gvYW1kNjQvY29uZi9XSE9PUFBFRV9DT01NT04iDQoNCiNpZGVudCAJCSJH
RU5FUklDLSRSZXZpc2lvbjogMS41OTMgJCINCmlkZW50CQkiU1BFRURZIDIw
MjItMDEtMDggMDM6MDA6MjggVVRDIg0KDQpubyBvcHRpb25zIAlMT0NLREVC
VUcJIyB0b28gZXhwZW5zaXZlIGZvciBwcm9kdWN0aW9uIHVzZSENCg0KIyBE
ZXZpY2UgY29uZmlndXJhdGlvbg0KDQphY3BpMAkJYXQgbWFpbmJ1czANCg0K
YWNwaWVjMCAJYXQgYWNwaTAJCSMgQUNQSSBFbWJlZGRlZCBDb250cm9sbGVy
IChsYXRlKQ0KYWNwaWVjZHQwCWF0IGFjcGkwCQkjIEFDUEkgRW1iZWRkZWQg
Q29udHJvbGxlciAoZWFybHkpDQphdHRpbWVyMAlhdCBhY3BpMAkJIyBBVCBU
aW1lcg0KDQojIFBDSSBidXMgc3VwcG9ydA0KcGNpMAkJYXQgbWFpbmJ1czAg
YnVzIDANCnBjaGIwCQlhdCBwY2kwIGRldiAgMCBmdW5jdGlvbiAwICMgUENJ
LUhvc3QgYnJpZGdlcw0KcHBiMQkJYXQgcGNpMCBkZXYgIDEgZnVuY3Rpb24g
MCAjIFBDSS1QQ0kgYnJpZGdlcw0KcHBiMgkJYXQgcGNpMCBkZXYgIDEgZnVu
Y3Rpb24gMSAjIFBDSS1QQ0kgYnJpZGdlcw0KcHBiMAkJYXQgcGNpMCBkZXYg
IDMgZnVuY3Rpb24gMCAjIFBDSS1QQ0kgYnJpZGdlcw0KeGhjaTAJCWF0IHBj
aTAJZGV2IDIwIGZ1bmN0aW9uIDAgIyBlWHRlbnNpYmxlIFVTQiBIb3N0IENv
bnRyb2xsZXINCndtMAkJYXQgcGNpMCBkZXYgMjUgZnVuY3Rpb24gMCAjIFJl
YWx0ZWsgODEzOUMrLzgxNjkvODE2OVMvODExMFMNCmlocGh5MCAJCWF0IHdt
MCAgcGh5IDIJCSAgIyBSZWFsdGVrIDgxNjlTLzgxMTAgaW50ZXJuYWwgUEhZ
cw0KI3VrcGh5MAkJYXQgbWlpPyBwaHkgPwkJICAjIGdlbmVyaWMgdW5rbm93
biBQSFlzDQoNCmVoY2kwCQlhdCBwY2kwCWRldiAyNiBmdW5jdGlvbiAwICMg
RW5oYW5jZWQgVVNCIEhvc3QgQ29udHJvbGxlcg0KcHBiMwkJYXQgcGNpMCBk
ZXYgMjggZnVuY3Rpb24gMCAjIFBDSS1QQ0kgYnJpZGdlcw0KcHBiNAkJYXQg
cGNpMCBkZXYgMjggZnVuY3Rpb24gNCAjIFBDSS1QQ0kgYnJpZGdlcw0KZWhj
aTEJCWF0IHBjaTAJZGV2IDI5IGZ1bmN0aW9uIDAgIyBFbmhhbmNlZCBVU0Ig
SG9zdCBDb250cm9sbGVyDQppY2hscGNpYjAJYXQgcGNpMCBkZXYgMzEgZnVu
Y3Rpb24gMCAjIEludGVsIElDSCBQQ0ktTFBDIHcvIHdhdGNoZG9nLA0KCQkJ
CQkgICMgdGltZWNvdW50ZXIsIFNwZWVkc3RlcCwgZ3BpbywNCgkJCQkJICAj
IGFuZCBIUEVUDQphaGNpc2F0YTAJYXQgcGNpMCBkZXYgMzEgZnVuY3Rpb24g
MiAjIEFIQ0kgU0FUQSBjb250cm9sbGVycw0KDQpwY2kxCQlhdCBwcGIwIGJ1
cyAxDQoNCiMgdmdhMCBpcyBuZWVkZWQgc2luY2Ugbm91dmVhdSBjdXJyZW50
bHkgZG9lc24ndCB3b3JrIG9uIG1hbnkgbW9kZXJuDQojIG5WaWRpYSB2aWRl
byBjYXJkcy4NCg0KdmdhMAkJYXQgcGNpMSBkZXYgMCBmdW5jdGlvbiAwDQpu
b3V2ZWF1MAlhdCBwY2kxIGRldiAwIGZ1bmN0aW9uIDANCm5vdXZlYXVmYjAJ
YXQgbm91dmVhdTANCg0KcmFkZW9uMAkJYXQgcGNpMSBkZXYgIDAgZnVuY3Rp
b24gMA0KcmFkZW9uZHJta21zZmIwCWF0IHJhZGVvbjANCg0KZ2VuZmIwCQlh
dCBwY2kxIGRldiAgMCBmdW5jdGlvbiAwDQoNCnBjaTIJCWF0IHBwYjEgYnVz
IDINCg0KcGNpMwkJYXQgcHBiMiBidXMgMw0KDQpwY2k0CQlhdCBwcGIzIGJ1
cyA0DQoNCnBjaTUJCWF0IHBwYjQgYnVzIDUNCnhoY2kxCQlhdCBwY2k1CWRl
diAgMCBmdW5jdGlvbiAwICMgZVh0ZW5zaWJsZSBVU0IgSG9zdCBDb250cm9s
bGVyDQoNCnBjaTYJCWF0IG1haW5idXMwIGJ1cyAyNTUNCg0KIyBDb25zb2xl
IERldmljZXMNCg0Kd3NkaXNwbGF5MAlhdCB3c2VtdWxkaXNwbGF5ZGV2Pw0K
DQojIEFUQS9JREUvU0NTSSBkZXZpY2VzDQoNCmF0YWJ1czAJCWF0IGFoY2lz
YXRhMCBjaGFubmVsIDANCmF0YWJ1czEJCWF0IGFoY2lzYXRhMCBjaGFubmVs
IDENCmF0YWJ1cyoJCWF0IGFoY2lzYXRhPyBjaGFubmVsID8NCg0Kd2QwCQlh
dCBhdGFidXMwIGRyaXZlIDAgZmxhZ3MgMHgwMDAwCQkjIEFUQS9JREUgaGFy
ZCBkcml2ZXMNCndkMQkJYXQgYXRhYnVzMSBkcml2ZSAwIGZsYWdzIDB4MDAw
MAkJIyBBVEEvSURFIGhhcmQgZHJpdmVzDQp3ZCoJCWF0IGF0YWJ1cz8NCg0K
IyBJU0EgYnVzIGRldmljZXMgLSBrZXlib2FyZCwgbW91c2UNCiMgKGNvbnNv
bGUgcG9ydCBjb20wIGlzIGF0dGFjaGVkIGF0IGFjcGkwKQ0KDQppc2EwCQlh
dCBpY2hscGNpYj8JCSMgSVNBIGJ1cw0KcGNrYmMwCQlhdCBpc2E/CQkJIyBw
YyBrZXlib2FyZCBjb250cm9sbGVyDQpwY2tiZDAJCWF0IHBja2JjMAkJIyBQ
QyBrZXlib2FyZA0KcG1zMAkJYXQgcGNrYmMwCQkjIFBTLzIgbW91c2UgZm9y
IHdzbW91c2UNCndza2JkKgkJYXQgcGNrYmQ/IGNvbnNvbGUgPyBtdXggMQ0K
d3Ntb3VzZSoJYXQgd3Ntb3VzZWRldj8NCmNvbTAJCWF0IGFjcGkwCQkjIFNl
cmlhbCBjb21tdW5pY2F0aW9ucyBpbnRlcmZhY2UNCg0KIyBVU0IgRGV2aWNl
cyAobm90IGhhcmR3aXJlZCwgZXhjZXB0IGZvciB1Z2VuMCBmb3IgdGhlIFVQ
UykNCg0KIyBVU0IgSHVicyBhbmQgYnVzc2VzDQp1c2IqCQlhdCB4aGNpPw0K
dXNiKgkJYXQgZWhjaT8NCnVodWIqCQlhdCB1c2I/DQp1aHViKgkJYXQgdWh1
Yj8gcG9ydCA/DQoNCiMgQVBDIFVQUyANCnVnZW4wCQlhdCB1aHViPyBwb3J0
ID8gdmVuZG9yIDB4NTFkIHByb2R1Y3QgMHgyDQoNCiMgVVNCIFN0b3JhZ2UN
CnVtYXNzKgkJYXQgdWh1Yj8gcG9ydCA/IGNvbmZpZ3VyYXRpb24gPyBpbnRl
cmZhY2UgPw0Kc2NzaWJ1cyoJYXQgdW1hc3M/DQpzZCoJCWF0IHNjc2lidXM/
IHRhcmdldCA/IGx1biA/DQpjZCoJCWF0IHNjc2lidXM/IHRhcmdldCA/IGx1
biA/DQphdGFwaWJ1cyoJYXQgdW1hc3M/DQpzZCoJCWF0IGF0YXBpYnVzPyBk
cml2ZSA/IGZsYWdzIDB4MDAwMA0KY2QqCQlhdCBhdGFwaWJ1cz8gZHJpdmUg
PyBmbGFncyAweDAwMDANCg0KIyBVU0IgSHVtYW4gaW50ZXJmYWNlIGRldmlj
ZXMNCnVoaWRldioJCWF0IHVodWI/IHBvcnQgPyBjb25maWd1cmF0aW9uID8g
aW50ZXJmYWNlID8NCnVoaWQqCQlhdCB1aGlkZXY/IHJlcG9ydGlkID8JIyBV
U0IgZ2VuZXJpYyBISUQNCnVrYmQqCQlhdCB1aGlkZXY/IHJlcG9ydGlkID8J
IyBVU0Iga2V5Ym9hcmRzDQp3c2tiZCoJCWF0IHVrYmQ/IGNvbnNvbGUgPyBt
dXggMQ0KdW1zKgkJYXQgdWhpZGV2PyByZXBvcnRpZCA/CSMgVVNCIG1pY2UN
Cg0KIyBVU0IgZ2VuZXJpYyBkcml2ZXINCiN1Z2VuKgkJYXQgdWh1Yj8gcG9y
dCA/DQoNCiMgVVNCIFByaW50ZXINCiN1bHB0KgkJYXQgdWh1Yj8gcG9ydCA/
IGNvbmZpZ3VyYXRpb24gPyBpbnRlcmZhY2UgPw0KIyMjIEVORCBDT05GSUcg
RklMRSAiL2J1aWxkL25ldGJzZC1sb2NhbC9zcmNfcm8vc3lzL2FyY2gvYW1k
NjQvY29uZi9TUEVFRFkiDQojIyMgKGluY2x1ZGVkIGZyb20gImFyY2gvYW1k
NjQvY29uZi9XSE9PUFBFRV9DT01NT04iKQ0KIyMjPiBpbmNsdWRlCSJhcmNo
L2FtZDY0L2NvbmYvc3RkLmFtZDY0Ig0KIyMjPiANCiMjIz4gI2lkZW50CQki
R0VORVJJQy0kUmV2aXNpb246IDEuNTkzICQiDQojIyM+IA0KIyMjPiBpZGVu
dAkJIldIT09QUEVFLWNvbW1vbiINCiMjIz4gDQojIyM+IG9wdGlvbnMgCUlO
Q0xVREVfQ09ORklHX0ZJTEUJIyBlbWJlZCBjb25maWcgZmlsZSBpbiBrZXJu
ZWwgYmluYXJ5DQojIyM+IA0KIyMjPiBjb25maWcJCW5ldGJzZAlyb290IG9u
ID8gdHlwZSBmZnMNCiMjIz4gDQojIyM+IG1heHVzZXJzCTY0CQkjIGVzdGlt
YXRlZCBudW1iZXIgb2YgdXNlcnMNCiMjIz4gDQojIyM+ICMgUmVtb3ZlIHN0
YW5kYXJkIG9wdGlvbnMsIGFzIHRoZXkgYXJlIHByb3ZpZGVkIGJ5IG1vZHVs
ZXMNCiMjIz4gDQojIyM+IG5vIG9wdGlvbnMgCUVYRUNfU0NSSVBUDQojIyM+
IG5vIG9wdGlvbnMgCUVYRUNfRUxGNjQNCiMjIz4gbm8gb3B0aW9ucyAJQ09S
RURVTVANCiMjIz4gbm8gb3B0aW9ucyAJQUlPDQojIyM+IG5vIG9wdGlvbnMg
CU1RVUVVRQ0KIyMjPiBubyBvcHRpb25zIAlTRU1BUEhPUkUNCiMjIz4gbm8g
b3B0aW9ucyAJUFRSQUNFDQojIyM+IA0KIyMjPiAjIFN0YW5kYXJkIHN5c3Rl
bSBvcHRpb25zDQojIyM+IA0KIyMjPiBvcHRpb25zIAlJTlNFQ1VSRQkjIGRp
c2FibGUga2VybmVsIHNlY3VyaXR5IGxldmVscyAtIFggbmVlZHMgdGhpcw0K
IyMjPiANCiMjIz4gb3B0aW9ucyAJUlRDX09GRlNFVD0wCSMgaGFyZHdhcmUg
Y2xvY2sgaXMgdGhpcyBtYW55IG1pbnMuIHdlc3Qgb2YgR01UDQojIyM+IG9w
dGlvbnMgCU5UUAkJIyBOVFAgcGhhc2UvZnJlcXVlbmN5IGxvY2tlZCBsb29w
DQojIyM+IG9wdGlvbnMgCUtUUkFDRQkJIyBzeXN0ZW0gY2FsbCB0cmFjaW5n
IHZpYSBrdHJhY2UoMSkNCiMjIz4gb3B0aW9ucyAJQ1BVX1VDT0RFCSMgY3B1
IHVjb2RlIGxvYWRpbmcgc3VwcG9ydA0KIyMjPiBvcHRpb25zIAlLRFRSQUNF
X0hPT0tTCSMga2VybmVsIERUcmFjZSBob29rcw0KIyMjPiANCiMjIz4gb3B0
aW9ucyAJTU9EVUxBUgkJIyBuZXcgc3R5bGUgbW9kdWxlKDcpIGZyYW1ld29y
aw0KIyMjPiBvcHRpb25zIAlNT0RVTEFSX0RFRkFVTFRfQVVUT0xPQUQNCiMj
Iz4gb3B0aW9ucyAJVkdBX1BPU1QJIyBpbi1rZXJuZWwgc3VwcG9ydCBmb3Ig
VkdBIFBPU1QNCiMjIz4gb3B0aW9ucyAJVVNFUkNPTkYJIyB1c2VyY29uZig0
KSBzdXBwb3J0DQojIyM+IG9wdGlvbnMgCVNZU0NUTF9JTkNMVURFX0RFU0NS
CSMgSW5jbHVkZSBzeXNjdGwgZGVzY3JpcHRpb25zIGluIGtlcm5lbA0KIyMj
PiANCiMjIz4gIyBDUFUtcmVsYXRlZCBvcHRpb25zDQojIyM+IG9wdGlvbnMg
CVVTRVJfTERUCSMgVXNlci1zZXR0YWJsZSBMRFQsIHVzZWQgYnkgV2luZQ0K
IyMjPiBvcHRpb25zIAlTVlMJCSMgU2VwYXJhdGUgVmlydHVhbCBTcGFjZQ0K
IyMjPiBvcHRpb25zIAlQQ1BVX0lEVAkjIFBlciBDUFUgSURUcw0KIyMjPiAN
CiMjIz4gIyBHQ0MgU3BlY3RyZSB2YXJpYW50IDIgbWl0aWdhdGlvbg0KIyMj
PiBtYWtlb3B0aW9ucwlTUEVDVFJFX1YyX0dDQ19NSVRJR0FUSU9OPTENCiMj
Iz4gb3B0aW9ucyAJU1BFQ1RSRV9WMl9HQ0NfTUlUSUdBVElPTg0KIyMjPiAN
CiMjIz4gb3B0aW9ucyAJRElBR05PU1RJQwkjIGluZXhwZW5zaXZlIGtlcm5l
bCBjb25zaXN0ZW5jeSBjaGVja3MNCiMjIz4gb3B0aW9ucyAJREVCVUcJCSMg
ZXhwZW5zaXZlIGRlYnVnZ2luZyBjaGVja3Mvc3VwcG9ydA0KIyMjPiBvcHRp
b25zIAlMT0NLREVCVUcJIyBleHBlbnNpdmUgbG9ja2luZyBjaGVja3Mvc3Vw
cG9ydA0KIyMjPiBvcHRpb25zIAlNU0dCVUZTSVpFPTUyNDI4OA0KIyMjPiAN
CiMjIz4gbWFrZW9wdGlvbnMJQ09QVFM9Ii1PMiAtZm5vLW9taXQtZnJhbWUt
cG9pbnRlciINCiMjIz4gbWFrZW9wdGlvbnMJREVCVUc9Ii1nIgkjIGNvbXBp
bGUgZnVsbCBzeW1ib2wgdGFibGUgLSBDVEYgbmVlZHMgdGhpcw0KIyMjPiAN
CiMjIz4gIyBEREJfKiBvcHRpb25zIC0gc2VlIGRkYig0KSwgc3lzY3RsKDcp
LCBhbmQgb3B0aW9ucyg0KQ0KIyMjPiANCiMjIz4gb3B0aW9ucyAJRERCCQkj
IGluLWtlcm5lbCBkZWJ1Z2dlcg0KIyMjPiBvcHRpb25zIAlEREJfT05QQU5J
Qz0xCQkjIGVudGVyIGRkYiBpZiBwYW5pYyg5KQ0KIyMjPiBvcHRpb25zIAlE
REJfQ09NTUFORE9ORU5URVI9ImJ0OyBzaG93IHJlZzsgc3luYyINCiMjIz4g
b3B0aW9ucyAJRERCX0hJU1RPUllfU0laRT01MTIJIyBlbmFibGUgaGlzdG9y
eSBlZGl0aW5nIGluIEREQg0KIyMjPiBvcHRpb25zIAlEREJfVEVFX01TR0JV
Rj0xCSMgY29weSBEREIgb3V0cHV0IHRvIGRtZXNnKDgpDQojIyM+IA0KIyMj
PiAjIEZpbGUgc3lzdGVtcw0KIyMjPiAjZmlsZS1zeXN0ZW0gCUZGUwkJIyBV
RlMNCiMjIz4gI29wdGlvbnMgCVFVT1RBMgkJIyBuZXcsIGluLWZpbGVzeXN0
ZW0gVUZTIHF1b3Rhcw0KIyMjPiAjb3B0aW9ucyAJRkZTX0VJCQkjIEZGUyBF
bmRpYW4gSW5kZXBlbmRlbnQgc3VwcG9ydA0KIyMjPiAjb3B0aW9ucyAJRElT
S0xBQkVMX0VJCSMgZGlza2xhYmVsIEVuZGlhbiBJbmRlcGVuZGVudCBzdXBw
b3J0DQojIyM+ICNvcHRpb25zIAlXQVBCTAkJIyBGaWxlIHN5c3RlbSBqb3Vy
bmFsaW5nIHN1cHBvcnQNCiMjIz4gI29wdGlvbnMgCVVGU19FWFRBVFRSCSMg
RXh0ZW5kZWQgYXR0cmlidXRlIHN1cHBvcnQgZm9yIFVGUzENCiMjIz4gDQoj
IyM+ICMgTmV0d29ya2luZyBvcHRpb25zDQojIyM+IG9wdGlvbnMgCUlORVQJ
CSMgSVAgKyBJQ01QICsgVENQICsgVURQDQojIyM+IG9wdGlvbnMgCUlORVQ2
CQkjIElQVjYNCiMjIz4gDQojIyM+IHBzZXVkby1kZXZpY2UJbG9vcAkJIyBu
ZXR3b3JrIGxvb3BiYWNrDQojIyM+IA0KIyMjPiAjIHdzY29ucyBvcHRpb25z
DQojIyM+ICMNCiMjIz4gb3B0aW9ucyAJV1NFTVVMX1ZUMTAwCQkJIyBWVDEw
MCAvIFZUMjIwIGVtdWxhdGlvbg0KIyMjPiBvcHRpb25zIAlXU19LRVJORUxf
Rkc9V1NDT0xfR1JFRU4NCiMjIz4gb3B0aW9ucyAJV1NESVNQTEFZX0NVU1RP
TV9PVVRQVVQgIyBjb2xvciBjdXN0b21pemF0aW9uIGZyb20gd3Njb25zY3Rs
KDgpDQojIyM+ICNvcHRpb25zIAlXU19LRVJORUxfQkc9V1NDT0xfQkxBQ0sN
CiMjIz4gIyBjdXN0b21pemF0aW9uIG9mIGNvbnNvbGUgYm9yZGVyIGNvbG9y
DQojIyM+IG9wdGlvbnMgCVdTRElTUExBWV9DVVNUT01fQk9SREVSICMgY3Vz
dG9tIGJvcmRlciBjb2xvcnMgdmlhIHdzY29uc2N0bCg4KQ0KIyMjPiAjIGNv
bXBhdGliaWxpdHkgdG8gb3RoZXIgY29uc29sZSBkcml2ZXJzDQojIyM+IG9w
dGlvbnMgCVdTRElTUExBWV9DT01QQVRfUENWVAkJIyBlbXVsYXRlIHNvbWUg
aW9jdGxzDQojIyM+IG9wdGlvbnMgCVdTRElTUExBWV9DT01QQVRfU1lTQ09O
UwkjIGVtdWxhdGUgc29tZSBpb2N0bHMNCiMjIz4gb3B0aW9ucyAJV1NESVNQ
TEFZX0NPTVBBVF9VU0wJCSMgd3Njb25zY2ZnIFZUIGhhbmRsaW5nDQojIyM+
IG9wdGlvbnMgCVdTRElTUExBWV9DT01QQVRfUkFXS0JECQkjIGNhbiBnZXQg
cmF3IHNjYW5jb2Rlcw0KIyMjPiAjIGRvbid0IGF0dGFjaCBwY2tiZCBhcyB0
aGUgY29uc29sZSBpZiBubyBQUy8yIGtleWJvYXJkIGlzIGZvdW5kDQojIyM+
IG9wdGlvbnMgCVBDS0JEX0NOQVRUQUNIX01BWV9GQUlMDQojIyM+IG9wdGlv
bnMgCVBDRElTUExBWV9TT0ZUQ1VSU09SDQojIyM+IG9wdGlvbnMgCVdTRElT
UExBWV9TQ1JPTExTVVBQT1JUDQojIyM+IA0KIyMjPiBwc2V1ZG8tZGV2aWNl
CXdzbXV4CQkJIyBtb3VzZSAmIGtleWJvYXJkIG11bHRpcGxleG9yDQojIyM+
ICMgR2l2ZSB1cyBhIGNob2ljZSBvZiBmb250IGRlcGVuZGluZyBvbiBtb25p
dG9yIHNpemUNCiMjIz4gcHNldWRvLWRldmljZQl3c2ZvbnQNCiMjIz4gb3B0
aW9ucyAJRk9OVF9CT0xEOHgxNg0KIyMjPiBvcHRpb25zIAlGT05UX0JPTEQx
NngzMg0KIyMjPiANCiMjIz4gIyBNaXNjZWxsYW5lb3VzIG9wdGlvbnMNCiMj
Iz4gDQojIyM+IG9wdGlvbnMgCUZJTEVBU1NPQwkJIyBmaWxlYXNzb2MoOSkg
LSBuZWVkZWQgYnkgVmVyaWV4ZWMNCiMjIz4gCQkJCQkjIGFuZCBQQVhfU0VH
VkdVQVJEDQojIyM+IG9wdGlvbnMgCVBBWF9TRUdWR1VBUkQ9MAkJIyBQYVgg
U2VnbWVudGF0aW9uIGZhdWx0IGd1YXJkDQojIyM+IG9wdGlvbnMgCVBBWF9N
UFJPVEVDVD0xCQkjIFBhWCBtcHJvdGVjdCgyKSByZXN0cmljdGlvbnMNCiMj
Iz4gb3B0aW9ucyAJUEFYX01QUk9URUNUX0RFQlVHPTEJIyBQYVggbXByb3Rl
Y3QgZGVidWcNCiMjIz4gb3B0aW9ucyAJUEFYX0FTTFI9MQkJIyBQYVggQWRk
cmVzcyBTcGFjZSBMYXlvdXQgUmFuZG9taXphdGlvbg0KIyMjPiBvcHRpb25z
IAlQQVhfQVNMUl9ERUJVRz0xCSMgUGFYIEFTTFIgZGVidWcNCiMjIz4gDQoj
IyM+IG9wdGlvbnMgCUFDUElfU0NBTlBDSQkJIyBmaW5kIFBDSSByb290cyB1
c2luZyBBQ1BJDQojIyM+IA0KIyMjPiBvcHRpb25zIAlES1dFREdFX0FVVE9E
SVNDT1ZFUgkjIEF1dG9tYXRpY2FsbHkgYWRkIGRrKDQpIGluc3RhbmNlcw0K
IyMjPiBvcHRpb25zIAlES1dFREdFX01FVEhPRF9HUFQJIyBTdXBwb3J0cyBH
UFQgcGFydGl0aW9ucyBhcyB3ZWRnZXMNCiMjIz4gI29wdGlvbnMgCURLV0VE
R0VfTUVUSE9EX0JTRExBQkVMCSMgU3VwcG9ydCBkaXNrbGFiZWwgZW50cmll
cyBhcyB3ZWRnZXMNCiMjIz4gI29wdGlvbnMgCURLV0VER0VfTUVUSE9EX01C
UgkjIFN1cHBvcnQgTUJSIHBhcnRpdGlvbnMgYXMgd2VkZ2VzDQojIyM+ICNv
cHRpb25zIAlES1dFREdFX01FVEhPRF9BUFBMRSAgICAjIFN1cHBvcnQgQXBw
bGUgcGFydGl0aW9ucyBhcyB3ZWRnZXMNCiMjIz4gI29wdGlvbnMgCURLV0VE
R0VfTUVUSE9EX1JEQgkjIFN1cHBvcnQgUkRCIHBhcnRpdGlvbnMgYXMgd2Vk
Z2VzDQojIyM+IA0KIyMjPiBvcHRpb25zIAlBR1BfWDg2DQojIyM+IG9wdGlv
bnMgCVZDT05TX0RSQVdfSU5UUg0KIyMjPiANCiMjIz4gI29wdGlvbnMgCUtB
U0xSCQkjIEtlcm5lbCBBZGRyZXNzIFNwYWNlIExheW91dCBSYW5kb21pemF0
aW9uDQojIyM+ICNtYWtlb3B0aW9ucwlLQVNMUj0xCQkjIChhbmQgdGhlICJw
cmUta2VybiIpDQojIyM+IA0KIyMjPiAjIFBzZXVkby1EZXZpY2VzDQojIyM+
IA0KIyMjPiBwc2V1ZG8tZGV2aWNlCXB0eQkJCSMgcHNldWRvLXRlcm1pbmFs
cw0KIyMjPiBwc2V1ZG8tZGV2aWNlCWtzeW1zCQkJIyAvZGV2L2tzeW1zDQoj
IyM+IHBzZXVkby1kZXZpY2UJbG9ja3N0YXQJCSMgbG9jayBwcm9maWxpbmcN
CiMjIz4gI3BzZXVkby1kZXZpY2UJc2VxdWVuY2VyCQkjIE1JREkgc2VxdWVu
Y2VyDQojIyMgKGVuZCBpbmNsdWRlICJhcmNoL2FtZDY0L2NvbmYvV0hPT1BQ
RUVfQ09NTU9OIikNCiMjIyAoaW5jbHVkZWQgZnJvbSAiYXJjaC9hbWQ2NC9j
b25mL3N0ZC5hbWQ2NCIpDQojIyM+ICMgJE5ldEJTRDogc3RkLmFtZDY0LHYg
MS4xMiAyMDIwLzA0LzI1IDE1OjI2OjE2IGJvdXllciBFeHAgJA0KIyMjPiAj
DQojIyM+ICMgc3RhbmRhcmQsIHJlcXVpcmVkIE5ldEJTRC9hbWQ2NCAnb3B0
aW9ucycNCiMjIz4gDQojIyM+IG1hY2hpbmUgYW1kNjQgeDg2IHhlbg0KIyMj
PiBpbmNsdWRlIAkiY29uZi9zdGQiCSMgTUkgc3RhbmRhcmQgb3B0aW9ucw0K
IyMjPiBpbmNsdWRlIAkiYXJjaC94ZW4vY29uZi9zdGQueGVudmVyc2lvbiIN
CiMjIz4gDQojIyM+IG9wdGlvbnMgCUNQVV9JTl9DS1NVTQ0KIyMjPiBvcHRp
b25zIAlFWEVDX0VMRjY0CSMgZXhlYyBFTEYgYmluYXJpZXMNCiMjIz4gb3B0
aW9ucyAJRVhFQ19TQ1JJUFQJIyBleGVjICMhIHNjcmlwdHMNCiMjIz4gb3B0
aW9ucyAJTVRSUg0KIyMjPiBvcHRpb25zIAlNVUxUSVBST0NFU1NPUg0KIyMj
PiANCiMjIz4gb3B0aW9ucyAJQ0hJTERfTUFYPTEwMjQJIyAxNjAgaXMgdG9v
IGZldw0KIyMjPiBvcHRpb25zIAlPUEVOX01BWD0xMDI0CSMgMTI4IGlzIHRv
byBmZXcNCiMjIz4gDQojIyM+IG1haW5idXMwIGF0IHJvb3QNCiMjIz4gY3B1
KiBhdCBtYWluYnVzPw0KIyMjPiBpb2FwaWMqIGF0IG1haW5idXM/IGFwaWQg
Pw0KIyMjPiANCiMjIz4gIyBBdGhlcm9zIEhBTCBvcHRpb25zDQojIyM+IGlu
Y2x1ZGUgImV4dGVybmFsL2lzYy9hdGhlcm9zX2hhbC9jb25mL3N0ZC5hdGhf
aGFsIg0KIyMjIChlbmQgaW5jbHVkZSAiYXJjaC9hbWQ2NC9jb25mL3N0ZC5h
bWQ2NCIpDQojIyMgKGluY2x1ZGVkIGZyb20gImNvbmYvc3RkIikNCiMjIz4g
IyAkTmV0QlNEOiBzdGQsdiAxLjIzIDIwMTkvMDEvMjcgMDI6MDg6NDEgcGdv
eWV0dGUgRXhwICQNCiMjIz4gIw0KIyMjPiAjIHN0YW5kYXJkIE1JICdvcHRp
b25zJw0KIyMjPiAjDQojIyM+ICMgdGhpcyBmaWxlIGlzIGZvciBvcHRpb25z
IHdoaWNoIGNhbid0IGJlIG9mZi1ieS1kZWZhdWx0IGZvciBzb21lIHJlYXNv
bnMuDQojIyM+ICMgIml0J3MgY29tbW9ubHkgdXNlZCIgaXMgTk9UIGEgZ29v
ZCByZWFzb24gdG8gZW5hYmxlIG9wdGlvbnMgaGVyZS4NCiMjIz4gDQojIyM+
ICMNCiMjIz4gIyBBbHdheXMgaW5jbHVkZSAia2VybiIgYXR0cmlidXRlICht
b2R1bGUpLiAgT3RoZXIgYXR0cmlidXRlcyBkb24ndCBuZWVkIHRvDQojIyM+
ICMgZGVwZW5kIG9uICJrZXJuIi4NCiMjIz4gIw0KIyMjPiBzZWxlY3QJa2Vy
bg0KIyMjPiANCiMjIz4gIyBBbHdheXMgaW5jbHVkZSB0aGUgInZmcyIgYXR0
cmlidXRlIChtb2R1bGUpLiAgQWx0aG91Z2ggYWxsIG9mIHRoZQ0KIyMjPiAj
IHVmcy94eHggZmlsZSBzeXN0ZW1zIGRlcGVuZCBvbiB0aGUgdmZzIGF0dHJp
YnV0ZSwgaXQgaXMgbm90IHJlcXVpcmVkDQojIyM+ICMgdGhhdCBhbnkgZmls
ZSBzeXN0ZW0gYWN0dWFsbHkgYmUgYnVpbHQtaW4gdG8gdGhlIGtlcm5lbC4g
IChBdCBsZWFzdA0KIyMjPiAjIG9uIHNvbWUgYXJjaGl0ZWN0dXJlcywgZmls
ZSBzeXN0ZW0gbW9kdWxlcyBjYW4gYmUgbG9hZGVkIGF0IGJvb3QNCiMjIz4g
IyB0aW1lLikNCiMjIz4gDQojIyM+IHNlbGVjdCB2ZnMNCiMjIz4gDQojIyM+
IHNlbGVjdAluZXQJCSMgWFhYIENsZWFuIHVwIGRlcGVuZGVuY3kNCiMjIz4g
DQojIyM+ICMgdGhlIGZvbGxvd2luZyBvcHRpb25zIGFyZSBvbi1ieS1kZWZh
dWx0IHRvIGtlZXANCiMjIz4gIyBrZXJuZWwgY29uZmlnIGZpbGUgY29tcGF0
aWJpbGl0eS4NCiMjIz4gb3B0aW9ucwlWTVNXQVAJCSMgU3dhcCBkZXZpY2Uv
ZmlsZSBzdXBwb3J0DQojIyM+IG9wdGlvbnMJQlVGUV9GQ0ZTCSMgRmlyc3Qt
Y29tZSBGaXJzdC1zZXJ2ZSBzdHJhdGVneQ0KIyMjPiBvcHRpb25zCUJVRlFf
RElTS1NPUlQJIyBUcmFkaXRpb25hbCBtaW4gc2VlayBzb3J0IHN0cmF0ZWd5
DQojIyM+IG9wdGlvbnMJUkZDMjI5MgkJIyBQcmV2aW91cyB2ZXJzaW9uIG9m
IEFkdi4gU29ja2V0cyBBUEkgZm9yIElQdjYgDQojIyM+IG9wdGlvbnMJUFRS
QUNFCQkjIEluY2x1ZGUgcHRyYWNlKDIpIHN5c2NhbGwNCiMjIz4gb3B0aW9u
cwlQVFJBQ0VfSE9PS1MJIyBJbmNsdWRlIHB0cmFjZSBob29rcw0KIyMjPiBv
cHRpb25zCUNPUkVEVU1QCSMgYWxsb3cgcHJvY2Vzc2VzIHRvIGNvcmVkdW1w
Lg0KIyMjPiBvcHRpb25zCUFJTwkJIyBQT1NJWCBhc3luY2hyb25vdXMgSS9P
DQojIyM+IG9wdGlvbnMJTVFVRVVFCQkjIFBPU0lYIG1lc3NhZ2UgcXVldWVz
DQojIyM+IG9wdGlvbnMJU0VNQVBIT1JFCSMgUE9TSVggc2VtYXBob3Jlcwkj
IFhYWC1QUkcNCiMjIz4gDQojIyM+ICMgQ29tbW9uIGNvbXBhdGliaWxpdHkg
ZnVuY3Rpb25zLiBUaGV5IGhhcHBlbiB0byBiZSBuZWVkZWQgZXZlbiB3aGVu
DQojIyM+ICMgbm8gY29tcGF0aWJpbGl0eSBvcHRpb24gaXMgZXhwbGljaXRs
eSBlbmFibGVkLg0KIyMjPiAjDQojIyM+IG9wdGlvbnMgICAgICAgIENPTVBB
VF9VVElMUw0KIyMjPiANCiMjIz4gIw0KIyMjPiAjIFNlY3VyaXR5IG1vZGVs
Lg0KIyMjPiAjDQojIyM+IG9wdGlvbnMJc2VjbW9kZWxfYnNkNDQJIyBUcmFk
aXRpb25hbCA0LjRCU0Qgc2VjdXJpdHkgbW9kZWwNCiMjIz4gDQojIyM+ICMN
CiMjIz4gIyBTY2hlZHVsaW5nIGFsZ29yaXRobQ0KIyMjPiAjDQojIyM+IG9w
dGlvbnMJU0NIRURfNEJTRA0KIyMjPiANCiMjIz4gcHNldWRvLWRldmljZQlj
cHVjdGwNCiMjIz4gDQojIyM+ICMNCiMjIz4gIyBLZXJuZWwgZW50cm9weSBw
b29sIGFuZCByYW5kb20tbnVtYmVyIGdlbmVyYXRvciBwc2V1ZG9kZXZpY2Uu
DQojIyM+ICMgVGhlIHBzZXVkb2RldmljZSBtaWdodCBzdG9wIGJlaW5nICJz
dGQiIHdoZW4gdGhlIHR3byBhcmUgdG9ybg0KIyMjPiAjIGFwYXJ0IHNvbWUg
ZGF5IGJ1dCB0aGUgZW50cm9weSBwb29sIGl0c2VsZiBuZXZlciB3aWxsICh0
aGV5IGFyZQ0KIyMjPiAjIHByZXNlbnRseSBpbXBsZW1lbnRlZCBpbiB0aGUg
c2FtZSBzb3VyY2UgZmlsZSkNCiMjIz4gIw0KIyMjPiBwc2V1ZG8tZGV2aWNl
CXJuZA0KIyMjIChlbmQgaW5jbHVkZSAiY29uZi9zdGQiKQ0KIyMjIChpbmNs
dWRlZCBmcm9tICJhcmNoL3hlbi9jb25mL3N0ZC54ZW52ZXJzaW9uIikNCiMj
Iz4gIyAkTmV0QlNEOiBzdGQueGVudmVyc2lvbix2IDEuMyAyMDIwLzA0LzI1
IDE1OjI2OjE3IGJvdXllciBFeHAgJA0KIyMjPiAjDQojIyM+ICMgWGVuIG9w
dGlvbnMgc2hhcmVkIGZvciBhbGwgYXJjaHMgKGkzODYsIGFtZDY0KQ0KIyMj
PiANCiMjIz4gb3B0aW9ucyAJX19YRU5fSU5URVJGQUNFX1ZFUlNJT05fXz0w
eDAwMDMwMjBhICMgWGVuIDMuMi4xMCBpbnRlcmZhY2UNCiMjIz4gDQojIyMg
KGVuZCBpbmNsdWRlICJhcmNoL3hlbi9jb25mL3N0ZC54ZW52ZXJzaW9uIikN
CiMjIyAoaW5jbHVkZWQgZnJvbSAiZXh0ZXJuYWwvaXNjL2F0aGVyb3NfaGFs
L2NvbmYvc3RkLmF0aF9oYWwiKQ0KIyMjPiAjb3B0aW9ucyBBVEhIQUxfQVNT
RVJUDQojIyM+ICNvcHRpb25zIEFUSEhBTF9ERUJVRw0KIyMjPiAjb3B0aW9u
cyBBVEhIQUxfREVCVUdfQUxRDQojIyM+IA0KIyMjPiAjIEF0aGVyb3MgSEFM
IENoaXBzZXQgU3VwcG9ydA0KIyMjPiAjDQojIyM+IG9wdGlvbnMgQVRISEFM
X0FSNTIxMA0KIyMjPiBvcHRpb25zIEFUSEhBTF9BUjUyMTENCiMjIz4gb3B0
aW9ucyBBVEhIQUxfQVI1MjEyDQojIyM+IG9wdGlvbnMgQVRISEFMX0FSNTMx
MQ0KIyMjPiAjb3B0aW9ucyBBVEhIQUxfQVI1MzEyDQojIyM+ICNvcHRpb25z
IEFUSEhBTF9BUjIzMTYNCiMjIz4gI29wdGlvbnMgQVRISEFMX0FSMjMxNw0K
IyMjPiBvcHRpb25zIEFUSEhBTF9BUjU0MTYNCiMjIz4gb3B0aW9ucyBBVEhI
QUxfQVI5MjgwDQojIyM+IG9wdGlvbnMgQVRISEFMX0FSOTI4NQ0KIyMjPiAN
CiMjIz4gIyBBdGhlcm9zIEFSNTIxMi9BUjUzMTIgUkYgU3VwcG9ydA0KIyMj
PiAjDQojIyM+IG9wdGlvbnMgQVRISEFMX1JGMjMxNg0KIyMjPiBvcHRpb25z
IEFUSEhBTF9SRjIzMTcNCiMjIz4gb3B0aW9ucyBBVEhIQUxfUkYyNDEzDQoj
IyM+IG9wdGlvbnMgQVRISEFMX1JGMjQyNQ0KIyMjPiBvcHRpb25zIEFUSEhB
TF9SRjUxMTENCiMjIz4gb3B0aW9ucyBBVEhIQUxfUkY1MTEyDQojIyM+IG9w
dGlvbnMgQVRISEFMX1JGNTQxMw0KIyMjIChlbmQgaW5jbHVkZSAiZXh0ZXJu
YWwvaXNjL2F0aGVyb3NfaGFsL2NvbmYvc3RkLmF0aF9oYWwiKQ0K
--0-985055574-1642959176=:7921
Content-Type: TEXT/PLAIN; charset=US-ASCII; name=boot.cfg
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.NEB.4.64.2201230932561.7921@speedy.whooppee.com>
Content-Description:
Content-Disposition: attachment; filename=boot.cfg
bG9hZD11ZnMNCmxvYWQ9d2FwYmwNCmxvYWQ9ZmZzDQptZW51PUJvb3Qgbm9y
bWFsbHk6cm5kc2VlZCAvdmFyL2RiL2VudHJvcHktZmlsZTtib290DQptZW51
PUJvb3Qgc2luZ2xlIHVzZXI6cm5kc2VlZCAvdmFyL2RiL2VudHJvcHktZmls
ZTtib290IC1zDQptZW51PURyb3AgdG8gYm9vdCBwcm9tcHQ6cHJvbXB0DQpt
ZW51PVJ1biBtZW1vcnkgdGVzdDpib290IC91c3IvcGtnL21kZWMvbWVtdGVz
dHBsdXMNCg0KZGVmYXVsdD0xDQp0aW1lb3V0PTUNCmNsZWFyPTENCg==
--0-985055574-1642959176=:7921--
From: Paul Goyette <paul@whooppee.com>
To: Christos Zoulas <christos@zoulas.com>
Cc: gnats-bugs@netbsd.org
Subject: Re: bin/56643: problem with restore(8)
Date: Sun, 23 Jan 2022 09:45:06 -0800 (PST)
> Attached!
And here are a couple of local changes that make the "push ffs"
stuff work. Please note that you also need to remove UFS_EXTATTR
from the ufs and ffs Makefiles.
===================================================================
RCS file: /cvsroot/src/sys/lib/libsa/ffsv1.c,v
retrieving revision 1.8
diff -u -p -r1.8 ffsv1.c
--- sys/lib/libsa/ffsv1.c 27 May 2021 06:54:44 -0000 1.8
+++ sys/lib/libsa/ffsv1.c 8 Jan 2022 21:10:18 -0000
@@ -19,7 +19,7 @@
#define FS_MAGIC FS_UFS1_MAGIC
-#if 0
+#if 1 /*XXX-PRG 0 */
#define FSMOD "wapbl/ufs/ffs"
#endif
Index: sys/lib/libsa/ffsv2.c
===================================================================
RCS file: /cvsroot/src/sys/lib/libsa/ffsv2.c,v
retrieving revision 1.8
diff -u -p -r1.8 ffsv2.c
--- sys/lib/libsa/ffsv2.c 27 May 2021 06:54:44 -0000 1.8
+++ sys/lib/libsa/ffsv2.c 8 Jan 2022 21:10:20 -0000
@@ -19,7 +19,7 @@
#define FS_MAGIC FS_UFS2_MAGIC
-#if 0
+#if 1 /*XXX-PRG 0 */
#define FSMOD "wapbl/ufs/ffs"
#endif
+--------------------+--------------------------+----------------------+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired) | FA29 0E3B 35AF E8AE 6651 | paul@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoyette@netbsd.org |
| & Network Engineer | | pgoyette99@gmail.com |
+--------------------+--------------------------+----------------------+
From: Christos Zoulas <christos@zoulas.com>
To: gnats-bugs@netbsd.org
Cc: gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org,
paul@whooppee.com
Subject: Re: bin/56643: problem with restore(8)
Date: Mon, 24 Jan 2022 14:49:31 -0500
--Apple-Mail=_3A9FC0F2-4567-417A-921D-98A387CC99B4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=us-ascii
It is still not reproducible for me:
[2:42pm] 2515#dd if=3D/dev/zero of=3Ddisk seek=3D1024k count=3D1
1+0 records in
1+0 records out
512 bytes transferred in 0.002 secs (256000 bytes/sec)
[2:42pm] 2516#vnconfig -c vnd0 disk
[2:43pm] 2517#newfs -O 2 /dev/rvnd0a
/dev/rvnd0a: 512.0MB (1048576 sectors) block size 8192, fragment size =
1024
using 12 cylinder groups of 42.67MB, 5462 blks, 10304 inodes.
super-block backups (for fsck_ffs -b #) at:
144, 87536, 174928, 262320, 349712, 437104, 524496, 611888, 699280, =
786672,
=
..........................................................................=
.....
[2:43pm] 2518#mount /dev/vnd0a /mnt
[2:43pm] 2519#cp -r /bin /mnt
[2:43pm] 2520#umount /mnt
[2:43pm] 2521#dump 0f - /dev/rvnd0a | restore -rf -
DUMP: Date of this level 0 dump: Mon Jan 24 14:44:12 2022
DUMP: Date of last level 0 dump: the epoch
DUMP: Dumping /dev/rvnd0a (an unlisted file system) to standard output
DUMP: Label: none
DUMP: mapping (Pass I) [regular files]
DUMP: mapping (Pass II) [directories]
DUMP: estimated 2629 tape blocks.
DUMP: Volume 1 started at: Mon Jan 24 14:44:12 2022
DUMP: dumping (Pass III) [directories]
DUMP: dumping (Pass IV) [regular files]
DUMP: 2613 tape blocks
DUMP: Volume 1 completed at: Mon Jan 24 14:44:12 2022
DUMP: Date of this level 0 dump: Mon Jan 24 14:44:12 2022
DUMP: Date this dump completed: Mon Jan 24 14:44:12 2022
DUMP: Average transfer rate: 0 KB/s
DUMP: DUMP IS DONE
[2:44pm] 2522#modstat | grep boot
ffs vfs boot - 0 101897 ufs,wapbl
ufs misc boot a 1 84397 wapbl
wapbl vfs boot - 2 22572 -
[2:44pm] 2523#modstat | grep filesys
bpf driver filesys a 0 17596 bpf_filter
bpf_filter misc filesys a 1 2483 -
crypto driver filesys a 0 16313 opencrypto
exec_elf64 exec filesys a 0 5891 -
exec_script exec filesys a 0 1013 -
kernfs vfs filesys a 0 8545 -
opencrypto misc filesys a 1 17031 -
procfs vfs filesys a 0 26838 ptrace_common
ptrace_common exec filesys a 1 7043 -
ptyfs vfs filesys a 0 7390 -
tmpfs vfs filesys a 0 43518 -
vnd driver filesys a 0 12196 zlib
zlib misc filesys a 1 24965 -
[2:44pm] 2524#uname -a
NetBSD mb1.astron.com 9.99.93 NetBSD 9.99.93 (SPEEDY 2022-01-08 03:00:28 =
UTC) #2: Mon Jan 24 14:36:02 EST 2022 =
christos@mb1.astron.com:/usr/src/sys/arch/amd64/compile/SPEEDY amd64
[2:48pm] 2525#
> On Jan 23, 2022, at 12:50 PM, Paul Goyette <paul@whooppee.com> wrote:
>=20
> The following reply was made to PR bin/56643; it has been noted by =
GNATS.
>=20
> From: Paul Goyette <paul@whooppee.com>
> To: Christos Zoulas <christos@zoulas.com>
> Cc: gnats-bugs@netbsd.org
> Subject: Re: bin/56643: problem with restore(8)
> Date: Sun, 23 Jan 2022 09:45:06 -0800 (PST)
>=20
>> Attached!
>=20
> And here are a couple of local changes that make the "push ffs"
> stuff work. Please note that you also need to remove UFS_EXTATTR
> from the ufs and ffs Makefiles.
>=20
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> RCS file: /cvsroot/src/sys/lib/libsa/ffsv1.c,v
> retrieving revision 1.8
> diff -u -p -r1.8 ffsv1.c
> --- sys/lib/libsa/ffsv1.c 27 May 2021 06:54:44 -0000 1.8
> +++ sys/lib/libsa/ffsv1.c 8 Jan 2022 21:10:18 -0000
> @@ -19,7 +19,7 @@
>=20
> #define FS_MAGIC FS_UFS1_MAGIC
>=20
> -#if 0
> +#if 1 /*XXX-PRG 0 */
> #define FSMOD "wapbl/ufs/ffs"
> #endif
>=20
> Index: sys/lib/libsa/ffsv2.c
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> RCS file: /cvsroot/src/sys/lib/libsa/ffsv2.c,v
> retrieving revision 1.8
> diff -u -p -r1.8 ffsv2.c
> --- sys/lib/libsa/ffsv2.c 27 May 2021 06:54:44 -0000 1.8
> +++ sys/lib/libsa/ffsv2.c 8 Jan 2022 21:10:20 -0000
> @@ -19,7 +19,7 @@
>=20
> #define FS_MAGIC FS_UFS2_MAGIC
>=20
> -#if 0
> +#if 1 /*XXX-PRG 0 */
> #define FSMOD "wapbl/ufs/ffs"
> #endif
>=20
>=20
>=20
>=20
> =
+--------------------+--------------------------+----------------------+
> | Paul Goyette | PGP Key fingerprint: | E-mail addresses: =
|
> | (Retired) | FA29 0E3B 35AF E8AE 6651 | paul@whooppee.com =
|
> | Software Developer | 0786 F758 55DE 53BA 7731 | pgoyette@netbsd.org =
|
> | & Network Engineer | | pgoyette99@gmail.com =
|
> =
+--------------------+--------------------------+----------------------+
>=20
--Apple-Mail=_3A9FC0F2-4567-417A-921D-98A387CC99B4
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
iF0EARECAB0WIQS+BJlbqPkO0MDBdsRxESqxbLM7OgUCYe8CzAAKCRBxESqxbLM7
Oh5SAJwJ3U6OBOQt3owbh7mMSQ9uTP1weACfQLxo8NeEvZObmadIB7IszPE4Wy0=
=m1cs
-----END PGP SIGNATURE-----
--Apple-Mail=_3A9FC0F2-4567-417A-921D-98A387CC99B4--
From: Paul Goyette <paul@whooppee.com>
To: Christos Zoulas <christos@zoulas.com>
Cc: gnats-bugs@netbsd.org
Subject: Re: bin/56643: problem with restore(8)
Date: Mon, 24 Jan 2022 12:34:01 -0800 (PST)
Christos Zoulas wrote:
> It is still not reproducible for me:
Yeah, for me using similar commands it does not fail. (I even copied
some files into the input file-system before dumping.)
...
# dump -0f- /mnt | restore -rf-
DUMP: Found /dev/rvnd0a on /mnt in mount table
DUMP: Date of this level 0 dump: Mon Jan 24 12:12:35 2022
DUMP: Date of last level 0 dump: the epoch
DUMP: Dumping /dev/rvnd0a (/mnt) to standard output
DUMP: Label: none
DUMP: mapping (Pass I) [regular files]
DUMP: mapping (Pass II) [directories]
DUMP: estimated 7859 tape blocks.
DUMP: Volume 1 started at: Mon Jan 24 12:12:40 2022
DUMP: dumping (Pass III) [directories]
DUMP: dumping (Pass IV) [regular files]
DUMP: 7809 tape blocks
DUMP: Volume 1 completed at: Mon Jan 24 12:12:40 2022
DUMP: Date of this level 0 dump: Mon Jan 24 12:12:35 2022
DUMP: Date this dump completed: Mon Jan 24 12:12:40 2022
DUMP: Average transfer rate: 0 KB/s
DUMP: DUMP IS DONE
#
HOWEVER, the following sequence still fails:
# dd if=/dev/zero of=TEMP bs=32k count=200000
200000+0 records in
200000+0 records out
6553600000 bytes transferred in 43.794 secs (149646070 bytes/sec)
# vnconfig -c vnd0 TEMP
newfs -O2 vnd0a
/dev/rvnd0a: 6250.0MB (12800000 sectors) block size 16384, fragment size 2048
using 34 cylinder groups of 183.83MB, 11765 blks, 22848 inodes.
super-block backups (for fsck_ffs -b #) at:
160, 376640, 753120, 1129600, 1506080, 1882560, 2259040, 2635520, 3012000,
...............................................................................
# mount /dev/vnd0a /mnt
# cd /mnt
# dump -0f- /var | restore -rf-
DUMP: Found /dev/rwd0e on /var in /etc/fstab
DUMP: Date of this level 0 dump: Mon Jan 24 12:26:14 2022
DUMP: Date of last level 0 dump: the epoch
DUMP: Dumping /dev/rwd0e (/var) to standard output
DUMP: Label: none
DUMP: mapping (Pass I) [regular files]
DUMP: mapping (Pass II) [directories]
DUMP: estimated 1222738 tape blocks.
DUMP: Volume 1 started at: Mon Jan 24 12:26:16 2022
DUMP: dumping (Pass III) [directories]
DUMP: dumping (Pass IV) [regular files]
getfile: lost data
abort? [yn] n
DUMP: 1220386 tape blocks
DUMP: Volume 1 completed at: Mon Jan 24 12:26:48 2022
DUMP: Volume 1 took 0:00:32
DUMP: Volume 1 transfer rate: 38137 KB/s
DUMP: Date of this level 0 dump: Mon Jan 24 12:26:14 2022
DUMP: Date this dump completed: Mon Jan 24 12:26:48 2022
DUMP: Average transfer rate: 38137 KB/s
DUMP: DUMP IS DONE
# dumpfs /var | head
file system: /dev/rwd0e
format FFSv2
endian little-endian
location 65536 (-b 128)
magic 19540119 time Mon Jan 24 12:23:54 2022
...
Note that this time I only get thet "lost data" message once; all
earlier occurrences had _two_ of those messages.
Is there some possibility of debug-printf()s to see details of which
input file is being processed, so we can dump the on-disk structures
from the input volume?
+--------------------+--------------------------+----------------------+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired) | FA29 0E3B 35AF E8AE 6651 | paul@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoyette@netbsd.org |
| & Network Engineer | | pgoyette99@gmail.com |
+--------------------+--------------------------+----------------------+
From: Robert Elz <kre@munnari.OZ.AU>
To: Paul Goyette <paul@whooppee.com>
Cc: gnats-bugs@netbsd.org
Subject: Re: bin/56643: problem with restore(8)
Date: Tue, 25 Jan 2022 05:12:46 +0700
Date: Mon, 24 Jan 2022 20:35:01 +0000 (UTC)
From: Paul Goyette <paul@whooppee.com>
Message-ID: <20220124203501.9EE431A923A@mollari.NetBSD.org>
| Is there some possibility of debug-printf()s to see details of which
| input file is being processed, so we can dump the on-disk structures
| from the input volume?
With or without that, you need to start with a "bad" dump output file that
is stable (no re-generating it for every run ... especially not using
/var whose contents are likely to be different every time).
Ideally the smallest dump you can come up with which exhibits the
problem (since the issue is apparently with dump, once you have that
image, restore should fail on it every time, no matter how or where run).
Then either debug added to restore, or perhaps just running it with -i
instead of -r, might allow the "bad" whatever it is to be located,
and perhaps then it will be possible to examine the relevant data in
the dump file to find out what has gone wrong.
Perhaps even running restore under gdb with a breakpoint on the code
that issues that error might work.
But the bad dump image is where all this starts (if necessary, that could
be exported for someone else to examine, if you get nowhere with it).
kre
From: Paul Goyette <paul@whooppee.com>
To: Christos Zoulas <christos@zoulas.com>
Cc: gnats-bugs@netbsd.org
Subject: Re: bin/56643: problem with restore(8)
Date: Tue, 25 Jan 2022 10:37:32 -0800 (PST)
With a recently-created dump of my /var partition, I was able to
re-run restore(8) with the -v flag, to identify the files that
result in the ``lost data'' messages:
# zcat /$path/var-speedy.dmp.xz | restore -rvf-
...
Make node ./net-snmp
Make node ./net-snmp/mib_indexes
Extract new leaves.
Checkpointing the restore
extract file ./clamav/mirrors.dat
extract file ./clamav/bytecode.cld
extract file ./clamav/daily.cld
extract file ./clamav/main.cld
getfile: lost data
abort? [yn] n
extract file ./yp/Makefile.main
extract file ./yp/Makefile.yp
extract file ./yp/nicknames
...
extract file ./dspam/data/paul/paul.sig/61e3d2fd216486398667488.sig
extract file ./dspam/data/paul/paul.sig/61e3d37746842486620443.sig
extract file ./dspam/data/paul/paul.css
getfile: lost data
abort? [yn] n
extract file ./dspam/data/paul/paul.sig/61e3d4cd200891648685870.sig
extract file ./dspam/data/paul/paul.sig/61e3d53d246142097410548.sig
extract file ./dspam/data/paul/paul.sig/61e3da26173121246939194.sig
...
extract file ./backups/etc/ssh/ssh_host_ed25519_key.pub.current
extract file ./cron/tabs/root
Add links
Set directory mode, owner, and times.
Check the symbol table.
Checkpointing the restore
#
So, the two files are
/var/clamav/main.cld
and /var/dspam/data/paul/paul.css
In the first case, continuing results in processing the first file of
a different directory; in the second case, continuing on processes a
fiel within a subdirectory of the failure (ie, restore normal file
a/b/x then error and continue with a/b/c/y). So in both cases the
error seems to occur on the last normal file of a directory.
There's nothing special (at least, nothing of which I am aware) about
either of these files.
+--------------------+--------------------------+----------------------+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired) | FA29 0E3B 35AF E8AE 6651 | paul@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoyette@netbsd.org |
| & Network Engineer | | pgoyette99@gmail.com |
+--------------------+--------------------------+----------------------+
From: Paul Goyette <paul@whooppee.com>
To: Christos Zoulas <christos@zoulas.com>
Cc: gnats-bugs@netbsd.org
Subject: Re: bin/56643: problem with restore(8)
Date: Tue, 25 Jan 2022 12:07:59 -0800 (PST)
(Logging some IRC debugging to the audit trail)
I did a cross-compare between old/new versions of dump/restore, with
the following results
old_dump | old_restore ---> works
old_dump | new_restore ---> works
new_dump | old_restore ---> works AFAICT but the lost data message
(and check) doesn't exist in old restore
new_dump | new_restore ---> fails as before
I even tried to say 'y' to the "abort" question, and 'y' to the
"dump core" question; here's the backtrace
#0 0x0000776a82b9c04a in _lwp_kill () from /lib/libc.so.12
#1 0x0000776a82b9c59a in abort ()
at /build/netbsd-local/src_ro/lib/libc/stdlib/abort.c:74
#2 0x00000000d6c0dcb4 in panic.cold ()
#3 0x00000000d6c0baa6 in getfile ()
#4 0x00000000d6c0bd32 in extractfile ()
#5 0x00000000d6c05775 in createleaves ()
#6 0x00000000d6c0e1f0 in main ()
I also re-ran both new_dump tests. With new_restore, it checks for
the lost-data condition and result in a "truncated" output file.
With old_restore, the check/message doesn't exist, so restore just
continues; however diff(1) reports that the output file does not
match the input file.
It seems pretty sure that dump(8) is broken in some way.
+--------------------+--------------------------+----------------------+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired) | FA29 0E3B 35AF E8AE 6651 | paul@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoyette@netbsd.org |
| & Network Engineer | | pgoyette99@gmail.com |
+--------------------+--------------------------+----------------------+
From: Paul Goyette <paul@whooppee.com>
To: Christos Zoulas <christos@zoulas.com>
Cc: gnats-bugs@netbsd.org
Subject: Re: bin/56643: problem with restore(8)
Date: Tue, 25 Jan 2022 15:48:25 -0800 (PST)
Perhaps useful information, maybe not.
Looking at the two problem files with fsdb, nothing obvious jumps
out; data looks just fine (to me). (I would be happy to provide
hexdumps of any relevant blocks if someone would tell me how to
identify the specific blocks you want to see!)
First file - /var/clamav/main.cld
# fsdb -n -f /dev/rwd0e
** /dev/rwd0e (NO WRITE)
Editing file system `/dev/rwd0e'
Last Mounted on /var
current inode: directory
I=2 MODE=40755 SIZE=512
MTIME=Jan 18 09:35:13 2022 [344047108 nsec]
CTIME=Jan 18 09:35:13 2022 [344047108 nsec]
ATIME=Jan 25 13:55:00 2022 [38619302 nsec]
BIRTHTIME=Mar 29 21:22:21 2015 [0 nsec]
OWNER=root GRP=wheel LINKCNT=30 FLAGS=0x0 BLKCNT=0x4 GEN=0x23abf369
fsdb (inum: 2)> cd clamav
component `clamav': current inode: directory
I=137472 MODE=40775 SIZE=512
MTIME=Mar 30 11:27:41 2021 [551608860 nsec]
CTIME=Mar 30 11:27:41 2021 [551608860 nsec]
ATIME=Jan 25 11:19:13 2022 [841890356 nsec]
BIRTHTIME=Apr 5 19:27:17 2015 [631076165 nsec]
OWNER=clamav GRP=clamav LINKCNT=2 FLAGS=0x0 BLKCNT=0x4 GEN=0x372c7fe3
fsdb (inum: 137472)> ls
slot 0 ino 137472 reclen 12: directory, `.'
slot 1 ino 2 reclen 168: directory, `..'
slot 2 ino 137476 reclen 20: regular, `mirrors.dat'
slot 3 ino 137495 reclen 20: regular, `daily.cld'
slot 4 ino 137479 reclen 24: regular, `bytecode.cld'
slot 5 ino 160394 reclen 268: regular, `main.cld'
fsdb (inum: 137472)> inode 160394
current inode: regular file
I=160394 MODE=100644 SIZE=307403264
MTIME=Nov 25 17:40:45 2019 [167512080 nsec]
CTIME=Nov 25 17:40:49 2019 [323593359 nsec]
ATIME=Jan 25 11:29:43 2022 [439450410 nsec]
BIRTHTIME=Nov 25 17:40:43 2019 [823315522 nsec]
OWNER=clamav GRP=clamav LINKCNT=1 FLAGS=0x0 BLKCNT=0x92ac0
GEN=0x61593aa1
fsdb (inum: 160394)>
And the second file - /var/dspam/data/paul/paul.css
fsdb (inum: 160394)> inode 2
current inode: directory
I=2 MODE=40755 SIZE=512
MTIME=Jan 18 09:35:13 2022 [344047108 nsec]
CTIME=Jan 18 09:35:13 2022 [344047108 nsec]
ATIME=Jan 25 13:55:00 2022 [38619302 nsec]
BIRTHTIME=Mar 29 21:22:21 2015 [0 nsec]
OWNER=root GRP=wheel LINKCNT=30 FLAGS=0x0 BLKCNT=0x4 GEN=0x23abf369
fsdb (inum: 2)> cd dspam/data/paul
component `dspam': current inode: directory
I=1580928 MODE=40775 SIZE=512
MTIME=May 15 14:30:44 2017 [231013797 nsec]
CTIME=Jan 17 08:24:07 2022 [367337099 nsec]
ATIME=Jan 25 07:52:10 2022 [672468052 nsec]
BIRTHTIME=Dec 14 15:14:25 2015 [176410979 nsec]
OWNER=dspam GRP=www LINKCNT=4 FLAGS=0x0 BLKCNT=0x4 GEN=0x61e635c2
component `data': current inode: directory
I=1580930 MODE=40770 SIZE=512
MTIME=Nov 1 12:10:40 2018 [361447320 nsec]
CTIME=Nov 1 12:10:40 2018 [361447320 nsec]
ATIME=Jan 25 07:52:10 2022 [672485395 nsec]
BIRTHTIME=Dec 18 16:25:23 2015 [573591112 nsec]
OWNER=dspam GRP=www LINKCNT=4 FLAGS=0x0 BLKCNT=0x4 GEN=0x410d77f8
component `paul': current inode: directory
I=1580931 MODE=40770 SIZE=512
MTIME=Jan 25 00:00:00 2022 [713353241 nsec]
CTIME=Jan 25 00:00:00 2022 [713353241 nsec]
ATIME=Jan 25 07:52:10 2022 [672532778 nsec]
BIRTHTIME=Dec 1 19:31:53 2017 [676514239 nsec]
OWNER=dspam GRP=www LINKCNT=3 FLAGS=0x0 BLKCNT=0x4 GEN=0x70dd5cd9
fsdb (inum: 1580931)> ls
slot 0 ino 1580931 reclen 12: directory, `.'
slot 1 ino 1580930 reclen 12: directory, `..'
slot 2 ino 1580932 reclen 20: regular, `paul.lock'
slot 3 ino 1581110 reclen 20: regular, `paul.css'
slot 4 ino 1580935 reclen 20: directory, `paul.sig'
slot 5 ino 1581244 reclen 20: regular, `paul.log'
slot 6 ino 1581607 reclen 408: regular, `.dspam11362.css'
fsdb (inum: 1580931)> inode 1581110
current inode: regular file
I=1581110 MODE=100660 SIZE=341140464
MTIME=Jan 25 15:31:56 2022 [270021489 nsec]
CTIME=Jan 25 15:31:56 2022 [270021489 nsec]
ATIME=Jan 25 15:31:56 2022 [270021489 nsec]
BIRTHTIME=Jan 23 00:15:00 2022 [635505469 nsec]
OWNER=dspam GRP=www LINKCNT=1 FLAGS=0x0 BLKCNT=0xa2c40 GEN=0x301d9073
fsdb (inum: 1581110)>
+--------------------+--------------------------+----------------------+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired) | FA29 0E3B 35AF E8AE 6651 | paul@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoyette@netbsd.org |
| & Network Engineer | | pgoyette99@gmail.com |
+--------------------+--------------------------+----------------------+
From: RVP <rvp@SDF.ORG>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: bin/56643: problem with restore(8)
Date: Wed, 26 Jan 2022 00:26:39 +0000 (UTC)
On Tue, 25 Jan 2022, Paul Goyette wrote:
> First file - /var/clamav/main.cld
>
> I=160394 MODE=100644 SIZE=307403264
>
> And the second file - /var/dspam/data/paul/paul.css
>
> I=1581110 MODE=100660 SIZE=341140464
>
Both of those files are rather large at 300+ MB. Does dump have a
problem with other similarly-sized (or smaller--how much smaller?)
files?
-RVP
From: Paul Goyette <paul@whooppee.com>
To: gnats-bugs@netbsd.org
Cc: gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: bin/56643: problem with restore(8)
Date: Tue, 25 Jan 2022 17:22:51 -0800 (PST)
On Wed, 26 Jan 2022, RVP wrote:
> The following reply was made to PR bin/56643; it has been noted by GNATS.
>
> From: RVP <rvp@SDF.ORG>
> To: gnats-bugs@netbsd.org
> Cc:
> Subject: Re: bin/56643: problem with restore(8)
> Date: Wed, 26 Jan 2022 00:26:39 +0000 (UTC)
>
> On Tue, 25 Jan 2022, Paul Goyette wrote:
>
> > First file - /var/clamav/main.cld
> >
> > I=160394 MODE=100644 SIZE=307403264
> >
> > And the second file - /var/dspam/data/paul/paul.css
> >
> > I=1581110 MODE=100660 SIZE=341140464
> >
>
> Both of those files are rather large at 300+ MB. Does dump have a
> problem with other similarly-sized (or smaller--how much smaller?)
> files?
I've never had any problems with larger or smaller sizes.
+--------------------+--------------------------+----------------------+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired) | FA29 0E3B 35AF E8AE 6651 | paul@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoyette@netbsd.org |
| & Network Engineer | | pgoyette99@gmail.com |
+--------------------+--------------------------+----------------------+
From: "Christos Zoulas" <christos@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/56643 CVS commit: src/sbin/dump
Date: Wed, 26 Jan 2022 15:22:14 -0500
Module Name: src
Committed By: christos
Date: Wed Jan 26 20:22:14 UTC 2022
Modified Files:
src/sbin/dump: traverse.c
Log Message:
PR/56643: Paul Goyette: Disable the last block adjustment for now. It seems
to break restore.
To generate a diff of this commit:
cvs rdiff -u -r1.54 -r1.55 src/sbin/dump/traverse.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
State-Changed-From-To: open->closed
State-Changed-By: pgoyette@NetBSD.org
State-Changed-When: Wed, 26 Jan 2022 22:14:21 +0000
State-Changed-Why:
Problem fixed by Christos's commit. Thanks for quick action.
>Unformatted:
(Contact us)
$NetBSD: query-full-pr,v 1.46 2020/01/03 16:35:01 leot Exp $
$NetBSD: gnats_config.sh,v 1.9 2014/08/02 14:16:04 spz Exp $
Copyright © 1994-2020
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.
Home