Arch Linux

+1 from me. What kinds of things could we do to support this? It seems like if we dropped two completely seperate roots on the CD with their respective packages, and then picked the right one at bootup to mount in our unionfs, we could do this. Of course, that is probably oversimplifying the issue.

Wow, I didn't even know you *could* do such a thing. Or do you just mean a single 686 cd that also has x86_64 packages

Naw, we could put 2 kernels on the CD and setup different images so that we have both systems on there. It's totally doable and a good idea. But it'd make the ISOs double in size

That shouldn't matter as long as it fit the size of a 650/700MB CD-R.

Any progress here?

Ah, deadline 08-01. Hmmm.

Let me mark this one down and try to pump something out before next monday.

Simo, Dan, do you know if all your installer changes are pushed to gerolde?

Thomas, could you look into releasing a new initscripts package to help me out here?

Hi, is there anything new? Froscon is near and the ISOs must be somewhat tested and burned and labled.

Anything what i could test or help?

Jipppiiieeee!

Pierre ans i have the beast!
Currently we have a functionally archlinux-2008.08-ftp-multiarch.iso ISO, with 2.6.26.
It boots on i686 and on x86_64.

With the archiso skripts and tool this is sooo easy ;-)
We test and talk a little more, then we could explain what we have done (Pierre have to do this, his english is even better <g>)

I'm very exited... And the core iso should'nt be a stopper....

I upload an archive with the necassary files. So you could have a look over it and maybe test it.
A readme is in the archive.
This way work here to get multi-arch core and ftp iso's.

Hints and so on are very welcome!
You could reach me at gerbra at jabber.archlinux dot de

The multi-arch iso could/should be tested, please have a look:
http://users.archlinux.de/~pierre/tmp/archlinux-2008.08-core-multi.iso

Hint: there is sometimes a general problem with the installer when using low RAM (256MB) and choose
not to save installed/selected packages during package selection/installation.
The ramdisk with / runs out of space. I think we will found a solution on this.
It's related to last comments in http://bugs.archlinux.org/task/8155

I have imported Gerhard's scripts into a git repo. I added a workaround to avoid the problem with the installer mentioned above. See: http://git.archlinux.de/cgit.cgi?r=archiso-froscon

I just finished uploading an RC of the iso at http://downloads.archlinux.de/iso/2008.08-froscon-rc/

Please report any problems. I think I'll create a new one tomorrow with fixed openssl and ca-certificates. If there aren't any more problems left I'll burn them at tuesday or wednesday.

Did you use the 2008.06 release of the installer or the last version at :
http://code.neotuli.net/gitweb/?p=installer.git;a=shortlog;h=refs/heads/working
?

As Aaron mentioned, these changes were not pushed to gerolde, but they should fix the "ramdisk running out of space" issue properly, without workarounds.

We use the 2008.06 installer from core, yes. In a chat with simo he mentioned that the whole git is not usefull for production.
I think we compare the solution from the git version with our changes on current installer, but i think the result is both the same.

We are on a little pressure with time to burn the cd's, so for now i think our multi-arch iso is functionable, maybe only for
this event. In the future we could discuss if we maybe offer such a multi-arch iso/img in addition to the normal isos.
The needed changes on scripts, hooks and build procedure a few (result from the good base concept of archlive/archiso!), so maybe we could benefit all from our work.

The current archiso code supports loading squashfs images built for different architectures, which covers most bases. Now we just need a good system to build these images

Is it much work to get this working on the short term? We were planning this for the next release, but I think pretty much everyone agrees this would be nice to have asap. (eg for 2009.08)

