On Thu, 18 Feb 2010 01:04:15 +0100 Thomas Bächler wrote:

Am 18.02.2010 00:13, schrieb Aaron Griffin:

...

There is a report on it, but I don't know it offhand. The current idea I had was that we simply do all the massaging in the archiso hooks. That is, we create one CD with two different base images and two kernels. The menu items would indicate i686 or x86_64 kernels, and would choose the right aufs image for that architecture.

Yes, this effectively doubles the size of these CDs, but I'm not too sure I want to ship the dual arch CDs regularly. What do you guys think?

For FrOSCon 2009, I created the CD by hand: I took initramfs images from both CDs (removed the legacy-ide one because space wasn't enough) and all squashfs images, manipulated isomounts and grub manually. I didn't need to modify anything but isomounts and grub for it to work!

I also find it better to keep as much the same and only differentiate where necessary (on a "higher level") the more stuff that both arches can share, the better.

We should put -any packages into a separate squashfs to save some space, although I suspect with the addition of the lts kernel to core, it won't fit anymore.

Either way, this approach should be more space efficient then Aarons proposal, right? Dieter

Am 18.02.2010 18:58, schrieb Aaron Griffin:

...

Either way, this approach should be more space efficient then Aarons proposal, right?

Well... there's always the option of changing the kernel, but only use the 32bit userspace. I mean, all we really want is the installed system to vary, not the live one.

I somehow dislike the idea. However, there's no technical reason not to do it: 1) 32 Bit pacman can install 64 Bit packages. 2) All post_install is done in chrooted with the 64 Bit userspace. 3) It also works as a rescue CD, as chrooting into a 64 Bit environment is always possible as long as a 64 Bit kernel is running. We could/should even make it possible to select (if a 64 Bit kernel was booted, which can be checked with uname -m) if we want to install a 32 or 64 Bit target system (we would have to generate the pacman config on the fly, should be easy). That would leave us with: - kernel x86_64 - initrd x86_64 - kernel i686 - initrd i686 - packages core-any - packages core-i686 - packages core-x86_64 - squashfs base system i686 - maybe overlay-any So we save squashfs base system x86_64.

On Thu, Feb 18, 2010 at 2:04 PM, Dan McGee wrote:

On Thu, Feb 18, 2010 at 1:14 PM, Thomas Bächler wrote:

...

That would leave us with: - kernel x86_64 - initrd x86_64 - kernel i686 - initrd i686 - packages core-any - packages core-i686 - packages core-x86_64 - squashfs base system i686 - maybe overlay-any

All 3 of the "packages" things can go in one big directory anyway- the filenames are all unique since we put the architecture in the package filenames. That would make the mounting process a lot less complex as nothing would need to change between what kernel, processor, etc. you are booting up on or want to install. Only the installer would care.

Eh, maybe not. We'd have two "core.db.tar.gz" files that'd overlap. It's doable, just a little more hairy than it seems. Something like core-i686.db.tar.gz and core-x86_64.db.tar.gz would need [core-*] sections in the pacman.conf

On Thu, 18 Feb 2010 14:57:02 -0600 Dan McGee wrote:

Looking at it another way, just throw all the above in a single directory, and leave the "repo" bare with just the DB only. Use the single directory as a package cache and it will work (and should never actually have to download any packages). This also keeps the FTP install from needing to download packages that are on the CD. I'm sure we do something similar but this does reduce the complexity again.

-Dan

nice trick/hack. no catches? is this completely transparent? when installing packages, it won't try do copy packages to some other dir (and hence user more space after all) because the source is "only a cache" ? Dieter

On 02/18/2010 08:34 PM, Thomas Bächler wrote:

Am 18.02.2010 21:04, schrieb Dan McGee:

...

On Thu, Feb 18, 2010 at 1:14 PM, Thomas Bächler wrote:

...

That would leave us with: - kernel x86_64 - initrd x86_64 - kernel i686 - initrd i686 - packages core-any - packages core-i686 - packages core-x86_64 - squashfs base system i686 - maybe overlay-any

All 3 of the "packages" things can go in one big directory anyway- the filenames are all unique since we put the architecture in the package filenames. That would make the mounting process a lot less complex as nothing would need to change between what kernel, processor, etc. you are booting up on or want to install. Only the installer would care.

I would create all those as squashfs images. After that, we can put them together for different ISOs, like core-i686, core-x86_64, core-any, netinstall-i686, netinstall-x86_64 - all by just modifying the isomounts file and (not) putting the appropriate squashfs images to the disc, no other remastering necessary.

sounds good, but.... booting x86_64 kernel with i686 userspace, kernel modules are invalid, so maybe, should also add squashfs with only kernel modules, /lib/modules, whn booting x86_64 For overlay any, yes, but pacman.conf need to be parsed at startup, (current pacman does not support $arch in .conf). Since overlay is just 8KB, is not a space issue, can have for both archs with each pacman.conf. Another point, maybe can have a script that launch /sbin/init with linux32 wrapper, and using init=/the/script at kernel command line. -- Gerardo Exequiel Pozzi ( djgera ) http://www.djgera.com.ar KeyID: 0x1B8C330D Key fingerprint = 0CAA D5D4 CD85 4434 A219 76ED 39AB 221B 1B8C 330D

On Thu, Feb 18, 2010 at 9:25 PM, Gerardo Exequiel Pozzi wrote:

On 02/18/2010 09:09 PM, Gerardo Exequiel Pozzi wrote:

...

On 02/18/2010 08:34 PM, Thomas Bächler wrote:

...

Am 18.02.2010 21:04, schrieb Dan McGee:

...

On Thu, Feb 18, 2010 at 1:14 PM, Thomas Bächler  wrote:

...

That would leave us with: - kernel x86_64 - initrd x86_64 - kernel i686 - initrd i686 - packages core-any - packages core-i686 - packages core-x86_64 - squashfs base system i686 - maybe overlay-any

All 3 of the "packages" things can go in one big directory anyway- the filenames are all unique since we put the architecture in the package filenames. That would make the mounting process a lot less complex as nothing would need to change between what kernel, processor, etc. you are booting up on or want to install. Only the installer would care.

I would create all those as squashfs images. After that, we can put them together for different ISOs, like core-i686, core-x86_64, core-any, netinstall-i686, netinstall-x86_64 - all by just modifying the isomounts file and (not) putting the appropriate squashfs images to the disc, no other remastering necessary.

sounds good, but.... booting x86_64 kernel with i686 userspace, kernel modules are invalid, so maybe, should also add squashfs with only kernel modules, /lib/modules, whn booting x86_64

For overlay any, yes, but pacman.conf need to be parsed at startup, (current pacman does not support $arch in .conf). Since overlay is just 8KB, is not a space issue, can have for both archs with each pacman.conf.

Another point, maybe can have a script that launch /sbin/init with linux32 wrapper, and using init=/the/script at kernel command line.

Maybe can go all in one CD 700MB CD

*.any packages in core-pkg are just about 4MB not much.

One interesting thing: doing a comparation of /usr/share between two root-images shows that:

usr/share/{man,info,doc,kbd} differs, but only because files are gz, or ps or html. usr/share/groff/*/font/*/DESC in i686 default paper is A4 in x86_64 is letter.

From currents isos: 9.4M    i686/boot (unused here: System26.map is about 1M) 211M   i686/core-pkgs.sqfs 143M   i686/root-image.sqfs 9.9M    x86_64/boot (unused here: System26.map is about 1M) 224M   x86_64/core-pkgs.sqfs 152M   x86_64/root-image.sqfs

10+212+144+11+225+153 = 755M

90M     work/iso/root-image.sqfs (i686) (no usr/share) 99M     work/iso/root-image.sqfs (x86_64) (no usr/share) 54M     work/iso/usrshare.sqfs

10+212+91+11+225+100+55 = 704 (ouch!)

But removing (if not fit), manpages/infopages/docs (and not all are necessary to remove), will fit perfectly. ;)

