[opensuse] Possible openSUSE 12.1 install methodology

newer
[opensuse] google search result...

older
[opensuse] Fwd: this has been how...

Roger Oberholtzer

5 Dec 2011 5 Dec '11

15:55

I would like to install 12.1 on a spare partition in a rather quick manner (meaning little down time for the existing 11.2 system - 12.1 can still take a while to be ready). I would imagine I could install 12.1 from, say, the KDE live CD. Then, boot in to my old 11.2 partition, and then chroot (mounting /proc and all as one does) into the new 12.1 partition and continue adding packages and whatever with zypper? Any gottchas? Perhaps installing something with kernel modules might fail if the install wants to load them. Might I expect any other problems that would make this a painful approach? Yours sincerely, Roger Oberholtzer OPQ Systems / Ramböll RST Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Show replies by date

Dennis Gallien

5 Dec 5 Dec

16:43

On Monday, December 05, 2011 10:55 AM Roger Oberholtzer wrote:

...

I would like to install 12.1 on a spare partition in a rather quick manner (meaning little down time for the existing 11.2 system - 12.1 can still take a while to be ready). I would imagine I could install 12.1 from, say, the KDE live CD. Then, boot in to my old 11.2 partition, and then chroot (mounting /proc and all as one does) into the new 12.1 partition and continue adding packages and whatever with zypper? Any gottchas? Perhaps installing something with kernel modules might fail if the install wants to load them. Might I expect any other problems that would make this a painful approach?

Yours sincerely,

Roger Oberholtzer

I do both a test fresh install as well as a test upgrade simulation on other separate partitions, with every new release. First, I would not use the Live-CD. In the past, I've gotten unexpected results installing from it compared to the DVD. With 12.1 that may not happen, but IMO and IME the DVD is safer. This is especially true if you have other OS's on the machine, in particular Windows. But I have run into other issues in the past too, due to there being less on the CD. Second, you want to be particularly careful with the Boot Loader step. Again, I haven't tried the Live-CD for installation in a while, so frankly I don't remember how much flexibility it provides. But for sure with the DVD, you can enter the Boot Loader dialogue step and, at the minimum, make sure that grub is only installed to the boot sector of the partition you are installing to. If you are comfortable with grub, you can remove all grub installation and take care of that later from your 11.2 production instance. Either way, you are assured that your 11.2 will continue to control booting the machine. Third, in your 11.2 production instance, you need to set up booting the 12.1 partition. There are number of different ways to do this, depending on whether you installed grub to the 12.1 boot sector. If you did, in YaST Boot Loader you can ask it (lower right) to generate a new configuration; if it works right it will find 12.1 and create a "chainloader" stanza in /boot/grub/menu.lst for booting 12.1. Or, if you know the grub syntax, you can add that stanza yourself manually with a text editor as root. With this method, grub in 11.2 is handing off boot control to grub in 12.1, and so the menu.lst file in both installs is being used. Or, if you did not install grub at all with 12.1, you can add a standard "root, "kernel", and "initrd" stanza to your 11.2 menu.lst that will directly boot 12.1. (I don't recall if YaST will suggest this for you as described above, but it's harmless to check.) So with this method grub in 12.1 is not being used at all, and so the 12.1 menu.lst as well is not used. Since I leave my 2 test partitions in place all the time, I find it easiest to just control everything from my single production install. That is, I do not use the chainloader method because a standard boot stanza from the production menu.lst works fine and then I only have to make changes to a single menu.lst. At the same time, I have a 3rd partition which is a backup mirror of my production install; since I use it as a failover it must be bootable by itself and therefore for it I use the chainloader method. You can now boot into 12.1 and use it however you wish, no need for mount -- bind, chroot, etc. You have a fully working 12.1 for clean simulation. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Greg Freemyer

18:41

On Mon, Dec 5, 2011 at 10:55 AM, Roger Oberholtzer wrote:

...

