Gentoo Archives: gentoo-dev

From: Andrew Cowie <andrew@×××××××××××××××××××.com>
To: gentoo-dev@l.g.o
Subject: [gentoo-dev] Copy on write
Date: Thu, 27 May 2004 04:34:03
1 I'm trying to design a methodology to test major system upgrades.
3 I'll give you the specific case, so that you can work through all the
4 scenarios: Gnome 2.6 has been out for a while, and recently stable in
5 Gentoo x86 [go foser!] However, gnome have released 2.6.1 of many
6 things, which means *bugfixes*. THAT is in ~arch, and I'd like to be
7 able to test it out - and then a) not upgrade from Gnome 2.4.2 b) use
8 Gnome 2.6.0, or c) use Gnome 2.6.1 and make a positive report to Gentoo
9 devs.
11 I had the idea of copying the *entire* system to a spare partition and
12 then chroot'ing into it, similar to the installation sequence. I did
13 some tests, but although the building side of things works, X won't
14 start. Weird {kernel,xfree,?} module issues. [Any idea why X wouldn't
15 start from a chroot? I had dev, proc, sys bind mounted in] For various
16 reasons, booting off of that device/partition isn't practical, and in
17 any case, I'd like a way for the original system to stay extent while
18 the test case is running.
20 I also thought of User Mode Linux, which has a brilliant copy-on-write
21 feature where you can start with an underlying system and then have it
22 write changes, only, to another partition. That would also work in this
23 case, except for the same difficulty - how can one get X running from
24 within a UML instance? Does that even mean anything?
26 Which leads me to wonder - is there a way of doing copy-on-write *not*
27 in UML? Something like mount -o bind, but with COW.
29 While buildpkg means that packages produced can be [re]used in the
30 original system should things work out (and bind-mounting /usr/portage
31 to the chroot worked out nicely to that end), the weakness with Gentoo's
32 packaging system is that ./configure'ing everything means that packages
33 down the dependency tree requiring upgraded libraries to be present,
34 installed, on the build system.
36 As we all know, backing out of something like a Gnome upgrade would be a
37 significant nightmare, hence the desire to test and not be put in a
38 situation of trying to back out.
40 Again, I'm not worried about it *building* - I'm worried about specific
41 use cases for our environment which I really need to test before
42 installing. Using a spare box isn't an option as I travel a great deal,
43 and in this case (ie need to personally inspect graphical) my laptop is
44 it.
46 Thoughts?
48 AfC
50 --
51 Andrew Frederick Cowie
52 Operational Dynamics Consulting Pty Ltd
54 Operations Consulting and Infrastructure Engineering
58 Sydney, New York, Toronto, London
60 --
61 gentoo-dev@g.o mailing list


Subject Author
Re: [gentoo-dev] Copy on write Stuart Herbert <stuart@g.o>
Re: [gentoo-dev] Copy on write Jeff Smelser <tradergt@×××××××.org>
[gentoo-dev] Re: Copy on write sf <sf@×××××.de>
Re: [gentoo-dev] Copy on write Joseph Booker <joe@××××××××××.net>