mkarchiso originally removed all the docs and info pages, IIRC. We removed that at some point, though

Am 19.02.2010 01:09, schrieb Gerardo Exequiel Pozzi:

Another point, maybe can have a script that launch /sbin/init with linux32 wrapper, and using init=/the/script at kernel command line.

There's no need to do that, unless you want to build the kernel.

On Fri, 19 Feb 2010 00:34:57 +0100 Thomas Bächler wrote:

Am 18.02.2010 21:04, schrieb Dan McGee:

...

On Thu, Feb 18, 2010 at 1:14 PM, Thomas Bächler wrote:

...

That would leave us with: - kernel x86_64 - initrd x86_64 - kernel i686 - initrd i686 - packages core-any - packages core-i686 - packages core-x86_64 - squashfs base system i686 - maybe overlay-any

All 3 of the "packages" things can go in one big directory anyway- the filenames are all unique since we put the architecture in the package filenames. That would make the mounting process a lot less complex as nothing would need to change between what kernel, processor, etc. you are booting up on or want to install. Only the installer would care.

I would create all those as squashfs images. After that, we can put them together for different ISOs, like core-i686, core-x86_64, core-any, netinstall-i686, netinstall-x86_64 - all by just modifying the isomounts file and (not) putting the appropriate squashfs images to the disc, no other remastering necessary.

hmm. you lost me. why would we want this? isn't the point of creating dual arch images that you do not need separate arch-specific iso's anymore? also, to solve the ".db.tar.gz" overlap problem, isn't it possible with aufs to mount multiple folders over each other and define a preference in case filenames collide so that you get the correct .db.tar.gz? Dieter