I would like to install 12.1 on a spare partition in a rather quick manner (meaning little down time for the existing 11.2 system - 12.1 can still take a while to be ready). I would imagine I could install 12.1 from, say, the KDE live CD. Then, boot in to my old 11.2 partition, and then chroot (mounting /proc and all as one does) into the new 12.1 partition and continue adding packages and whatever with zypper? Any gottchas? Perhaps installing something with kernel modules might fail if the install wants to load them. Might I expect any other problems that would make this a painful approach?

Yours sincerely,

Roger Oberholtzer

OPQ Systems / Ramböll RST

Roger, Is it feasible to setup your new partition as the OS drive for a virtual machine, then do the full install at whatever pace it needs. (Hours and/or days). Then once your happy with the new installation, convert it to a normal physical install? (I have not done this myself, but it seems fairly straight-forward.) Greg -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Dennis Gallien

19:01

On Monday, December 05, 2011 01:41 PM Greg Freemyer wrote:

...

On Mon, Dec 5, 2011 at 10:55 AM, Roger Oberholtzer wrote:

...
I would like to install 12.1 on a spare partition in a rather quick manner (meaning little down time for the existing 11.2 system - 12.1 can still take a while to be ready). I would imagine I could install 12.1 from, say, the KDE live CD. Then, boot in to my old 11.2 partition, and then chroot (mounting /proc and all as one does) into the new 12.1 partition and continue adding packages and whatever with zypper? Any gottchas? Perhaps installing something with kernel modules might fail if the install wants to load them. Might I expect any other problems that would make this a painful approach?

Yours sincerely,

Roger Oberholtzer

OPQ Systems / Ramböll RST

Roger,

Is it feasible to setup your new partition as the OS drive for a virtual machine, then do the full install at whatever pace it needs. (Hours and/or days).

Then once your happy with the new installation, convert it to a normal physical install?

(I have not done this myself, but it seems fairly straight-forward.)

Roger, I've done as Greg suggested many times. And especially if you already have an easy vm setup like VBox, this can be a good "quick-n-dirty" way to test. The downside to be aware of is that in a vm (varies by which one) some of the hardware is abstracted rather than directly accessed, and hence the installation will "see" not the real hardware but what the vm mgr presents to it, and not use the drivers or kernel modules a real install would. You may encounter this with your graphics, audio, network, etc. A specific example, my system has a on-board jmicron controller for handling IDE, since the chipset only handles SATA. With a VBox or VMware vm, the hard disk is actually just a file on disk; the vm mgr's controller will be something like an ICH6. But the real jmicron controller requires its own kernel module to be loaded from the initrd. Consequently, in this case the vm install does not reveal that the jmicron module will be required if an IDE hard disk is being used nor if the optical drive is IDE rather than SATA. You can give this a try, just be aware that when you go to do the real install, you may encounter something that the vm install did not. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

jdd

19:28

Le 05/12/2011 16:55, Roger Oberholtzer a écrit :

...

I would like to install 12.1 on a spare partition in a rather quick manner

