Re: HEADS UP: you need to install a new kernel before an installworld.
On Wed, Oct 30, 2002 at 01:14 -0700, M. Warner Losh wrote:
>
> UPDATING has the closest thing to a comprehensive guide. As far as I
> can tell, it is definitive in its list of potential issues, but if I'm
> wrong, let me know.
>
> I'm just glad I don't have to document all the things that mergemaster
> does.
[ late reply, I know -- catching up with the -current ML traffic ]
May I remind you of the docs/40851 PR ([PATCH] "mergemaster -p" in
UPDATING's "COMMON ITEMS" section)? From the PR's description:
| UPDATING in -STABLE does not mention the needed "mergemaster -p"
| step in its COMMON ITEMS section. UPDATING in -CURRENT seems to
| have the "mergemaster -p" invocation in the wrong place.
And if I may add: One should run the mergemaster script which
lives in the source tree since the installed one (the one found
in $PATH when a short command is given) might not be up to date
or even can be inappropriate or wrong when operating on a new
source tree.
Calling the script from the source tree will work as long as it
is self contained (does not need other source which is not
installed yet but merely uses system commands from the environment
it is running in). Installing the script before calling it (using
$PATH) might be more robust for the future. In this case the
"make install; mergemaster [opt]" sequence should be included in
the COMMON ITEMS section (yes, I know it's among the MMDD
entries, but this might not be enough when this command is
considered part of the general and regular sequence of updating
steps).
The manpage says about the -p option:
| .It Fl p
| Pre-buildworld mode.
| Compares only files known to be essential to the success of
| {build|install}world,
| including
| .Pa /etc/make.conf .
that's why I suggest moving the "mergemaster -p" invocation up
before the buildworld step when we talk about robustness of the
updating sequence. We might have gotten away with what we did
up to now, but I wouldn't count on it to always succeed ...
I just checked against my local CVS repo (revs 1.73.2.76 and 1.228
of UPDATING) and the PR's issues still apply.
virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76
Gerhard Sittig true | mail -s "get gpg key" [EMAIL PROTECTED]
--
If you don't understand or are scared by any of the above
ask your parents or an adult to help you.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: you need to install a new kernel before an installworld.
If memory serves me right, Doug Barton wrote: > This should go on the "Comprehensive guide to updating from source to 5.0" > that I'm sure our trusty release engineers are producing? Some of this is described in the early adopter's guide (still a work in progress) that I committed to the release documentation set a few days ago. It refers to src/UPDATING for the source-upgrade-from-4.X steps, but several people have suggested bringing this material into the document. I'm open to that, but first: 1) I'd like the content to settle a bit first, 2) I need to find time to do this. #2 is less of an issue if someone else wants to help out. Cheers, Bruce. msg45567/pgp0.pgp Description: PGP signature
Re: HEADS UP: you need to install a new kernel before an installworld.
IMO it's more a matter of POLA for those upgrading to -current for the first time. For those that don't realize exactly how different 5.x is, spelling out the steps of installing device.hints, installing the new loader, etc. makes their life easier. This should go on the "Comprehensive guide to updating from source to 5.0" that I'm sure our trusty release engineers are producing? -- "We have known freedom's price. We have shown freedom's power. And in this great conflict, ... we will see freedom's victory." - George W. Bush, President of the United States State of the Union, January 28, 2002 Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: you need to install a new kernel before an installworld.
< said: > /boot/loader though is a different story. 'make installkernel' does not > install the new loader. However, most non-ancient 4.x loaders can > boot a 5.x kernel sufficiently well that this shouldn't be a crisis. Or, > they used to be able to when I last tried it (not too long ago). As noted, it worked for me as recently as Thursday. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: you need to install a new kernel before an installworld.
"M. Warner Losh" wrote: > In message: <[EMAIL PROTECTED]> > Tim Kientzle <[EMAIL PROTECTED]> writes: > : Peter Wemm wrote: > : > : > 'make installworld' without ... a new kernel would be rather messy. > : > : > ... a reminder of the sequence is probably in order: > : > buildworld > : > buildkernel > : > installkernel > : > reboot > : > installworld > : > reboot > : > : > : This _does_not_work_ because 'installkernel' does > : not update the bootblocks. It should. Otherwise, > : 'installkernel' is not filling it's contract: it is > : not ensuring that the next boot uses the new kernel. > > Are you sure you need new bootblocks? I've not had issues and am > pretty careless about when I do installworld vs installkernel. > > You need them for the 4.x -> 5.0 upgrade, but I didn't think you've > needed new ones for a long time now. If it does need them, somebody had better tell my systems. I've got old 3.x bootblocks on some of them. /boot/loader though is a different story. 'make installkernel' does not install the new loader. However, most non-ancient 4.x loaders can boot a 5.x kernel sufficiently well that this shouldn't be a crisis. Or, they used to be able to when I last tried it (not too long ago). Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: you need to install a new kernel before an installworld.
On Mon, Oct 28, 2002 at 11:56:34AM -0800, Tim Kientzle wrote: > M. Warner Losh wrote: > > >Tim Kientzle <[EMAIL PROTECTED]> writes: > > >: ... 'installkernel' is not filling it's contract: it is > >: not ensuring that the next boot uses the new kernel. > > > >Are you sure you need new bootblocks? I've not had issues and am > >pretty careless about when I do installworld vs installkernel. > > > >You need them for the 4.x -> 5.0 upgrade, but I didn't think you've > >needed new ones for a long time now. > > In case you've forgotten, in another month or two, > thousands of people are going to be upgrading > from 4.x -> 5.0. Those are going to be people > who don't regularly read -current or even -stable. > The upgrade process right now is getting pretty > ugly and needs to be cleaned up some before > release. > Peter's comments that started this thread included info for people *already* running -current. He simply reviewed the *standard* procedure for updating a -current system. He was not addressing the 4.x to 5.0 upgrade path. Installing new boot blocks is a one time issue and it is not part of the standard updating procedure. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: you need to install a new kernel before an installworld.
M. Warner Losh wrote: Tim Kientzle <[EMAIL PROTECTED]> writes: : ... 'installkernel' is not filling it's contract: it is : not ensuring that the next boot uses the new kernel. Are you sure you need new bootblocks? I've not had issues and am pretty careless about when I do installworld vs installkernel. You need them for the 4.x -> 5.0 upgrade, but I didn't think you've needed new ones for a long time now. In case you've forgotten, in another month or two, thousands of people are going to be upgrading from 4.x -> 5.0. Those are going to be people who don't regularly read -current or even -stable. The upgrade process right now is getting pretty ugly and needs to be cleaned up some before release. Tim Kientzle To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: you need to install a new kernel before an installworld.
Juli Mallett wrote: * De: Patrick Hartling <[EMAIL PROTECTED]> [ Data: 2002-10-28 ] [ Subjecte: Re: HEADS UP: you need to install a new kernel before an installworld. ] Peter Wemm wrote: Due to sigaction(2) syscall number changes, doing a 'make installworld' without having booted a new kernel would be rather messy. For example, if you tried to reboot with the old kernel, /sbin/init and /bin/sh would get a signal and abort. That would be bad. Does this apply to ports as well? GNOME applications have started crashing a lot all of a sudden after updating my kernel (I haven't done 'installworld' yet). Do I need to rebuild all the GNOME stuff, or should I just back off to my previous kernel and wait a little while longer before doing another cvsup? Really? My GNOME apps built from 2 months (up to 2 hours) ago have been working better as I run kernel+world nearer to the impending release. Mine had been working quite well up until this weekend. Only two things changed on my system: the kernel and the freetype2 port version (it's now freetype2-2.1.2_1). I'm running GNOME 2.0, so it may have some instability due to growing pains. However, I have been running GNOME 2 since the (excellent) ports team got it working on FreeBSD--the problems only began this weekend. What sorts of problems are you running into? Nearly all GNOME applications crash with an "Abort trap" error, and the only way I can log out is to restart the X server. Nautilus is particularly evil because it can get into a situation where it crashes, restarts itself, and crashes again--repeating the process indefinitely. > Also, how old was your kernel, and how old is your userland? Userland and old kernel are from October 13. I built the new kernel Friday evening. I booted my Oct 13 kernel this morning, and the GNOME crashes are persisting, so I think my original diagnosis was wrong. I think I'll try to back off to the previous freetype2 revision and see if that fixes things. > With no more info, I'd prolly advise you to update everything to the latest, and if problems persist, rebuild your GNOME stuff, and if problems persist, throw exception... I may do so if backing off freetype2 doesn't fix things. But the latter bits of that are a bit drastic, depending on the hw! I'll manage. :) These are the pains of living on the bleeding edge. -Patrick -- Patrick L. Hartling | Research Assistant, VRAC [EMAIL PROTECTED]| 2274 Howe Hall Room 2624 PGP: http://www.137.org/patrick/pgp.txt | T: +1.515.294.4916 http://www.137.org/patrick/ | http://www.vrac.iastate.edu/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: you need to install a new kernel before an installworld.
* De: Patrick Hartling <[EMAIL PROTECTED]> [ Data: 2002-10-28 ] [ Subjecte: Re: HEADS UP: you need to install a new kernel before an installworld. ] > Peter Wemm wrote: > > Due to sigaction(2) syscall number changes, doing a 'make installworld' > > without having booted a new kernel would be rather messy. For example, if > > you tried to reboot with the old kernel, /sbin/init and /bin/sh would get a > > signal and abort. That would be bad. > > Does this apply to ports as well? GNOME applications have started > crashing a lot all of a sudden after updating my kernel (I haven't done > 'installworld' yet). Do I need to rebuild all the GNOME stuff, or > should I just back off to my previous kernel and wait a little while > longer before doing another cvsup? Really? My GNOME apps built from 2 months (up to 2 hours) ago have been working better as I run kernel+world nearer to the impending release. What sorts of problems are you running into? Also, how old was your kernel, and how old is your userland? With no more info, I'd prolly advise you to update everything to the latest, and if problems persist, rebuild your GNOME stuff, and if problems persist, throw exception... But the latter bits of that are a bit drastic, depending on the hw! -- Juli Mallett <[EMAIL PROTECTED]> | FreeBSD: The Power To Serve Will break world for fulltime employment. | finger [EMAIL PROTECTED] http://people.FreeBSD.org/~jmallett/ | Support my FreeBSD hacking! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: you need to install a new kernel before an installworld.
Peter Wemm wrote: Due to sigaction(2) syscall number changes, doing a 'make installworld' without having booted a new kernel would be rather messy. For example, if you tried to reboot with the old kernel, /sbin/init and /bin/sh would get a signal and abort. That would be bad. Does this apply to ports as well? GNOME applications have started crashing a lot all of a sudden after updating my kernel (I haven't done 'installworld' yet). Do I need to rebuild all the GNOME stuff, or should I just back off to my previous kernel and wait a little while longer before doing another cvsup? -Patrick -- Patrick L. Hartling | Research Assistant, VRAC [EMAIL PROTECTED]| 2274 Howe Hall Room 2624 PGP: http://www.137.org/patrick/pgp.txt | T: +1.515.294.4916 http://www.137.org/patrick/ | http://www.vrac.iastate.edu/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: you need to install a new kernel before an installworld.
On Sat, Oct 26, 2002 at 11:42:02AM -0700, Tim Kientzle wrote: > Peter Wemm wrote: > > >'make installworld' without ... a new kernel would be rather messy. > > >... a reminder of the sequence is probably in order: > > buildworld > > buildkernel > > installkernel > > reboot > > installworld > > reboot > > > This _does_not_work_ because 'installkernel' does > not update the bootblocks. It should. Otherwise, > 'installkernel' is not filling it's contract: it is > not ensuring that the next boot uses the new kernel. It works fine if you are already running 5.x with the newer bootblocks. You should only have to do the bootblock update once. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: you need to install a new kernel before an installworld.
Quoting Tim Kientzle <[EMAIL PROTECTED]>: | Peter Wemm wrote: | | > 'make installworld' without ... a new kernel would be rather messy. | | > ... a reminder of the sequence is probably in order: | > buildworld | > buildkernel | > installkernel | > reboot | > installworld | > reboot | | | This _does_not_work_ because 'installkernel' does | not update the bootblocks. It should. Otherwise, | 'installkernel' is not filling it's contract: it is | not ensuring that the next boot uses the new kernel. | It has worked for me this morning. I seem to have successfully installed and rebooted 3 vastly different machines. Laptop, desktop and a scsi, raid10, server, with no noticable problems. Now you've made me very nervious ;-) ed | An alternative: have installkernel link the new kernel | file back to the old location, at least until 5.1. | That way, either old or new boot blocks would boot | the new kernel. (This may be the better approach | all around; it leaves the downgrade option available | for a little bit longer.) | | Tim Kientzle | | | | | To Unsubscribe: send mail to [EMAIL PROTECTED] | with "unsubscribe freebsd-current" in the body of the message | -- - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: you need to install a new kernel before an installworld.
Peter Wemm wrote: 'make installworld' without ... a new kernel would be rather messy. ... a reminder of the sequence is probably in order: buildworld buildkernel installkernel reboot installworld reboot This _does_not_work_ because 'installkernel' does not update the bootblocks. It should. Otherwise, 'installkernel' is not filling it's contract: it is not ensuring that the next boot uses the new kernel. An alternative: have installkernel link the new kernel file back to the old location, at least until 5.1. That way, either old or new boot blocks would boot the new kernel. (This may be the better approach all around; it leaves the downgrade option available for a little bit longer.) Tim Kientzle To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
HEADS UP: you need to install a new kernel before an installworld.
Due to sigaction(2) syscall number changes, doing a 'make installworld' without having booted a new kernel would be rather messy. For example, if you tried to reboot with the old kernel, /sbin/init and /bin/sh would get a signal and abort. That would be bad. I've added an anti-foot-shooting device to Makefile.inc1 to try and prevent disasters like this. For folks using the *world/*kernel procedure, a reminder of the sequence is probably in order: buildworld buildkernel installkernel reboot installworld reboot You may prefer to avoid building world for a few days and use the newer kernel on its own. Once you've done an installworld, you cannot go back to any previous kernel.old that you may have laying around. For this reason, you probably want to delay an installworld until you are comfortable that your newer kernel builds are satisfactory. options COMPAT_FREEBSD4 is necessary for running older 5.x binaries. For now (an additional anti-foot-shooting measure), I've made it yell loudly if you leave it out. If you try hard enough (read the code), you can turn it off if you really want and if you are really sure that you have no more 4.x or old 5.x binaries around in /usr/local etc. options COMPAT_43 is checked at compile time on the alpha now. It is still compulsory until somebody fixes longjmp in libc to use ucontext_t instead of struct osigcontext. This really needs to be done before 5.0 is released. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
