You could have dual boot 32 and 64 bits with the 32 bits partition as a chroot inside 64 bits
On 11/13/06, Lennart Sorensen <[EMAIL PROTECTED]> wrote:
On Mon, Nov 13, 2006 at 06:00:32PM +0100, Micha wrote: > That's the very alternative. I'll have to read up this list > a little further to see how much effort it is. The chroot is documented in the amd64 howto for debian. Many people use it and it works quite well. I personally hate rebooting, so a dual boot system is of no interest to me. > ok, but that should not affect a shared /home anyway (as long as i > don't use a ~/bin or something - i use to install additional stuff in > /usr/local/bin or in /opt) Scripts are still ok in ~/bin of course. > My usual configuration is to delete 'obsolete' debs and x64 and x32 > should have different package names. > Actually, i don't know...do they ? Yes the architecture is part of the filename. > and i'm not sure if i like to dare the experiment ;) > because by any logic, you should be right here. > > I keep different kernel.org and debian trees in /usr/src since years, and i'm > working as root more times than as user since years, anyway, i think i am > careful. (And i'll not forget that funny accdident when i moved /bin into some > unknown location deep in the hierarchy :) > They have different naming (linux and lkinux-source), and i use the kernel > compile-in-version feature, and i don't need make-kpkg at all. > I work with some generic symlinks in /boot and i use to boil down any tedious > commandline into a scripted single command, like switching kernels by > modifying the links, or the whole procedure from compiling til final > setup, so usually don't need to change grub menu.lst. > Using make-kpkg for custom compiling creates at least the same amount > of RTFM and maintenance as the kernel.org way, maybe even less... > it's a good tool for debian packages, and automated image update, of course. The thing is that if you used shared /usr/src, then things that debian installs there from both versions would conflict. That's not good for the package system. > The idea is to mount /tmp as tmpfs, and i can't think of any > problem right now. Usually it's only a few M used by desktop > sessions. > > I'll look closely at chroot next, but will at least keep some free space > for now, for going parallel-boot later. Seems reasonable. -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
-- Engañarse por amor es el engaño más terrible; es una pérdida eterna para la que no hay compensación ni en el tiempo ni en la eternidad. Kierkegaard Jaime Ochoa Malagón Integrated Technology Tel: (55) 52 54 26 10