why do you bother really? If you have like it seems a spare partition, you just have to: * remember what is this partition and give it to openSUSE at install time (go to edit partition sheme, ask to use only this partition (format it and format only this one). Swap can be shared. Do not use any other partition, and mount it as / (root) * *important* install the *boot loader* *on your root partition*. Disable all other boot place during 12.1 install like this, you wont be able to boot directly 12.1. If you have an other openSUSE that boot your system, go to his grub config (use yast) and add the new 12.1. It's probably enough to use a link to the config file in 12.1 /boot/grub/menu.lst. But try first to ask (old) yast to give you a new config to see if it sees your new install. as long as you don't install a new boot loader, your system will still boot your old distro, so no real problem. If you happen to understand the brub boot editor, you can easily boot your new distro through it, but is not trivial. In fact it's simpler to do than to explain, if you understand the important part: do *not* install the new boot loader as default jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Roger Oberholtzer

22:26

On Mon, 2011-12-05 at 20:28 +0100, jdd wrote:

...

Le 05/12/2011 16:55, Roger Oberholtzer a écrit :

...
I would like to install 12.1 on a spare partition in a rather quick manner

why do you bother really?

I need to be sure that 12.1 compiles our applications. There are issues, for example, with changes to the IEEE1394 API interface to cameras that we must resolve. After all these things are sorted out, then I can boot and use 12.1. But not before that. I realize a second computer would do the trick. But I like to make problems for myself. It is how I learn, I guess. After 12.1 is working, I will reverse the setup and use the existing 11.2 partition to chroot to and compile apps. Virtual machines are nice and I do use them. But chroot to a partition is also productive for certain tasks. I used to build Gentoo diskless images under SUSE this way.

...

From the comments thus far, it seems the bootloader setup is something I need to watch. Which I will.

-- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Greg Freemyer

23:48

2011/12/5 Roger Oberholtzer :

...

On Mon, 2011-12-05 at 20:28 +0100, jdd wrote:

...
Le 05/12/2011 16:55, Roger Oberholtzer a écrit :

...
I would like to install 12.1 on a spare partition in a rather quick manner

why do you bother really?

I need to be sure that 12.1 compiles our applications. There are issues, for example, with changes to the IEEE1394 API interface to cameras that we must resolve. After all these things are sorted out, then I can boot and use 12.1.

...

osc build list

Roger, You seem to be doing this the hard way. Have you experimented with "osc build"? The opensuse-packaging list is probably the best place to discuss it if you have questions. Or maybe opensuse-buildservice? It does a really nice job of creating a chroot jail to build in. You can tell it which distro you want to build with and it creates a entire build directory tree full of all the relevant tools. It will even check the OBS repos to see if you have all the lastest tools. So if you are building against 12.1 updates as an example, it will pull down any updates your missing. That is it will pull them down into the jail. Not into your main OS. It defaults to building against factory, but it can build against any of the main OBS repos you have registered. With one of my projects: list is not a valid repository, use one of: devel_languages_perl_openSUSE_11.4, devel_languages_perl_openSUSE_12.1, devel_languages_perl_openSUSE_Factory, Fedora_14, openSUSE_11.3, openSUSE_11.4, openSUSE_12.1, openSUSE_Factory, openSUSE_Tumbleweed_standard, security_openSUSE_12.1, security_openSUSE_Factory, SLES_9, SLE_10, SLE_11 ================================ You can easily control which repos are available. Several non-openSUSE repos are available to build against. (Note Fedora in the above list, ubuntu is also in the potential list.). fyi: by default "osc build" needs a public instance of your package at build.opensuse.org, but osc build can also build without having a public copy on build.opensuse.org:

...

osc build --local-package openSUSE_12.1

Should do that for you. Assuming you code is not GPL, it should not be on build.opensuse.org, but that should not stop you from using the great build env. opensuse has created over the years. osc is a opensuse developed tool. You should get to know it a little, but it does so much it can be a bit overwhelming even after you've been using it for a while. Here's the help info for just the build sub-command: =============================================

...

osc help build build: Build a package on your local machine

You need to call the command inside a package directory, which should be a buildsystem checkout. (Local modifications are fine.) The arguments REPOSITORY and ARCH can be taken from the first two columns of the 'osc repos' output. BUILD_DESCR is either a RPM spec file, or a Debian dsc file. The command honours packagecachedir, build-root and build-uid settings in .oscrc, if present. You may want to set su-wrapper = 'sudo' in .oscrc, and configure sudo with option NOPASSWD for /usr/bin/build. If neither --clean nor --noinit is given, build will reuse an existing build-root again, removing unneeded packages and add missing ones. This is usually the fastest option. If the package doesn't exist on the server please use the --local-package option. If the project of the package doesn't exist on the server please use the --alternative-project <alternative-project> option: Example: osc build [OPTS] --alternative-project openSUSE:10.3 standard i586 BUILD_DESCR usage: osc build [OPTS] REPOSITORY ARCH BUILD_DESCR osc build [OPTS] REPOSITORY (ARCH = hostarch, BUILD_DESCR is detected automatically) osc build [OPTS] ARCH (REPOSITORY = build_repository (config option), BUILD_DESCR is detected automatically) osc build [OPTS] BUILD_DESCR (REPOSITORY = build_repository (config option), ARCH = hostarch) osc build [OPTS] (REPOSITORY = build_repository (config option), ARCH = hostarch, BUILD_DESCR is detected automatically) # Note: # Configuration can be overridden by envvars, e.g. # OSC_SU_WRAPPER overrides the setting of su-wrapper. # OSC_BUILD_ROOT overrides the setting of build-root. # OSC_PACKAGECACHEDIR overrides the setting of packagecachedir. Options: -h, --help show this help message and exit --oldpackages=DIR take previous build from DIR (special values: _self, _link) --disable-cpio-bulk-download disable downloading packages as cpio archive from api --release=N set release number of the package to N -b, --baselibs Create -32bit/-64bit/-x86 rpms for other architectures --disable-debuginfo disable build of debuginfo packages -d, --debuginfo also build debuginfo sub-packages --alternative-project=PROJECT specify the build target project --vm-type=TYPE use VM type TYPE (e.g. kvm) --linksources use hard links instead of a deep copied source --local-package build a package which does not exist on the server --build-uid=uid:gid|"caller" specify the numeric uid:gid pair to assign to the unprivileged "abuild" user or use "caller" to use the current user uid:gid --userootforbuild Run build as root. The default is to build as unprivileged user. Note that a line "# norootforbuild" in the spec file will invalidate this option. --define='X Y' define macro X with value Y --without=X disable feature X for build --with=X enable feature X for build --ccache use ccache to speed up rebuilds --icecream=N use N parallel build jobs with icecream -j N, --jobs=N Compile with N jobs --root=ROOT Build in specified directory -x PAC, --extra-pkgs=PAC Add this package when installing the build-root -k DIR, --keep-pkgs=DIR Save built packages into this directory -p DIR, --prefer-pkgs=DIR Prefer packages from this directory when installing the build-root --noservice, --no-service Skip run of local source services as specified in _service file. --no-verify Skip signature verification of packages used for build. (Global config in .oscrc: no_verify) --nochecks, --no-checks Do not run post build checks on the resulting packages. --noinit, --no-init Skip initialization of build root and start with build immediately. --overlay=OVERLAY Copy overlay filesystem to buildroot after installing all RPMs . --rsync-dest=RSYNCDESTPATH Copy folder to buildroot after installing all RPMs. Use together with --rsync-src. This is the path on the TARGET filesystem e.g. /usr/src/packages/BUILD/linux-2.6 . --rsync-src=RSYNCSRCPATH Copy folder to buildroot after installing all RPMs. Use together with --rsync-dest. This is the path on the HOST filesystem e.g. /tmp/linux-kernel-tree. It defines RSYNCDONE 1 . --no-changelog don't update the package changelog from a changes file -l, --preload Preload all files into the chache for offline operation -o, --offline Start with cached prjconf and packages without contacting the api server --clean Delete old build root before initializing it ===================================================== Good Luck Greg -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Roger Oberholtzer

6 Dec 6 Dec

07:40

On Mon, 2011-12-05 at 18:48 -0500, Greg Freemyer wrote:

...

Roger,

You seem to be doing this the hard way.

Have you experimented with "osc build"?

The opensuse-packaging list is probably the best place to discuss it if you have questions. Or maybe opensuse-buildservice?

I already build some things on OBS. Unfortunately, we do use proprietary libraries for things like 3D cameras and the like. We cannot put those in the public OBS. We would need to set up a local one. Still, an interesting idea, I admit.

...

It does a really nice job of creating a chroot jail to build in. You can tell it which distro you want to build with and it creates a entire build directory tree full of all the relevant tools. It will even check the OBS repos to see if you have all the lastest tools. So if you are building against 12.1 updates as an example, it will pull down any updates your missing.

Unfortunately, OBS is limited to (I think) supported openSUSE releases. 11.2 and 10.2 are no longer on that list. We need to maintain build environments for these older releases. I have done this in virtual machines. But it is much easier to have a chroot command in a Makefile than to start and manage a virtual machine to do a build. Especially in a source tree with many subdirectories, any or all of which may be rebuilt. A Makefile knows where it is in the tree and can manage whatever builds are needed. Getting a virtual machine to start and know which task to perform and to return the results integrated in the parent build's logs is not a trivial task. Not to mention that a chroot build does not add the overhead of starting/running a virtual machine each time one types 'make'. I have been toying with the idea of setting up a local OBS. The public one, however, has been fitting the bill quite nicely. So the motivation to do so has not been so great. BTW, thanks for all the info. I will keep this post when I play with a local OBS. Which I know I eventually will. Yours sincerely, Roger Oberholtzer OPQ Systems / Ramböll RST Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Lars Müller

12:03

On Tue, Dec 06, 2011 at 08:40:30AM +0100, Roger Oberholtzer wrote: [ 8< ]

...

Unfortunately, OBS is limited to (I think) supported openSUSE releases. 11.2 and 10.2 are no longer on that list.

Then you need to have an eye on the openSUSE Evergreen approach driven by the community. Well, this would not keep your 10.2 alive. <advertisement> Have you ever had an eye on SUSE Linux Enterprise? </advertisement> Lars -- Lars Müller [ˈlaː(r)z ˈmʏlɐ] Samba Team SUSE Linux, Maxfeldstraße 5, 90409 Nürnberg, Germany

Roger Oberholtzer

12:44

On Tue, 2011-12-06 at 13:03 +0100, Lars Müller wrote:

...

On Tue, Dec 06, 2011 at 08:40:30AM +0100, Roger Oberholtzer wrote: [ 8< ]

...
Unfortunately, OBS is limited to (I think) supported openSUSE releases. 11.2 and 10.2 are no longer on that list.

Then you need to have an eye on the openSUSE Evergreen approach driven by the community. Well, this would not keep your 10.2 alive.

<advertisement> Have you ever had an eye on SUSE Linux Enterprise? </advertisement>

Yes we have. And that does indeed have a longer supported life. But I fear that will only make the locals wait even longer before doing upgrades. We are trying to have a realistic incremental approach. Not quite there yet. Yours sincerely, Roger Oberholtzer OPQ Systems / Ramböll RST Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

jdd

09:01

Le 05/12/2011 23:26, Roger Oberholtzer a écrit :

...

...
why do you bother really?

I need to be sure that 12.1 compiles our applications.

I have sometime langage problems :-(. I just wanted to say that installing 12.1 is easy.

...

...
From the comments thus far, it seems the bootloader setup is something I need to watch. Which I will.

yes simply keep the old bootloader and install 12.1 in the free partition jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Per Jessen

07:23

Roger Oberholtzer wrote:

...

I would like to install 12.1 on a spare partition in a rather quick manner (meaning little down time for the existing 11.2 system - 12.1 can still take a while to be ready). I would imagine I could install 12.1 from, say, the KDE live CD. Then, boot in to my old 11.2 partition, and then chroot (mounting /proc and all as one does) into the new 12.1 partition and continue adding packages and whatever with zypper? Any gottchas?

I'm pretty certain I've done just that in the past, but I don't remember if it meant more problems or not :-) -- Per Jessen, Zürich (4.9°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

4531

Age (days ago)

4532

Last active (days ago)

List overview

Download

11 comments

6 participants

participants (6)

Dennis Gallien
Greg Freemyer
jdd
Lars Müller
Per Jessen
Roger Oberholtzer