From nobody Sun Feb 12 05:21:29 2023 X-Original-To: freebsd-arm@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 4PDwnT0mNdz3phfH for ; Sun, 12 Feb 2023 05:21:49 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic309-22.consmr.mail.gq1.yahoo.com (sonic309-22.consmr.mail.gq1.yahoo.com [98.137.65.148]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 4PDwnS4yBzz4MZ1 for ; Sun, 12 Feb 2023 05:21:48 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1676179306; bh=y146pKUmM9u3zL81VMdU5htyghaQkv2b8npfQ4oC2C0=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=bQb2g0oOCtvS0mMGGuwprWWCXXgJuKTwSmE2c1YiE3In60dLHZwzQxCxEubaV79aS/FwVTTgZmyiAK1KYOqnU6l0hf1HHumgbJNWU01XmkcsNfZs6lr85WaHJ4NPRsntsF1rUNdC9Vwuovuhisw3/ThYcaZrzJfQR8E+j9PffMsn+ky+7LJT0VcLbNkniacyBreIcG4PIMHNtFC7SHes4LqX52FrKz1DOYhHs2TpSkLUfCOthVASXW18533m6SpsBIwlulZoZikFliKepkI+cMOe6tuV6R11fcTs1bHY6QeZ8stGAVezDoc6XUYKZFEvD/NXzpVrSBDcfV0QjEQecQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1676179306; bh=XNOKd06w4aoeJwP/gh/rPnCWm5rgF8OTTtOaZTeCoZM=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=iZyk4xX3uGyArMlY3ZJfGooRUWFwxt7eq5COdOfm995TGWF0u/h5KyOXhBvgSQc13rLpKhq7vfbbV9agnP5ipP9r07KgfODfLj0tfpTj1uRqF3wlj6ieW1kAVq1snUAIJvsIdxMSb8XjIxZSjFWtscq8l9D1KEeWUutY/z4KrFZhQqwECKdE0gzo7mUmoyUw7nOtwBR30hmwAXXfHPHFNUiGi9E67A1hJdsLZSyNnOL0OiS7Z88iWLFjz9PrKQM4JX8ny/kWKtjtrYO6T7q17AH/qz+hbfHXMJruqb+OpC/fmR0DXvysOWP26g4brWtQcUwn1LSyII9OlJOTsZPPPQ== X-YMail-OSG: RHycH9sVM1lnoCm1RsUxDmESDtXAmZvclP3FmeUcWNYnE_gQ0VlirQlzwmEAj_u EakyIwMCTPAgwqgReXGU5oKuKOZOdLscD1Lybm9JyVyxShym4sLRCe2wtkGiNnus2Ske6pOaVPIf T3KPA5cQbsWHFR5Z.9CsM84.bCOpu4mrGtrGwTzp03vp0BODApHzSE0DtblgCE1T5nMLJ9OSTkI. nJeWD3Sl72XafUFCyMT0AxZ.S_1kKgNhKfljkqn8.QmbU.waJlO2hwR7j9Tjb3fy4dVC8wRblV_D E1BHtv0KJHcz2cqL2WKi8dUDXxPlVeGElps5U1Gz_unZGNoYtmAOQQylMfhOqQoEAGABMMwglNWz veysL81JD6QvclLZ_L7sbd2MA.PjTuKuAMjYGIKhmXLlD0ajq2vNdkv8t7dONHmdJrHogv2qoW38 r1tKK7ISUtPQ6vyZ4qf11L59bGcCGvAS5NS_3KnxkBFjTVDI6HqGMGU8Wv3oKLepXiGQyGou4gky Ha4Yi1SGWfpcj9.acUFX2XxQtSQu94IT_lydTls_FNirwrkuVnuVAg0jb02MvyT6gETNb.zOuh67 FRXzwntfISfmXKH_BTMjFFL5EanE5k9TsEcmdx9PVGHCvJEiGHetd4Wdmda90Jz1FZm.PZNbPsAk b_2x_O7htrb67SlZVoPCaqXR_Zvz5PiyqMuJF17CoEzUjnxsBkC_cGopu9u6G3XIOUZjxdRkSGk8 Q_tFiBTT17AZrGFJUBQ8ubmiUGui5oQXx7kKagELjR10ZQmfQNsd_4YsqEu_U.DnhIn5FiIk8NFg 5mwHs59RIqhj79iSR4lgpzRvLZ94kufsJPfAIZbk_gUpzmIj6bKHBlu2idi6Eyzf1JB0ONz_9aEh b3TerJErzNApJwakFFAFkd271lrGeNz9Oln9xBOSo3t3ZT70Xh.DGUJQypAchSbRh58ECbpa_kvS mYnApxv7fmAx.PKb5MpCtO4akL1OkTPdP0Pzm5z4Ds.6gQ_V5Px0mSrS8VLUiSWF2OKZemiIw1XZ .mVM3d66LorVm.OqOVuFKVJ1KcvVsAcuIIghN04VXg39NtrVzwxlfVqqBSbrR_OvW0McRERrSOYw B.pj5dl0f0FKIeFZs8J3VqrAr.scQTfIrsgAmjNL8Ri0qDBe.TPJEjs0mOiigak652NWDi0CGriN gWmn54JUOUCQDegjcQwpHSiQffNhWb0FWq.B.oXDP0IKGInDrWAU18lQ6_d1ROGLDDk_M03hARNg moJq72LRqqJSZQzpJ4NNdWQP6BYaxJqX3kWa2.vAtUn9CVqDzH14co3cnUnkbMvTMYkop7QopAt. lzq.szhRS_7__fahS7UgAo2uukc1dlmkBq8hdgWKkYvhq.lybFa7tyO3IBSCOx8ouZ31J8qUzAPI VkLWNVvy63DGBJd6RgdjtgfCxbUWgYieXCvizQB9ChPc4S8eR1vCVXVrSEoZubMB4xJ_bxdIOlPf umBk98NCDfO2tsa1W0dD6wpmofI1gLSY9V7E.u9VJ7dKNei4LUvF25d7R0GsMppt_zIyHfQk1roE .jrJYPa5ayvrszMkV6t.u_xgojb5w_76Np13BIGd48XBKtq7m.ir3inONDPyz3benVkqqkjgnb.W _lsJn0.fh_3eMAEK0FyNphbJaYv_9eYqQRN3HGEMOMltCOC.leJYl_D0tlw5jB3CNpFu64fPwL6_ 6fimevH_8sSExoKlqb4DWS7Uf_7a0HJPEWh2D9fk9rPcmyeennOkDLlMHBjmUNAqGI.4SYNKDzCq .8ZYWUYROygt2hZk.zfuCkAgLkR8fc9m9pUHv6E7MKVT7DjLaJprRQ0kMMUgzBzpMGA16fDe3u8w T9WpE0n0umGr69rj_POM0nqGLAkJkR4SrmXTyKoSgOy9RhADYYCT2gEuQSSoCZkQdEm9iOXTID5h hyeDy0XWaJNpOIvtCvdypy5L4aExPokJP.a2IYrl0.ab1Yhu3joOrpiwsFwKapT1gDRPxPZF7K1I ECGhaZF9KpVvH8wlXZAaCF.SYOyLQYAOcMzFgFgTUelC6sLn6fCErmrjUYXwwaqiiGtcd3ptxUIr 6h0DY.3iXUOp87DlFG_QPlpT.kj9oJDFWUWqmh6KOKgFSAUFsCED2.cnKksou9RS_6tlLJTulFp5 lePjyrwRDfORyk12EFKH0xfdQlra02g_ABiuhTlgoG2VT2hToLRzdQGZF4Qt0zMr9ErayOd9PNWE FrifhZXrXIOBuWTeHlJUZFWKjhitRBjFlk9O_9Xz.W3Ptf0aPUwGE2fmAaLugwJeogFBd31KURpA - X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Sun, 12 Feb 2023 05:21:46 +0000 Received: by hermes--production-ne1-746bc6c6c4-vvpbb (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 9289c65b4ba8d77297a4853a2cb78656; Sun, 12 Feb 2023 05:21:41 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.300.101.1.3\)) Subject: Re: fsck segfaults on rpi3 running 13-stable From: Mark Millard In-Reply-To: <20230212043524.GA19401@www.zefox.net> Date: Sat, 11 Feb 2023 21:21:29 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: 7bit Message-Id: <984314A1-FF42-4F92-A212-6BC0D85CB630@yahoo.com> References: <20230211224057.GA17805@www.zefox.net> <9DC74DD9-9AA1-4822-B425-217AAC7DB3F5@yahoo.com> <20230212043524.GA19401@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3731.300.101.1.3) X-Rspamd-Queue-Id: 4PDwnS4yBzz4MZ1 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Feb 11, 2023, at 20:35, bob prohaska wrote: > On Sat, Feb 11, 2023 at 06:57:41PM -0800, Mark Millard wrote: >> On Feb 11, 2023, at 14:40, bob prohaska wrote: >> >>> While running buildworld on a Pi3 running 13-stable the machine >>> panic'd. On restart using the previous kernel fsck failed with a >>> segfault, which repeated when the disk was moved to a -current Pi3. >>> >>> In single user mode on -current the segfault message is >>> >>> .... >>> 7912408300994173476 BAD I=74682090 >>> 4313599915630302063 BAD I=74682090 >>> -4473632163892877928 BAD I=74682090 >>> 8068741989830080453 BAD I=74682090 >>> 3857159125896022134 BAD I=74682090 >>> -4354179704011695453 BAD I=74682090 >>> 7611175298055105740 BAD I=74682090 >>> 3985638883347136889 BAD I=74682090 >>> -2495754894521232470 BAD I=74682090 >>> 7739654885841380823 BAD I=74682090 >>> INODE CHECK-HASH FAILED I=74999808 OWNER=1842251117 MODE=15044 >>> fsck: /dev/da1s2d: Segmentation fault >>> >>> I gather this like unlikely to be recoverable, but it would be >>> nice to understand what went wrong if possible. >> >> Did it produce a *.core file? >> > > The 13-current host, looking at the 13-stable disk, reports > root@www:~ # savecore -C -v /dev/da1s2b > checking for kernel dump on device /dev/da1s2b > mediasize = 2147483648 bytes > sectorsize = 512 bytes > magic mismatch on last dump header on /dev/da1s2b 14-CURRENT? For system crash dumps, they may need to be handled by the same type of system that produced them. (Thus the "magic mismatch"?) However, I was not actually after that in my question. I was after fsck crash file(s), not system crash information. (Also useful, just for different purposes.) > No dump exists > > Seemingly no file was made, or it got erased amid my fumbling. I was not after the original system crash information in my question. I was after what might have been recorded when fsck was run and failed. So, since you ran a fsck under 14(?)-CURRENT, the file system for 14(?)-CURRENT might have a *.core file from the fsck run. (Unsure for fsck.core vs. fsck_ffs.core as the file name.) This is on a non-corrupted file system. I was avoiding trying to look at files from a corrupted file system. If the fsck failure can be fixed, you might be able to use fsck after it was fixed to repair the file system. The more things done with/to the corrupted file system, the worse its status for analysis or repair after those changes. > The corruption of the ailing disk is almost certainly in some > part of /usr/obj or /usr/src. Is there any subterfuge that > might allow me to simply delete, say, /usr/obj and then let > the buildworld process re-populate it? Something along the > lines of > mount -o force /dev/da1s2d /mnt > and then run > rm -rf /mnt/obj > > then unmount and try fsck again. At this stage there's not much > to be lost.... I'd go for having fsck fixed if you can provide enough context for someone to identify the failure and make a fix. (So: an update to 14(?)-CURRENT.) This presumes that you have the time to wait vs. having to quickly just start over after quickly taking a riskier route if it fails. === Mark Millard marklmi at yahoo.com