Re: partitioning with dualboot 32 / 64
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 <firstname.lastname@example.org> 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
> I'll look closely at chroot next, but will at least keep some free space
> for now, for going parallel-boot later.
To UNSUBSCRIBE, email to debian-amd64-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact email@example.com
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.
Jaime Ochoa Malagón
Tel: (55) 52 54 26 10