-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tijnema
Sent: Friday, June 08, 2007 4:46 AM
To: LFS Support List
Subject: Re: Headers problems
On 6/7/07, Ken Moffat <[EMAIL PROTECTED]> wrote:
> On Thu, Jun 07, 2007 at 10:23:33PM +0200, Tijnema wrote:
> >
> > Ok, thanks you both for your replies, i would expect the headers to be
> > upgraded together with the kernel.
>
> No! Please, repeat after me:
> **Only upgrade the headers if you upgrade glibc**
>
> Sometimes, nasty things get sneaked into the kernel (e.g. the udev
> changes around 2.6.15 or thereabouts), but in general you can update
> to a newer kernel without changing userspace - if that wasn't true,
> everybody would be hosed and testing new kernels would be doubly
> hard. You are thinking back to the days when people were misled
> into keeping the kernel source in /usr/src/linux. If you build a
> new kernel, you can unpack it in ~/ (as a user), cat /proc/config.gz
> >.config, make oldconfig and then build it and try it out - if you
> don't like it, go back to the earlier kernel while you sort out any
> problems.
I save my .config file from last build :), so I use that one...
But good to know how everything is now, and not in the old days :P
> > But, you both say that a complete reinstall is recommended when
> > upgrading Glibc, but I guess you both don't have Graphical desktop
> > (X+KDE) and heavy programs (OOo) installed?
> I do have a partial kde install (base, kmix, graphics, utils,
> kaffeine), but as I said earlier I avoid OOo. Oh, and I use the
> gimp, gnumeric, and abiword, plus what I think is xorg-7.2 (maybe
> the occasional versions differ, I find it hard keeping track of the
> versions for xorg).
>
> Dan thinks minor glibc version upgrades (2.3.5 to 2.3.6, maybe 2.6
> to 2.6.1) are ok.
Minor upgrades are more or less bug fixes right? So I think Dan is right.
> > I mean, if I upgrade glibc from 2.5 to 2.6, should I reinstall X, KDE,
> > OOo and about 500 optional dependencies for X and KDE??
> > If so, I won't even think of upgrading glibc :P
> >
> > Tijnema
> If you are going to stay with {,B}LFS long-term, you need to create
> your own build-scripts. In my case, my multilib builds, and
> scripts, are lagging behind (multilib modular X is by no means
> pretty), but for plain 32-bit (or pure64) I only need 5 scripts
> after I've booted (that's somewhere around 185 packages, including a
> chunk of things that aren't in BLFS, plus some extra fonts).
>
> OTOH, I don't build a lot of xorg and nowadays I can't even run twm
> (probably missing old fonts).
>
> ĸen
Yes, I'm staying with BLFS for a long time (forever?), I use it as my
Server, which is my development machine. The problem for upgrading
isn't building the programs itself, but the time it takes to compile,
no matter if it's automated or not, it takes days to recompile all the
stuff I have installed... I'm only at a good old single core AMD
Athlon XP system, which is clocked down to 1.15Ghz with 512MB SD
RAM... and I just can't live without the machine for a few days :P
It's my server for all kind of stuff, data, music, movies, streaming
TV, web, Linux program dev system, etc...
Is there any good way to build the new (B)LFS System next to the old
one and replace it later? So that I can keep all old programs running
fine, and just build the new one. 2 drives,
1st:
/boot (100M)
/ (60GB)
swap (1024 MB)
2nd:
/data (500GB)
So, i just store all data on the 2nd drive as /data, and if it's
needed I can split the / in 2 partitions of both 30GB, that's enough
to keep my whole (B)LFS system on both. The only question is if it
will work, and how to do it.
I'm currently at glibc-2.3.6, and I would love to upgrade it to
glibc-2.6, I just described the first problem, the second problem is
that my server doesn't like working too hard :P If I max load it for
some time, it will reset automatically, I'm still not sure where the
problem is, I think it gets overheated or such, but this means I can't
run GCC4 Test suite while the rest of the system is running, like X,
KDE etc. I don't know if it works when i shut down X/KDE. It's not
loaded at my normal desktop, both shutdown with some kind of error,
but I don't care, because I don't even have a monitor connected to my
server anymore. I'm using it by LAN (SSH/VNC), When I'm using VNC, it
starts ,of course, X and KDE, and I can't shut it down because that
would kill the VNC session. I can't do it through putty either,
because I need to keep the putty window open, and since the test suite
takes a few hours to complete, it is impossible for me to keep the
window open. So this points me to two things,
1) Will build scripts, like you guys use, resume after a PC restart?
Or at least restart from the point the script quit, and not start all
over again?
2) Is there a way to set the max load for the system to lets say 80%,
so I'm sure it won't restart?
Ok, too long email now.. :P
Tijnema
Here is an easy solution to your top scenario:
Run all the compilations first (./configure + make). This will compile all the
software, which is the time-consuming part. Then go back through and run the
make install steps for everything. Remember that all the core dependencies will
still be the old (or "host") system. As long as you are not manually deleting
binaries, you will probably be OK, except for the few packages that have
dependencies on the upgraded system. It's always a risk to upgrade core system
components, linux or otherwise. In a worst-case scenario, you would do the
upgrade twice- the first pass just for the core components, and the second to
make sure that everything is using the core components. Theoretically, this
would upgrade the whole system with minimal downtime. I recommend you create an
image of your tree as a backup in case things get screwed up.
Now for your numbered items:
1) Build scripts start at the beginning and run through to the end. Restarting
a build script that was interrupted by power failure is extremely dangerous
because you don't know how corrupted the compiled binaries may be, or for that
matter, the filesystem.
2) I don't know about load balancing, but look in you kernel options for
various ACPI and hardware monitoring features.... you could probably script
something to switch processor modes or downclock to reduce the system
temperature.
Hopefully some of this will help!
Dan
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
