From nobody Tue Jul 05 17:51:33 2022 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 026781D1C4CE for ; Tue, 5 Jul 2022 17:53:03 +0000 (UTC) (envelope-from warlock@phouka1.phouka.net) Received: from phouka1.phouka.net (phouka1.phouka.net [107.170.196.116]) (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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "phouka.net", Issuer "Go Daddy Secure Certificate Authority - G2" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Lcqyk0bzRz4stg for ; Tue, 5 Jul 2022 17:53:02 +0000 (UTC) (envelope-from warlock@phouka1.phouka.net) Received: from phouka1.phouka.net (localhost [127.0.0.1]) by phouka1.phouka.net (8.16.1/8.16.1) with ESMTPS id 265HpYUW019839 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 5 Jul 2022 10:51:34 -0700 (PDT) (envelope-from warlock@phouka1.phouka.net) Received: (from warlock@localhost) by phouka1.phouka.net (8.16.1/8.16.1/Submit) id 265HpXIN019838; Tue, 5 Jul 2022 10:51:33 -0700 (PDT) (envelope-from warlock) Date: Tue, 5 Jul 2022 10:51:33 -0700 From: John Kennedy To: "Dr. Rolf Jansen" Cc: freebsd-arm@freebsd.org Subject: Re: Failed to execute custom kernels which where build on a RPi 4 operated by 13.1-RELEASE Message-ID: References: <71D4E84B-5D80-43A5-BE22-8E4F6486B7E4@cyclaero.com> 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 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <71D4E84B-5D80-43A5-BE22-8E4F6486B7E4@cyclaero.com> X-Rspamd-Queue-Id: 4Lcqyk0bzRz4stg X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of warlock@phouka1.phouka.net has no SPF policy when checking 107.170.196.116) smtp.mailfrom=warlock@phouka1.phouka.net X-Spamd-Result: default: False [-1.80 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[phouka.net]; AUTH_NA(1.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-arm]; FORGED_SENDER(0.30)[warlock@phouka.net,warlock@phouka1.phouka.net]; R_SPF_NA(0.00)[no SPF record]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:14061, ipnet:107.170.192.0/18, country:US]; FROM_NEQ_ENVFROM(0.00)[warlock@phouka.net,warlock@phouka1.phouka.net]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On Tue, Jul 05, 2022 at 12:09:57PM -0300, Dr. Rolf Jansen wrote: > I like RELEASE, because with that freebsd-update does work (remember arm64 is 1st tier since v13). Therefore, keeping the system updated is less hassle with RELEASE, compared to STABLE or CURRENT. That said, I kept my BeagleBone Blacks for years on CURRENT without big issues, by using an approach, which I lined out in a BLog post of mine: Yeah, I've been using FreeBSD on RPI's long before tier 1 and when package repos for it were far less certain, so I did it myself. I've got a bunch of one-offs, and you seem to be doing this at scale (and enjoying the benefits of it). For -CURRENT vs -STABLE vs -RELEASE, I was just thinking of what you'd want to file a bug report (after X -STABLE works, -RELEASE missing Y). -CURRENT has never burned me too badly, -STABLE is just closer to -REL. > https://papers.freebsd.org/2021/eurobsdcon/gallatin-netflix-freebsd-400gbps/ > > For me the reason is, if something becomes broken, I switch back to the previous snapshot (using said approach), I report the issue and usually wait one week until it becomes fixed by the next snapshot. Not sure if that's the video you wanted, at least in the context of what I think you're going for in a snapshot. But again, you seem to be doing something at scale with customers so you're not looking for bespoke. I seem to remember that you couldn't upgrade to the ALPHA/BETA/RC/PRE levels, but that may not be true anymore. > > I don't think "downgrading" from 14 to 13 is generally recommended (in > > my case, ZFS options would generally get me, but I believe you said > > you're UFS). > > I hate ZFS. Overly sophisticated for no real benefit. I mention ZFS and UFS in this context because of a bug that Bob Prohaska was running into with UFS superblock corruption. He could see that on his serial console, so probably not your issue. > I don't want to mess around with u-boot. If the stock one does not work, then something is broken and needs to be reported. That said, I don't believe, that the present issue is an u-boot one. I care about uboot (or not) in merely trying to eliminate it as a source of the problem (if it hands it off to FreeBSD, probably FreeBSD's problem but if it doesn't. Again, just thinking of things you'd want in a bug report. > That would be the second step. The first step would be that somebody else confirms my finding that building and running a custom kernel on a stock FreeBSD 13.1-RELEASE on RPi 4 does not work out. And actually that was my initial question. Yeah, guess I can't help you 1:1 there.