From: William Kenworthy <billk@iinet.net.au>
To: gentoo-server@lists.gentoo.org
Subject: Re: [gentoo-server] Challenging Update Question
Date: Tue, 12 Feb 2008 21:18:52 +0900 [thread overview]
Message-ID: <1202818732.31917.42.camel@rattus> (raw)
In-Reply-To: <20080212050049.t5rxg319w8ws4ccs@webmail.collinstarkweather.com>
The other way around - update the toolchain first. That is gcc,
binutils, glibc, ...
When this is all working do a emerge world -ep to make sure everything
is up to date for 2.4 (Dont forget the expat upgrade gotchas - read the
guide!) Use revdep-rebuild liberally!
Then do the kernel and reboot
Then bring up anything that was held back by 2.4.
It will actually be the toolchain (and probably expat) that will cause
the most grief! Stay with a 3.x series gcc until the end - there are
upgrade guides if you want a 4 series, but wait.
I did this some time back on a large system (~1000 packages) and it does
work - and the system can stay online for almost all of it as well. If
you have a relatively small system, it is much easier and quicker as
there are far fewer complications.
BillK
On Tue, 2008-02-12 at 05:00 -0700, Collin Starkweather wrote:
> Quoting "W.Kenworthy" <billk@iinet.net.au>:
>
> > Rebuild/upgrade on the redundant drive in a chroot
> > Rebuild elsewhere (local to you) on similar hardware and copy OS over.
> > I suspect though, that building a new system, getting it working and
> > shipping it as a black box would be the most low risk/effective
> > strategy.
> >
> > Hint:
> > Setup grub to boot either os so local support only has to select which
> > disk to boot from if there is a failure.
>
> Thanks for the advice.
>
> This may seem a novice question, but can you build a 2.6 kernel and
> use it to boot a system built against 2.4? That is, to divide the
> move into two testable components, kernel and everything else,
>
> 1) Build a full new system on the redundant drive with a 2.6 kernel
> 2) Copy *just* the kernel over and test it (with a menu in grub as you
> suggest in case it barfs)
> 3) If the kernel works, then move the rest over
>
> Or does the kernel change enough between major iterations that you'd
> have to, say, rebuild glibc or somesuch?
>
> Cheers,
>
> -Collin
>
> --
> Collin Starkweather, Ph.D.
> http://www.linkedin.com/in/collinstarkweather
>
--
William Kenworthy <billk@iinet.net.au>
Home in Perth!
--
gentoo-server@lists.gentoo.org mailing list
next prev parent reply other threads:[~2008-02-12 12:18 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-12 6:30 [gentoo-server] Challenging Update Question Collin Starkweather
2008-02-12 6:38 ` RijilV
2008-02-12 7:13 ` W.Kenworthy
2008-02-12 12:00 ` Collin Starkweather
2008-02-12 12:17 ` Andrew Gaffney
2008-02-12 12:18 ` William Kenworthy [this message]
2008-02-12 13:13 ` Benjamen R. Meyer
2008-02-12 19:44 ` Randy Barlow
2008-02-12 20:34 ` RijilV
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1202818732.31917.42.camel@rattus \
--to=billk@iinet.net.au \
--cc=gentoo-server@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox