Jim Trigg wrote:
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
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

To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-questions" in the body of the message

Reply via email to