On Wed, Feb 26, 2003 at 03:46:35PM +0000, Daniel Bye wrote:
Yes, and the suggestions have been to follow the procedure in the handbook or the UPDATING file, as the buildworld process is carefully crafted to be done in that order.
I'm trying to minimize the amount that has to be done in single-user mode (I don't have console access; I have to trust my hosting company's tech support for that part). Is there any serious reason that mergemaster needs to be run in single-user mode?
The canonical answer is "mergemaster can not update files that are in use"
You'll need to trust your own judgement here ... but if you're sure that nobody is altering the files that mergemaster is updating, it will work fine. Depending on your system, it could be possible that while you're merging in new user/groups, some other user is running adduser, and one or the other of your changes will be lost (or worse). This is just an example of what could go wrong. As you go through mergemaster, think logically about your system's setup and whether or not it's safe to update that file. Obviously, "single- user mode" ensures that there's only a single user on the system, and guarantees this, but it's possible (if you know your system and the other potential users) to get away with it. Keep in mind that mergemaster is just a shell script. There's nothing to stop you from reading through it and determining what your risk factor is prior to trying it. (Hopefully Doug Barton won't take this the wrong way, as mergemaster is an _excellent_ shell script)
And _always_ back up /etc before running mergemaster. It only has to save you from a stupid mistake 1 time to be worth it! (I know)
Ideally, I'm trying to get something that needs no operator intervention
during single-user mode. Currently, if mergemaster can be run just
before booting into single-user mode, the operator needs to type one
command ("upgrade", a shell script in /root/bin which runs the fsck,
mount, swapon, cd, make installworld, and fastboot commands).
That sounds like a pretty good setup!
-- Bill Moran Potential Technologies http://www.potentialtech.com
To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-questions" in the body of the message
