[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: partitioning with dualboot 32 / 64

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

Reply to: