From: Sven Joachim [mailto:svenj...@gmx.de] > On 2013-01-24 14:51 +0100, Mark Allums wrote: > > > Can one do this? Not: Is this easy, but merely: Is this something that is > > feasible? > > > > I have a 32-bit system that I would like to migrate into 64-bitness within > > the same basic framework, within the same "install". That is, can I go from > > > > 32-bit kernel-arch + 32-bit userland => > > 64-bit kernel-arch + 32-bit userland => > > This works just fine (with a few caveats, e.g. virtualbox does _not_ > work with this combination), just install and boot a linux-image-*-amd64 > kernel. I've been running that combination for years. > > > 64-bit kernel-arch + 64-bit userland > > > > within Debian Squeeze or Wheezy, or Bodhi Lucid or Precise? Without a > clean > > install? > > No, this is not really possible, at least not without a high risk of > totally breaking your system. What you _can_ do to minimize downtime is > to run "debootstrap --arch=amd64" in a dedicated filesystem and then > install the same packages as on your i386 system in the chroot (export > the list on i386 with "dpkg --get-selections" and import it on amd64 > with "dpkg --set-selections"), and then copy over your /etc directory > (you need to adapt fstab of course, but no other changes should be > necessary). > > Then you should be able to dual-boot the i386 and amd64 installations, > and you can dispose of the i386 one when you no longer need it. > > > I was thinking that multiarch might help this happen. > > There are two problems with that: > > - Not all packages have been multiarchified, including some important > packages with many reverse dependencies like perl and python. > Crossgrading those will leave you with many broken packages, at least > temporarily. Cross your fingers that apt will show a way out. > > - Apt does not properly support crossgrades, for a package foo which is > not "Multi-Arch: same" it treats foo:i386 and foo:amd64 as two > different, conflicting packages. This means that it will remove > foo:i386 before installing foo:amd64 which obviously does not work for > Essential packages, so you have to crossgrade those with dpkg alone. > This is quite a hassle since you have to install all necessary > libraries beforehand. > > I have crossgraded some packages in i386 chroots that way, but in the > current state of affairs I would definitely _not_ dare to try a full > crossgrade on my main system with almost 2000 installed packages.
Let me give you a scenario. I have a lightweight system using Bodhi 1.x. It has a single disk with no swap in a single partition. I can virtualize it easily. Similar virtual machines are used in a classroom situation, thanks to the simplicity of Virtualbox. Bohdi is the choice because it is based on Ubuntu, but uses Enlightenment to help keep it lean enough to download and install in a virtual machine for a class without dedicating a whole machine to something that you only need for that one class. People can do their homework at home. The professor can set up a special environment that allow everyone to use the same thing and minimize frustration. I want to preserve the environment as much as possible, but 1.) resize the disk image and add swap and a separate /boot and /home partition 2.) upgrade Bohdi to 2.2.x 3.) move from 32-bit to 64-bit. The first I can easily do, disks and partitions are child's play, these days (back up your data!). No. 2, I can do, it is a bit tricky, but it is similar to upgrading Ubuntu. To do it, you can install more Ubuntu infrastructure and use the upgrader, do simply do it the Debian Way, with apt-get upgrade, apt-get dist-upgrade, etc. The third bit is the hard part. I am wondering if I should go from lucid to precise first, or do the 32/64-bit trick first. Or is there a way to do both at once? If I package it into a virtual machine instance, first, then I can snapshot along the way. I can revert the snapshot if I screw it up, and start over. Also, I can then deploy the newly refurbished system as a student virtual machine. I want to go back to native-on-bare-metal, there are ways to do that, too. The scenario is relevant for Debian-User because I want to do something similar with other (Debian) machines and because this is a learning experience for me, and others reading this list might gain something useful as well. Mark -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/005501cdfa4b$b5b19de0$2114d9a0$@allums.com
