From nobody Thu Jul 14 16:21:00 2022 X-Original-To: dev-commits-src-main@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 4LkKVZ0LCzz3hT2k for ; Thu, 14 Jul 2022 16:21:10 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic301-22.consmr.mail.gq1.yahoo.com (sonic301-22.consmr.mail.gq1.yahoo.com [98.137.64.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 4LkKVX6w5Qz4JBC for ; Thu, 14 Jul 2022 16:21:08 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1657815665; bh=KRj3OQWgtqW99yWl44VXyL1So9IalFigcHfnL3k+GcQ=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=Di5kAG8jkNF2UOJsyRxISiWp8hSf6PIqM1HUgOXFgcbzm1zcSkDUst2C/kXARVXfUyr0DzKb4Y3gJ5J/e/W7DvT43NsexYJ8fAa+bRPfxrLI+gd4UHr+WufIRetG6QEQLQsbtNJ3ZM4nxxQ5ig+MI3pTf3IJQ8v1W1pwYTEWjbKcw9YJgS7iKwlXpy8Qnur7Nr+WYpBXz+1KZTIGavqpKRDDLgFHvm57L3Fz1gRHnGDu3kuCguTOsVTFW5t0xTaDqi+2+AD76ca7pRS+a0O4z9rEB8yInFOphkjxTqlpa4jAgtRFe3HLoqf2yTkE+vhbo2ivPrfThKUlOJes6frbOw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1657815665; bh=i9dL5CUYC/tO+cPFJAHaXyO0ckUh9lbx9Jlw+7+TzpX=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=WohJBG+8crjMx3R/SvSI/lcE4Lo58d8YhmAL8ozZPusBLmbzoNIFKARz77sMAQb+ZxNilcr65kZD4ICfRTSjL4L0Pfte6RzPSnsvIvUUDwq8vSSdofNEbd7sghxCR000bCXUcp3+ZB5iHG2aq0YXHxPe09dS6zToj7hRjEeSC+mzJJ+P2c5NXp0dK5RxW0YOFSHrrtP8xgT0uXFXsa1E7LxHBYhW1jOHEGZd/HnVYGDU//TRkx6IkI+9DJ1quppTzR57uijCuWkyCnWLUajv8dqfTdGLQAib5qyoxnfbhSsue2UZLmm79ftLTx0owLoBk5wdZspQCov9h3G6d91kxw== X-YMail-OSG: uZP4GoMVM1lHfMZnJ1WAod3qncjZG1pPo4egKz_isgzGe5ZhrQZ1UwLA_woLaIe P_9pAMuCdUHJbT.pAr5lOeTqDS9UMVk7.DGHHHWHGXr54zLqpVPXkltrTPE8Hd7u6W5PhlGomwI8 lMEzpvpkwkYkK4TUZtM8pjnRV01CoNeAcWRSvNJA_WPGl45C7YXw8SGWiFAyOt9VI3vIWmUx6hzo znUpGMyqoNG..l7bwCSCAteERLXIBxrLjvN1XoLuz_DM7nt1D5lp8Q6gDzPC.aJ4ICuBB0jvkHzJ LDOn2mt9NAO.Au0.C20mTP5tQGxmZmD7QqJD4Lqo1V2swNlpG2lHlKUAEW6zPa7Axh_qR_yeTG8p kI52l_E5sNzvmmY0Yd_nDhO2EywwleOl9KKaawrp_LYhMlZdXIAHeVfm_Yhd8lQn3Y6YoXAKjJAT Ce2gt.TX0NrcRrtsEi_bRrYG.D9TzrXN0dpXBr7PQQ5mvcIcvHktYdgY3uwioTtmVp8UvmTjYyru vako1AQbYON1pM9xdPICsjm66l1uFvYIgxv18lQsvtgJyKe9GQh4n20lhwPEqV3KHgzlOB7HECHg VuvQafW_jK3y8ViJjTsH1vN7rWcyk3yGJGeELvXSO2kx2hFxmB53VkL0XWflP1y3WdNCg3aJL8jl 9OEbdFGkHRK49010dCVTupljR6P7qXL9Fpj8AFFGVFRwBDH3y.nzDBK7t11Mf5xq2HFqn7hj_eUz MMThme40uZlHnB.VfhgiTI0AaKhKIfMSB5Kn4mIMXSxKQyQt4lSBypUXDfmbXu3FL.Q33RCoe4i4 HR_zVv9mQDkE4.thMPsCrREusKf6jxFg9NXhGIOvw2pECiSlupdL2ftookpl3jlROi3USeCVUxtg GX2r01JYWPYbmwxaxOJ4kI.zckU6fGW2vVVs7iHmQs6Z5Ytsf5noEpD8FbcMYDJsH_fD0s__nvjk zu1kpvhYUFs5TJngE75zSHilXqtckuu0f6HJZDtsAGxFH4ZW2YIu8AHoMSWcvIVEUiUMpZSPVEI0 XZ9fylTOKji5igXxfDqKLSmB823luCEBWShcyXhmx2EUZvkLrMfGPcW.Fkm368gi2bdro6P1TLoy vgJ5vMgJL4cg9krAju7ATfv6.nPb5HPXIK_a3rP2IR0JESxRXu0p0T_UsIIa7JIchfM0rvVqs9dA jZ389UYt57HxzigYEqCDxlAdmfo4tWL6gvCY04_xCFCEtbrlsMnYJl_9bSaTRQ1ToZ_7NfyBpft0 70FVp2AZzqmZRFornhlK4kCli_mg0iw4bDV5k.d17XboVsu66aNe_h7HgTa00pLCIR5Q7Lv3rGUv dWSju9pHo_E1Xfam6QjYwfJl55tUonn6hX1r.J1gIi.68lcgvMcJX_rtt3L0b2BiZf9n4Qhok6ao rq4mQf8UcAMn4X6.DNM0COj7k0t7NCP._q01oGl37kecnT2.KbEjElUfvjD2IVvqimNOcev1qt2D v0OVApE6zhH_CD5lsszBXgjrJvHwEVEx_dsXG06jtoRGIxSFzEhQESaNli_lDjJb7qHu5cv9Rc2U CbEvUUiYjvVkxK0U0dlrUNYlxYCbiEOLD.2EWlArBYrCBy.M9Xp_1heSolDODpFdbdqyZoH57M7S vrZdUustjyffQM7a0vSODlUiKyeq6L7Q_T2qQVRA20Yx0ddYPxn2282SmPjbLxVRL7q3X_NMhEUK sTCfD6n2K8kzrMTyma9vLUZFTuZ0g26wWrN0Y7uRmAmgYItvEkGL4nhn.6lkXvsjaHjCFUWaY3ip 1GAR76m.7INtUA4MH4vzmtezqYbofziq9tuUzx3j.mTnWgExM0nbeIiV0tEqNYmFWK.jJOf.LqQn veyfR82k0iD5c7REcxS656Uxoqf04O8mZCbzq1M8178SojcMZCp6EZej9mqlwXJDm.kP2IZkoZdS cscnW.pKx2RZBzOetciXiviQ0uv95NZKalhebW0_RbhK8xqB.S1HSOb1av5ayE_799qMI.GaQDZU AIH9r0oJvI0uV43q5VqnxZrnR7yCm3glJiE4HkAJBhJ.4NFl7bDkkbRt5g7AdlvuMZ_dqOH2qGW8 CjbhI5snMlgXOgYzNpsBQvaob2f_WDmeYAgi8zKq3BvZCyLYfiGiYZvziJRioV_Nz1YiK.wOF5pg QcTaaWXpZeMOX3x8TT4OHoCG0bQN0ft_3ZERpdo.8zbx3KHYwPC2Eeaz4MJCsO.TkPDGqp2v79EA 5I5iWoDInjG0hBjQOE1kmwzs7jAAO9lLe8ncyyJwMVTIjz9hTCGGXf_Rj0EzZewufKDBPw183fxU vHOsX X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Thu, 14 Jul 2022 16:21:05 +0000 Received: by hermes--production-ne1-7864dcfd54-zcbtw (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 24728e52a986ac94156add5c9050045b; Thu, 14 Jul 2022 16:21:01 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Commit messages for the main branch of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-main List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-src-main@freebsd.org X-BeenThere: dev-commits-src-main@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: git: 1dfcff294e44 - main - release: increase IMAGE_SIZE for arm, arm64, riscv From: Mark Millard In-Reply-To: <20220714152125.GB30607@FreeBSD.org> Date: Thu, 14 Jul 2022 09:21:00 -0700 Cc: dev-commits-src-main@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <3E2DCFBD-CC8F-4C13-B18C-B7DA26ED8E84@yahoo.com> References: <84410D65-6F86-44E5-8B14-8A523C9919C7.ref@yahoo.com> <84410D65-6F86-44E5-8B14-8A523C9919C7@yahoo.com> <20220713201327.GY30607@FreeBSD.org> <7F4F9683-B4DE-4F65-BBD7-027039A0C270@yahoo.com> <20220713204227.GA30607@FreeBSD.org> <8A02A4A4-9F3A-47F2-9985-EA2151043BB7@yahoo.com> <4D903E5A-58FB-4516-AC53-AEDFF48564A7@yahoo.com> <20220714152125.GB30607@FreeBSD.org> To: Glen Barber X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4LkKVX6w5Qz4JBC X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=Di5kAG8j; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.148 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.47 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; NEURAL_HAM_LONG(-0.98)[-0.976]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.148:from]; RCVD_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[yahoo.com]; TO_DN_SOME(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; DKIM_TRACE(0.00)[yahoo.com:+]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[dev-commits-src-main] X-ThisMailContainsUnwantedMimeParts: N On 2022-Jul-14, at 08:21, Glen Barber wrote: > On Thu, Jul 14, 2022 at 08:10:12AM -0700, Mark Millard wrote: > [... snip ...] >=20 >> But it does not appear that modern /usr/src/release/ by itself >> would produce the inefficient alignments unless the mdconfig >> and gpart combination used did something odd overall that >> did not happen in my example sequence. >>=20 >> Here, I'm just using the mismatch to indicate that the snapshot >> and release builds do not seem to match what /usr/src/release/ >> is set up to do. I've not managed to reproduce the alignment >> that the snapshot and release .img files have in them by >> following the /usr/src/release steps for the example Small >> Board Computer that I'm using to illustrate the issue. >>=20 >> It suggests something odd is going on for the official image >> builds that makes the difference. What, I've no clue. >>=20 >=20 > I do not know either, but I have been looking into it. All of the > userland utilities (mkimg, makefs, etc) that are used are used = *within* > the build chroot, so I see no sign of any "leakage" from the build = host > itself creeping into the process. mkimg (via mkisoimages.sh) does not apply to the likes of RPI.conf or the other SBCs: disc1, dvd, and bootonly are not involved but are what use mkisoimages.sh . A similar point goes for use via make-memstick.sh : not involved for SBC contexts list RPI.conf . The same goes for makefs : it is only used via mkisoimages.sh and make-memstick.sh --which are not involved. /usr/main-src/release/release.sh has: /usr/main-src/release/release.sh:chroot_arm_build_release() { that has the code: export mddev=3D$(chroot ${CHROOTDIR} \ mdconfig -f ${IMGBASE##${CHROOTDIR}} ${MD_ARGS}) arm_create_disk arm_install_base arm_install_boot arm_install_uboot mdconfig -d -u ${mddev} and /usr/main-src/release/tools/arm.subr has: arm_create_disk() { # Create the target raw file and temporary work directory. chroot ${CHROOTDIR} gpart create -s ${PART_SCHEME} ${mddev} if [ "${PART_SCHEME}" =3D "GPT" ]; then chroot ${CHROOTDIR} gpart add -t efi -l efi -a 512k -s = ${FAT_SIZE} ${mddev} chroot ${CHROOTDIR} newfs_msdos -L efi -F ${FAT_TYPE} = /dev/${mddev}p1 chroot ${CHROOTDIR} gpart add -t freebsd-ufs -l rootfs = -a 64k ${mddev} chroot ${CHROOTDIR} newfs -U -L rootfs /dev/${mddev}p2 fi if [ "${PART_SCHEME}" =3D "MBR" ]; then chroot ${CHROOTDIR} gpart add -t '!12' -a 512k -s = ${FAT_SIZE} ${mddev} chroot ${CHROOTDIR} gpart set -a active -i 1 ${mddev} chroot ${CHROOTDIR} newfs_msdos -L msdosboot -F = ${FAT_TYPE} /dev/${mddev}s1 chroot ${CHROOTDIR} gpart add -t freebsd ${mddev} chroot ${CHROOTDIR} gpart create -s bsd ${mddev}s2 chroot ${CHROOTDIR} gpart add -t freebsd-ufs -a 64k = ${mddev}s2 chroot ${CHROOTDIR} newfs -U -L rootfs /dev/${mddev}s2a fi return 0 } Out of that, only mdconfig and gpart contribute to the alignment that I've been referencing. newfs_msdos and newfs work just within what they are given, not changing the gpart results, so far as I know. Investigating the mdconfig result in the jail by adding some output might help. Something like adding gpart show's after the gpart create and each gpart add could confirm some of the staging for the SBC images: arm_create_disk() { # Create the target raw file and temporary work directory. chroot ${CHROOTDIR} gpart create -s ${PART_SCHEME} ${mddev} gpart show ${mddev} if [ "${PART_SCHEME}" =3D "GPT" ]; then chroot ${CHROOTDIR} gpart add -t efi -l efi -a 512k -s = ${FAT_SIZE} ${mddev} gpart show ${mddev} chroot ${CHROOTDIR} newfs_msdos -L efi -F ${FAT_TYPE} = /dev/${mddev}p1 chroot ${CHROOTDIR} gpart add -t freebsd-ufs -l rootfs = -a 64k ${mddev} gpart show ${mddev} chroot ${CHROOTDIR} newfs -U -L rootfs /dev/${mddev}p2 fi if [ "${PART_SCHEME}" =3D "MBR" ]; then chroot ${CHROOTDIR} gpart add -t '!12' -a 512k -s = ${FAT_SIZE} ${mddev} gpart show ${mddev} chroot ${CHROOTDIR} gpart set -a active -i 1 ${mddev} chroot ${CHROOTDIR} newfs_msdos -L msdosboot -F = ${FAT_TYPE} /dev/${mddev}s1 chroot ${CHROOTDIR} gpart add -t freebsd ${mddev} gpart show ${mddev} chroot ${CHROOTDIR} gpart create -s bsd ${mddev}s2 chroot ${CHROOTDIR} gpart add -t freebsd-ufs -a 64k = ${mddev}s2 gpart show ${mddev} chroot ${CHROOTDIR} newfs -U -L rootfs /dev/${mddev}s2a fi return 0 } Manual execution of just the commands in question in an interactive instance of the jail could be an alternative (if that makes sense). > Additionally, I double-checked (and triple-checked) the configuration > files used for these builds, and there are no stale artifacts of > overriding IMAGE_SIZE or any other variables - everything sources the > in-tree ${srcdir}/release/${TARGET}/${TARGET_ARCH}.conf (i.e., > release/riscv/riscv64.conf, for example). Again, for what I'm reporting, the: ${srcdir}/release/${TARGET}/${TARGET_ARCH}.conf are not involved. The following are involved: # ls -C1 /usr/main-src/release/[a-r]*/[A-Z]*.conf /usr/main-src/release/arm/GENERICSD.conf /usr/main-src/release/arm/RPI-B.conf /usr/main-src/release/arm64/PINE64-LTS.conf /usr/main-src/release/arm64/PINE64.conf /usr/main-src/release/arm64/PINEBOOK.conf /usr/main-src/release/arm64/ROCK64.conf /usr/main-src/release/arm64/ROCKPRO64.conf /usr/main-src/release/arm64/RPI.conf /usr/main-src/release/riscv/GENERICSD.conf I've been using RPI.conf's context as the example. > That said, there have been a few updates to PR 264032 overnight that = has > lead to some head-scratching. >=20 > By the way, thank you for poking into this in the depth that you had. > It is very much appreciated. =3D=3D=3D Mark Millard marklmi at yahoo.com