Am Fri, 19 Feb 2010 09:23:06 +0100 schrieb Dieter Plaetinck :

hmm. you lost me. why would we want this? isn't the point of creating dual arch images that you do not need separate arch-specific iso's anymore?

When reading this thread for a while I'm asking myself, what's wrong with the separate arch-specific iso's. I mean the user has to choose which arch he wants to install anyway. Are arch-specific iso's not more KISS? Greetings, Heiko

Am Fri, 19 Feb 2010 12:14:00 +0100 schrieb Sven-Hendrik Haase :

Having devices in my home of which only some are x86_64 capable, it definitely comes in handy to have a dual-arch CD instead of two separate CDs. In my eyes this keeps it simpler than juggling between multiple images and CDs. Also it gets simpler for the user on the download site as well as for the mirrors. Therefore, while the content of the images gets less simple, the user experience itself becomes simpler (as in improved) which is a win in my book.

I, too, have to install Arch on both architectures but I hadn't had a problem with having two CDs. I rather find it easier. This way I know what arch I get when I choose the CD and don't need to care about the arch during installation. I also have to help people with installing Arch by telephone. This way I can send them the CD they need for their arch and have one important source of trouble less. And as Thomas has written, people who only need one arch "WILL (probably) complain about download size". i686 is, btw. only for older CPUs. As far as I know nowadays - since several years - only 64 bit CPUs are produced. At least that's what my computer dealer said. Greetings, Heiko

Am Fri, 19 Feb 2010 13:11:44 +0100 schrieb Thomas Bächler :

No matter what we decide, generating the Dual-Arch CD is needed. So far, we always had to create these manually when we needed them: http://dev.archlinux.org/~thomas/cds_froscon/cd0809.jpg

Well, I wanted to come to FrOSCon but couldn't yet. So I didn't know these CDs. ;-)

There lots of Atom CPUs out there without 64 bit support. Also the Core Solo/Core Duo Laptop CPUs had no 64 bit (but now that I think about it, that was 2006).

I don't know much about the Atoms but the Core Solo/Core Duo are nowadays 64 bit as my computer dealer told me. That was what I asked him about. Or let me put it like this: I told him as a matter of course something about Single Core CPUs being 32 bit. He only looked at me aghast and told me that every CPU manufacturer only produces 64 bit CPUs since years. As far as I remember he told me, that it was indeed about 2005 or 2006 when the CPU manufacturers stopped producing 32 bit CPUs. Greetings, Heiko

Am Fri, 19 Feb 2010 14:03:27 +0100 schrieb Pierre Schmitz :

Am Freitag, 19. Februar 2010 13:49:06 schrieb Heiko Baums:

...

as my computer dealer told me

Your dealer obviously has no idea what he is talking about.

I doubt that, but I can't verify it. He usually has a quite good knowledge. Greetings, Heiko

Am 19.02.2010 13:49, schrieb Heiko Baums:

I don't know much about the Atoms but the Core Solo/Core Duo are nowadays 64 bit as my computer dealer told me. That was what I asked him about. Or let me put it like this: I told him as a matter of course something about Single Core CPUs being 32 bit. He only looked at me aghast and told me that every CPU manufacturer only produces 64 bit CPUs since years. As far as I remember he told me, that it was indeed about 2005 or 2006 when the CPU manufacturers stopped producing 32 bit CPUs.

The Core CPU was introduced in 2005 and disappeared quickly after the introduction of the first mobile version of the Core 2 in fall 2006 (all dates from memory, no guarantee). Also, the Core 2 was never produced as a "Solo" variant. But I am pretty sure that the Atom is still manufactured as a 32 Bit CPU, at least some models.

Am Fri, 19 Feb 2010 13:11:44 +0100 schrieb Thomas Bächler :

There lots of Atom CPUs out there without 64 bit support. Also the Core Solo/Core Duo Laptop CPUs had no 64 bit (but now that I think about it, that was 2006).

Regarding the Atoms I just found this German article: http://www.pcwelt.de/intel_virtualnotebook/cpu/technik_trends/154029/intel_a... "Der x86-Prozessor beherrscht auch gängigen Funktionen wie die Befehlssatz-Erweiterung SSE3, unterstützt 32- und 64-Bit-Betriebssysteme und -Programme sowie die Virtualisierung in Hardware." And these specifications from Intel: http://ark.intel.com/Product.aspx?id=35641 "Instruction Set 64-bit" And here's a thread about Ubuntu on Atoms at linuxquestions.org: http://www.linuxquestions.org/questions/linux-hardware-18/intel-atom-330-ubu... So also at least the newer Atoms seem to be 64 bit CPUs. But I can't verify this. Greetings, Heiko