Have you looked into using FatELF? (http://icculus.org/fatelf/)

FatELF is a dead project

I made a script that "join" both archiso .iso images. There are profiles, for removing some files or split some directories from .sqfs images. Running with 'full' profile result in a image of 654MB, with three boot options: i686, x86_64 and x86_64 kernel with i686 userspace.

http://github.com/djgera/archiso2dual

This is pretty nice. Do you think we should incorporate it into the archiso codebase?

Thanks. I think, yes. You can directly merge in a separate directory "archiso2dual" along with "archiso" and "configs". Or if you prefer, I can merge inside "archiso", modify Makefile, and configs files can be installed on "/usr/share/archiso/archiso2dual". Finally can do a git pull from my repo.

Done. The installation is separated from main archiso.

http://github.com/djgera/archiso/tree/djgera

archiso2dual script is now merged in archiso. Only left: decide what combination of .isos available for download:

total 1.9G
631M archlinux-2010.03.19-core-dual.iso
353M archlinux-2010.03.19-core-i686.iso
374M archlinux-2010.03.19-core-x86_64.iso
225M archlinux-2010.03.19-netinstall-dual.iso
156M archlinux-2010.03.19-netinstall-i686.iso
165M archlinux-2010.03.19-netinstall-x86_64.iso

Generated by: archiso2dual -T full -3 archlinux-2010.03.19-core-i686.iso -6 archlinux-2010.03.19-core-x86_64.iso -o archlinux-2010.03.19-core-dual.iso -y
Based on pxe_nbd branch  FS#12619 .

Thanks Gerardo. the script ran nicely, but i still need to test images/inspect the source code a bit.
http://mailman.archlinux.org/pipermail/arch-releng/2010-April/000949.html

gerardo, i have a hard time figuring out exactly how the script works and what it strips.
what is removed when using -T full? and what are the things we could keep (assuming a hard limit of 700MB ?) is it possible to share the same man pages for both arches?
right now the core dual image is 577.0M, netinstall 228.0M. this can be a bit more :)

Hi

