Re: partitioning with dualboot 32 / 64
Lennart Sorensen <lsorense@csclub.uwaterloo.ca> writes:
> On Mon, Nov 13, 2006 at 03:22:00PM +0100, Micha wrote:
>> I'm going to install debian etch on AMD64 debian, from scratch on a
>> clean HD, and i intend to prepare partitions for an additional x32
>> install which i may decide to add later, depending on my experiences,
>> just as a fallback. I will use the same apps, and both would be Debian
>> Sid, updated daily or right after booting.
>> I like to hear your opinion if that's worth the effort, and if i should
>> try to balance redundancy and maintenance costs ?
>
> I would think it was much better to just install the 64bit and then
> install a 32bit in a chroot. That keeps both available at the same time
> (since a 64bit kernel will run both).
If at all. The only thing I did with my 32bit chroot in the last year
is run mplayer, aviplay or xine for when I needed some non-free codec
the amd64 players can't have.
>> The first consideration is, in how far would a debian sid x64
>> installation differ from the analog x32 install at all ? Can i track it
>> down to some few directories, like /bin, /sbin, /lib ... what else?
>> Then i would ask if it's possible to boot into the same 'stub' root
>> system (if we can call it still that) and mount the missing directories
>> according to the chosen kernel - via initrd, and maybe some custom
>> script. Possible ? Impossible ? Useless ? I've no idea.
That is definetly a possibility.
Create /mnt/both-usr/i386, /mnt/both-usr/amd64 and /mnt/both-usr/both.
mount --bind /mnt/both-usr/i386 /usr
or
mount --bind /mnt/both-usr/i386 /usr
depending on the arch (via fstab)
Write a script that generates a md5sum for every file under /usr/ for
both archs. For every matching file move the file into
/mnt/both-usr/both and create hardlinks in /mnt/both-usr/i386 and
/mnt/both-usr/amd64. (Or compare size and then content for each file
that exists in both.) That should give you as much benefit as sharing
/usr/share suggested below without any of the problems.
Only do this for /usr. It is not worth for /etc, /bin, /sbin, ... as
you get problems having them on a seperate partition. You would really
need custom initrd then. Not impossible and probably takes just a few
minutes (hours, weeks) to understand mkinitramfs or yarid or whatever
your favourite tool is. But is it worth it for the few k that could be
shared?
> The installs are very similar.
>
>> Traditionally, however, i would see it the other way round, booting
>> into a dedicated root and mounting some shared directories.
>>
>> Then i have some questions:
>>
>> /home .... can there still be differences e.g. in version between x64
>> and x32 ?
>
> Sharing /home sounds perfectly reasonable. Of course if the use has any
> binaries compiled for 64bit they won't run with a 32bit kernel, and
> 32bit programs may require libraries that aren't on a 64bit system.
Not all programs have bitness indiferent ~/.foo files. There were
cases where it broke. People consider them bugs so try and keep
reporting any issues.
As for stuff you compile yourself install a 64bit kernel under i386
too or simply just use the one from amd64. Share /boot.
>> /var/cache/apt/archives ... i can't see any problem here, can you ?
>
> Not sure. Of course anyone that does an apt-get clean after an upgrade,
> won't have anything in there anyhow.
>
>> /usr/share .... a relatively huge peice - but will apt refuse to manage
>> (mainly, to deinstall) stuff that was updated by the 'other debian' ?
>> (Would at least /usr/share/doc be safe ?)
>
> I don't think dpkg will like that idea at all.
/usr/share/doc is not allowed to contain anything needed to run
packages and afaik free for you to clean up. It should be save to
share /usr/share from the programs point of view if you keep both
installs in sync, that's why it is called share. Dpkg should also work
out fine with files disapearing by the other installation. But
maintainer scripts might die horribly when they call scripts from
/usr/share during upgrades that suddenly are there no more or behave
differently.
I don't think the space saved is worth the risk.
766M /usr/share
What harddisk do you have that this is a big deal?
>> /usr/scr .... i will have several source trees from kernel.org or
>> debian, and i've no problem with backups of different .configs, so
>> basically this should work...?
>
> Your sources you can do whatever you want. Since dpkg does install some
> things to /usr/src, it is not a good place to keep your own sources.
> Pick a better location (like /home for example).
>
>> I think i can share swap (with an additional hibernation swap for each
>> debian.)
>
> I don't know if the swap format is identical between architectures. You
> would have to find that out first.
Size limitations differ for certain but if you keep it small enough
for i386 that should work. If they differ then you need a mkswap
during boot.
>> I discarded the idea to share /tmp, don't want to fix the size.
>> I also think i will use tmpfs.
>
> /tmp is often better done as tmpfs in ram anyhow.
MfG
Goswin
Reply to: