Carl Brewer wrote:
Didn't realise it was your first time with etcupdate. I've been using it for a while and mergemaster which is its freebsd counterpart so I'm mostly used to answering its questions. To be fair the system will probably run quite happily with the 6.x binaries and 5.x etc which would give you less state to roll back. Until I got adept with etcupdate I ran systems like that for quite a while.I ran the update last night, initially 5.2 -> 6.1.5, it mostly worked but when I rebooted after etcupdate'ing (which, has a _lot_ of "um? I dunno?" questions!) it wouldn't mount / r/w, kept complaining that /etc/rc.d/swap1 was finding /dev/wd0b busy. I could remount / and then stuff seemed to work ok, but it wouldn't boot up without a manual remount (mount -u -w / ).
I also didn't find it too scary as it a lot like doing a 3 way merge in software development so I have a good understanding of what's going on. I do appreciate its a lot more scary if you don't have a lot of experience with processes like that.
etcupdate doesn't modify /etc/fstab as that's not something that is part of the release distribution. That file gets created by the installation process.
Although I've always got a whole filesystem backup I often explicitly backup /etc before starting the etcupdate process. The first time I did it I actually did it on a copy of /etc rather than the real version just to get familiar with the process.
I normally use the following flags to cut down on the number of questions:-l - This stops etcupdate asking questions about files that haven't changed even if you have modified them locally)
-a - But this is only useful if you have already run etcupdate once on a system.
Going into the process you need to have a good idea of the files you have modified:
At a minimum there will probably be: /etc/master.passwd /etc/group /etc/syslog.conf /etc/newsyslog.confWhen etcupdate reaches one of these files (or anything else it can't tell what to do automatically) its going to ask what it wants.
If you are certain that you haven't modified the file locally then let it install the new file. If you know you have made mods you can let etcupdate merge them or tell it to skip the file. In the skip file case it will leave your original changes intact and leave the distribution version of the file in the tmp directory it creates. You can then manually merge the 2 together using an editor. I tend to do the merge process in etcupdate but if you are unsure that the result makes sense its probably better to skip and do it by hand at the end.
There is one file you probably want to always keep unchanged and thats /etc/rc.conf as there is nothing in the distribution version of that file you are ever going to need. Don't confuse this file with /etc/defaults/rc.conf where you ALWAYS want the distribution version.
Not that I'm aware of but if its failing to mount root read/write it suggests something went wrong with the rc_configured=YES line that has to be in /etc/rc.conf for the system to start multi-user. So I suspect something odd happened when merging rc.conf the wrong way. That would drop the system into single user mode.I don't *think* I let etcupdate modify fstab, it looked the same as the above and /etc/rc.d/swap1 seems also to be the same. Something changed in the way NetBSD mounts swap space between 5 and 6? Or did I stuff up something else?
If you merge in etcupdate remember your change are presented on the left side of the merge/diff and the changes from the upgrade are on the right.
Probably also worth reading the man page for etcupdate as well to see if there is something I've missed. ;)
Mike