* Option -T full removes /boot /usr/include /usr/src /usr/share/doc /usr/share/info /usr/share/man (see doc ###)
* Is posible (like now) share all /usr/share for both arches, there is no difference beetwen two archs, at least on packages that are installed.
* If I remember good, you can keep all files in the .iso and iso sizes still below 700MB barrier. This is done using -T split_lm thats only split /usr/share from / making it shareable for both archs, and split /lib/modules, making posible booting a x86_64 kernel with i686 userspace.

### (please let me know is this is not clear)
* basic: join both images, no changes in *.sqfs
* split_us: 'basic' + split usr/share/
* split_lm: 'split_us' + split lib/modules/
* purge_us: 'split_us' + prune usr/share/{doc,info,man}/
* full: 'purge_us' + prune boot/ usr/include/ usr/src/

I think that will be better if:
* both "split_us" and "split_lm" are joined in one "split" option.
* removing directories in more flexible way, rather than in fixed "profiles".

OK I pushed the changes: (join the split* options) [#1] and (make purge step more flexible) [#2]. Code is now a bit small [#3] ;)

Just use -T split, core iso will be below 700MB ;)

[#1] http://github.com/djgera/archiso/commit/de4c11c56c90aec834212cf6ad17ee86389dcb48
[#2] http://github.com/djgera/archiso/commit/180d9b1cc539f15cb9afd5a6d95f144219e40f1c
[#3] http://github.com/djgera/archiso/blob/djgera/archiso2dual/archiso2dual

thanks. the code is now a bit more understandable :)

*I think much of my confusion stems from the usage of the word "split", this feature in fact unifies (merges, combines, deduplicates, ..) two directories, so that both arches use the same directory.
maybe you should use the word 'merge' instead of 'split'.
* $isomounts_file always contains all possible mounts, which may or may not exist depending on which profile the user runs? (ie libmodules.sqfs may not exist)
* if we use -T split, you can run a 64bit kernel in a 64bit userspace right? what exactly does 'split /lib/modules/' (or merge /lib/modules) imply? what are the consequences for the system? does this mean that the 64bit kernel will use 32bit modules? is that ok? does that even work? I'm ok with the feature to boot a 64bit kernel with 32bit userspace, but only as bonus. it should always be possible to boot a fully 64bit environment.

good :)

* or maybe simply call "levels"
0 -> Just merge both iso. No changes made to root-image.sqfs.
1 -> Merge both iso files. The file root-image.sqfs is modified (usr/share and lib/modules paths moved to separate .sqfs files for each path)
2 -> like level 1, plus remove listed paths on removefiles.lst

* isomounts files always contains all posible files. Since archiso hook ignores inexistent images. Doing this is safe and there is no warning ;)
* you can run all posible kernel/user schemes (32/32, 64/64, 64/32) in all profiles. In "basic" and only on it, 64/32 scheme boot, but modules at root-image.sqfs does not work because are from 32 bits. Also remember that not all ioctls32 are wrapped on 64 bits.
And yes, booting a 64/32 is a "bonus" or "just for fun". Maybe this should be clarified at syslinux menu as "experimental".

Also note that move 32 bits modules from root-image.sqfs to a separate .sqfs, is irrelevant. This is done only for keep simetry between both root-images.sqfs.

So, if i understand correctly, for split/full, booting 64/32 does not even work at all? why not? does the kernel abort when it can't find 64bit modules, or something?
I believe users reported that 64/32 works, although they get the aufs problem, but other then that the image should work. but maybe i heard that wrong. i have no 64bit myself so i can't check.

In those cases (split, full?) where 64/32 does not work at all, we should remove the entry from the menu.
In those cases where it works mostly we should add something like "experimental, no kernel modules" to the menu entry.

>> So, if i understand correctly, for split/full, booting 64/32 does not even work at all? why not? does the kernel abort when it can't find 64bit modules, or something?
* because 64 bits modules needed to boot are on initramfs image, so system always boot.

>> I believe users reported that 64/32 works, although they get the aufs problem, but other then that the image should work. but maybe i heard that wrong. i have no 64bit myself so i can't check.
* Thats is different, is not related to modules. Is that not all ioctls32 are wrapped on 64 bits. In that case can be safetly ignored, because the remount command always does nothing in live enviroment.

>> In those cases (split, full?) where 64/32 does not work at all, we should remove the entry from the menu.
>> In those cases where it works mostly we should add something like "experimental, no kernel modules" to the menu entry.
* This depends on what you want to do on live enviroment, 64/32 scheme always works on all "basic/split/full" profiles:
+ If you need to load another 64 bit module, that is not loaded at initramfs step => basic profile is not for you.
+ If you need some specific ioctl32 => split/full is not for you.

So 64/32 is always "experimental" on all cases. Keep it documented on wiki why this is marked as experimental.

* Current dual image sizes (basic/split/full):

664M archlinux-2010.04.24-core-dual.iso
610M archlinux-2010.04.24-core-dual.iso
572M archlinux-2010.04.24-core-dual.iso

326M archlinux-2010.04.24-netinstall-dual.iso
272M archlinux-2010.04.24-netinstall-dual.iso
234M archlinux-2010.04.24-netinstall-dual.iso

Why doing all this strip voodoo at all? If we can put all files on an iso which is less than 700MB we are fine.

We should also forget about tis 64bit kernel and 32bit user space. This is not and will never be supported in Arch and may cause strange problems. (e.g. we use uname -m = user space arch in several scripts; and o idea what happens if you try to install pacakges within the live system or try to compile a driver etc.)

Sure, strip voodoo was necessary before packages in .xz format. But at this moment is suficient with a simple merge (-T basic).

(1) so remove K64/U32 from syslinux menu and make with a simple merge without touching root-image in oficial .iso?
(2) if (1) is true, then remove unused code[*] from archiso2dual to keep it simple?

[*] Unused code: "uncompress .sqfs", "delete files", "split files", "make .sqfs".

* okay, if we don't/can't support 64/32 then we should remove it from our isos. although i think the code can remain in archiso2dual, we just shouldn't use it for the official releases.

* merging /usr/share seems still useful to me, nothing wrong with some free space gains. but probably the folders are not 100% the same right now (or in the future), so maybe we should not strip it.

* the directory removing code in the full profile seems useful to have, although we won't use it for official media.

so for the official media, we just use -T basic. But the archiso2dual code can stay mostly the same. (just remove the 64/32 entry from isolinux menu and maybe put a README or other file in there that says you can do it with that menu entry)

Gerardo, you say: "If you need to load another 64 bit module, that is not loaded at initramfs step => basic profile is not for you."
is that a typo? I thought with the basic profile you have the full unmodified root filesystem, including the right modules etc. so it should work perfectly.

OK.
Nope, is not a typo, booting with 64/32 scheme (-T basic) is: boot 64 bit kernel + 64 bit initramfs (64 bit modules) + 32 bit root-image (32 bit modules) => modules incompatible with kernel.

Conclusion/TODO:
1) Remove 64/32 option from syslinux menu + isomounts.x86_64-i686 => can merge both isomounts in one file (me, working now)
2) Merge my git branch in master (Aaron)
3) Create dual isos with -T basic that is the default (Dieter)

* Remove support for booting 64 bit kernel with 32 userspace
* Use one isomounts file for both architectures

thanks for all your work Gerardo, the code is now really nice and simple. and works fine. closing this ticket.