Headers problems

Spahn, Daniel dspahn at cuh2a.com
Fri Jun 8 06:54:54 PDT 2007



-----Original Message-----
From: lfs-support-bounces at linuxfromscratch.org [mailto:lfs-support-bounces at linuxfromscratch.org] 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 <ken at linuxfromscratch.org> 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



More information about the lfs-support mailing list