Re: [gentoo-user] Multiple Update Issues - what order should things be done?

[Alan McKinnon <alan.mckinnon@gmail.com>]

On Saturday 06 March 2010 01:30:38 Tanstaafl wrote:
> On 3/5/2010 2:20 PM, Alan McKinnon wrote:
> > On Friday 05 March 2010 21:09:33 Tanstaafl wrote:
> >> I had already installed gcc-4.3.4 a while back, but still haven't
> >> switched to it, so currently everything is compiled with 4.1.2.
> > 
> > Then switch to 4.3.4
> 
> Very helpful - not. I don't know if it is safe having userspace lvm2
> tools compiled with a newer/different version of gcc than the kernel
> (which has lvm2 compiled in). Maybe someone here knows - and maybe
> that's why I asked.

user space tools do not interact with kernel internals. They interact through 
an API which is very stable.It's the internal kernel stuff that is unstable.

As a comparison, login does not care what syslogger you use or it's version, 
so you can change them at will. I have used lvm2 on multiple machine over many 
years with multiple versions and multiple compilers. Never had a compatibility 
issue. This is as it should be and the behaviour I expect.

> >> So, what should I do first? Will the new version of lvm2 work ok
> >> with the older kernel?
> > 
> > Dunno, what does the ebuild say?
> 
> I'm a user, not a programmer. I looked in an ebuild once - it was
> interesting, but didn't tell me a whole lot. I also have been bitten
> more than once by major changes to a package that came in a minor
> version bump that wasn't documented in the ebuild or anywhere else, so
> I've learned to be careful, especially where critical system updates are
> concerned (like lvm2, gcc and the kernel).
> 
> My question was directed toward people who use lvm2 and (hopefully) know
> the answer... googling didn't reveal an answer (or at least I didn't
> find the proper incantation)...
> 
> So, again, does anyone know if the new version of lvm2 (with integrated
> device-mapper) will work ok on the 2.6.23 kernel, or is there a minimum
> version required?

Again, this is in the ebuild. You can ignore most of the weird details and 
look for important stuff. Dependencies are in DEPEND, and in the case of the 
latest lvm2, the only important limits are:

!!sys-fs/device-mapper
>=sys-apps/util-linux-2.16

lvm now does device-mapper itself, so you must unmerge device-mapper and merge 
lvm2. These are userspace tools so it's safe, you won't lose data or 
functionality as long as you don't reboot in the middle.

util-linux is pretty normal too, this will be upgraded when you upgrade lvm.

If the gentoo maintainer knows about incompatibilities, they often put it in 
an elog in the ebuild, which displays when the ebuild runs. That doesn't help 
you now, you want to know this before the ebuild runs, not after, so look in 
the ebuild for elog statements. Easily recognisable - large hunks of plain 
text. The only messages there concern baselayout2 - see the end

> >> If so I could switch to gcc-4.3.4, fix/update lvm2, then rebuild
> >> world, then update the kernel later once the boss is ok with it?
> > 
> > Just update the kernel and be done with it. This is the thing to do
> > first and you already know that. So just do it.
> 
> Ever heard of a PHB?
> 
> I don't upgrade the kernel very often, nor have to fix blockers
> manually, so I'd rather ask a few questions (admitting I don't know
> everything - or even much of anything - in the process - try it Alan,
> it's actually quite liberating), and not dig myself into a hole I may
> not be able to dig myself out of easily.
> 
> >> Also - when you switch compilers, do you need to reboot right away
> >> (after rebuilding world (and thus the kernel)?
> > 
> > What does rebooting have to do with the compiler? The compiler only
> > builds code then stops. Rebooting does nothing to it.
> 
> What does your question have to do with mine? Look, I appreciate any
> help I can get here, but try reading the question you're responding to
> if you're going to take the time to respond (you missed the stuff in
> parenthesis)...

You were talking about switching compilers then rebooting. There's no 
requirement for a reboot in that step.

Once you have successfully updated the box and it's kernel, then reboot it to 
load the new kernel, but you can do that step whenever you are ready.

You mention a PHB.

PHB's don't like updates/upgrades - they imagine all kinds of dragons lurking 
inside chips which eat babies etc etc etc. The way out of this is to make the 
problem his problem. Pretty fair, as he caused it.

You get a spare machine and set it up just like the one you plan to update, 
and run tests on that. Make all your mistakes on a test box so they don;t 
happen on a live box. The PHB now has two choices:

1. Not pay for a machine and suffer the consequences if things bork
2. Provide a machine and have proven data to hand to use when authorizing the 
update

All kinds of emotional crap interferes with this process, but it is manifestly 
impossible to get the benefits of both choices. It is impossible in the same 
way that apples do not fall up. Worded correctly, the PHB can be brought to an 
understanding that is he wants certainty, then he must finance it. If he is 
impressed with buzzwords, this is "best practice" and "prod/dev environments".

From what you describe, I recommend you make this pitch first. If it is not 
approved and it goes south it is certainly not your fault anymore.

> 
> On 3/5/2010 3:40 PM, Sebastian Beßler wrote:
> > As far as I read the post from Tanstaafl the question is not if he
> > has to restart after the switch to the new compiler but if he has to
> > restart after the rebuild of world with the new compiler, because he
> > also rebuilds the kernel.
> 
> Exactly - thank you Sebastian...
> 
> > My experience is that you don't need to restart right away after a
> > kernel rebuild as long as you don't want to (re)load modules because
> > that would not do 'cause kernel and modules must both be build with
> > the same compiler to work.
> 
> Interesting - I don't use modules on a server, I only build with with
> what I need compiled in... so no modules/module support at all, but
> that's good to know if I ever decide to use Gentoo on the desktop - thanks.
> 
> > But to be sure it is possible to postpone the kernel rebuild to be
> > near of a time where a restart can be done.
> 
> Yes, that I was planning on doing when I got approval to upgrade the
> kernel, but I figured I'd include the kernel version out of concern for
> the newer version of lvm2...
> 
> I was already leaning toward the kernel upgrade first as being the
> safest solution (then fix lvm2, then switch compilers, update everything
> else, then rebuild world), but I have to justify it to the boss, which
> is why I asked in the first place...


I suspect your kernel/compiler/lvm upgrad will be smooth and trouble-free. If 
the box is old, and you have to switch to openrc/baselayout2, that's where 
your troubles are going to happen. This is a deep change that touches many 
things with lots of configs being updated and things moving around. 

What version of those packages are you running, and what do you plan to 
upgrade to, if at all?





-- 
alan dot mckinnon at gmail dot com