Date: Mon, 2 Oct 2000 14:16:28 +0200 From: Szilveszter Adam <sziszi@petra.hos.u-szeged.hu> To: David Marsh <drmarsh@bigfoot.com> Cc: freebsd-stable@freebsd.org Subject: Re: Order of 'make's in updating from 3.2 -> RELENG_4 Message-ID: <20001002141628.A5850@petra.hos.u-szeged.hu> In-Reply-To: <XFMail.001002001928.drmarsh@bigfoot.com>; from drmarsh@bigfoot.com on Mon, Oct 02, 2000 at 12:19:28AM %2B0100 References: <XFMail.001002001928.drmarsh@bigfoot.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi!
Although I no longer run -STABLE, I will try to help, because I saw no one
to jump up and do it...
On Mon, Oct 02, 2000 at 12:19:28AM +0100, David Marsh wrote:
> I am currently running FreeBSD 3.2, which I installed from the
> distribution CDs.
>
> I would like to update to 4.x (mainly to see if I can get my soundcard
> (SoundBlaster 16 PCI) to work, and because I notice that my system
> can't make some of the newer ports, and, also, "it's about time.." ;-)
OK. So, I will tell you something which may not be much joy to you but I
want you to complete this transition safely.
First you should upgrade to 3.5.1-STABLE (the latest from the RELENG_3
branch) and do an upgrade from there. It may work directly, but it is not
certain. 3.2-RELEASE is relatively old.
> I'm now at the stage where, over the past few days, I have cvsup'ped my
> sources to RELENG_4: because I'm sharing the phone line with others,
> I've been cvsup'ping in "chunks", for about an hour each night (and
> stopping cvsup from the GUI before I hang up, each time), until my
> system is up to date. (I assume that everything is now up to date,
> because if I try to cvsup again, it seems happy that it has
> everything it needs..?
Well... if it fetches nothing more and finishes successfully, then yes.
> My cvsup file fetches 'src-all' with the following settings:
>
> *default host=cvsup.uk.FreeBSD.org
> *default base=/usr/local/etc/cvsup
> *default prefix=/usr
>
> *default release=cvs tag=RELENG_4
> *default delete use-rel-suffix
Seems OK. Apart from the fact that I am not sure, if rebuilding the world is
well supported from non-standard locations (I have never tried it.)
> However, I'm unsure about the following:
>
> ## Export-restricted collections.
> #
> # Only people in the USA and Canada may fetch these collections. If
> # you are not in the USA or Canada, please use the collections in the
> # "secure-supfile" instead.
> #src-crypto
> #src-eBones
> #src-secure
These no longer even exist. Yes, these are now part of src-all. No need to
worry about them:-)
> I have also read the Handbook section on "make world" and
> /usr/src/UPDATING.
>
>
> /usr/src/UPDATING mentions various occasions when changes (after 3.2
> was released) to the sources have required remakes of either the
> kernel or the world, eg:
>
> 19990929 sigset_t change
> 199912xx change from wd to ad
> 20000117 texinfo updated
> (mildly curious why this requires such a 'big fix'?)
because texinfo is one of the tools that is used to build the rest of the
world and the new version was not fully compatible with the previous one.
'Make world' is rather complex and saves people a lot of work when
they do source upgrades. I am not aware of any other OS (free or otherwise)
which would allow you this ease of upgrading.
<marketing plug>
As we have just read on this
list, there was this guy who successfully upgraded his 2.2.5 box to -STABLE
just now and it worked! All others, put that into your binary upgrade
packages and smoke it.
FreeBSD rocks!
</marketing plug>
If you are curious about what happens and how, just "tape" your make
buildworld/installworld session with script(1) and you can see the exact
commands as they were executed. It is also helpful for finding causes of
problems if there were any during the build. (That is why the Handbook
recommends it, too.) You can also look at the Makefiles but it is rather
complex...
On the other hand, you do not need to worry about these items in UPDATING,
because this is more of a changelog than anything else. If you get the
latest source and make world as described there, you will have all previous
changes applied, too. The only things you should look out for are
configuration changes. If UPDATING says that you need add a new option to
your kernel or that you should change one of your config files or similar,
than you should do that (unless later invalidated by another entry. Many of
the entries were temporary. Order is new itmes first, oldest ones at the
bottom. IIRC.)
> This induces a sense of fear that my planned upgrade may be tricker
> (impossible?) than thought. Or, is it the case that these entries *only*
> affect "people upgrading from earlier [than 3.x?] versions of
> -stable/-current" as the file says, and that I don't need to worry
> about these?
As I said, all upgrades are all-inclusive. You get the latest fixes plus all
previous ones. No need to worry. But this is the reason why upgardes across
branch changes (when the first digit of the RELEASE number changes, too) are
only sure to succeed if you first grab the latest of the branch you are on
(in your case, RELENG_3) and upgrade to the new branch.
> How does the change from wd to ad affect me?
> (Is wd still present, so I can worry about changing to ad 'later'?)
IIRC wd is still there, but changing to ad(4) is not difficult. All you do
is make the appropriate devices in /dev with MAKEDEV as described in
UPDATING and then edit the /etc/fstab file and at the next reboot things
will work already the new way. Problems will only arise if you are one of
those unlucky
people, who have the mobo+hdd combos ad(4) does not like, because then full
performance will not be available to you. (AFAIR VIA chipsets were among the
main culprits.) (I have an LX440 mobo and two Quantum HDDs and they work
fine.)
> If I can do an upgrade, when I compare the Handbook and "UPDATING",
> I'm unsure which I should follow with regard to the following conflict
> (I know the Handbook does say that UPDATING normally takes precedence):
The items in UPDATING take precedence over the Handbook because the latter
is a general-purpose document while the former only covers upgrade in this
particular situation. So when the two are not the same, follow the
UPDATING file and you will be safe.
> The Handbook says:
> ------------------
>
> [check /etc/make.conf (I don't have /etc/defaults/make.conf) and
> /etc/groups [done, seem OK]]
>
> cd /usr/src
> make buildworld
> <drop to single-user>
> make installworld
> <use mergemaster (Can I ignore the rest of section 18.4.7??)>
Yes. Careful use of mergemaster(8) will bring all you need.
> <update /dev>
>
>
> *then* make a new kernel
>
> (How? UPDATING also appears to suggest that making the kernel has also
> been split into two build/install parts, or do I use the 'old' way?)
During the upgrade, do as UPDATING says. Later, I think you can choose. (I
run -CURRENT and I still use the 'old' way.)
> UPDATING says:
> --------------
>
> (Under the section "To update from 3.x to 4.x stable")
>
> cd /usr/src
> make buildworld
>
> <follow directions to build/install a kernel>
>
> [Does this mean I should _actually_ build/install a kernel at this point
> (before installworld), as described a couple of paragraphs earlier in
> UPDATING?]
Yes.
> cd /usr/src/sbin/mknod
> make install
>
>
> <follow rebuild disk /dev entries above>
>
> [Could somebody tell me exactly how to convert the pseudocode
> ("list of disk/slices") into what I should type in? I'm always a bit
> fuzzy about how exactly I should refer to disks/slices..
cd /dev
sh ./MAKEDEV all ad0 ad2
sh ./MAKEDEV ad0s1a ad2s1a ad2s2a
Then change all wd* to ad* and all wcd* to acd* in /etc/fstab and there you go.
> My system is currently setup as follows:
> /dev/wd2s2b none swap
> /dev/wd2s2a / ufs
> /dev/wd2s2f /usr ufs
> /dev/wd2s2e /var ufs
> /dev/wcd0c /cdrom cd9660
> #
> /dev/wd0s2a /mnt/bkp ufs
> /dev/wd0s1 /mnt/mfsc msdos
> /dev/wd2s1 /mnt/mfsd msdos
> proc /proc procfs
> (Yes, the disk that FreeBSD is installed on is attached to the primary
> thingie [1] on the second IDE controller. I have "root_disk_unit=2" in
> /boot/loader.conf to enable my boot sequence to work properly. I
> realise that this is a slightly unusual setup, is it likely to cause
> any problems here?
I do not think so.
> [1] My vocabulary has failed me at this time of night: I mean, channel,
> connector, port, whatever-you-call-it..]
So you mean secondary master? Ah, no problem:-)
> reboot
>
> [Does this mean to do a complete and total reboot?
> (ie, shutdown -r, right down to the BIOS starting up again?)]
Yes. When you build a new kernel, you always need a complete reboot.
> <in single user>
> cd /usr/src
> cd gnu/usr.bin/texinfo/install-info
> make install
> cd ../../../..
> ldconfig -R /usr/obj/usr/src/lib/libc
>
> make installworld [5]
>
> [There is no Footnote 5!? :-( ]
:-) Sorry, I cannot say, what Mr. Losh had in mind/was smoking at this
point:-)
> mergemaster [4]
> reboot
> <multi-user>
>
>
>
> The order of installworld, mergemaster, updating /dev, and remaking the
> kernel, are different in the two descriptions.
>
> Should I follow UPDATING as it says?
Yes.
> Is it right to make a new kernel before doing installworld and all the
> rest?
In this situation it is required but if you follow the instructions, there
will be no problem. Otherwise, well I make my kernel last but some people
say that it can cause problems if the new kernel fails and I have a new
world with wich the old kernel cannot work properly. (Normally not an issue
for me because I upgrade every two days or so:-) Again, there is a
suggested way in UPDATING for tracking -STABLE further down the road, I
think you can stick to that.
> Once again, I apologise if these are extraordinarily daft questions.
No probs. As you have done more of this make world stuff, you will get more
confident and be able to help others, too:-) It is not hard, just unusual at
first sight. But you can see OS development at work(tm) as it really goes,
not just the end product in form of next version/new binary
packages/rpms/debs what have you.:-) Welcome to this new world!
> Many thanks for any help/advice!
Your welcome... I hope this was at least in part helpful.
> David.
--
Regards:
Szilveszter ADAM
Szeged University
Szeged Hungary
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20001002141628.A5850>