Date: Thu, 2 Jul 2015 02:13:21 +0000 (UTC) From: Glen Barber <gjb@FreeBSD.org> To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: svn commit: r285018 - head/release/tools Message-ID: <201507020213.t622DL3V013324@repo.freebsd.org>
next in thread | raw e-mail | index | archive | help
Author: gjb Date: Thu Jul 2 02:13:20 2015 New Revision: 285018 URL: https://svnweb.freebsd.org/changeset/base/285018 Log: Implement an evil workaround that prevents UFS/MSDOS labels from being written to disk with newfs(8) and newfs_msdosfs(8). When iterating through snapshot builds in serial, it is possible for a build failure to leave stale md(4) devices behind, in some cases, they could have a UFS or MSDOS filesystem label assigned. If the md(4) is not destroyed (or not able to be destroyed, as has happened recently due to my own fault), the filesystem label that already exists can interfere with a new md(4) device that is targeted to have the same label. This behavior, although admittedly a logic error in the wrapper build scripts, has caused intermittent reports (in particular with the armv6 builds) of missing UFS/MSDOSFS labels, causing the image to fallback to the mountroot prompt. This appears to only happen when the backing md(4) device is destroyed before the calling umount(8) on the target mount, after which the UFS/MSDOSFS label persists. The workaround is this: If EVERYTHINGISFINE is set to non-empty value, check for an existing ufs/rootfs and msdosfs/MSDOSBOOT filesystem label in arm_create_disk(), and rm(1) them if they exist. The EVERYTHINGISFINE variable is chosen because it is used in exactly one other place - release/Makefile.mirrors - and there are big scary warnings at the top of that file as well that it should *not* be used under normal circumstances. This should not destroy a build machine that also uses '/dev/ufs/rootfs' as the UFS label, and I have verified in extensive local testing that the destroyed label is recreated when the md(4) is unmounted/mounted, but this really should not be enabled by anyone. Having said all that, I absolutely *do* plan MFC this to stable/10 for the 10.2-RELEASE cycle, as so far, I have only observed this behavior on stable/10, but this is a temporary solution until I can unravel all of the failure paths to properly trap them. MFC after: 3 days Sponsored by: The FreeBSD Foundation Modified: head/release/tools/arm.subr Modified: head/release/tools/arm.subr ============================================================================== --- head/release/tools/arm.subr Wed Jul 1 23:27:01 2015 (r285017) +++ head/release/tools/arm.subr Thu Jul 2 02:13:20 2015 (r285018) @@ -63,6 +63,18 @@ umount_loop() { } arm_create_disk() { + # XXX: This is potentially dangerous, but works around an issue + # properly labeling md(4) devices when the label already + # exists. + # EVERYTHINGISFINE should *never* be set for non-RE use. + # Trust me. I'm an engineer. + if [ ! -z "${EVERYTHINGISFINE}" ]; then + for _label in ufs/rootfs msdosfs/MSDOSBOOT; do + if [ -e "${CHROOTDIR}/dev/${_label}" ]; then + rm ${CHROOTDIR}/dev/${_label} + fi + done + fi # Create the target raw file and temporary work directory. chroot ${CHROOTDIR} gpart create -s ${PART_SCHEME} ${mddev} chroot ${CHROOTDIR} gpart add -t '!12' -a 63 -s ${FAT_SIZE} ${mddev}
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201507020213.t622DL3V013324>