From owner-freebsd-current Mon Jul 21 06:20:25 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id GAA13121 for current-outgoing; Mon, 21 Jul 1997 06:20:25 -0700 (PDT) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id GAA13116; Mon, 21 Jul 1997 06:20:15 -0700 (PDT) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.6/8.6.9) with ESMTP id GAA27690; Mon, 21 Jul 1997 06:19:30 -0700 (PDT) To: bde@freebsd.org cc: current@freebsd.org Subject: /boot.foo madness Date: Mon, 21 Jul 1997 06:19:30 -0700 Message-ID: <27686.869491170@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Because of the introduction of these three files: /boot.config /boot.help /kernel.config New RELENG_2_2 installations now come up with a root filesystem which contains none of these files, resulting in 3 fairly ominous-looking error messages on startup and a complete lack of boot help. This is simply not an acceptable scenario, and the question I'd like to bring before you all is: "How do we want to fix it?" I can think of several ways, all kind of gross. One way would be to install these files along with the boot blocks if they don't already exist in the targetdir, the "pros" of that approach being that you could update your boot blocks and prototype boot configuration files in one place, plus it'd wind up in the bindist(s) by default. The #1 con of this idea is that it's truly gross to contemplate install rules writing into /, plus you'd have a staleness problem as things changed. Updating /etc is enough of an established no-no, now we're talking about installing things straight into the root dir? Surely the beginning of the end, that would be. Another way would be to artificially create these files in the bin dist(s) through the efforts of one of the release building rules in /usr/src/release/Makefile. This would allow us to get away with not modifying anybody's install rules at the expense of yet more confusing "magic" inside of /usr/src/release/Makefile Either approach which splats things into the bindist also runs the risk of blowing away your configuration data during an upgrade, since that would involve copying another bindist over the old, and that's why the 3rd and perhaps least offensive alternative is to put this into the "post-install fixup" procedure in sysinstall which puts the last few finishing and somewhat kludgy touches on an extracted bin dist. This could then intelligently add the files if they did not already exist. Comments? Jordan