Date: Mon, 21 Jul 1997 16:49:40 +0200 (CEST) From: Mikael Karpberg <karpen@ocean.campus.luth.se> To: jkh@time.cdrom.com (Jordan K. Hubbard) Cc: bde@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: /boot.foo madness Message-ID: <199707211449.QAA09651@ocean.campus.luth.se> In-Reply-To: <27686.869491170@time.cdrom.com> from "Jordan K. Hubbard" at "Jul 21, 97 06:19:30 am"
next in thread | previous in thread | raw e-mail | index | archive | help
According to Jordan K. Hubbard: > 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? I think the second alternative sounds ok, with a small change. There should be no problem with the files being in the bindist, should it? In case of an upgrade you simply save those files, if they exist, just like you save /etc, and then in the "post install fixup" you check the "save directory" for those files, and if they exist you move the new files (which might contain something the user may want to see) to /boot.foo.new, and put his old files back into position. Or am I missing something? :-) /Mikael
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199707211449.QAA09651>